Abstract

The Health Level 7 (HL7) communication protocol was created to effectively and rapidly share Electronic Health Information (EHI). This standard has been widely used in the medical industry for decades, undergoing continuous development which has produced multiple transmission formats. While HL7 enables efficient medical information sharing, its reliance on outdated communication formats has incurred technical debt, causing healthcare systems to inherit security weaknesses and compatibility limitations. Legacy HL7 implementations often use insecure Application Programming Interface (API) designs that make them easier to exploit, resulting in the theft or tampering of medical data.

Recent medical and legal regulations, combined with data protection requirements, necessitate reassessment of HL7 transmission protocols and API implementations to address their long-standing security issues. To that end, this article examines HL7 protocol development, the architecture of each protocol, and the attack surfaces and vulnerabilities of protocols in use. It also provides defense and mitigation strategies to secure EHI exchange and support regulatory compliance.

What is Health Level 7 (HL7)?

Health Level 7 (HL7), proposed in 1987, derives its name from operating at the application layer–the 7^th layer of the Open Systems Interconnection (OSI) model.
Developed by the Health Level Seven International organization, it is a set of international standards for exchanging, integrating, sharing, and retrieving EHI.¹

HL7 uses automated data exchange instead of manual entry, minimizing errors while saving time and administrative costs.
By making previous results queryable, it avoids duplicate testing.
Furthermore, it provides clinicians with rapid access to comprehensive patient information, enabling more informed decisions and improving patient treatment outcomes.
At the same time, the structured and standardized data provided by HL7 is the foundation for the development of emerging technologies such as artificial intelligence, telemedicine, and population health analysis.²

The following diagram is an example illustrating how HL7 is applied in the healthcare industry:³

• Patient Electronic Medical Record Management: HL7 integration allows hospitals to better manage new patients’ electronic medical record data because it can save time and costs. A patient’s real-time physiological data (blood pressure, pulse, etc.) can be extracted from the Patient Interface and transmitted to a mobile device or to an on-premise or cloud-based EHR (Electronic Health Record) via the HL7 protocol. Patients need to access sensitive information, and healthcare providers must comply with data security protocols. Integrating HL7 can solve both these problems, giving patients access to their medical records while protecting their personal information.
• Seamless Information Exchange Between Hospitals: HL7 enables the unimpeded flow of information between hospitals, thereby greatly improving communication. In addition, FHIR and Web-based APIs also make it easier for medical institutions to share patient health information and expand the knowledge base for the medical community. Taking the above diagram as an example, we can see that using the HL7 standard transmission protocol makes it easy to obtain the patient’s Electronic Health Record (EHR).
• Process Automation: Process automation eliminates the need for manual data entry and tiresome forwarding of data between multiple departments. HL7 integration can synchronize and structure all records, test results, and prescriptions. When a patient is, for example, diagnosed with influenza, the doctor need only enter an ORM order on their terminal to communicate with the pharmacy. The pharmacy can then dispense the medication and the patient can pick it up at a designated location with no middleman or manual steps to deal with.
• Information Sharing with Regulatory Agencies: The healthcare industry is highly reliant on regulation; medical institutions and medical staff must frequently share information with regulatory agencies. Meeting HL7 compliance standards can facilitate and simplify this process.

[1] Health Level 7, Wikipedia, retrieved on Nov. 20th, 2025. https://zh.wikipedia.org/wiki/Health_Level_7

[2] Why HL7 Protocol Matters for Your Healthcare Industry, Qualityze, Jun. 30th, 2025. https://www.qualityze.com/blogs/hl7-protocal-healthcare-industry

[3] Everything you need to know about HL7, Riken Shah, OSP, retrieved on Nov. 25th, 2025. https://www.osplabs.com/insights/everything-you-need-to-know-about-hl7/

HL7 Protocol in a Nutshell

HL7 v2.x

HL7 v2.x is a flexible, segment-based messaging standard and is the most widely used medical standard globally.
Up to 95% of US medical institutions use this version, and all major medical information system vendors support it.
Its format is human-readable ASCII text, using delimiters (such as pipes | and carets ^) to organize data.⁴

Here’s an example of an HL7 v2.4 message:⁵

MSH|^~\&|AccMgr|1|||20050110114442||ADT^A02|59910287|P|2.3|||
EVN|A02|20050110114442|||||
PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111^DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121234|||||||||||NO
PV1|1|I|IN1^214^1^1^^^S|3||PREOP^101^|37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|2|40007716^^^AccMgr^VN|4|||||||||||||||||||1||I|||20050110045253||||||

[4] HL7 Messages Examples: Decoding HL7 Message Structures, Folio3, retrieved on Nov. 20th, 2025. https://digitalhealth.folio3.com/blog/hl7-messages-examples/

[5] HL7 Message Samples, retrieved on Nov. 18th, 2025. https://hl7messageparser.azurewebsites.net/Parse/Samples

MLLP

HL7 v2 messages are not typically transmitted directly over the network as raw text streams. Instead, they are encapsulated in a standard called the “Minimum Lower Layer Protocol” (MLLP).
Since TCP/IP is a continuous bit-stream protocol, the receiving end cannot naturally distinguish the boundaries of messages. The role of MLLP is to provide this delimitation function.⁶

• Start Block (SB): Single byte, ASCII Vertical Tab <VT> (value 0x0B)
• Message Data: The actual HL7 message content.
• End Block (EB): Single byte, ASCII File Separator <FS> (value 0x1C).
• Carriage Return (CR): Single byte, ASCII Carriage Return <CR> (value 0x0D), immediately following the End Block.

A complete HL7 message encapsulated with MLLP looks like this:

<VT>HL7 Message<FS><CR>

[6] HL7 Transport Method: LLP, iNterfaceWare, retrieved on Nov. 20, 2025. https://www.interfaceware.com/hl7-transport-llp

HL7 v3.0

Compared to v2.x, the v3.0 version is more rigorous and complex, focusing on standardizing the entire data exchange process.
Based on the HL7 Reference Information Model (RIM), it aims to resolve the ambiguity of v2 by providing a single, consistent data model with XML-based messaging.
Although technically more robust, its complexity has hindered it from being as widely adopted as v2.x.⁷

[7] FHIR vs. HL7: Which Standard Fits Your Healthcare Project? Kojin, Nov. 5th, 2025. https://kodjin.com/blog/fhir-vs-hl7-key-differences-and-which-is-a-better-choice/

Fast Healthcare Interoperability Resources (FHIR)

FHIR is an HL7 standard designed for modern, API-driven healthcare data exchange. Unlike HL7 v2.x and v3.0, it uses a resource-based data model
(for example, Patient, Observation, and Medication) and defines RESTful interactions for accessing and manipulating those resources.
FHIR natively supports web-friendly formats such as JSON and XML, enabling easier integration with web and mobile applications.
It draws on concepts from earlier HL7 standards while prioritizing interoperability, extensibility, and developer accessibility.⁸

Here’s an example of the medical examination result:⁹

{
"resourceType": "Bundle",
"id": "83260ced-c4a9-4770-9b4a-ef70c30d48b1",
"meta": {
"lastUpdated": "2023-11-13T03:54:20.492+00:00"
},
"type": "searchset",
"total": 1,
"link": [
{
"relation": "self",
"url": "https://hapi.fhir.org/baseR4//DiagnosticReport?subject=Patient%2Fpat-example"
}
],
"entry": [
{
"fullUrl": "https://hapi.fhir.org/baseR4/DiagnosticReport/34597291",
"resource": {
"resourceType": "DiagnosticReport",
"id": "34597291",
"meta": {
"versionId": "1",
"lastUpdated": "2023-11-13T03:28:16.026+00:00",
"source": "#7FkcZ1cB5mgqJ8tu",
"profile": [
"https://twcore.mohw.gov.tw/ig/twcore/StructureDefinition/DiagnosticReport-twcore"
]
},
"text": {
"status": "generated",
"div": "<div xmlns="http://www.w3.org/1999/xhtml"><h3><b>Diagnostic report</b></h3><p><b>Diagnostic status</b>：Remission <span style="background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki">( <a href="http://hl7.org/fhir/R4/valueset-diagnostic-report-status.html">DiagnosticReportStatus</a>#registered)</span></p><p><b>Diagnostic categories</b>：Laboratory <span style="background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki">( <a href="http://hl7.org/fhir/R4/valueset-diagnostic-service-sections.html">DiagnosticServiceSectionCodes</a>#LAB)</span></p><p><b>Patient</b>：<a href="Patient-pat-example.html">Patient/pat-example</a> "Tom Hawk"</p><p><b>Clinical report time</b>：2022-08-01 05:00:14-0500</p><p><b>Diagnostic report time</b>：2022-08-01 06:00:14-0500</p><p><b>Identification of symptoms, problems, or diagnoses</b>：Blood urea nitrogen<span style="background: LightGoldenRodYellow; margin: 4px; border: 1px solid khaki"> ( <a href="http://loinc.org">LOINC</a>#09002C)</span></p><p><b>Diagnostic results</b>：<a href="Observation-obs-lab-example.html">Observation/obs-lab-example</a></p><p><b>Diagnostic</b>：<a href="Practitioner-pra-example.html">Practitioner/pra-example</a> "George Town"</p></div>"
},
"status": "registered",
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0074",
"code": "LAB",
"display": "Laboratory"
}
],
"text": "Laboratory"
}
],
"code": {
"coding": [
{
"system": "https://twcore.mohw.gov.tw/ig/twcore/CodeSystem/medical-service-payment-tw",
"code": "09002C",
"display": "Blood urea nitrogen"
}
],
"text": "Blood urea nitrogen"
},
"subject": {
"reference": "Patient/pat-example"
},
"effectiveDateTime": "2022-08-01T17:00:14-05:00",
"issued": "2022-08-01T18:00:14-05:00",
"performer": [
{
"reference": "Practitioner/pra-example"
}
],
"result": [
{
"reference": "Observation/obs-lab-example"
}
]
},
"search": {
"mode": "match"
}
}
]
}

[8] What Is Healthcare Interoperability? A Simple Guide to Connected Care, Simble, Oct. 7th, 2025. https://www.simbie.ai/what-is-healthcare-interoperability/

[9] https://twcore.mohw.gov.tw/twsample/Home/DiagnosticReport

HL7 Vulnerabilities

HL7 v2.x Attack Surface

HL7 v2.x was originally designed to make information exchange convenient in an era that predated modern security expectations. As a result, there are inherent weaknesses in its security model:

Lack of Native Encryption

The HL7 v2.x standard itself does not require or provide an encryption mechanism for data in transit. Instead, messages are transmitted in plaintext over the network, including sensitive Protected Health Information, leaving the messages exposed to anyone with access to the network.

Weak or Missing Authentication

In addition to plaintext transmission, HL7 v2.x has no built-in authentication mechanism. Any system on the network can connect to an open HL7 communication port (usually TCP 2575) and start sending or receiving messages. Even if there is authentication, it is usually handled at the application level or relies on weak IP address whitelisting. This makes the HL7 interface a prime target for unauthorized access once an attacker gains an initial foothold in the internal network.

No Built-in Data Integrity Verification

HL7 v2.x has no native mechanism to verify whether the message has been altered during transmission. Acknowledgment (ACK) messages only confirm receipt, not the integrity of the message. This opens the door to Man-in-the-Middle attacks (MitM), where attackers can intercept and manipulate key clinical data in many alarming ways, including changing diagnoses, medication dosages, or patient billing information.

Due to the above reasons, the HL7 v2.x protocol is inherently insecure, and attackers can easily launch the following attacks:^10,11

Data Leakage

Since the native HL7 v2.x does not encrypt, attackers can eavesdrop on information within the intranet once they gain access to the victim’s intranet computer. As long as they recognize HL7 v2.x packets (e.g., MSH, PID, etc.), they can begin stealing private information, and then collect or even sell such information.

Attackers can maintain persistence, stealing data over time to ultimately exfiltrate

Data Tampering

Since HL7 v2.x defines no native encryption or integrity controls, attackers can tamper with message contents in transit. Because there is no built-in mechanism to verify message integrity, neither the sender nor the receiver can detect whether a message has been altered. For patients, manipulation of ORM messages used to order medications or diagnostic tests can result in incorrect treatment, missed diagnoses, or inappropriate clinical actions.

By manipulating the medication order, attackers can cause the pharmacy to dispense a dosage ten times higher than prescribed

In terms of billing systems, tampered detailed financial transaction (DFT) messages may cause financial loss or fraud.

By manipulating transaction amounts in transit between clinics and the National Health Insurance (NHI) system, attackers can trigger fraudulent insurance payouts

Denial of Service (DoS)

Since there is no authentication mechanism, medical devices and systems do not limit the number of connections or implement connection timeouts. Attackers can send a large number of requests to overwhelm these devices, paralyzing the medical system.

By flooding a lab system with requests, attackers can overwhelm it and prevent responses to legitimate requests

[10] HL7 Interface Monitoring: 4 Ways to Mitigate Security Risks, retrieved on Nov. 19th, 2025. https://lifepoint.com/hl7-interface-monitoring/

[11] HL7 Data Interfaces in Medical Environments: Attacking and Defending the Achille’s Heel of Healthcare, Dallas Haselhorst, September, 2017. https://www.giac.org/paper/gcia/11917/hl7-data-interfaces-medical-environments-understanding-fundamental-flaw-healthcare/137401

Real-World Example: HL7Magic

At DEFCON 31 in 2023, Katie Inns presented “HL7Magic”, a tool designed to help security testers to proxy, parse, and amend HL7 messages.
This tool demonstrates the feasibility of data tampering attacks by enabling testers to manipulate medical data (such as test results or doctor’s orders) in transit.¹²

[12] HL7Magic: Medical Data Hacking Made Easy, Katie Inns, DEFCON 31, Mar. 26th, 2024. https://labs.withsecure.com/publications/hl7magic–a-tool-for-testing-medical-devices-using-the-hl7-proto

FHIR API Attack Surface

In sharp contrast to HL7 v2.x, the modern FHIR standard has built powerful security considerations into its specifications. It provides guidelines on communication security (recommending TLS), authentication, authorization/access control (recommending OAuth 2.0), audit logging, and data labeling. The “ONC Cures Act Final Rule” in the US promotes patients accessing their EHI via APIs and mandates the use of the FHIR standard, pushing the industry toward more modern and secure interoperability.

Even when security architectures such as authentication and access control are defined, poor vendor implementations continue to expose medical systems to risk. Common failures include non-compliance with security specifications and the use of hardcoded credentials, such as embedded API keys, in production environments.

Example 1: Playing with FHIR

Although the FHIR standard is designed to be more secure than HL7 v2.x, the threat has shifted from the “protocol layer” to the “implementation layer”. At the DEF CON 29 Biohacking Village, Alissa Knight tested 3 production FHIR APIs that served an ecosystem of 48 total apps and APIs, covering aggregated EHR data from 25,000 healthcare providers and payers. Her findings included:¹³

• 100% of tested FHIR APIs had BOLA vulnerabilities: All three production FHIR APIs Knight tested had “Broken Object Level Authorization” (BOLA) vulnerabilities. An attacker using only one patient’s valid login credentials could access other patients’ health data.
  • Attack Scenario: An attacker logs in as “Patient A”, intercepts the API request (e.g., GET /api/Patient/12345), and changes the ID to GET /api/Patient/12346. Since the server fails to authorize the request (only verifying the login), it erroneously returns the entire record of “Patient B”.
• 53% of apps have hardcoded keys: More than half of the mobile applications had API keys and authentication tokens hardcoded in the application code.
• 100% of apps lack certificate pinning: All tested applications did not use certificate pinning, making them vulnerable to Man-in-the-Middle (MitM) attacks.
• 50% of aggregators lack data isolation: Half of the clinical data aggregators failed to implement database segmentation between customers (tenants) in their backend databases, allowing access to patient records belonging to other apps developed on their platform for other providers.

The study concluded that by using just one patient’s login account, an attacker could access sensitive records of up to 4 million patients and clinicians.

[13] Playing with FHIR, Alissa Knight, Mitch Parker, Biohacking Village, DEF CON 29, Sep. 25th, 2021. https://www.youtube.com/watch?v=wrNyd60XPMg

Example 2: Exploitable API Vulnerabilities

In addition to the issues mentioned above, insecure data parsing methods are also common problems with FHIR APIs. Representative vulnerabilities are listed below:

CVE-2024-52007

HAPI FHIR is a complete implementation of the HL7 FHIR standard in Java for healthcare interoperability. To comply with FHIR’s acceptance of XML and JSON formats, the HAPI FHIR core library org.hl7.fhir.core implements message parsing for both formats.

However, when receiving XML messages, the library can leak sensitive host information if external entity access is not properly restricted. This vulnerability occurs when the affected component executes XSLT without disabling XML External Entities (XXE) parsing. An attacker can craft an XML file containing malicious DTD declarations to exfiltrate the contents of system files. For example:¹⁴

<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

This payload would cause the parser to read and return the contents of the system’s password file.

[14] NVD – CVE-2024-52007, NIST, Nov. 8th, 2024. https://nvd.nist.gov/vuln/detail/CVE-2024-52007

CVE-2021-32054

The root cause is the lack of a Content-Disposition header when the server provides HTTP responses for certain files. The Content-Disposition: attachment header is a key instruction telling the browser to “download” the response as a file rather than “render” it in the browser window. If this header is not included, an attacker can upload a malicious JavaScript file disguised as a .jpg or .pdf file. If a victim then accesses the file’s URL through their web browser, the malicious JavaScript can execute, stealing session credentials that can be used to read, modify, or delete patient data via the API.¹⁵

[15] NVD – CVE-2021-32054, May 14th, 2021. https://nvd.nist.gov/vuln/detail/CVE-2021-32054

CVE-2021-32053

This vulnerability stems from the _history operation in the FHIR standard used to query resource history. When the server processes a _history request, the JPA implementation executes a SELECT COUNT statement that requires a full index scan. This type of query consumes significant system resources. When a large number of clients execute _history operations concurrently, the database becomes overwhelmed by these resource-consuming queries, leading to connection pool exhaustion and service unavailability.¹⁶

[16] NVD – CVE-2021-32053, May 10th, 2021. https://nvd.nist.gov/vuln/detail/CVE-2021-32053

Policy and Law Compliance

In order to better protect medical information, some government units have formulated detailed regulations and standards for this type of information exchange:

Health Insurance Portability and Accountability Act (HIPAA)

HIPAA was enacted by the 104th US Congress and signed into law by President Bill Clinton on August 21, 1996. It established standards for protecting Personally Identifiable Information maintained by the healthcare and health insurance industries from fraud and theft. HIPAA’s security requirements include three categories of safeguards: Administrative Safeguards, Physical Safeguards, and Technical Safeguards. Since this article primarily discusses HL7 protocol security, we focus on compliance with Technical Safeguards, which cover access control, audit control, integrity, and transmission security.¹⁷

For HL7 v2.x, due to its aforementioned lack of native encryption, transmission security becomes its main compliance challenge. If an organization exchanges HL7 v2.x information without additional protection such as TLS encryption or VPN transmission, it fails to meet the Technical Safeguards required by HIPAA, despite successfully transmitting HL7-compliant messages.

[17] Health Insurance Portability and Accountability Act, Wikipedia, retrieved on Nov. 11th, 2025. https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

[18] HIPAA security rule & risk analysis, AMA, retrieved on Nov. 11th, 2025. https://www.ama-assn.org/practice-management/hipaa/hipaa-security-rule-risk-analysis

ONC Cures Act Final Rule

Issued by The Office of the National Coordinator for Health Information Technology (ONC) under the 21st Century Cures Act, its core goals are:

1. Promote Interoperability: Ensure that Electronic Health Information (EHI) can be accessed and exchanged securely between different systems, vendors, and healthcare organizations.
2. Empower Patient Control: Allow patients to access and control their own electronic health records.
3. Prohibit Information Blocking: Prohibit healthcare providers, health IT developers, and health information networks from engaging in practices that interfere with, prevent, or materially discourage the access, exchange, or use of Electronic Health Information.

[19] The ONC Cures Act Final Rule, The Office of National Coordinator, retrieved on Nov. 20th, 2025. https://www.healthit.gov/sites/default/files/page2/2020-03/TheONCCuresActFinalRule.pdf

How to Defend/Mitigate?

Encrypt All Data During Transmission

Since HL7 v2.x defines no native encryption or integrity controls, messages must be protected using transport-layer encryption (such as TLS) or network-layer tunneling (such as VPN or IPsec).²⁰

• VPN Tunneling: Routes all HL7 MLLP traffic through an encrypted VPN tunnel between endpoints, protecting cleartext communications.
• MLLP over TLS: Applies TLS encryption directly to the MLLP connection itself. Support varies across different vendors and integration engines.
• Secure File Transfer (SFTP/FTPS): For batch-oriented data exchange, HL7 messages can be transmitted as files via SFTP or FTPS.
• SSH Tunneling: Provides encrypted point-to-point forwarding of HL7 traffic, typically used for limited or temporary connections.

[20] Secure Protocols for HL7 – iNTERFACEWARE Help Center. https://help.interfaceware.com/kb/164

Harden Endpoints and Control Access

In addition to data encryption, authentication and endpoint hardening are critical:

• Implement Network Segmentation and Firewalls: Isolate HL7 interface engines and clinical systems using network segmentation. Use firewalls to strictly restrict traffic to HL7 ports (such as TCP 2575) and only allow connections from authorized IP addresses.
• Strong Authentication and Authorization: Use application-level authentication, or mutual TLS (mTLS), where both client and server present certificates to verify each other’s identity.
• Interface Monitoring and Auditing: Implement continuous monitoring of HL7 interfaces. Log all connections and message transmissions. Use network monitoring tools to detect anomalous activity such as unusually high traffic, connections from unauthorized IP addresses, or malformed messages.

Management and Procedural Safeguards

Human error is also something we need to factor in:²¹

• Conduct Comprehensive Risk Analysis: As required by HIPAA, regularly assess the risks to information transmitted via HL7. This analysis should identify vulnerabilities, threats, and existing controls to inform the implementation of new safeguards.
• Vendor Management: Review the security practices of all vendors connecting to your system via HL7. Enforce security requirements such as VPN use in Business Associate Agreements (BAA) and technical specifications.
• Staff Training and Documentation: Train IT and clinical staff on managing HL7 interfaces and protecting health data by documenting each interface in detail, including data flow, security controls, and designated contacts for maintenance and incident response.

[21] HIPAA security rule & risk analysis. https://www.ama-assn.org/practice-management/hipaa/hipaa-security-rule-risk-analysis

Conclusion

HL7 v2.x unified and accelerated medical record delivery, while FHIR provides modern protocol-level security capabilities. However, HL7 v2.x transmits data in cleartext, and FHIR implementations suffer from authentication flaws and insecure API designs, creating significant risks to electronic health information. To ensure secure and compliant transmission of medical data, organizations must address both legacy HL7 v2.x vulnerabilities and FHIR implementation issues through network segmentation, encrypted transmission, and strong authentication controls.

Protect Your Medical Assets

• Implement firewall allowlists that permit only authorized devices to transmit HL7 traffic.
• Use TXOne EdgeIPS to detect HL7 traffic and configure appropriate access controls to protect system stability and security.
• To reduce attack surface, inventory network assets and disable HL7 on devices that do not require it.