SOAPwareXchangeHL7 Transcription Interface Specifications
SOAPwareXchangeHL7 is the interface module allowing HL7-compliant interfaces between the SOAPware® charting product and other HL7-compliant systems. This document describes the specific manner in which HL7 is implemented in SOAPwareXchangeHL7, and how the various standard fields will be used.
SOAPwareXchangeHL7 accepts HL7-compliant messages from other systems, and uses them to create formatted reports in the Reports section of the appropriate SOAPware® chart. If the patient described in the PID section of the HL7 message cannot be matched, it will be added to a queue for the SOAPware user to handle.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
Birthdate matches, OR
Last name matches
Social Security numbers match, AND
Birthdate matches, AND
Last name matches, AND
First name matches
First name and Last name matches, AND
Birthdate matches, AND
So a match can be made on
First Name AND Last Name AND Birthdate
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:
Matters of communication are between the lab and the site. SOAPware®, Inc does not provide communications services.
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 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.
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.
The XchangeHL7 will automatically send an ACK after each report is received. This cannot be controlled or altered via the XchangeHL7 GUI.
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 other communication methods are required, such as dial-up file transfers, the SOAPware®, Inc. programming team can evaluate the possibility of creating a transfer program for an additional fee.
Segment Descriptions and Legend:
MSH Message Header
PID Patient Identification
ORC Common Order
OBR Observation Request
NTE Notes and Comments
BOLDED fields are required.
The MSH (Message Header) Segment
SOAPwareXchangeHL7 requires the MSH segment to be the first in the file. It does not accept FHS, BHS, or any other information before the MSH segment.
A separate MSH segment is required for each PID 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. If a Lab/LIS will be sending multiple result types or multiple values in MSH-3, this must be indicated in the testing phase and samples sent for each.
Messages parsed through this interface will be filed in the "Miscellaneous" 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 Patient ID in PID-3 will be entered into a matching table. This ID can be anything, as long as it is unique and consistent per patient. First Name, Last Name, Birthdate, 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 OBR (Observation Request) Segment*
*At least one OBR must be included under each ORC segment.
Multiple CC physicians sent in OBR-28 will be processed individually and a report created for each. Physicians that do not belong to the practice may be excluded in the SOAPwareXchangeHL7 physician mapping option.
At this time, 32 fields are REQUIRED for each OBR segment. While every field does not necessarily need to be populated, each field up to OBR-32 must be represented.
OBR-4^2 will display as the title of the report in SOAPware® and is a required field.