HL7 – Integration Specification & Case Studies |
| Introduction |
| Overview |
| This document describes the HL7 message supported by Binary Spectrum for practitioner import from third Party Applications. |
|
| Binary Spectrum uses Health Level Seven (HL7) clinical and administrative software standard to provide for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, the standard is used to create flexible, cost effective approaches, guidelines, methodologies, and related services for interoperability between healthcare information systems. |
|
| Binary Spectrum's HL7 adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. The most widely used being a messaging standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data. |
|
| The primary functions of Binary Spectrum's HL7 modules are to communicate demographic and order data between Binary Spectrum and other systems and equipment within a hospital setting, a Radiology practice or other medical facility. Binary Spectrum uses HL7 to interface to: |
|
 |
Hospital Information Systems (HIS) |
|
Picture Archiving Communications Systems (PACS) |
|
Electronic Medical Records Systems (EMR) |
|
Other healthcare systems |
|
|
| The standards used for communicating information between the systems and components, as shown in the diagram in Fig. 3 can be summarized in the following table. |
|
| HL7 Definition |
| Heath Level Seven (HL7) is the registered trade mark of the HL7 consortium – an ANSI approved non profit standards body set up to establish communications protocols for the health industry. In its present format (since version 2.3) HL7 is a delimited tree based text message protocol. For more information on HL7, please check out the HL7 consortium web site at: www.hl7.org |
|
| HL7 is one of several ANSI-accredited Standards Developing Organizations (SDO's) operating in the healthcare arena. Most SDO's produce standards for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. HL7's domain is clinical and administrative data. The mission of HL7: |
|
| "To provide standards for the exchange, management and integration of data that support clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems." |
|
| Another definition of HL7: |
| "To provide standards for the exchange of data among health-care computer applications that eliminates or substantially reduces the custom interface programming and program maintenance that may otherwise be required." |
|
| Install Process |
| Given the level of customization required for each installation, Binary Spectrum takes full responsibility of the installation of the HL7 module at the customer's location. |
|
| HL7 Version Supported |
| 2.3 |
|
| Installation Methods |
| There are two approaches followed for installing HL7. |
|
|
|
| Folder based |
| For each new and updated records for patient registration and scheduling a file gets created in folders "patient" and "appt" respectively and these files are picked up by a service and the details are recorded in the database of EMR.The architecture is as follows: |
|
| In folder approach the implementation ends at creating the files. |
|
| TCP/IP based approach |
| In this approach the files created are sent over TCP/IP connection, at the receiving end a service will be listening at a particular port which will import the data into EMR database after receiving the data at the specified port. |
|
| HL 7 – Message Types and Segments |
| ADT (Admission, Discharge and Transfer) |
| The segments are |
|
EVN - event type segment |
|
PID - patient identification segment |
|
PV1 - patient visit segment |
|
PV2 - patient visit - additional information segment |
|
NK1 - next of kin / associated parties segment |
|
AL1 - patient allergy information segment |
|
NPU - bed status update segment |
|
MRG - merge patient information segment |
|
PD1 - patient additional demographic segment |
|
DB1 - Disability segment |
|
|
| Order Entry |
| The segments are |
|
ORC - common order segment |
|
BLG - billing segment |
|
|
| Observations reporting |
| The segments are |
|
OBR - observation request segment |
|
OBX - observation/result segment |
|
|
| Patient referral |
| The segments are |
|
RF1 - referral information segment |
|
AUT - authorization information segment |
|
PRD - provider data segment |
|
CTD - contact data segment |
|
|
| Financial management |
| The segments are |
|
FT1 - financial transaction segment |
|
DG1 - diagnosis segment |
|
DRG - diagnosis related group segment |
|
PR1 - procedures segment |
|
GT1 - guarantor segment |
|
IN1 - insurance segment |
|
IN2 - insurance additional information segment |
|
IN3 - insurance additional information, certification segment |
|
ACC - accident segment |
|
UB1 - UB82 data segment |
|
UB2 - UB92 data segment |
|
|
| Master files |
| The segments are |
|
MFI - master file identification segment |
|
MFE - master file entry segment |
|
MFA - master file acknowledgment segment |
|
|
| Patient care |
| The segments are |
|
GOL - goal detail segment |
|
PRB - problem detail segment |
|
ROL - role segment |
|
PTH - pathway segment |
|
VAR - variance segment |
|
|
| Scheduling |
| The segments are |
|
ARQ - appointment request segment |
|
SCH - schedule activity information segment |
|
RGS - resource group segment |
|
AIS - appointment information - service segment |
|
AIG - appointment information - general resource segment |
|
AIL - appointment information - location resource segment |
|
AIP - appointment information - personnel resource segment |
|
APR - appointment preferences segment |
|
|
| Medical records/information management |
| The segments are |
|
TXA - transcription document header segment |
|
OBX - observation segment usage |
|
|
| CASE Studies |
| Scenario 1 – Folder Based approachfor installing HL7. |
| Problem Definition: |
| One of our esteemed clients had a client server driven Practice Management Application (PMS) and an EMR application installed at his system. The client was using the PMS for Patient Registration, Scheduling, and sending Claims and EMR was used for recording Patient Chart. |
|
| It was extremely difficult to sink the data between the 2 applications in terms of Patients, Scheduling, Charting and Charges. The client approached us for a solution that would bridge this information GAP between the 2 systems. |
|
| The approach that Binary Spectrum proposed and implement was to exchange the data between the 2 systems via a Folder based – HL7 Format. The functional Architecture of this solution is give below. |
|
| Solution: |
| When any new or updated ADT, SCH transactions occurs in the PMS application a trigger in the PMS database would create ADT and SCH HL7 messages respectively. These HL7 message files would be stored in the file system in the ADT and SCH folders respectively. |
|
| The Export File watch service would then pick this HL7 messages, parse them to verify the standard HL7 format and then insert or update the EMR database. Once the EMR database is updated an acknowledgement is sent across to confirm the operation. If the status of the acknowledgement was successful then the HL7 message is moved to the ADT/SCH success folder else if it's a failure then the HL7 message is moved to the ADT/SCH failure folder. |
|
| The similar process is executed when a charge is sent across from the EMR. All charge capture transactions are stored as HL7 messages in the Charge Folder. The Import File watch service would pick up these HL& message and update the PMS database and the acknowledgement messages are sent respectively. |
|
| The entire process is further recorded in the log which would maintain the status of each and every transaction with data and time. |
|
| Scenario 2 – TCP/IP approach for installing HL7 |
|
| Problem Definition: |
| One of our esteemed clients had a client server driven Practice Management Application (PMS) and a web based EMR application installed. The client was using the PMS for Patient Registration, Scheduling, and sending Claims and EMR was used for recording Patient Charts. |
|
| We had the similar problem with sinking the data between the 2 applications in terms of Patients, Scheduling, Charting and Charges. Another problem was that the EMR was a web based application and they wanted a TCP/IP approach to bridge the information gap between the 2 systems. The functional Architecture of this solution is give below. |
|
| Solution: |
| In this approach the ADT/SCH HL7 messages created by the PMS application are sent over TCP/IP connection one at a time to the EMR application. At the receiving end an Import service will be listening at a particular port which will import the data into EMR database. Once the EMR has been updated an acknowledgement is sent across to confirm the transaction. The PMS application then sends the next ADT/SCH message on receiving the acknowledgement from the EMR Import service. |
|
| Similarly, when a new charge is created in the EMR, the messages are sent over via the TCP/IP connection. There's another PMS Import Service which will get these charge HL 7 message over a defined port and update the PMS database respectively. The charge message is also sent one at a time over the TCP/IP port based on the acknowledgement sent from the PMS Import service. A transaction log is maintained to record all transactions. |
|
| Scenario 3 – Manual Excel Charge File Upload. |
| Problem Definition: |
| This client had a unique requirement. They had an EMR and a PMS application and they wanted to send across only the charges from the EMR to the PMS for sending across the claims to the clearing house. The charge file that was exported from the EMR was in an Excel format. The client also wanted the process of selecting the charge file to be manual so that they have a control over the charges that needs to be sent for clearing.
|
|
| Solution: |
| This was quite an interesting and challenging and a unique requirement. Each of these excel files where different and the data in the files were also not consistent. First we had to finalize on the format of the excel file which contained the charges. This took care of the default columns that would be sent across the mandatory data in each column and also the data type of each column was fixed. |
|
| We created a Excel File Upload component that would allow the client to select a charge file of there choice to be sent. Once the file was sent across we had a HL7 Parser component that would parse through the excel file and create charge HL 7 messages based on the HL 7 Standard. The HL7 Parser while parsing the Excel file would record inconsistent data into the database transaction log as failed charges which would then be rectified and the same excel file would be resent. The HL 7 Parser would create HL7 charge files for those which had data in a proper format and store them in the Charge Folder in the File System. |
|
| The Import File Watch service would then pick up these charge files and import them to the PMS database. |
|
| Once the charge process was successfully imported across from EMR to the PMS the ExcelFile Upload Component had an option to view the log file. This log file recorded all the charge transactions and would display all the failed charges with the reason for its failure. It also had the option of view the previous charge logs thus facilitating the client to review the charge logs at any point in future. The ExcelFile Upload Component gave the client an option to purge the log files if required. |
|
|
