Tuesday, April 10, 2012

HealthIT Standards 101: The EDI Standards


This is the second in a Series I’m calling HealthIT Standards 101.  In this post, I’ll discuss the EDI standards used in Healthcare IT.  A quick disclaimer here:  I'm not much of an EDI standards geek outside the HL7 space.  While I know HL7 very well, I have only read NCPDP and X12 specifications.

Electronic Data Interchange Standards in Healthcare IT
There are a number of standards used in healthcare that work similarly and are based on Electronic Data Interchange standards.  These standards are designed to be independent of the communication technology, and simply describe the syntax and format of communications in terms of the text characters used to represent the information.

A unit of communication is described as a transaction or a message depending on which standard you are reading.  I’ll use the term message in this post to describe both.  There are two EDI standards from which these standards originate:  UN/EDIFACT, and X12.  The NCPDP Script standard used for ePrescribing in the US still retains its EDIFACT origins and syntax.  HL7 Version 2 messages used for a variety of Healthcare integration works very similarly to the EDIFACT standard (in fact, you can use a similar processor for both HL7 and NCPDP standards).  HL7 messages don’t follow the EDIFACT syntax rules for message headers or escaping special characters.

These EDI based messages begin with a header identifying the kind of message being sent.  That header is followed by a number of components called segments.  These are provided in the sequence specified by the message specification.  Each segment is further divided into fields, which contain a value using a data type specified by the standard.  Messages, segments and fields are delimited by special characters which vary depending upon the standard.  In some cases, fields can be further subdivided into components and subcomponents.  A single segment or groups of segments can repeat (these are called loops in the X12 world), allowing complex structures to be communicated.

The X12 EDI format was developed by ASC X12 (Accredited Standards Committee X12), and primarily serves US industry.  The X12N Insurance subcommittee of X12 develops the standards that are used for health insurance transactions in the US.

HL7 Version 2

An example HL7 Version 2 message follows
EVN|A01|198808181123||<cr>
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M||C|
  1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|
  (919)271-3434||S||PATID12345001^2^M10^ADT1^AN^A|123456789|987654^NC|<cr>
NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>

HL7 created the first release of HL7 Version 2 was created more than 20 years ago (in 1989), and addressed just a few message types.  Version 2 was an update of the HL7 Version 1.0 standard released in 1987 that harmonized HL7 with the syntax being used in ASTM standards used for similar purposes.  There have been several major and minor releases of the Version 2.0 standard since then.

Commonly implemented messages in the standard include ADT (Admission, Discharge and Transfer) which is used to support those functions in admission and registration systems, practice management integration with EHR systems, and general integration with master patient indexes.

The ORU message supports unsolicited updates and results for various diagnostic testing results (including labs and imaging), and is often used for test reporting in both inpatient and outpatient settings.

When ordering is automated (using CPOE), HL7 provides a number of messages to support ordering of tests (e.g., the OML for laboratory ordering), medication orders (in inpatient settings), and other kinds of orders (e.g., Diet).

While ORU is most commonly used to support reporting of structured results, it can also be used to communicate narrative test results, but was not designed to capture the necessary details to manage the reporting process.  The MDM messages in HL7 Version 2.- provide greater capability to manage test reporting using documents, rather than structured messages.  These are commonly implemented to communicate completed reports to EHR or hospital information systems.

While the ORU is probably the most commonly implemented message for communicating between from outside organizations into a healthcare provider, the HL7 VXU (unsolicited Vaccination Update) is commonly implemented by ambulatory providers to communicate vaccination information out to local and state public health agencies.

The most commonly implemented release of HL7 Version 2.0 is the US is probably HL7 Version 2.3.1, which is one of the options permissible under Meaningful Use Stage 1 (see the section on regulations below).  There are a number of implementation guides that support public health reporting for lab results, immunizations, and syndromic surveillance.  HL7 Version 2.5.1 was also an option for Meaningful Use Stage 2, and is being proposed as the single standard to use for these purposes and for receiving lab results into an EHR in Stage 2.

While Meaningful Use selects HL7 Version 2 for various uses, administrative simplification (HIPAA) regulations in the US require the use of X12 messages for payer (insurance) transactions, and NCPDP messages for ePrescribing (HITECH/Meaningful Use, eRX rules, and HIPAA) and communication with pharmacy benefits managers (PBMs).

NCPDP Script
An example NCPDP Prescription message follows.
UNA:+./*’
UIB+UNOA:Ø++1234567+++77777777:C:PASSWORDA+77Ø163Ø:P+19971ØØ1:Ø81322’
UIH+SCRIPT:ØØ8:ØØ1:NEWRX+11ØØ72+++19971ØØ1:Ø81322’
PVD+P1+77Ø163Ø:D3+++++MAIN STREET PHARMACY++61522Ø5656:TE’
PVD+PC+6666666:ØB+++JONES:MARK++++61522198ØØ:TE’
PTT++19541225+SMITH:MARY+F+333445555:SY’
DRU+P:CALAN SR 24ØMG::::24Ø:ME+EA:6Ø:38+:1 TID -TAKE ONE TABLET TWO TIMES A
DAY UNTIL GONE+85:19971ØØ1:1Ø2*ZDS:3Ø:8Ø4+Ø+R:1’
UIT+11ØØ72+6’
UIZ++1’

NCPDP Script was first created in 1997 to support communication of prescription information between providers, pharmacies, payers and intermediaries.  NCPDP Script uses the UN/EDIFACT syntax for EDI communications, and defines messages for (not a complete list):

·        Communicating new prescriptions (NEWRX)
·        Receiving notification of filled prescriptions (RXFIL)
·        Requesting a Refill (REFREQ/REFRES)
·        Changing a Prescription (RXCHG/CHGRES)
·        Cancelling a Prescription (CANRX/CANRES)
·        Requesting and Receiving Medication Histories (RXHREQ/RXHRES)

The two most significant version of NCPDP Script for US use are Version 8.1 completed in 2005, and version 10.6 completed in 2008.  The former was required under HIPAA, one or the other is required for Meaningful Use certification and under ePrescribing regulation.  The latest version of Meaningful Use standards proposes the use of version 10.6 only.

X12
An example X12 message follows.
ST*276*0001~
BHT*0010*13**19961115~
HL*1*20*1~
NM1*PR*2*ABC INSURANCE*****PI*12345~
HL*2*1*21*1~
NM1*41*2*XYZ SERVICE*****46*X67E~
HL*3*2*19*1~
NM1*1P*2*HOME HOSPITAL*****SV*987666~
HL*4*3*22*0~
DMG*D8*19201210*M~
NM1*QC*1*SMITH*FRED****MI*123456789A~
TRN*1*1625032606~
REF*BLT*111~
AMT*T3*8513.88~
DTP*232*RD8*19960831-19960906~
HL*5*3*22*0~
DMG*D8*19201115*F~
NM1*QC*1*JONES*MARY****MI*234567890A~
TRN*1*1622241518~
AMT*T3*7599~
DTP*232*RD8*19960731-19960809~
HL*6*2*19*1~
NM1*1P*2*HOME HOSPITAL*****SV*124567890~
HL*7*6*22*1~
DMG*D8*19451101*M~
NM1*IL*1*MANN*JOHN****MI*345678901~
HL*8*7*23~
DMG*D8*19651101*M~
NM1*QC*1*MANN*JOSEPH****MI*345678901-02~
TRN*1*16270853402~
REF*1K*961681010827~
REF*BLT*131~
AMT*T3*4899.5~
SE*34*0001~

X12 was chartered by ANSI as an Accredited Standards Developer more than three decades ago.  They are (along with HL7 and NCPDP) one of six Designated Standards Maintenance Organizations for maintaining standards used with HIPAA transactions.  The Insurance Subcommittee (X12N) of X12 is responsible for development of EDI standards used in the Insurance industry, and develops the transactions used in Healthcare.

There are two principal versions of X12 which are significant in Healthcare.  The 4010 series was allowed to be used from the inception of HIPAA up until January 2012, and was to be replaced by the 5010 series.  Due to implementation delays, CMS announced an enforcement delay until June of 2012.

There are a number of different kinds of transactions which use the X12 transactions.  Some of the more significant include:

Transaction  Description
837              Claims
835              Claim Payment Notification
275/277       Claims Attachments Request/Response
276/277       Claims Status Request/Response
270/271       Eligibility Request/Response
278              Referral Authorization

EDI and XML
EDI refers primarily to an older, text delimited syntax popular before XML came to the fore.  The standards listed above all use this older, text-based forms of electronic data interchange.  However, the standards organizations have also developed XML renditions of the EDI standards.  NCPDP created a separate XML implementation guide for NCPDP 8.1.  It now includes the XML Schema in versions since version 10.5 (see the Basic Guide to NCPDP Standards).  HL7 published XML encoding rules for its Version 2 standards in 2003.  While X12 has created XML encodings for some of its standards, I am not familiar with many systems used in Healthcare that do anything with them.

XML formats are often used inside “Interface Engines”.  These are software applications traditionally used to support EDI messaging.  Many Interface Engines are able to switch between the traditional EDI syntax, and either a proprietary XML format, or the standard XML syntax for the same message.  Using an XML syntax inside an interface makes it very easy to transform messages between formats using a variety of XML tools.  The most commonly used tool is XSLT, a W3C standard language defined to enable transformations of XML documents.

While HL7 created an XML Syntax for its Version 2 standards, they created a whole new architecture using XML for their CDA and Version 3 standards, which I’ll talk about next time.

2 comments:

  1. We have a system that receives VXU messages from an HIE using 251. We are the application endpoint. We return an ACK/NACK as is would be expected. However, the HIE is unable to handle the receipt of an Ack and wants us to modify our system to support an aggregate view of the Ack results for their providers. We were 'floored' that they couldn't handle ACK's, being an HIE and are now getting pushback. Is this 'normal' for an HIE. At this point all they are is a dumb pipe to us.

    ReplyDelete
    Replies
    1. What is normal is for some to try to do as little as they can get away with. In this case, I think where you said "a dumb pipe" you might have meant "as dumb as a pipe".

      Delete