Sending HL7 Messages to System

The following document describes how to interface with MIE via an HL7 interface. Whereas the purpose of this interface is to send Hl7 messages real-time to system using TCP/IP protocol, TCP/IP protocol over SSL/TLS, or a restful web service post.

Assumptions

---

The following assumptions have been made concerning the implementation of the interface:

• It is assumed that the reader of this document is familiar with HL7 v 2.X. This document is not intended to standalone but should be used in conjunction with the HL7 Specification Version 2.3 and Higher.
• The reader is familiar with the HL7 MLLP (Minimal Lower Level Protocol).
• The HL7 interface is real-time using TCP/IP protocol, TCP/IP protocol over SSL/TLS, HTTPS restful web service post.
• The Hl7 Messages sent through the interface will have codes/descriptions/identifiers in the HL7 message foreign to the Enterprise Health system and that translations of this data will be handled within Enterprise Health (when required).

Interface Overview

---

In order to process the data successfully, the following items must be supplied/completed:

• External system(s) must furnish IP address(s) that will be used for connectivity.
• Interface system parameters must be setup in order to direct the interface on how to format the data for the external system.
• Translation files (if the practice is using translations) must be setup that will convert Master File Values (Physician, Location, Insurance Company, Appointment Codes, Document Types and Observation Result Codes) into Enterprise Health values.

How it Works

The following describes the process as it occurs:

• A message is sent to MIE’s Hl7 Enterprise Health Interface. The message is then processed accordingly and an acknowledgment of success or error is sent back to sending systems Hl7 interface.
• If success then the sending system is free to send the next result.
• If error, then the sending system should continue to send the message until a successful acknowledgment has been sent back from the receiving systems HL7 Interface.

Communication Flow

---

Communications control characters will be used for all messages sent between MIE’s Enterprise Health system and the receiving system. The Minimal Lower Level Protocol (MLLP) is used by the TCP/IP connection, as specified by HL7 standard. The control characters will consist of: 1. A single vertical tab character to indicate the start of block (Hex), 0x0B, at the beginning of the message; 2. Every segment in the HL7 message will be terminated by the termination character (hex) - 0x0D (carriage return). 3. The characters (Hex) 0x1C (FS) to indicate end of block, and termination character (hex) - 0x0D (carriage return) at the end of the message. For more information, refer to appendix C, section 1, of the HL7 Implementation Support Guide. When the HL7 Interface processes an inbound message, it sends back an acknowledgment indicating the message was received successfully (accept - AA) or unsuccessfully (failure - AR and AE). A sending system should use this information to know when to send the next message or so it can automatically retry on a failure.

HL7 RESTful POST

It is possible to send HL7 messages over a restful web service post using HTTPS. It is recommended to use a multi-part/form POST content type to properly encode the variables and the message itself. The webservice requires specific variables to exist within the POST, included are unique login credentials provided at the start of the interface project. HL7 - RESTful

HL7 Standard Acknowledgments

MIE will be using the following MSA acknowledgment codes, the following codes are to be treated as such:

• AA (Application Accepted) - the message was accepted and successfully processed.
• AR (Application Rejected) - the only time a message should not be automatically retried, an AR acknowledgment code indicates that the message is not formatted properly.
• AE (Application Error) - a notice of failure on the receiving side and does not indicate that the message is bad and must be resent. These acknowledgments conform to the HL7 standard. The interface determines the acknowledgment mode to use based on the values sent in MSH.15 and MSH.16, sending back the acknowledgment in the manner requested by the message sender. For more information, refer to chapter two of the HL7 standard documentation.

Accepted HL7 Message types legend - < > = 0 to many, [ ] = 0 to 1, { } means 1 to many.

Scheduling (SIU)

• SIU^S12  : MSH  SCH  [ PID  ] [ NTE  ] [ PV1  ] [ DG1  ] [ RGS  ] [ AIG  ] AIL  [ AIP  ]
• SIU^S14  : MSH  SCH  [ PID  ] [ NTE  ] [ PV1  ] [ DG1  ] [ RGS  ] [ AIG  ] AIL  [ AIP  ]
• SIU^S15  : MSH  SCH  [ PID  ] [ NTE  ] [ PV1  ] [ DG1  ] [ RGS  ] [ AIG  ] [ AIL  ] [ AIP  ]

Patient Registration (ADT)

• ADT^A01  : MSH  [ EVN  ] PID  [ PV1  ] < PV2  > < IN1  >
• ADT^A04  : MSH  [ EVN  ] PID  [ PV1  ] [ DG1  ] [ GT1  ] < IN1  < IN2  > >
• ADT^A08  : MSH  [ EVN  ] PID  [ PV1  ] [ DG1  ] [ GT1  ] < IN1  < IN2  > >
• ADT^A40  : MSH  EVN  { PID  [ PD1  ] MRG  [ PV1  ] }

Lab Results (ORU)

• ORU^R01 : MSH  PID  [ PV1  ] {ORC  { OBR  { OBX  < NTE  > } }}
• ORU^R03 : MSH  PID  [ PV1  ] {ORC  { OBR  { OBX  < NTE  > } }}

Lab Orders (ORM)

• ORM^O01 : MSH  PID  <NTE > [ PV1  ] [ PV2  ] <IN1 > [ GT1  ] { ORC  { OBR  <NTE > <DG1 > <OBX > } } [ ZPA  ] [ ZIL  ]

Documents (MDM)

• MDM^T02  : MSH  [ EVN  ] PID  [ PV1  ] TXA  { OBX  }

Financial Transactions (DFT)

• DFT^P03  : MSH [ EVN  ] PID  [ PV1  ] <OBX > { FT1  < PR1  >} < DG1  > [ GT1  ] < IN1  < IN2  > >

Immunizations (VXU)

• VXU^V04 : MSH PID ORC RXA RXR

Acknowledgement (ACK) message

• ACK  : MSH  MSA  [ ERR  ] < ZTN  > < ZDG  >

Field Definitions

Responsible Observer

Logic when processing Responsible Observer for hl7 v2.3 messages: OBX 16 (responsible observer) is used to set the performing lab facility, which is stored as a user in Enterprise Health . The obx 16.1 value can auto create a user or it can be mapped to a user in Enterprise Health  depending on the user setting for OBX user in the hl7 configuration. If auto creating the user is configured, the other XCN sub component values in OBX 16 are used to create the lab facility user. If we are translating the values in OBX 16.1 the user in Enterprise Health will be manually created with the correct lab contact name, address, etc… Even if the user is Auto created, the User’s information can be corrected or amended by editing the user account in Enterprise Health .

  
  
  
  
  
OBX|1|NM|wbc^Wbc^Local^6690-2^Wbc^LN||7.0|/nl|3.8-11.0||||F|||20120410160227|lab|12^XYZ LAB|  
  
  
  

  
  
  

The identifier 12 will then link to a system user. This user can then can modified if needed to include any other required information.** 

When displaying the laboratory results in Enterprise Health the system polls all of the observations stored together at the Result level (OBR) it will then display the common lab between the observations at the end of the result. Any observation that has a differing lab facility, that facility is then printed in line with the observation.