Typically health care providers will have patients who are customers of many different insurance companies. When a provider sends out billing information it has to send it in various formats as expected from the different companies. In some cases it goes even beyond data formatting. For example the billing code for a medical procedure could be different across multiple insurance companies. This forces providers to customize billing for each individual insurance company, which in turn increases the operating expenses. In cases like auto accidents where multiple insurance companies can be involved, the hospital personnel have to get involved via phone or email to resolve the billing disputes. We can begin to see that there is a huge resource drain for providers to manage transaction processing with insurance companies.
The solutions for this problem could be: 1) to standardize the billing and other information sharing between providers and insurance companies, and 2) to execute transactions electronically without manual intervention.
Based on this approach, the Unites States passed into law the Health Insurance Portability and Accountability Act of 1996 (HIPAA), which mandates standardization of transfer of health information. This standardization uses the format called Electronic Data Interchange (EDI).
The EDI based standards are not exclusive to healthcare industry and they have been used effectively by various industries for a many years. For example, Wal-Mart uses EDI standards to exchange information with suppliers to manage their supply chain.
What is EDI?
To understand EDI, let us see what we are trying to achieve with EDI. Essentially, we are trying to exchange healthcare related information (billing, eligibility, etc.) electronically between two different parties say a hospital and insurance company. The exchange happens via files typically in a very controlled manner such as secure FTP (STFP). The files need to be exchanged reliably and easily. Moreover the file needs to be in the format both systems can understand and both systems can extract information accurately.
So what does EDI mean in a broad sense?
1) EDI as a file: EDI is a standard file format for handling data, in the same way XML can be thought of as another standard file format. The EDI format is created long before the modern Internet and availability of fast computers; hence the EDI format is in human readable ASCII characters and is very efficient taking less bandwidth during transmission.
2) EDI as a data structure: EDI file has data, organized in a structured way as defined in the standard. The organization is logical and easy to follow. The EDI standard is designed to replace paper based transaction (like invoices) for computers, so the mapping data to EDI is relatively easy.
3) EDI as a business communication: Another way to look at EDI is as a way for business conversation. The same way the emails are used between two parties to exchange information for business purpose; two systems can exchange information for business purpose using EDI formatted files. In relation to the health care industry, any health care related information (enrolling to insurance, asking for eligibility, billing, payment, resolving billing involving multiple insurances etc.) can be queried and answered in EDI formatted files. Huge volumes of information for thousands of patients can be exchanged electronically using EDI formatted files, making EDI very efficient and cost effective way of doing business.
EDI Standards for Healthcare Industry
The EDI standard describes how the data is going to be formatted. To be useful, the data related to the particular industry needs to be defined for a specific functional purpose of that industry. This is why there are various health care specific EDI standards defined to address specific needs for health care. For example, the data needed for billing will be different than data needed for an eligibility inquiry, hence two separate data standards for them. The standards not only describe the data types, but also detail the various states the system might be in during data exchange. The standard also describes what data fields are mandatory and which are optional based on the state. In summary, the standards are comprehensive and have complete information necessary to implement them.
Here is the list of EDI standards for health cares and their purposes.
1. EDI Health Care Claim Transaction Set (EDI 837): This is used to submit billing information for the services provided to patients. The billing information can be sent from providers to payers directly or indirectly via intermediary billers and clearing houses. There are two standards related to EDI 837 with some variation. One is used by providers (i.e. doctors, dentists, etc.) named EDI 837 Professional (EDI 837P) and other is used by institutions (i.e. hospitals, nursing home, etc.) named EDI 837 Institutional (EDI 837I).
2. EDI Health Care Claim Payment/Advice Transaction Set (EDI 835): This is used to make a payment in response to billing with EDI 837. This standard is also used when there is correction needs to be made in the billing (called Explanation of Benefits (EOB) remittance advice) or when there are multiple insurance companies involved and there needs to be EOB sent among them.
3. EDI Benefit Enrolment and Maintenance Set (EDI 834): This is used to by employers to enroll members to the payers such as insurance companies and government agencies (i.e. Medicaid, Medicare, etc.).
4. EDI Health Care Eligibility/Benefit Inquiry Set (EDI 270): This is used to inquire about the healthcare benefits and eligibility. For example, before doing some procedures a provider can inquire about the policy coverage with the insurance company using this standard.
5. EDI Health Care Eligibility/Benefit Response Set (EDI 271): This is used in response to request inquire about health care benefits and eligibility with EDI 270. Some of the information provided might be benefit status, dependent coverage level, dates of coverage, co-pays, deductibles, exclusions, and limitations.
6. EDI Health Care Claim Status Request Set (EDI 276): After sending billing claims with EDI 837 and while waiting for payment with EDI 835, if a provider wants to inquire about the status of the billing claim, this transaction set is used. For example, a hospital can have policy to initiate an automated request for status of claims after certain date of sending the claim and receive the status information back electronically.
7. EDI Health Care Service Review Information Set (EDI 278): This transaction set is used to send healthcare service information such as subscriber, patient, demographic, diagnosis or treatment data for the purpose of request for review, certification, notification or reporting the outcome of a healthcare services review. For example, if a hospital needs to get referral for a patient or wants to send information for review by other doctors or insurance company, this transaction set can be used.
8. EDI Functional Acknowledgement Transaction Set (EDI 997): When you send email to somebody requesting some action which may take some time typically you will like to get acknowledgment of the email. For example “I have received it and working on it”, or “the request is not valid” or “I need following more information to process.”
In the similar way this transaction set is used to acknowledge of receipt of any EDI request. Typically after claim billing files (EDI 837) are sent to a payer’s system some level of validation takes place for format and required fields. The result of this validation will be sent back to the sender in the form of this transaction set (EDI 997), informing whether the file is accepted or not, if there is any information missing in the file, or if the file needs to be resent with some modification.
Here is an example of how the EDI files will be exchanged.
EDI Format
Now we will look into detail of EDI format. Before that let us look at a sample EDI file. Note that all characters are ASCII based, and there are lot of ‘*’ and ‘~’ characters, the meaning of which we be explained later. Also there is no Line Feed (LF character 0x0A) or Carriage Return (CR character 0x0D) characters present in the file, even though it appears so in printed format shown below. In fact, it is continuous stream of characters without LF or CR in actual practice.
ISA*00* *00* *ZZ*133052274 *00*SHPCHIP *201105*1532*U*00401*000001645*0*P*:~
GS*HP*133052274*SHPCHIP*20110505*1532*1646*X*004010X091A1~
ST*835*1234~
BPR*C*150000*C*ACH*CTX*01*9999992*DA*123456*1512345678**01*99988880*DA*98765*19960913~
TRN*1*12345*1512345678~
DTM*405*19960916~
N1*PR*INSURANCE COMPANY OF TIMBUCKTU~
N3*1 MAIN STREET~
N4*TIMBUCKTU*AK*89111~
REF*2U*999~
N1*PE*CYBIL MENTAL HOSPITAL*XX*6543210903~
LX*961211~
TS3*6543210903*11*19961231*1*211366.97*138018.4***138018.4**73348.57~
TS2*2178.45*1919.71**56.82*197.69*4.23~
CLP*666123*1*211366.97*138018.4**MA*1999999444444*11*1~
CAS*CO*A2*73348.57~
NM1*QC*1*SHEPARD*SAM*O***HN*666666666A~
MIA*0***138018.4~
DTM*232*19960816~
DTM*233*19960824~
QTY*CA*8~
LX*961213~
TS3*6543210909*13*19961231*1*15000*15000***11980.33**3019.67~
CLP*777777*1*15000*11980.33**MB*1999999444445*13*1~
CAS*CO*A2*3019.67~
NM1*QC*1*BORDEN*LIZ*E***HN*996669999B~
MOA***MA02~
DTM*232*19960512~
PLB*6543210903*19961231*CV:CP*-1.27~
SE*28*1234~
GE*1*1646~
IEA*1*000001645~
EDI Basics
These are the basic concepts behind EDI format.
1) Segment: Essentially an EDI file is nothing but a collection of segments, the same way a paragraph is a collection of sentences. As a sentence conveys single meaningful complete information, a segment describes single information with way of data values.
These are 3 segments taken from EDI 835 sample above, which is conveying information about the payer and its address. The 1st segment gives information about insurance name, the 2nd the street name, and 3rd is city, state and zip code.
N1*PR*INSURANCE COMPANY OF TIMBUCKTU~
N3*1 MAIN STREET~
N4*TIMBUCKTU*AK*89111~
Note that actually there is no carriage return (CR, character 0x0D) or Line Feed ( LF, character 0x0A). It is continuous stream of ASCII characters with a delimiter, typically ‘~’ character, which separates one segment from other.
N1*PR*INSURANCE COMPANY OF TIMBUCKTU~N3*1 MAIN STREET~N4*TIMBUCKTU*AK*89111~
2) Element: The data values in each segments are called elements, which are typically delimited by ‘*’ character.
Delimiters
In fact, there are 3 kinds of delimiters in EDI: segment delimiter, element delimiter and sub-element delimiter. Any characters can be used as delimiters. And they are defined in very first segment in an EDI file (ISA segment). Note that it means that the EDI parser can learn about the delimiter only after it starts reading an EDI file. The question comes is how can the parser know where to delimit in the very first time? Well, EDI solves this problem by making the very first ISA segment is of fixed length of 106 characters, with 104th (element), 105th (sub-element) and 106th (segment) as delimiters. The other segments after that are of variable length. The delimiters are chosen such that they are not the part of any data values; otherwise the EDI parser will fail. In healthcare related EDI standards, segment delimiter is ‘~’, element delimiter is ‘*’ and sub-element delimiter is ‘:’
ISA*00* *00* *ZZ*133052274 *00*SHPCHIP *201105*1532*U*00401*000001645*0*P*:~
The segments are identified with first 2 or 3 characters. The subsequent elements are mentioned as
In this example, the segment describes the city, state and zip code information.
N4*TIMBUCKTU*AK*89111~
N401 = TIMBUCKTU
N402 = AK
N403 = 89111
In some cases, the elements in the segment are situational and the values are not needed to be sent. When it happens, you will see multiple element delimiters one after another bunched together (**), as in example shown below.
NM1*QC*1*SHEPARD*SAM*O***HN*666666666A~
3) Envelope
A typical EDI file will look like, as shown below, with ISA, GS and ST as first 3 segments, and SE, GE and IEA as last 3 segments.
ISA
GS
ST
(data contents here)
SE
GE
IEA
ISA*00* *00* *ZZ*133052274 *00*SHPCHIP *201105*1532*U*00401*000001645*0*P*:~
GS*HP*133052274*SHPCHIP*20110505*1532*1646*X*004010X091A1~
ST*835*1234~
…
…
…
SE*28*1234~
GE*1*1646~
IEA*1*000001645~
The first segment is always ISA and last segment is IEA, making it ISA-IEA envelope or pair. Similarly there are GS-GE envelope and ST-SE envelope. Enveloping is the way EDI ensures file integrity and lets the message determine its destination and type.
The ISA - IEA envelope is called the interchange envelope which contents for the envelope and its content. Note the matching controller number (000001645) in both ISA and IEA segments, in example above. The IEA01 (with value 1) indicates how many GE-GS pair is inside IEA-ISA pair. When implementing, pay attention to ISA05 (Interchange ID Qualifier for sender), ISA06 (Interchange Sender ID), ISA07 (Interchange ID Qualifier for receiver) and ISA08 (Interchange Receiver ID).
The GS segment is the second enveloping segment. It shares some properties with the ISA segment. There is a sender and receiver, version Identifier, time stamp and control number. But one thing that the GS has that the ISA does not is a Functional Identifier (GS01). Also note the matching controller number (1646) in GS-GE envelope and GE01 is 1 indicating there is only one ST-SE pair. GE01 value will change based on how many ST-SE pairs are present.
ST-SE is another mandatory envelope that describes document identifier (Is it 834 or 837 etc.) and control number. The SE01 is segment counter within ST-SE. In the example above, it is saying that there are 28 segments within ST-SE pair. All health care related standards describe detail of ST-SE and segments within that envelope. The actual meat of data information for a particular standard resides inside ST-SE envelope.
If interchange IDs and functional IDs are same for both senders and receivers, it is possible to send multiple ST-SE envelopes, as shown below.
ISA
GS
ST
(data contents here)
SE
ST
(data contents here)
SE
GE
IEA
It is also possible to have multiple GS-GE envelopes within single ISA envelope. But in practice, due to the limit on the file size the system can handle, we will see only one ISA-IEA envelope, one GS-GE envelope. Sometimes we will see multiple ST-SE, but not as often. If possible it is good idea to avoid multiple ST-SE envelopes.
In the future, I will describe details on each health care related EDI standards EDI 837, EDI 835 etc. Describing those standards means describing details on segments within ST-SE envelope.
