Tallan's Technology Blog

Tallan's Top Technologists Share Their Thoughts on Today's Technology Challenges

Working with HIPAA Professional Claim (837P) messages in BizTalk (Part 1)

Dan Field

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 should give an integration developer enough to make a good go at understanding the data.  I’ll focus on Professional claims, but much of this post would also apply to Institutional and Dental claims; and in this post, we’ll be starting closer to the raw EDI data.

The 837P is a Professional Claim file.  It is what a doctors office or similar entity would send your insurance company to describe what doctors saw you, what diagnoses and procedures were made, and how much was charged.  Like other EDI transactions, it’s organized into “loops” and “segments,” and has certain identifiers to indicate what kind of transaction it is.

To identify an 837P, you’d look to the GS08, ST01, and ST03 values.  Here is a sample of the first three lines of an 837P file with those fields in bold:

ISA*00* *00* *ZZ*SenderParty *ZZ*ReceiverParty *131212*0703*^*00501*201334690*0*P*:~
GS*HC*999999*999999*20151112*0703*2013690*X*005010X222A1~
ST*837*20110*005010X222A1~

ST01 tells us this is an 837 claim file; GS08 and ST03 specify what kind it is.  As you can see, GS08 and ST03 should match each other.  The valid values for an 837P (5010 version) are 00501X222, 00501X222A1, and 005010X222A2; the “A” number specifies which errata version of the transaction is being used. In BizTalk, only the ST segment will be left in the schema – the GS and ISA values are promoted into the message context.

A BHT segment indicates the beginning of the transaction, mainly with some fixed values.

Then we have what BizTalk will call the 1000A and B loops.  This contains the submitter and receiver information, including names, addresses, contact information, and identifiers.  The submitter is the group or organization sending the claim, the receiver is the entity receiving it.

Next is the 2000A loop.  This contains information about the billing provider: name, IDs, contact information, and so on.  It is possible to have multiple billing providers in the same claim file, and the file represents the beginning of the 2000A loop with an HL segment like so:

HL*1**20*1~

HL01 says which HL segment this is in the file (the first will always be a 2000A).  HL02 is like a foreign key to HL01  – since the 2000A has no parent, it’s empty here.  HL03 says what kind of loop (20 is for 2000A), and HL04 says whether this loop has any child HL segments (2000As always do).  When generating claim files, it’s important to get these values right; each successive HL segment in the file should increment from its parent, and the key relationships between segments must be respected.

The 2000B loop, which contains Subscriber (insurance holder) information, will have a similar HL segment:

HL*2*1*22*0~

This HL segment is saying: I am the second HL segment in the file, my parent is #1, I’m a 2000B loop, and I have no HL children.  A 2000B loop will have a 2000C child if the subscriber is not the patient; for example: my child is a patient and I am the insurance holder; my information is found in the 2000B segment, and my child’s information would be found in the 2000C segment.  The 2000B loop has an important segment that really determines whether or not the patient and subscriber at the same person: the SBR segment

SBR*P*18*******CI~

SBR01 is saying whether this is the primary insurance (or S for secondary, T for tertiary, etc).  SBR02 says the subscriber is the patient when it’s 18; it’s left blank otherwise, and a different code is used to indicate patient/subscriber relationships.  SBR09 is a claim filing indicator code, here indicating commercial insurance usage.  Checking whether SBR02 = 18 is a safe way to determine where you’ll find the claim and service information.

Under the 2000B  (or 2000C for non-subscriber patients), there will be 2300 (Claim) and 2400 (Service Line) loops.  The claim loops will describe diagnoses, what doctor(s) saw the patient in what capacity, what facility(ies) the patient was at, how much the claim is for, a claim ID, and so on.  They always start with a CLM segment, which has an ID (CLM01), total amount (CLM02), information about what kind of service/loctaion (CLM05), and other information about patient and physician consent:

CLM*54321*250***12:B:1*Y*A*Y*Y~

Service lines are used to break down individual services, and give more details if other doctors/providers were involved.  They start with an LX segment that increments sequentially for each service line:

LX*1~

So if I go to my doctor’s office and have an exam, blood work, and some other procedure that toal $250, that $250 would be in the claim line.  In the service lines, there’d be a break down ($75 for blood work, $75 for another procedure, $100 for the exam).  Those service lines would indicate whether my primary doctor or some other doctor did various procedures, and also provided code information indicating what procedures were run.  If it was actually a visit for my child, all of that information would come under a 2000C loop instead.

Some common segements you’ll see in these loops are:

NM1: Contains name and ID information.

  • NM101 will tell you what kind of NM loop (more on that next post).
  • NM102 will specify whether this is a person (1) or business (2).
  • NM103 will be a last or organization name
  • NM104 will be a first name
  • NM105 will be a middle initial/name
  • NM106 will be a prefix
  • NM107 will be a suffix
  • NM108 will be an ID qualifier (for example, ‘EI’ for federal tax ID; more next post)
  • NM109 will be the ID

N3 and N4: Address information

  • N301: Street 1
  • N302: Street 2
  • N401: City
  • N402: State
  • N403: Zip

DMG segments contain demographic information

  • DMG01: Date qualifier
  • DMG02: Date of birth
  • DMG03: Gender code

PER Segments contain contact information (telephone, fax, email, etc.)

REF segments contain a qualifier that specifies what kind of REF (REF01) and usually a numerical ID based on the qualifier.

HI segments contain diagnosis information specific to a qualifier.

SV1/2 segments contain service line specific information.

DTP segments contian an identifier, a date qualifier, and a date or timespan describing some part of an event.

Next post: Using the BizTalk EDI schemas to simplify and explain these mysterious qualifiers!

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>