Each of the systems – Radiology Information System (RIS), Lab Information System (LIS), Hospital Information System (HIS), Electronic Health Record (EHR) and Electronic Medical Record (EMR) communicate with each other in different languages. Increased number of healthcare applications and the necessity of centralized electronic health record drive the requirement for the universal language among the applications. To solve this issue, HL7 was introduced as the single, flexible and universal standard of communication in 1987. This article summarizes the importance and steps involved in a successful HL7 integration.
Key Abbreviations
HL7 – Health Level Seven HIPAA – Health Insurance Portability and Accountability Act RIS – Radiology Information System LIS – Lab Information System HIS – Hospital Information System EHR – Electronic Health Record EMR – Electronic Medical Record RIM – Reference Information Model ISO – International Organization for Standardization ANSI – American National Standards Institute FIFO – First In First Out CDA – Clinical Document Architecture CCR – Continuity of Care XML – Extensible Markup Language
DESCRIPTION:
What is HL7?
HL7 is the universal user-friendly standard which enables the communication between two or more healthcare applications. The health related information will be transferred in the form of one or more HL7 messages such as patient record and billing information.
The HL7 interoperability standard is often called the nonstandard standard, since it does not consider any specific part as special and, hence, there is no standard business or clinical model for clinical interaction.
HL7 development needs the involvement of clinical application analyst, integration specialist, application programmers and system analyst.
What does HL7 stand for?
HL7 (Health Level Seven) symbolizes a 7-layer ISO communication model
Physical: Connects the entity to the transmission media
Data Link: Provides error control between adjacent nodes
Network: Routes the information in the network
Transport: Provides end-to-end communication control
Session: Handles problems that are not communication issues
Presentation: Converts the information
Application: Provides different services to the applications
1-4 deals with Communication; 5-7 deals with Function. All these layers are used by HL7 interface engine for transfer and retrieval of HL7 data.
HL7 Interoperability Standard versions
2.0 – 1988 – Prototype 2.1 – 1990 – First standard 2.2 – 1994 – Widely adopted 2.3 – 1997 – In operation 2.3.1 – 1999 – Approved ANSI standard 2.4 – 2000 – Approved ANSI standard 2.5 – 2003 – Current ANSI standard 3.0 – In development
OBJECTIVES:
The vision of HL7 development is a world where everyone can securely access and use the right health data when and where they need it. In order to achieve that goal, the workflow should be simplified between healthcare software applications and various vendors for the enhanced quality, accuracy, cost and efficiency of healthcare providers.
Strategies:
Develop clear standards of health care information to exchange between computer applications for an enhanced patient care.
Develop a methodology of HL7 interoperability standards from the HL7 Reference Information Model (RIM).
Educate the healthcare industries, policy makers and public about the benefits of healthcare information standardization.
Promote the use of HL7 interoperability standards world-wide through the creation of HL7 International Affiliate organizations.
Encourage domain experts from healthcare industry stakeholder organizations to join in HL7 for developing healthcare information standards in their area of expertise.
Collaborate with other standards development organizations and national and international sanctioning bodies (e.g. ANSI and ISO), to promote the use of compatible standards.
Collaborate with healthcare information technology users to ensure that HL7 standards meet real-world requirements.
HEALTHCARE INTEGRATION SOLUTIONS
Healthcare integration overview
Export endpoint – sending application
Import endpoint – receiving application
Methodology – move data between two endpoints
Methodology – handling the queuing messages
Methodology – sorting the message flow
Each healthcare application must be accessible to send and accept patient data. There are certain fixed rules of what to accept and send for easy exchange. This access is strictly controlled by each application vendor to ensure data integrity within their application.
Healthcare Integration Requirements
First In, First out (FIFO): The exchange of clinical data must be in FIFO order. The first HL7 message received will also be the first HL7 message delivered.
Flexibility to Address Varying Requirements: Since HL7 is essentially a platform for negotiation, the interface solution must be flexible to deal with HL7 V2.3.1, V2.4, V2.5, etc. It should be able to send one message in varied versions to multiple applications.
External Application and Provider Integration: Real-world integration takes place between multiple applications in multiple locations. Healthcare interface traffic can be intense so a strong traffic director in the middle is extremely important. Else, the output will get delayed which might lead to costly implementations, application modifications, etc. Each application in the integration path should be able to send and/or receive data, ideally in an HL7 format.
Short Implementation Cycle: The workflow for interface configuration should be easy, logical and GUI driven. The developer does not have to be available to implement each application or site.
Scalable: The number of interfaces will grow over time. An interface solution must also be able to grow with the demands of the market.
Different Data Formats: In addition to HL7, the interface solution should be able to handle other clinical standards including the Clinical Document Architecture (CDA), Continuity of Care (CCR), and XML.
Ease of Interface Testing & Maintenance: Delivering quality interfaces is crucial. Hence, few testing functions such as conformance checking, message unit testing, and communication testing should be incorporated within the interface solution.
Ease of Monitoring & Management: To keep customer support costs low, interface implementations should be easy to monitor and resolution tools should be readily available to fix any upcoming error.
HIPAA & HL7 INTEGRATION PROTOCOLS
Data sharing between clinical and financial systems is always a challenging task, in terms of reliability, security and compliance. That is where exactly, the importance of HL7 and HIPAA arises.
HL7 exchanges clinical date between healthcare applications from different vendors. HIPAA (Health Insurance Portability and Accountability Act) was implemented in 1966 in order to update healthcare transactions and to uphold patients privacy rights.
HL7 will be triggered by the events like patient admission and billing within the enterprise like hospitals. Whereas between enterprises like hospitals and insurance companies, HIPAA enabled EDI-X12 transactions will be exchanged. HL7 is also used in certain HIPAA EDI-X12 transactions.
For instance, if a patient is admitted in hospital, the Patient Administration System (PAS) maintain the details about that patient. If other system like Pharmacy Systems need information about this patient, it sends an HL7 message about the patient to the proper hospital systems.
Later, when the hospital sends a claim for payment to another enterprise, like an insurance company, the hospital and the insurance company exchange HIPAA EDI-X12 messages. These HIPAA EDI-X12 messages may contain an embedded HL7 message about the patient also.
INTEGRATION OPTIONS AVAILABLE
An enterprise such as hospital has got many HL7 enabled applications. To reduce data entry duration and increase overall efficiency of the facility, these applications should communicate with each other. An HL7 interface development includes:
An export endpoint for the sending application
An import endpoint for the receiving application
A method of moving data between the two endpoints
There are two basic ways for effective communication:
Point-to-point where each pair of applications communicates independently of other applications. Point-to-point interfaces send data from system A to system B through an interface in between (FIFO). It is very expensive and time consuming to implement communications. Hence it may not would not work effectively for a vendor.
Using an interface / integration engine placed in the midst of all the applications to aid in information exchange and monitoring. Hence the interoperability of entire system would remain effective. It is comparatively less time consuming and less expensive due to engine flexibility. Interface monitoring and adding new or replace existing application is considerably better.
Each provider should decide which option would be more productive and cost-effective for their organization. If the interfacing environment is limited and focused, then the point-to-point approach may work. If the interfacing requirements are growing internally to streamline workflow and externally to meet EMR requirements, then the interface engine approach would be better.
HL7 INTEGRATION PROCEDURE
Rather than implementing the recent phase of your HL7 integration, analyse your health system’s needs and build a customized interface solution that will meet your budget along with current and future needs. A strong interface team with a coordinated testing by subject matter experts can provide successful outcome in HL7 implementation.
Step 1: Plan the interface
HL7 interfaces are required to support data integration. Properly integrated HL7 interfaces can reduce duplicate data entry and enhance user workflow due to application interoperability. Common HL7 interfaces used within health care organizations.
ADT – Admission, discharge, transfer
DFT – Detailed financial transaction
ORU – Observation results
ORM – Orders
MDM – Medical document management
MFN – Master files notification
SIU – Scheduling
BAR – Billing account record
The below mentioned flowchart shows the planning step of right interface.
In addition to this flow, the right staff members and consultants should be included for the project execution.
Identification of the right HL7 interface and their respective field content should be reviewed to avoid data irregularities. Especially, ADT workflows should be reviewed in terms of sending and receiving data.
Step 2: Build the Interface
Execution—This is the project execution phase where many steps are involved. First, interface engineers should complete application side work efforts. They should define each port along with their respective content.
Interface build—The specifications should be kept in mind before building the appropriate interface. Setting up the interface to handle the content and field locations for medical record numbers is included in this step.
Testing—Connectivity testing should be performed about the interface build stage before proceeding to the validation step. Connectivity testing is done to check whether HL7 data exchange passes successfully from source to destination without any network barrier.
Step 3: Test and Validate
The testing phase is another important phase of the HL7 integration. Proper review of the design, utilization and content of these interfaces is the most important step for the successful completion. Unit and integrated testing involve the expertise of application subject matter experts. They are typically great at working with the technical items relevant to an interface.
Unit testing involves validating specific feeds and reviewing data for accuracy. This step would identify any issues missed by the interface engineer during initial gap analysis.
Integrated testing involves reviewing data as it flows through upstream and downstream systems via HL7 interface development. Whoever is familiar with the data should be involved in validation steps.
WHAT ROLE A TECH PERSON PLAYS?
In order to implement a cost effective HL7 Interface engine, the operations should be streamlined. For that, all departments and processes should work together for an effective communication with the help of tech person.
The workflow should be documented on how data passes internally within the departments and externally with outside providers and specialists.
The tech person analyzes how the components of the system work together and how to code inbound / outbound messages.
Such analysis will help in implementing the right integration engine, which will transform your data into user friendly content for better patient care management.
After creating the strategy, reviewing systems for integration, and identifying the right interface, your IT team will begin to create inter-operability through the customization of a new interface engine.
This technical step involves finding the right system for data storage, retrieval and analysis.
After determining the appropriate approach, data from your existing system should be integrated into your interface, without interrupting the current operation.
Finally, your IT team will perform the testing step before going live with the new interface engine.
CONCLUSION
Healthcare communications such as HL7 need security measures added for both existing and new installations. At present, various security measures such as encryption and SSH tunnelling are used to secure HL7 data exchange. Healthcare needs to do more for data protection and that updation should take place soon.
Same way, each updated version of HL7 incorporates new features and options which complicates the standard one. With the emergence of new HIPAA guidelines, the best interface engine should allow multiple connections to both internal and external applications for an easy data exchange. Hence, HL7 will continue to be a major component in healthcare evolution.
Riken Shah is the CEO of OSP. He is a tech enthusiast, healthcare innovation specialist, and avid reader. With over a decade of experience, Riken has helped healthcare companies to be more productive and successful.
