HL7 FOR ELECTRONIC DATA EXCHANGE HL7 offers a one-stop shop for all related services of standardization, including testing, certification and implementation help. This cements HL7 as the centre point for development of medical data standards HL7 closely cooperates with several other influential SSOs which increase the credibility of the organization and guarantees adoption HL7 India HL7 India is an independent, non-profit-distributing, membership based organization that exists to encourage the adoption of standards for healthcare information communication within India. HL7 India Affiliate successfully launched the HL7 e-learning course program in March, 2010. Abstract This article contains the specifications for Version 2.4 of the Health Level Seven (HL7) Standard for electronic data exchange in all healthcare environments, with special emphasis on inpatient acute care facilities (i.e., hospitals). This is targeted for audience using HL7 for testing and gives a brief idea about HL7 ADT messages, which are used to validate the messages between the interfaces in the healthcare applications. A. HL7 BACKGROUND Need for HL7 It is critical to understand that each healthcare setting is radically different in terms of business relationships, payment structures, data collected, database structures, and software systems.every hospital, imaging center, outpatient surgery center, clinical lab, doctor s office and physiotherapy center has unique requirements for capturing the patient s data and transaction details. When we multiply each of these health care settings by the number of countries or political settings where care will be delivered, the result is almost an infinite number of unique requirements. It is in this complex system where all the health care settings and users of clinical systems are different that HL7 attempts to establish a single, flexible, worldwide standard for the representation/movement of clinical data. What Is Health Level Seven (HL7)? A common misconception is that HL7 is not a software application. The title HL7 conjures images of a packet of compact discs, manuals, and clever icons. This could not be further from the truth. In reality, the HL7 standard is a book of rules with thousands of pages of detailed interfacing information that sets forth a framework for negotiation in interfacing, giving programmers and analysts a starting point from which to begin their technical discussions.hl7 is a messaging standard that enables clinical applications to exchange data HL7 is an international community of healthcare subject matter experts and information scientists collaborating to create standards for the exchange, management and integration of electronic healthcare information. HL7 promotes the use of such standards within and among healthcare organizations to increase the effectiveness and efficiency of healthcare delivery for the benefit of all. The HL7 community is organized in the form of a global organization (Health Level Seven, Inc.) and country-specific affiliate organizations.
Interesting Facts About 45% of the global membership (of either HL7 Inc. or an HL7 affiliate) is located in Europe, 35% in North America, 15% in Asia- Oceania and 5% elsewhere The HL7 standard is often called the nonstandard standard. While not entirely true, it does reflect that almost every hospital, clinic, imaging center, lab, and care facility is special and, therefore, there is no such thing as a standard business or clinical model for interacting with patients. As of 1998, HL7 had documented several hundred healthcare provider organizations that have implemented computer interfaces based on the HL7 Standard. It is possible for a healthcare provider institution to use HL7 without actually being an HL7 member through a member vendor or through outright purchase of the Standard without joining HL7. Story of birth of HL7 Patients may take it for granted that a RIS, lab information system (LIS), hospital information system (HIS), and electronic medical record (EMR) inherently communicate with one another seamlessly. They may expect information to be sent freely between a hospital and a nearby imaging center or clinical laboratory. However, in many cases, each system speaks its own language. In 1987, in an attempt to begin solving this problem, an international community of healthcare subject matter experts and information scientists collaborated to create the HL7 standard for the exchange, management, and integration of electronic healthcare information, as per the HL7 Web site (www.hl7.org/about). Today, HL7 is a standards developing organization accredited by the American National Standards Institute (ANSI) to author consensus-based standards representing a broad view from healthcare system stakeholders. From a practical standpoint, the HL7 committee has compiled a collection of message formats and related clinical standards that loosely define an ideal presentation of clinical information. Together, the standards provide a framework in which data may be exchanged. Just as programmers utilize the broad capabilities of Java, Visual Basic, C++, and XML to solve their specific needs, HL7 offers a broad messaging standard that can accommodate both large-scale hospital networks and stand-alone diagnostic imaging centers and clinics. The Name "Health Level-7" The name "Health Level-7" is a reference to the seventh "application" layer of the ISO OSI Reference model. The name indicates that HL7 focuses on application layer protocols for the health care domain, independent of lower layers. HL7 effectively considers all lower layers merely as tools. Collaboration HL7 collaborates with other standards development organizations and national and international sanctioning bodies (e.g. ANSI and ISO), in both the healthcare and information infrastructure domains to promote the use of supportive and compatible standards. HL7 collaborates with healthcare information technology users to ensure that HL7 standards meet real-world requirements, and that appropriate standards development efforts are initiated by HL7 to meet emergent requirements. What s in a Name? The name Health Level 7 symbolizes the seven-layer International Standards Organization (ISO) Communications Model: 1. Physical: Connects the entity to the transmission media 2. Data Link: Provides error control between adjacent nodes 3. Network: Routes the information in the network 4. Transport: Provides end-to-end communication control 5. Session: Handles problems that are not communication issues 6. Presentation: Converts the information 7. Application: Provides different services to the applications 2
HL7 EVOLUTION HL7 was created by clinical interface specialists who needed a better method to interface applications instead of costly customized coding. A small number of mostly acute care hospitals and software vendors formed a volunteer group to create a more standard way of building interfaces. They initially defined a loose and largely implied data model of messaging touch points between applications. Their vision to eliminate custom interfaces and radically reduce the cost of interfacing required predefining only 80% of the interface framework up front. This provides the flexibility to address unique special business, clinical, and workflow rules in the remaining 20% of the interface. This practical approach was critical for HL7 s widespread acceptance. Healthcare system interface before HL7 HL7 s prime objective is to simplify the implementation of interfaces between healthcare software applications and various vendors, so as to reduce the pain and cost involved in custom interface programming. What was originally created as an intrahospital communications standard has matured and arguably become the undisputed, defacto model for the entire healthcare industry s data exchange challenges? Before HL7, data exchanges between healthcare systems were performed via customized interfacing systems that required a great deal of programming on the part of the sending and receiving applications. These interfaces were expensive because there was no standard collection of patient attributes or standard set of interesting events. As a result, in the 1980s, the number of clinical interfaces in a typical hospital was small, and the cost per interface was high. The primary challenge of interfacing is that as internal hospital teams and software vendors create new clinical applications, each application is developed without input or collaboration with other application development teams. Commercial development teams rarely share proprietary data on how their applications are built, so it is difficult for other teams to build compatible applications. Users 1. Clinical interface specialists tasked with moving clinical data, creating tools to move such data, or creating clinical applications that need to share or exchange data with other systems: These users are responsible for moving clinical data between applications or healthcare providers. 2. Government or other politically homogeneous entities looking to share data across multiple entities or in future data movement (generally, few legacy systems are present): These users are often looking to move clinical data in a new area not covered by current interfaces and have the ability to adopt or mandate a messaging standard. 3. Medical informatists who work within the field of health informatics, which is the study of the logic of healthcare and how clinical knowledge, is created. These users seek to create or adopt a clinical ontology a sort of hierarchical structure of healthcare knowledge (a data model), terminology (a vocabulary), and workflow (how things get done). More the Users, More the Value The value of the standard is driven by the type of user. For a clinical interface specialist, evaluating the power of any new technology or IT standard requires understanding the network effect. In other words, the standard s value vastly increases as more sites and vendors adopt it. Consider any of the popular de facto standards in use today: TCP, IP, HTTP, HTML, POP, telnet, Windows, or even the (ANSCII) American Standard Code for Information Interchange character set. They are all valuable because the user base has grown to be large, and the standards work in the real world. Similarly, the network effect for HL7 would be effective if many healthcare applications started using it. HL7 is able to satisfy the need that drove its creation: solve 80% of the clinical interfacing problem in a flexible way using a consensus, volunteer-driven process. The focus was on making the standard easy to adopt, so the network effect would occur and create a significant cost savings as quickly as possible. 3
B. HL7 MESSAGING High Level Flow HL7 System HL7 HL7 Standard Standard Universal design Riddled with optionality Implementation chaos Interoperability difficult Test System ADT^A01 Message Profile HL7 Mess age Structure EVN PID NK1NK1NK1NK1 NK1 PV1 PV2 OBX AL1 Agreement Define constraints Message Profile EVN PID NK1NK1NK1NK1NK1 PV1 PV2 OBX AL1 Messaging Workbench Tools to build profiles e.g., MWB (VA) XML representation <?xml version="1.0"?> <HL7v2xConformanceProfile H <MetaData Name="CALINX"Or <Encodings> <Encoding>ER7</Encoding> </Encodings> <DynamicDefAccAck="NE"Ap <HL7MsgType= ADT" EventType= A01 <MetaData Name="CALINX"> <Segment Name="" LongN <Field Name="Field Separator" Us </Field> <Field Name="Encoding Characters" <Reference>2.16.9.2</Reference </Field> <Field Name="Sending Application" Conforms? Test Harness ^~\& REGA EVN A05 199901 PID 1 191919^ NK1 1 MASSIE^E NK1 2 MASSIE^I Message Maker Conformance testing needed Profile based Improves reliability and interoperability Suite of test messages Testing Framework Suitable for conformance testing Tools to build messages Message Maker (NIST) Automated and adaptable Message Definition A message is a collection of data that sends information about an event in the health care enterprise. HL7 is a standard interface format of messages, although it is actually considerably more than that, as we shall see. The ability to use standard formats is useful in many ways. Instead of having to write specifications from scratch each time data needs to be sent between two systems, we can make reference to a uniform document whose definitions assist in providing a common understanding between two systems. Originally developed in 1987, HL7 is now in use in more than twenty countries around the world. Version 2 of HL7 contains message for almost every conceivable healthcare application area, including the following. Registration Orders (Clinical and others) Results and observations Queries Finance Master files and Indexes Document Control Scheduling and logistics Personnel administration Patient care planning Network Synchronization Laboratory automation Unlike other standards, HL7 specifies no restrictions whatever on the protocols to be used in the lower layers of the interface. The definitions in HL7 concentrate on the logical arrangement of data and what is meant by information in various parts of the message. 4
HL7 Structure The physical format of the message that is how the message is actually put together and sent over the wire is up to the implementer. However, HL7 suggests a format, which we call the default encoding, which looks like the following: ^~\& MegaReg UABHospc ImgOrdMgr UABImgCtr 20010529090131-0500 ADT ^ A01 01052901 P 2.3.1 EVN 200105290901 200105290900 PID 56782445^^^UAReg^PI~999855750^^^USSSA^SS KLEINSAMPLE^BARRY^Q^ JR 19620910 M 2028-9^^HL70005^RA99113^^XYZ 260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^H 0105I30001^^^99DEF^AN PV1 I W^389^1^UABH^^^^3 12345^MORGAN^REX^J^^^MD^0010^UAMC^L 67890 ^GRAINGER^LUCY^X^^^MD^0010^L MED a0 13579^POTTER^SHERMAN^T^^^M D^0010^UAMC^L OBX 1 NM ^Body Height 1.80 m^meter^iso+ F OBX 2 NM ^Body Weight 79 Kg^Kilogram^ISO+ F AL1 1 ^ASPIRIN The default encoding is the delimiter-based formatting that is used to illustrate message in HL7 version 2 standards. Each of data lines contains an identifying tag, such as, and some number of data elements that are arranged by position. XML for formatting HL7 messages has been gaining acceptance in recent years. C. SPECIAL HL7 PROTOCOLS There are several extensions to the basic HL7 message protocol. These extensions represent implementation choices, and are to be used on a site-specific and application-specific basis as needed. Sequence number protocol For certain types of data transactions between systems the issue of keeping databases synchronized is critical. An example is an ancillary system such as lab, which needs to know the locations of all inpatients to route stat results correctly. If the lab receives an ADT transaction out of sequence, the census/location information may be incorrect. Although it is true that a simple one-to-one acknowledgment scheme can prevent outof-sequence transactions between any two systems, only the use of sequence numbers can prevent duplicate transactions. Note: Although this sequence number protocol is limited to the use of sequence numbers on a single transaction stream between two applications, this sequencing protocol is sufficiently robust to allow the design of HL7-compatible store-and-forward applications. a) Definitions, initial conditions 1) The system receiving the data stream is expected to store the sequence number of the most recently accepted transaction in a secure fashion before acknowledging that transaction. This stored sequence number allows comparison with the next transaction s sequence number, and the implementation of fault-tolerant restart capabilities. 2) The initiating system keeps a queue of outgoing transactions indexed by the sequence number. The length of this queue must be negotiated as part of the design process for a given link. The minimum length for this queue is one. 3) The sequence number is a positive (non-zero) integer; and it is incremented by one (by the initiating system) for each successive transaction. 5
b) Starting the link 1) The value of 0 (zero) for a sequence number is reserved: it is allowed only when the initiating system (re-)starts the link. 2) if the receiving system gets a transaction with a 0 (zero) in the sequence number field, it should respond with a general acknowledgment message whose MSA contains a sequence number one greater than the sequence number of the last transaction it accepted in the Expected Sequence Number field. If this value does not exist (as on the first startup of a given link), the MSA should contain a sequence number of -1, meaning that the receiving system will use the positive, non-zero sequence number of the first transaction it accepts as its initial sequence number (see resynching the link, item e below). 3) The initiating system then sends the transaction indexed by the expected sequence number (if that expected transaction is still on its queue). Otherwise the link is frozen until an operator intervenes. c) Normal operation of the link: As it accepts each transaction, the receiving system securely stores the sequence number (which agrees with its expected sequence number), and then acknowledges the message by echoing the sequence number in MSA-4-expected sequence number. d) Error conditions w.r.t initiating system These are generated by the receiving system, by its comparison of the sequence number sent out (with the in -13-sequence number) with the expected sequence number (MSA-4-expected sequence number received with the MSA). 1) Expected sequence number is one greater than current value. The previous acknowledgment was lost. That transaction was sent again. Correct by sending next transaction. 2) Expected sequence number less than current value. Initiating system can try starting again by issuing a transaction with a sequence number of zero; or freeze the link for operator intervention. 3) Other errors: freeze the link for operator intervention e) Forcing resynchronization of sequence numbers across the link The value of -1 for a sequence number is reserved: it is allowed only when the initiating system is resynching the link. Thus if the receiving system gets a value of -1 in the sequence number field, it should return a general acknowledgment message with a -1 in the expected sequence number field. The receiving system then resets its sequence number, using the non-zero positive sequence number of the next transaction it accepts. f) Notes When the initiating system sends a message with a sequence number of 0 or -1 (see b or e above), the segments beyond the need not be present in the message, or, if present, all fields can be null. In terms of the responding system, for these two cases, only a General acknowledgment message is needed. 6
Continuation messages and segments Besides the need to continue a message, there are occasional implementation conditions that force the continuation of a segment across messages. Such continued segments require the use of the ADD segment as follows: a) The segment being continued (call it ANY for this example) is ended at an arbitrary character position and terminated with the Standard segment terminator (carriage return). b) The following segment is the ADD segment. When it follows a segment being continued, the ADD segment contains no fields. Whether the message being continued is a response to a query, or an unsolicited update, the receiving system will use the continuation pointer (with the ADD segment) to continue the message. c) When a response (to a query) is continued, the first segment after the QRD and QRF (on a continued query) will be the ADD segment. All the fields after the ADD segment identifier (fields 1-N) will be the continuation of the ANY segment. The receiving system will then use the continuation pointer to join the two parts of the ANY segment and continue processing the message. d) For the continuation of an unsolicited update message, the ADD segment will be the first segment after the segment. The receiving system will use the continuation pointer field in the segment to identify the message being continued, and then use the ADD segment as described in c) to join the two parts of the ANY segment. e) Limitations:, MSA, DSC, PID, QRD, QRF, URD and URS segments cannot be continued. f) Although the UU example given below is for a display message, there is nothing in the protocol to prevent a record-oriented UU from being continued in this fashion. In the unsolicited display message, the ADD record on the continuation comes just after the URD/[URS] pair instead of directly after the. g) Transaction flow for a continued query-response pair with an ADD segment: First query and response QRD [QRF] MSA [ ERR ] QRD [QRF] {DSP} (Last DSP segment is incomplete) ADD (ADD segment contains no fields) DSC Second query and response QRD [QRF] DSC (contains the continuation pointer from the DSC segment of prior response message) MSA [ ERR ] QRD [QRF] ADD (contains the remainder of the last DSP segment of the previous response) {DSP} (Remaining DSP segments are complete) 7
Note: The second response could itself be continued with a second DSC and (if needed) a second ADD segment prior to it. This paradigm also applies to both original mode and enhanced mode queries of display and record oriented types. h) Transaction flow for a continued unsolicited message with a continued segment: First unsolicited message & acknowledgment URD [ URS ] {DSP} (last DSP is incomplete) ADD DSC (contains no fields) (Continuation segment) (General acknowledgment) MSA [ ERR ] Second unsolicited message & acknowledgment (contains continuation pointer from DSC segment of prior message) ADD (contains remainder of data from continued DSP segment from prior message) {DSP} (Note: This second message could itself be continued with a second DSC and (if needed) a second ADD segment prior to it.) (General acknowledgment) MSA [ ERR ] D. HL7 BATCH PROTOCOL There are instances when it is convenient to transfer a batch of HL7 messages. Common examples would be a batch of financial posting detail transactions (DFT s) sent from an ancillary to a financial system. Such a batch could be sent online using a common file transfer protocol, or offline via tape or diskette. HL7 batch file structure The structure of an HL7 batch file is given by the following (using the HL7 abstract message syntax) [FHS] (File header segment) { [BHS] (batch header segment) { [ (zero or more HL7 messages). ] } } [BTS] [FTS] (Batch trailer segment) (File trailer segment) Notes: The sequence numbering protocol has a natural application in batch transfers. See the discussion of batch acknowledgements that follows. Although a batch will usually consist of a single type of message, there is nothing in the definition that restricts a batch to only one message type. The HL7 file and batch header and trailer segments are defined in exactly the same manner as the HL7 message segments. Hence the HL7 message construction rules of Section 2.10 can be used to encode and decode HL7 batch files. 8
There are only two cases in which an HL7 batch file may contain zero HL7 messages: a) A batch containing zero HL7 messages may be sent to meet a requirement for periodic submission of batches when there are no messages to send. b) A batch containing zero negative acknowledgment messages may be sent to indicate that all the HL7 messages contained in the batch being acknowledged are implicitly acknowledged. BHS Batch Header BTS Batch Trailer FHS File Header FTS File Trailer The BTS segment contains a field, BTS-3-batch totals, which may have one or more totals drawn from fields within the individual messages. The method for computing such totals will be determined on a site or application basis unless explicitly stated in a functional chapter. Acknowledging batches In general, the utility of sending batches of data is that the data is accepted all-at-once, with errors processed on an exception basis. However, it is a permissible application of HL7 to acknowledge all messages. Several options for acknowledgment are given and will be chosen on an application basis. In these cases, the sequence numbering protocol can be useful to the applications processing the batch. The options are: a) All messages are acknowledged in the response batch. b) The receiving system prints some form of batch control report, which is then dealt with manually by personnel at the sending system. No acknowledgements are performed by the protocol software. c) An automated acknowledgment batch is created containing acknowledgment messages only for those messages containing errors. In this mode an empty acknowledgment batch may be created (i.e., an HL7 batch file without any HL7 acknowledgment messages). In each case where there is a response batch, its format is a batch of individual messages. Each individual message is in the format defined for an on-line response. Consider, for example, a batch that might be constructed to respond to a batch of Detailed Financial Transactions. The messages in the response batch would consist entirely of ACK messages, since ACK is the responseshown. When batches are retransmitted after the correction of errors, BHS-12-reference batch control ID should contain the batch control ID of the original batch. Batch message as a query response The HL7 query also can be used to query for a batch in the following manner: a) Use the value BB or BL of QRD-5-deferred response type to specify a batch response. The query will be acknowledged with a general acknowledgment. b) in addition, insert into the batch file the QRD and QRF segments as follows: [FHS] (file header segment) { [BHS] (batch header segment) [QRD] [QRF] {.. (the QRD and QRF define the query that this batch is a response to) (one or more HL7 messages) 9
. } [BTS] } [FTS] (batch trailer segment) (file trailer segment) E. HL7 Challenges It is often said that one s greatest strength is also his or her greatest weakness. HL7 is no exception. The flexibility that allows different environments to utilize different versions and aspects of HL7 can also make interfacing between unrelated systems extremely difficult. Complicating matters, each updated version of HL7 introduces new features and options. Not only is each version an 80% standard, but multiple versions also serve to further enhance and complicate the standard. This, of course, does not mean there are no solutions to this problem. Numerous organizations build HL7 interface engines, which serve as a hub that both routes and translates data between linked applications. Imagine watching the United Nations general assembly on CSPAN, and you get the idea. Different languages are being spoken, yet understood by each individual due to translators (interface engines) they are wearing. The very best interface engines allow for multiple connections to both internal and external applications, allowing for an optimal information exchange environment. Although other options, such as point-to-point interfaces, are available, they may be difficult to manage as requirements continue to evolve. F. CONCLUSION The adoption of the HL7 standard is allowing for the creation of better tools with which to transfer critical information. This will make every aspect of healthcare more efficient and dynamic and will lessen the opportunity for mistakes. Perhaps soon, a patient s visit to a clinic or a doctor s office may go like this: A nurse measures a patient s weight, which is electronically populated into his or her medical record. The nurse then takes the patient s blood pressure, and the result is also electronically populated into the medical record. Next, the doctor selects criteria for a lab order, and the lab receives it electronically almost instantly. The lab performs the order and electronically populates the patient s medical record with the results. HL7 certainly doesn t make these types of technological advancements happen, but the adoption and implementation of the HL7 message standard certainly helps make them possible more quickly. With the emergence of new HIPAA guidelines and legislation, and as more hospitals and clinics consider the regional health information organization model, EMRs improve, and laboratories and diagnostic imaging centers continue to integrate new technologies into their workflow, HL7 will continue to be a critical component in the evolution of healthcare. References http://www.itl.nist.gov/div897/ctg/messagemaker/slides/hl7_conf_messagemaker. ppt 10
Healthcare Group 1160 West Swedesford Road Building One, Suite 200 Berwyn, Pennsylvania 19312 +1.800.345.7672 Worldwide CSC Headquarters The Americas 3170 Fairview Park Drive Falls Church, Virginia 22042 United States +1.703.876.1000 Europe, Middle East, Africa Royal Pavilion Wellesley Road Aldershot, Hampshire GU11 1PZ United Kingdom +44(0)1252.534000 Australia 26 Talavera Road Macquarie Park, NSW 2113 Australia +61(0)29034.3000 Asia 20 Anson Road #11-01 Twenty Anson Singapore 079912 Republic of Singapore +65.6221.9095 About CSC The mission of CSC is to be a global leader in providing technology-enabled business solutions and services. With the broadest range of capabilities, CSC offers clients the solutions they need to manage complexity, focus on core businesses, collaborate with partners and clients, and improve operations. CSC makes a special point of understanding its clients and provides experts with real-world experience to work with them. CSC is vendor-independent, delivering solutions that best meet each client s unique requirements. For 50 years, clients in industries and governments worldwide have trusted CSC with their business process and information systems outsourcing, systems integration and consulting needs. The company trades on the New York Stock Exchange under the symbol CSC. www.csc.com Copyright 2010 Computer Sciences Corporation. All rights reserved.