In the last post, I wrote about the overall structure of 837P claim messages. 837I and 837D messages have similar structures, though with some differences – for example, the 837I has many more diagnosis code options, and the 837D has more specific nodes for tooth identification, etc. One important thing to note is that 837P, 837I, and 837D files are very similar, but not the same. It’s not enough to simply change the version numbers in the GS and ST segments and then try to process one the same as the other! If it were that easy, we wouldn’t need separate schemas for them in BizTalk!
BizTalk provides out of the box functionality to support these message types, with well developed functionality to translate the X12 EDI to XML and vice versa. The schema nodes also have friendly names, translating something like this:
... <MM1_SubscriberName> <NM101_EntityIdentifierCode>IL</NM1_EntityIdentifierCode> <NM102_EntityTypeQualifier>1</NM1_EntityTypeQualifier> <NM103_SubscriberLastName>Field</NM1_SubscirberLastName> ... etc.
There are a few things to take note of here:
- BizTalk will not allow completely invalid EDI to be transformed to XML.
- The schemas avoid reuse of the same node name, even if it’s used in a different context.
- BizTalk will not automatically populate qualifiers, even if there’s only one possible value and it’s required.
Invalid EDI and BizTalk
To point 1, this is both a strength and a weakness. It’s a weakness if your trading partner(s) occasionally (or always!) send X12 data that is formally invalid (missing required segments, non-standard qualifier use, etc.). However, it’s also a strength because you don’t want that bad data in your system anyway! There are three methods to deal with bad X12 coming in:
- Refuse to accept it. Let your trading partner know in a 999 or 277CA that the claim has been rejected because it’s invalid.
- Correct it before trying to convert it to XML. At Tallan, we’ve written custom components for clients to do field replacements, check for and/or remove duplicate fields, etc. before the data hits the EDI to XML engine in BizTalk.
- Create a custom version of the EDI schema that will validate against the document.
Number 1 is like a teacher who refuses to grade a paper until gross errors are corrected by the student: this teacher won’t be popular, but the students will learn a lot (if they do the work). The drawback is that your trading partners not be able to do that work, for whatever reason, and your business may not be in a position to compel them to do so.
Number 2 and 3 both have the advantage of requiring less from a trading partner, but the disadvantage of changing the message coming from your partner. This is like the teacher who accepts the major errors and just gives the student a so-so grade. The danger is that trading partners may become more and more lax, or that the claim data you’re correcting is corrected using bad assumptions. However, this option may be necessary if you and a trading partner have a non-standard usage of the X12 file that you both adhere to.
Of options 2 and 3, 2 is preferable as it is more flexible ad requires less delving into the internals of the BizTalk EDI engine; some schema modifications could work, but some might break the pipeline’s ability to serialize the raw X12 to XML.
Node naming in EDI Schemas
The BizTalk schemas give unique names to record nodes. When a claim loop shows up under the 2000B loop (a claim for a subscriber who is a patient), it will be in the TS837_2300_Loop node. If it shows up under the 2000C loop, it will be in the TS837_2300_Loop1 node. Similarly, subloops are postfixed (such as NM1_SubLoop, NM1_SubLoop_2, NM1_SubLoop_3, etc.) This offers the advantage of easily and quickly identifying whether a fragment of XML came from one loop or another; it also can give you an idea of how many times that loop occurred elsewhere in the document. However, the numbers can be confusing, and mean that designing Maps or writing XSLT for the schemas will have to take those XPaths into account. There’s no easy way to select the claim number regardless of whether this file is for a patient or a subscriber – you will have to specify the XPaths (or source links in the Mapper) for both if you need both.
BizTalk does not automatically populate qualifiers when constructing or mapping a message. It’s important that you map the qualifiers. This makes sense – in many cases different qualifiers are possible, for example D8 would specify a CCYYMMDD date in a DTP segment, whereas RD8 would specify that the DTP segment is a CCYYMMDD-CCYYMMDD format. EI would specify that an identifier is a Federal Tax ID, where as SN would specify that it is a social security number.
BizTalk does offer some help on this – qualifier fields that only accept certain values will have an enumeration on the node specifying that.
This is very helpful when trying to figure out what value to put in a NM101 field, or a DTP01 field. In the XML fragment above, the NM101 qualifier ‘IL’ specifies that this is the NM1 segment for a Subscriber Name – and that would be the qualifier you’d find in the BizTalk schema designer. To get the full specification of all allowed qualifiers and their meanings, you’d have to look at the WPC consolidated guide for the 837 claim you’re working with; these are not freely available, but certainly worth the purchase if you’ll be working with EDI exensively. BizTalk will, however, give you at least a hint about what values are valid – and frequently their meanings can be inferred.
In the end, a BizTalk developer will have to work with an EDI specialist when attempting to construct a file. However, BizTalk drastically reduces the time it takes to do so by ensuring structural integrity and providing many hints and helps when a file is invalid. This means that the EDI analyst and the BizTalk developer can be more focused on meeting business needs than worrying about structural validity.
Finally, I highly recommend this post from Senthil Muthiah – it’s not BizTalk specific, but it does provide some more details on some of the more commonly used segments of the 837P: