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:
Updated: part 2
Application integration is challenging in that it requires a wide breadth of knowledge: server and network architecture, object oriented programming and design patterns, messaging and communication patterns, workflow design, message translation, database design and programming, business rule processing, data validation and quality handling… the list goes on and on. On top of that, it’s important to be familiar with the data you’re working with from various sources and feeds to be able to effectively transform it.
EDI presents a whole host of challenges, and the 837 Professional, Institutional, and Dental transactions are among the most challenging to grapple with. This will be the first in a series covering a high level introduction and overview of the 837 Claim format in the BizTalk HIPAA EDI schemas. It is not quite going to the level of a competent EDI Analyst, but…