Is Immunotherapy - The Future of Cancer Treatment?

Potential of Precision Mdecine

What Lies ahead in Health Care Sector 2016

Health Care Lessions

EDI Basics

What is an EDI ?

EDI X12 (Electronic Data Interchange) is data format based on ASC X12 standards. It is used to exchange specific data between two or more trading partners. Term ‘trading partner’ may represent organization, group of organizations or some other entity. In most cases it is just organization or company.

EDI X12 is governed by standards released by ASC X12 (The Accredited Standards Committee). Each release contains set of message types like invoice, purchase order, health care claim, etc. Each message type has specific number assigned to it instead of name. For example: an invoice is 810, purchase order is 850 and health care claim is 837.

Every new release contains new version number. Version number examples: 4010, 4020, 4030, 5010, 5030, 6010, etc. Major releases
start with new first number. For example: 4010 is one of the major releases, so is 5010. However 4020 is minor release. Minor releases contain minor changes or improvements over major releases. At the time of this writing 5010 is most widely used release.

How EDI Works

Doctor diagnosis the patient and provide the treatment for the identified disease. Billing Team prepare the bill(claim) and the claim is transmitted into an EDI Document format called as 837 Health care claim. Then the EDI 837 Document securely transmitted to the insurance company via clearing house.
Then the Insurance company processes the claim which comes in the electronic format and provide the necessary reimbursement for the provider for the treatment given to the patient.
Why You Need EDI – the Benefits

• Lower costs
• Higher efficiency
• Improved accuracy
• Enhanced security
• Greater management information

Please read more on this excellent blog

Processing EDI Files in Java

Excellent Video on EDI Processing:

In Java there many library available to process large EDI file especially EDI Health Care transaction related files. One particular Library really stands out is smooks.

Lets Say :

We have to transform huge EDI files into single data sets (XML). Huge means up to 700K ‘data sets’ which is a file size of 250MB. Each file has a global header and n data groups. Each data group has global (on their) level information as well and n data sets. The file structure looks like this:

file |-- header [1] |-- data group [0 - *] | |-- header [1] | |-- data sets [0 - *]

These are the issues:
- transform the EDI into XML
- get the global and parent information into each data set
- split the file into n data sets
- export the data sets to file system or JMS (in this sample we will use file export)

The problem is the size of the file. We can’t transform it inside the RAM but we have to use something like data stream in and data stream out. Here comes smooks into game. Smooks is a library for transforming files. One possible combination is EDI in and XML out (check out the smooks page for more options and samples). To face our issues smooks gives us a rich toolset:
- transform the EDI into XML with a simple mapping language
- get the global and parent information into each data set is easy with mixing dom and sax
- split the file into n data sets can be done by freemarker in combination with dom/sax support
- export the data sets to file system or JMS (in this sample we will use file export) via one of the export cartridges

Camel Code Snippet:

from(“file://target/in?noop=true”)
.process(
new Processor() {
public void process(Exchange exchange) throws XMLStreamException, TransformerException {
Message in = exchange.getIn();
StreamSource source = exchange.getContext().getTypeConverter().tryConvertTo(StreamSource.class, exchange, in.getBody());
if (source != null) {
in.setBody(source);
}
}
})
.log(“starting splitting…”)
.to(“smooks://src/main/resources/file-config.xml”);

from(“file://target/out?delete=true”)
.to(“log:smooks?level=INFO&groupSize=1000″)
.setBody(constant(“”))
.to(“mock:out”);

Please read the complete blog here

EDI Transaction Set and Gateway In Health Care

EDI File Structure

EDI Transaction Set in Health Care

Transaction	Number	Business use
Claim/encounter	X12 837	For submitting claim to health plan, insurer, or other payer
Eligibility inquiry and response	X12 270 and 271	For inquiring of a health plan the status of a patient.s eligibility for benefits and details regarding the types of services covered, and for receiving information in response from the health plan or payer.
Claim status inquiry and response	X12 276 and 277	For inquiring about and monitoring outstanding claims (where is the claim? Why haven.t you paid us?) and for receiving information in response from the health plan or payer. Claims status codes are now standardized for all payers.
Referrals and prior authorizations	X12 278	For obtaining referrals and authorizations accurately and quickly, and for receiving prior authorization responses from the payer or utilization management organization (UMO) used by a payer.
Health care payment and remittance advice	X12 835	For replacing paper EOB/EOPs and explaining all adjustment data from payers. Also, permits auto-posting of payments to accounts receivable system.
Health claims attachments (proposed)	X12 275	For sending detailed clinical information in support of claims, in response to payment denials, and other similar uses.

EDI Gateway

Health Care Technology Standard 101

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.

Excellent blog in learning Health Care Standard

Plase click here for more details


Some Good Video Tutorials:
1


2

3


4

5

Oracle B2B HL7 Demo - click here

HL7 - Click Here