SOAPwareXchangeHL7 Lab Interface Specifications

This lesson describes the specific manner in which HL7 is implemented in SOAPwareXchangeHL7, and how the various standard fields will be used.

SOAPwareXchangeHL7 is the interface module allowing HL7-compliant interfaces between the SOAPware® charting product and other HL7-compliant systems.

SOAPwareXchangeHL7 accepts HL7-compliant messages from other systems, and uses them to create formatted reports in a chart section of the appropriate SOAPware® chart. If the patient described in the PID (Patient Identifier) section of the HL7 message cannot be matched, it will be added to a queue for the SOAPware user to handle manually. SOAPwareXchangeHL7 uses the matching algorithm below to determine if a patient already exists in SOAPware®

Patient Matching Process

An incoming record will be considered to be a match to a SOAPware® patient if:

External ID is found in patient map, AND

Birth date matches, OR

Last name matches


Social Security numbers match, AND

Birth date matches, AND

Last name matches, AND

First name matches


First name and Last name matches, AND

Birth date matches, AND

Sex matches

So a match can be made on

First Name AND Last Name AND Birth date


Sex OR Social Security Number

Results Only Interface

At this time, all HL7 interfaces implemented with SOAPwareXchangeHL7 will be results-only. Bi-directional interfaces are being evaluated for future implementation. Because of this, SOAPwareXchangeHL7 only processes results messages (ORU).

A standard ORU message would follow this format:










Most SOAPware users host the SOAPware application and database on their local networks. As such, matters of communication are between the lab and the clinic. SOAPware®, Inc does not provide communications services for message delivery. If the client is hosted by SOAPware's Cloud Service (SCS) then appropriate resources will give the sending facility access to establish connectivity for message delivery.

SOAPwareXchangeHL7 supports file-based or TCP-based interfaces. A file based interface will consist of the interfacing system, or system user, depositing HL7 messages in a specified location on the SOAPwareXchangeHL7 machine. SOAPwareXchangeHL7 will then retrieve and parse these messages. When the messages have been parsed, SOAPwareXchangeHL7 will remove them.

A TCP based interface will require a TCP connection between SOAPwareXchangeHL7 and the sending system.SOAPwareXchangeHL7 will listen for incoming messages, and parse them as they arrive. SOAPwareXchangeHL7 will always return an ACK messages for TCP messages received.


  • File-based

File based communication is the preferred communication method and allows for easiest troubleshooting for SOAPware Support. All incoming lab messages should be deposited to the same directory.This directory must be reserved for the sole purpose of incoming messages; no other file types or information should be stored there.SOAPwareXchangeHL7 will remove each file after processing.


  • TCP

Current versions of SOAPwareXchangeHL7 are only capable of monitoring a single port.If multiple labs are interfaces to the same site, one lab may use the TCP connection. The other labs must use a file-based method, depositing result files into the same directory.

The TCP connection should not be closed after each send, as this will require the SOAPwareXchangeHL7 user to reset the connection from their end.

While we realize the value of TCP connections and offer these, we do not have the resources to troubleshoot them, and will recommend a file-based solution if problems turn up with the connection. If a sending facility/application has issues with connecting to a specific port on a clients local network, SOAPware staff will recommend contacting the clients IT personnel for further troubleshooting.

The XchangeHL7 will automatically send an ACK after each report is received. This cannot be controlled or altered via the XchangeHL7 GUI.

The acceptable port range is up to 32000.


SOAPware, Inc. does offer connectivity services when none are available through the Lab company for an additional setup and subscription fee. Speak with the SOAPware Sales Team if these services are needed.

Segment Descriptions and Legend

Segment Descriptions and Legend

BOLDED fields are required.

The MSH (Message Header) Segment

The MSH (Message Header) Segment

SOAPwareXchangeHL7 requires the MSH segment to be the first in the file. We do not accept FHS, BHS, or any other information before the MSH segment.

A separate MSH segment is required for each PID (Patient Identifier) segment in the file.

The Sending Application value in MSH-3 is used by SOAPwareXchangeHL7 to determine the source of the message and the section in SOAPware the report will be translated. This value should remain consistent for any interfaces using the same delivery application/company.

Messages parsed through this interface will be filed in the "Labs"  chart section of the patient chart. The value in MSH-4 will be displayed in the footer of the lab report as "Sending Facility."

The PID (Patient Identifier) Segment

The PID (Patient Identifier) Segment

The Patient ID in PID-3 will be entered into a matching table and is a required field. This ID can be anything, as long as it is unique and consistent per patient. First Name, Last Name, Birth date, Sex, and Social Security Number are all used for the patient matching algorithm. Omitting any of this information may cause the record to be queued for manual assignment. Demographic information included in the PID segment will not be used to update the demographics in the patient chart.

While SSN is marked as a required field, this may not be the case if a match can be based on all other data items in the patient matching algorithm.

The ORC (Common Order) Segment

The ORC (Common Order) Segment

The Accession Number in ORC-3 is used for report matching purposes. When a message comes in with an accession number that already exists in SOAPware®, the existing report will be updated or replaced, depending on the result status (ORC-5) of the existing report. Result status from the ORC segment will be displayed as the report status. Report matching requires that an ORC segment be sent for all messages. If the status is not sent in ORC-5 it can be read from OBR-25 for report matching.

Accepted values for report matching include:

P = Partial/Pending

F = Final

CM = Complete

IP = In Progress

C = Corrected

Ordering Provider information will be read from either ORC-12, or OBR-16. A physician ID of some sort is required in one of those fields. Last name will be used as well, and makes for easier physician matching.

The OBR (Observation Request) Segment*

The OBR (Observation Request) Segment*

*At least one OBR must be included under each ORC segment.

The Accession Number will be read from OBR-3 if it is not present in ORC-3.

Every OBR-4^2 under the same ORC will be combined to form the title of the report in SOAPware®. Each ORC segment will trigger a new report or be treated as an update if duplicate accession numbers are sent. If any OBR-4^2 is not populated, it will defer to OBR-3 to generate the report title.

OBR-7 will appear in the report as the Collection Date. An ordering physician ID will be expected in OBR-16 if it was not present in ORC-12.

Result status from OBR-25 will be displayed with each group of results.

The date in OBR-22 will be shown in the report header as the Date Reported.

The SOAPwareXchangeHL7 will currently only accept and process results for Ordering Providers, and will not process CC providers from OBR-28.

The OBX (Observation) Segment*

The OBX (Observation) Segment*

*At least one OBX must be included under each OBR segment.

The value of OBX-2 will be used to determine how to display the results.

For all types except TX, OBX-3^2 will be used as the test name.OBX-5 will be displayed in the Value column. OBX-6 will display in the Units column, OBX-7 in the Reference Range column, and OBX-8 in the Abnormal Flags column. OBX-14 will be displayed as the individual test date/time.

If the abnormal flag is H or HH, the result line will be colored red.If the abnormal flag is L or LL, the result line will be colored blue. For all other abnormal values (positive, unknown, etc) the result line will be colored orange. If a result contains abnormal results the report title in the Tasks Manager will begin with "ABN:" and the task list item will have a higher priority.

When the OBX segment has a Type of TX, only OBX-5 will be displayed.

Escape Characters in the Default Lab Interface

Escape Characters in the Default Lab Interface

The NTE (Notes and Comments) Segment

The NTE (Notes and Comments) Segment

In order to retain the appropriate display, all NTE segments where NTE-3 is beyond 35 characters or the nearest word will be auto-wrapped to the next line. If longer notes are necessary, multiple NTE segments will be required.

The NTE segment can contain any additional information not encoded in the OBX segment. Usually the NTE segment will contain some combination of the following items: text results, canned messages, or result comments.The following section lists all of the segments potentially used in result messages. Fields in boldface are required, all others are optional. Segments not listed in this document may be sent to SOAPwareXchangeHL7, but will be ignored. Fields not listed in these tables may be included at the end of the segment, but will be ignored.

Sample HL7 Message and Screenshot of the Result in SOAPware

Sample HL7 Message and Screenshot of the Result in SOAPware

Here is a sample result message processed through SOAPwareXchangeHL7 as displayed in SOAPware. The raw HL7 ORU message is also found below.

By default, SOAPwareXchangeHL7 will build a report header with the following data items:

Demographic Items

 - Report Generated Date/Time

 - Patient first and last name

 - Birthdate

 - SSN

Report items

- Order accession number

- Order status

- Collection Date/Time

- Ordering Physician


Additionally, a report footer is generated by default with the following data items:

- Sending Application, pulled from MSH-3 (may also refer to the parser used)

- Sending Facility, pulled from MSH-4

- Parser used to process the message



MSH|^~\&|LAB|Sending Lab|||20030417123605||ORU^R01|20030417597657260000|P|2.3|||||||




OBX|1|NM|01^WHITE BLOOD CELL COUNT||2.5|THOUS/MCL|3.8-10.8|L|||F|||20030114082400||||

OBX|2|NM|02^RED BLOOD CELL COUNT||2.53|MILL/MCL|4.20-5.80|L|||F|||20030114082400||||







OBX|9|NM|09^PLATELET COUNT||250|THOUS/MCL|140-400|N|||F|||20030114082400||||