What if all hospital information systems were independent states that communicated with each other by sending diplomatic notes — each in their own language? This might sound like fiction, but it describes the situation in many medical facilities before HL7 integration. Of course, the era of passing paper notes is over, but manual data exchange between multiple systems is still a harsh reality of today’s medical industry.

• HL7 was designed to address this communication issue by improving the content of clinical data and providing the necessary structure. With HL7, the entire cycle of collecting, interpreting, and exchanging medical information is efficient and error-free. Practices can easily share diagnoses and lab results across EHRs, doctors can quickly access medical histories, and nurses are able to monitor planned procedures.
• HL7 is supported by more than 1600 members from over 50 countries, including 500+ corporate members representing healthcare providers, government stakeholders, payers, pharmaceutical companies, vendors/ suppliers, and consulting firms.
• Health Level Seven (HL7) is a set of standards that define how medical information is collected, processed, and exchanged. It’s a universal healthcare IT language spoken by the majority of the world. The eponymous non-profit organization created HL7 with the intention “to provide standards that empower global health data interoperability.” Here are the most essential of these standards:
• HL7 V2 is the most widely adopted messaging standard for health and medical data transactions in use today.
• HL7 V3 is the next iteration that includes both messages and documents, and introduces a more comprehensive information model
• HL7 CDA standards (Clinical and Administrative Domain) are a part of the HL7 V3 specification that focuses on clinical documents
• HL7 CCD standards (Continuity Care Document) define patient medical summaries for the US market
• HL7 EHR is a collection of profiles and functional models for managing Electronic Health Records
• HL7 FHIR, or Fast Health Interoperable Resources, is the newly developed standard built with modular components and optimized for use with web-based APIs (Application Programming Interfaces)

How does HL7 in healthcare work?

It provides a common framework for effective data communication within medical practices, between organizations, and with patients. Let’s have a detailed look at why HL7 is well worth the methodical and thorough integration it requires.

The US healthcare industry is incredibly complex and is sitting on an ever-increasing mountain of information. Studies suggest that each patient contributes about 80 megabytes of EMR and imaging data annually. Most of this data is stored and processed in isolated pools that belong to different medical institutions. What’s even more disturbing is that data can be dissociated and poorly structured even within the IT systems of a single institution.

Large healthcare providers usually rely on a variety of IT systems to keep their administrative, diagnostic, and treatment services running. A typical hospital, for instance, may use an HIS (Hospital Information System), an EMR (Electronic Medical Record), an LIS (Laboratory Information System), an RIS (Radiology Information System), and a PACS (Picture Archiving and Communication System). These systems all gather and generate information, but the different data formats they use prevent effective communication between them.

HL7 data integration can solve this problem in a number of ways. Below, we outline the main benefits you can achieve by implementing HL7 standards.

Why does healthcare need HL7?

Many healthcare providers, particularly specialists, are required to access multiple electronic systems to see relevant diagnoses for a patient. This can be even more challenging if they provide services in outpatient clinics that are not integrated with the local hospital system. This is where Fast Healthcare Interoperability Resources (FHIR) comes in and HL7 interoperability standards, such as the messaging format HLv2 or the most recent FHIR, exercise their value.

By providing a common language around content and structures for clinical data classes (e.g. diagnoses, allergies, procedures, …) data can be exchanged across EHRs without ambiguity and risk of misinterpretation.

Types of HL7 Messages Processing in MuleSoft:

• In MuleSoft we have different schemas for HL7 and the HL7 message is validated against that schema.
• That schema contains all the information for any kind of message (different message: different schema), describing which field will be mandatory and optional.

Messages example:

• ACK — General acknowledgement
• ADT — Admit, Discharge, Transfer
• BAR — Add/change billing account
• DFT — Detailed financial transaction
• MDM — Medical document management
• MFN — Master files notification
• ORM — Order (Pharmacy/treatment)
• ORU — Observation result (unsolicited)
• QRY — Query, original mode
• RAS — Pharmacy/treatment administration
• RDE — Pharmacy/treatment encoded order
• RGV — Pharmacy/treatment give
• SIU — Scheduling information unsolicited

Use Case:

Patient Registration (using ADT Message: hl7v2.3.1 & ADT_A04)

Strategy:

1. Make use of existing connectors present in the Anypoint exchange.

HL7 EDI Connector — To facilitate integration with healthcare systems by providing the tools needed to easily create, read, and transform HL7 version v2.x messages within Mule.

Salesforce Connector — To insert data into Salesforce.

2. Making these APIs reusable for future implementation.

Establishing a connection with HL7 EDI Connector:

1. In the Mule Palette view, click (X) Search in Exchange.
2. In the Add Dependencies to Project window, type HL7 in the search field.
3. Click HL7 EDI in Available modules.
4. Click Add and then Finish.
5. In the Mule Palette view, select HL7 and then select the desired operation (read operation is used in this use case).

6. Drag the operation onto the Studio canvas to the right of the input source.

7. Select the operation in the Studio canvas.

8. In the configuration screen for the operation, click the plus sign (+) next to the Connector configuration field to access the global element configuration fields.

9. Go to the Document tab in config to reference the schema.

a. Select Edit Inline in the schema definitions.

b. Click on (+) to add the Schema provided in the project folder structure.

10. Click on Test Connection to confirm that Mule can connect with the specified server.

11. Click OK.

Establishing a connection with Salesforce:

1. Add Salesforce connector from exchange using (X) Search in Exchange.
2. Drag and drop the required operation in the mule canvas.
3. Add a connector configuration for the added operation by clicking on (+) in the operation properties.

4. In the connector config, select the connection strategy.

5. Add the required details as per your connection strategy.

6. Click on Test Connection to confirm that Mule can connect with the specified server.

7. Click OK.

How you can implement STEP BY STEP

Mule Flow

Step 1: Set up a Http Listener with allowing method as POST, listening to port:8081 and path /patient.

Step 2: Create a POST request in Postman/ARC having an ADT_A04 message as the body.

Step 3: Drag and drop a HL7 EDI read connector and configure the connector as described above.

Step 4: Extract the PID information from the postman/arc body message for patient details.

Step 5: Extract the PV1 and PV2 information from the postman/arc body message for patient visit details.

Step 6: Insert the patient details into the patient object created in salesforce using salesforce connector.

Step 7: Extract the inserted record id,name from salesforce so that look up can be implemented on patient visit object.

Step 8: Insert the patient visit data into the patient visit details object created in the salesforce.

Step 9: Create a Digital experience using the salesforce experience cloud to show the data in real-time.