T2
Related Practice Areas
- T1: The Common Framework: Technical Issues and Requirements for Implementation
- T3: Medication History Standards
- T4: Laboratory Results Standards
- T6: Record Locator Service: Technical Background from the Massachusetts Prototype Community
Additional Resources
Download T2: Health Information Exchange: Architecture Implementation Guide
3 RLS/ISB Development Goals
3.1 Overall Directions
All communications are SSL-encrypted SOAP 1.1 messages.
ISB-to-ISB communication is always asynchronous. Upon receiving the SOAP query message, the ISB may immediately return an acknowledgment (ACK) message to the CLIENT. In that case, if a SOAP fault is generated, the CLIENT does not expect any further reply from the query server. If the message is accepted, the CLIENT expects to receive an asynchronous reply containing the query results. That is, the CLIENT creates a thread that will accept the eventual query results SOAP message from the ISB. The CLIENT system decides how to act if the return message does not arrive in a timely manner.
HL7 defines a parameter that defines the query as either “immediate” or “deferred.” The SOAP conversations that we describe as “synchronous” are HL7 “immediate” queries. The SOAP conversations that we describe as “asynchronous” are HL7 “deferred” queries. The “immediate” or “deferred” attribute is defined in HL7 field RCP.1 (Query Priority).
Errors in message validation are reported as SOAP faults. Errors in asynchronous processing logic are reported back to the client service within the SOAP response message.
Every NHIN request message includes information about the specific user making the request. The ISB logs the requestor identity information along with the query and the response. In other words, the ISB keeps a complete log of “who, what, when, and where” for all of the NHIN queries that it processes.
Most of the patient information in the query and response messages is represented as XML-encoded version 2.4 HL7. HL7’s formal specification of the XML encoding for version 2.4 resides at http://www.hl7.org. Patient medication dispensing history is returned in the query response message in NCPDP Scripts 8.1 format.
NHIN query messages are pure HL7, represented in XML per HL7’s documentation. Responses are all HL7, except for the medication dispensing history mentioned above. SNOs should readily be able to interpret and construct these familiar messages without re-inventing their message content creation services and functions. The NHIN should also be able to take advantage of new HL7 developments without having to change this fundamental NHIN message architecture.
3.2 Directions for ISB/RLS Design
All communications are SSL-encrypted SOAP 1.1 messages.
ISB-to-ISB communication is always asynchronous. Upon receiving the SOAP query message, the ISB immediately returns an acknowledgment (ACK) message to the CLIENT. If the message is rejected (a SOAP fault is generated instead of the ACK), the CLIENT does not expect any further reply. If the message is accepted, the CLIENT expects to receive an asynchronous reply containing the query results. That is, the CLIENT creates a thread that will accept the eventual query results SOAP message from the ISB. The CLIENT system decides how to act if the return message does not arrive in a timely manner.
Errors in message validation are reported as SOAP faults. Errors in asynchronous processing logic are reported back to the client service within the SOAP response message.
Every NHIN request message includes information about the specific user making the request. The ISB logs the requestor identity information along with the query and the response. In other words, the ISB keeps a complete log of “who, what, when, and where” for all of the NHIN queries that it processes.
Most of the patient information in the query and response messages is represented as XML-encoded version 2.4 HL7. HL7’s formal specification of the XML encoding for version 2.4 resides at http://www.hl7.org. Patient medication dispensing history is returned in the query response message in NCPDP Scripts 8.1 format.
NHIN query messages are pure HL7, represented in XML per HL7’s documentation. Responses are all HL7, except for the medication dispensing history mentioned above. SNOs should readily be able to interpret and construct these familiar messages without re-inventing their message content creation services and functions. The NHIN should also be able to take advantage of new HL7 developments without having to change this fundamental NHIN message architecture.
3.3 HL7 XML Background
HL7 is a well-established standard for communication of medical information between computer systems. HL7’s long standing encoding of 2.x HL7 messages has been “piped” delimited ASCII, with ASCII RETURN (ASCII 13) and/or LINE FEED (ASCII 10) characters demarking the end of HL7 message “segments,” and other delimiters defining the field and subfield boundaries. This is well-described in the HL7 manual available at http://www.hl7.org. HL7 has also now defined an XML encoding for version 2.x messages.
The tags for the XML encoding are defined by HL7’s existing abbreviations for segment, field and subcomponent names. For example, the tags names for segments are the three character HL7 segment names. “OBX” is the tag for the observation segment. The tag names for fields and data type components are the HL7 field abbreviations, e.g. the tag for the third OBX field would be OBX.3, and e.g. the tag for the third component of a CE data type would be “CE.3.” The XML schema for a given message identifies the segments and fields that are required.
Version 3 of HL7 is version 3.uses only XML encoding. However, almost all institutions currently use a 2.x version of HL7 and almost no clinical care system has adopted version 3. New 2.x HL7 versions continue to be developed in addition to the work on HL7 version 3.
We represent our messages in the widely used HL7 2.4 format so that it can be easily implemented in today’s institutions and because everyone in the industry is familiar with it. Using version 2.4XML gives us the advantage of the unified methods of processing the content of SOAP messages as well as direct translatability between pipe delimited HL7 messages and their XML equivalents. The HL7 content that is relevant to this project is listed in the following HL7 manual chapters.
| Chapter | Description |
|---|---|
| 1 | Broad description of the HL7 message format |
| 2 | Defines HL7 data types and control segments |
| 3 | Defines Patient Identification (PID) segments |
| 5 | Defines HL7 Query messages |
| 7 | Defines Observation Reporting segments for transmitting patient reports and results |
We designate some HL7 fields as “not used” for this project. Those field values will be ignored in the communications. No error will be signaled if these fields are populated.
HL7 content will be sent within the “body” of our SOAP messages with standard SOAP message headers and SOAP wrappers. The SOAP standard is defined at http://www.w3.org/TR/soap/.
Appendix B contains general guidelines for formatting the HL7 content. In the near future, we hope to simply point developers to an existing HL7 implementation guide, such as the ELINCS specification, for this information.