The eBusiness standards come in different flavors based on vertical industry, horizontal industry, proprietary, non-proprietary and so on. Most commonly used across the enterprises are EDI, ebXML, RosettaNet, UCCNet, FIX, HL7, SWIFT and HIPAA. These standards have their own proprietary messaging standards and some provides XML equivalent. In this section, we describe briefly how an enterprise built on Java and XML technology can accomplish business to business integration with trading partners who follow these eBusiness standards. For more detailed specification of each standard, refer the specification standard provided by the respective standards organization. Since these standards has been continuously evolving with the advancement of technology, it is very important for the readers to check the latest specification the respective standards.
1)HL7(Health Level 7)
Health Level 7 (HL7) is a specification standard designed to facilitate the data exchange among computer systems in the health care industry. Interoperability among the disparate computer systems such as Electronic Medical Record (EMR) systems, Laboratory Information (LIS) systems, Patient Administration Systems (PAS), Pharmacy Management Systems (PMS) and Electronic Practice Management (EPM) systems. The message model of HL7 has undergone considerable change since the release of version 3.0 and later versions. In the traditional HL7, prior to version 3.0, the message model is ASCII based segmented model. Since version 3.0, Reference Information Model (RIM) became the basis of development process. Version 3.0 supports XML based messaging structure. However, all the versions are backward compatible.
In the segmented Model, each HL7 message is comprised of segments which are delimited by carriage return characters (“\r”). Hence each new line in the HL7 message is a separate segment and each segment has its own semantic meaning. Each segment consists of composites which are delimited by pipes (“|). Each composite consists of fields which are delimited by carets (“^”). Fields within fields (sub-sub fields) are delimited by ampersand (“&”). Repeating fields are separated by tilde (“~”) character. The message structure of segmented model and an example are shown below.
Figure 1: Message structure of HL7
MSH^~ VALSYSVALCLINWIR19990802091524VXU^0400000124P2.3ALPID6678223LK729DOE^JANEDOE^MARY19980413FRXA09991999012319990123^^^90700^DTaP^CPT0.5VALCLIN
Figure 2: HL7 message
The multiplicity constraint for HL7 segment grammar notations are represented using different types of brackets. A segment without bracket means that segment must be present as in segment 1 shown in figure 1. (exactly one). A segment with a square bracket implies an optional segment as in segment 2 (i.e. [] means zero or one occurrence, which, is equivalent to “?” in XML DTD notation). A segment with a curly bracket implies the segment must be present one or more times as in segment 3 (i.e. {} means one or more occurrence, which is equivalent to “+” in XML DTD notation). A segment with both a curly bracket and square bracket implies the segment must be present zero or more times as in segment “n” (i.e. [{}] or {[]} means zero or more occurrence, which is equivalent to “*” in XML DTD notation).
The Reference Information Model is UML (Unified Modeling Language) based pictorial representation of clinical data objects and the state machine (for life cycle) for the messages of each domain. The RIM is an object oriented architecture with a shared model among all the domains in which each domain is responsible for creating the messages. With the advent of XML technology, HL7 specification created Clinical Document Architecture (CDA), which define an XML based architecture for clinical document exchange. The HL7 version 3 supports XML DTD based encoding. The root element of the CDA document release 1.0 is level one. This root element consists of two child containers, clinical document header (header) and body. The header element has four logical child containers: Document information, encounter data, service provider and service targets. The body element of the CDA document contains either one or more section elements or a single non-xml element which refer to an external file that provides the content of the body of the document. Within section element, information content is represented in paragraph, list or table containers. The structure of such a CDA document is shown in figure 3.
Figure 3: The structure of CDA document.
The semantics of the DTD are derived from RIM and domain vocabularies. The CDA document is embedded in a MIME document before sending the HL7 message to the trading partners. The CDA document is base64 encoded in the MIME document. Any clinical images are also bas64 encoded as MIME attachments. For more details about MIME, refer section 2.3. Prior to version 3.0, the CDA document is exchanged in the OBX segment as an encapsulated data type (ED) as shown in figure 4. In version 3, the MIME message is embedded in the Service.txt element within a user defined element.HL7 is a messaging format which can be sent over a transport protocol with de facto standard is TCP/IP point to point exchange. However, other protocols can be used such as FTP, SMTP and HTTP(S). B2B integration between trading partners exchanging HL7 messages using J2EE technology is described below.
Figure 4: HL7 message prior to version 3.0 with embedded CDA message
2) HIPAA (Health Insurance Portability and Accountability Act): The Health Insurance Portability and Accountability Act of 1996 is to improve the portability and continuity of health insurance coverage in the group and individual markets, to simplify the administration of health insurance and to mitigate waste, fraud and abuse in health insurance and health care delivery. The HIPAA also has provisions to address the security and privacy of health care data. The objectives of these standards are to improve the efficiency and effectiveness of the
health care system by the use of EDI. The key EDI based HIPAA transactions envisaged are,
a) 270,271 : Eligibility benefit enquiry request and response,
b) 276,277 : Claim status enquiry request and response,
c) 278 : Health service review request and response,
d) 820 : Sending payment order and remittance advice,
e) 834 : Sending benefit enrollment and maintenance,
f) 835 : Electronic remittance of claim payment,
g) 837 : Health care claims of institutional, professional, and dental types.
The HIPAA implementation incorporates the standalone or the encapsulation of HL7 Clinical Document Architecture (CDA) in the BIN (Binary Data Segment) of the EDI for the above transactions as shown in figure 5. For more information about the HL7 CDA, refer section 1.
Figure 5: Structure of HL7 CDA document embedded in a EDI message.
A typical health care transaction flow involving a provider and payer using HIPAA transactions are shown in figure 6.
Figure 6: Health care transaction flow.
Process Flow:
1) The provider sends a health care claim request to the payer. The claim can be either standalone 837 or attachment of additional information 275 with HL7 CDA embedded in it.
2) Payer sends back a functional acknowledgement 997
3) If the additional information 275 was not sent with the claim as described in 1, or the information 275 was not sufficient, payer may request for additional information 277.
4) The provider responds to the request for additional information by sending the 277 transaction containing HL7 message to the payer.
5) When the payer completes the adjudication process, it sends the health care claim remittance transaction 835 to the provider.
B2B integration architecture between trading partners exchanging HIPAA transactions using EDI messages with J2EE technology is described below.
3) HL7 (Health Level 7) Architecture
A general description of HL7 protocol and usage is described in section 1. This section shows how two trading partners exchange HL7 message between them. The trading partner sends a request HL7 message (inbound) to the enterprise which process the message and creates a HL7 response message (outbound) and sends back to the trading partner. The application layer protocol used is HTTPS. Since the HL7 protocol does not specify the security, it is the responsibility of the trading partners to implement transport level and message level security. The inbound and outbound message flow are shown in 7 and 8 respectively.
Process Flow:
a) The trading partner creates a HL7 message and sends to the enterprise.
b) The request is intercepted at the DMZ of the enterprise. The request is authenticated against a security system (see chapter 18 on security for more details) either using basic authentication or certificate based mutual authentication.
c) If the request is authenticated, HL7 document is sent to the integration server. If not, a HTTP error message is sent back to the trading partner in the same connection. Integration server checks the syntax of the inbound HL7 document and creates an Acknowledgement and sends back to the trading partner. This is to notify the trading partner that the HL7 document is received.
Figure 7: HL7 based B2B integration with J2EE – inbound HL7 message.
Figure 8: HL7 based B2B integration with J2EE – outbound HL7 message.
d) If the message is based on traditional HL7 message, the HL7 message processor maps the inbound HL7 message to a canonical flat file schema (at design time). At run time, the inbound HL7 message is mapped to the XML instance and sent to the down stream application. If the message is based on XML, the HL7 message processor extracts the XML message from the inbound HL7 message (in MIME format) and maps to a canonical XML and sends the XML instance to the downstream applications.
e) Once the downstream application completes the business process, it creates a response XML message and maps to the HL7 response message and sends to the trading partner.
4) HIPAA (Health Insurance Portability and Accountability Act) Architecture
Trading partners such as providers and payers exchanges HIPAA transactions using EDI messages are described in this section. The payer’s enterprise system is assumed to be built on J2EE platform. HIPAA transaction is a message based protocol. The client (in this example, the provider) may use HTTP(S), FTP, EDIINT AS1 or EDIINT AS2 as the transport protocol. The inbound and outbound HIPAA transaction flow is shown in figure 9 and 10 respectively.
Figure 9: HIPAA request transaction with J2EE – inbound EDI message.
Process Flow:
a) The trading partner (for example, the Provider) creates an EDI message with HIPAA request transaction and sends to the enterprise over HTTP (for example, the Payer).
b) The request may be intercepted at the DMZ of the enterprise. The request is authenticated against a security system (see chapter 18 on security for more details) either using basic authentication or certificate based mutual authentication.
c) If the request is authenticated, EDI message is sent to the integration server. If not, a HTTP error message is sent back to the trading partner in the same connection. Integration server checks the syntax of the inbound EDI message and creates an 997 Functional Acknowledgement and sends back to the trading partner. This is to notify the trading partner that the EDI message is received.
d) The EDI message processor maps the inbound EDI message to a canonical flat file schema (at design time). At run time, the inbound EDI message is mapped to the XML instance and sent to the down stream application. If the EDI message contains HL7 CDA documents, the EDI message processor extracts the XML message from the inbound HL7 message and maps to a canonical XML and sends the XML instance to the downstream applications.
e) Once the downstream application completes the business process, it creates a response XML message and maps to the EDI response message and sends to the trading partner (HIPAA response transaction).
Figure 10: HIPAA response transaction with J2EE – outbound EDI message.
__________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this document is to be used or reproduced without the written consent from the author (roychettan@gmail.com).
No comments:
Post a Comment