EHR/EMR Medical Device Integration

Why this matters

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 3, 2026 final guidance) treats every external interface as a documented attack surface. EHR connectivity is no longer an "IT integration detail" left to the hospital, it is a labeled data flow that must appear in the Security Architecture Views, the threat model, and the labeling provided to the Health Delivery Organization (HDO).

Section 524B of the FD&C Act applies to any device that includes software and has the ability to connect to the internet, and the HSCC Joint Security Plan and MDS2 disclosures both require manufacturers to describe how the device authenticates, encrypts, and logs each EHR interface. Verizon's 2024 Data Breach Investigations Report attributes a disproportionate share of healthcare breaches to credential compromise and lateral movement through integration infrastructure, which is exactly where HL7 interface engines sit. Reviewers know this, and "we use the hospital's integration engine" is not an acceptable answer on its own.

EHR vs EMR: what's the actual difference?

EMR (Electronic Medical Record) is the digital chart inside a single practice or hospital. It replaces the paper folder, but it does not travel between organizations.

EHR (Electronic Health Record) is designed to be shared across providers, hospitals, labs, pharmacies, and the patient. It supports interoperability standards (HL7 v2, FHIR, C-CDA), patient portals, and cross-organization exchange through networks like Carequality and TEFCA.

In day-to-day conversation the two terms are used interchangeably, but the FDA, ONC, and HHS consistently use EHR when they mean the interoperable, networked system. For medical device cybersecurity, that distinction matters because the attack surface lives in the interoperable layer: the FHIR API, the HL7 interface engine, the integration middleware. An "EMR-only" device with no outbound interfaces has a much smaller threat surface than an "EHR-integrated" device that pushes observations through a hospital integration engine.

Which EHRs do medical devices actually connect to?

There is no single EHR market. Five vendors dominate inpatient care, and a longer tail covers ambulatory practices.

Most device manufacturers do not maintain a separate connector per vendor. Instead they integrate once with a hospital-side integration engine, or they use an API broker (Redox, Datica, 1upHealth) that normalizes the differences between EHR FHIR implementations.

How the integration actually works: engines and protocols

Integration engines

The integration engine is the broker between the device and the EHR. Common ones:

• Rhapsody (Lyniate), large hospital deployments
• Mirth Connect (NextGen), widely used, often the cheapest tier
• Corepoint (Lyniate), common in mid-market hospitals
• InterSystems Ensemble / IRIS, Epic shops often run this

The engine normalizes messages, applies routing rules, and writes to the EHR. From the device's point of view it is just a TCP endpoint on the hospital LAN.

Protocols

• HL7 v2 over MLLP (Minimal Lower Layer Protocol), the workhorse for observations (ORU), orders (ORM), and ADT. Cleartext TCP by default, no built-in authentication.
• FHIR (Fast Healthcare Interoperability Resources), modern REST/JSON, OAuth 2.0, SMART on FHIR for app authorization. Required for ONC-certified EHRs under the 21st Century Cures Act.
• DICOM, imaging modalities, with DIMSE over TCP and DICOMweb over HTTPS.
• IHE profiles (PIX, PDQ, XDS, ATNA), interoperability profiles layered on top of HL7 and DICOM for cross-enterprise scenarios.
• C-CDA documents, exchanged less often by devices, more often by EHRs themselves.

Cybersecurity risks unique to EHR integration

The risks below are the ones that recur on actual pen tests and in actual FDA deficiency letters.

Unauthenticated MLLP feeds

HL7 v2 over MLLP has no native authentication, no encryption, and no integrity check. "It's on a private VLAN" is the standard defense and the standard finding. Once an attacker reaches that VLAN through any compromised endpoint, they can inject ADT, ORM, or ORU messages, change demographic data, or replay observations. The fix is TLS-wrapped MLLP, mutual auth where the engine supports it, and a Bump-in-the-Wire gateway if the device cannot natively do TLS.

FHIR token scope creep

SMART on FHIR scopes are granular (patient/Observation.write, user/Patient.read), but device integrations are often given */* or wildcard resource scopes "to keep things moving during onboarding." Long-lived refresh tokens compound the problem. If the device is compromised, the attacker inherits the same scope.

PHI in interface logs

See also: Home Use vs Hospital Device Cybersecurity Requirements, Indications for Use, Predicates, and Cybersecurity Scope, and Breakthrough Device Designation and Cybersecurity.

Integration engines log message contents for debugging. Those logs accumulate PHI and frequently land in centralized logging stacks that have weaker access controls than the EHR itself. This is both a HIPAA finding and a cybersecurity finding because the log store becomes a high-value target.

Integration engine as lateral-movement pivot

The engine talks to the EHR, the device network, the LIS, the RIS, and often the ADT broadcast. Compromising it gives an attacker east-west access across the hospital. Devices that share credentials with the engine (a common shortcut) extend the blast radius onto the device fleet.

Vendor-supplied shared service accounts

Many devices ship with a single integration account whose password is documented in the install guide and is rarely rotated. The FDA increasingly asks for per-instance credentials and a documented rotation path in labeling.

MITM on intra-hospital VLANs

ARP spoofing and rogue DHCP remain effective inside hospital VLANs that were architected before zero trust was a phrase. Devices that fall back to plaintext when TLS negotiation fails are particularly exposed.

What the FDA expects in the submission

Under the Feb 3, 2026 guidance, EHR connectivity has to show up in four places:

1. Data Flow Diagram(s), each EHR interface as a data flow crossing a trust boundary, with the protocol labeled (MLLP, FHIR/HTTPS, DICOM).
2. Security Architecture Views, the Global System View must show the device's position relative to the integration engine and EHR; the Multi-Patient Harm View must address whether a compromised interface can affect more than one patient. See our Security Architecture Views post for the four-view structure.
3. Threat Model, STRIDE entries for each interface, covering spoofing of the integration source, tampering of HL7 messages, repudiation through shared accounts, information disclosure through logs, denial of service on the MLLP listener, and elevation of privilege through over-scoped FHIR tokens.
4. Labeling to the HDO, required network configuration, supported TLS versions, credential management expectations, and any IHE profiles the device implements.

The interoperability section of the labeling should also reflect the FDA's Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices, and align with HSCC JSP and MDS2 disclosures.

Talk to us about your EHR integration documentation →

How Blue Goat approaches EHR-integrated devices

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. For EHR-connected devices we run the integration surface as a first-class threat-model boundary, not an afterthought. Every interface gets a data flow, a STRIDE row, and a labeled control, and we test the actual protocol behavior (MLLP fallback, FHIR scope enforcement, certificate validation) rather than trusting the spec.

We deliver the full Feb 3, 2026 guidance documentation set scoped to your integration profile, integrated with your IEC 62304 software lifecycle and ISO 14971 risk file. See our medical device cybersecurity services for scope. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

To turn these risks into submission-ready evidence, see our medical device threat modeling service.

FAQ

What's the difference between an EHR and an EMR?

An EMR (Electronic Medical Record) is the digital chart for one practice or hospital and does not travel between organizations. An EHR (Electronic Health Record) is built for interoperability across providers, labs, pharmacies, and the patient, using standards like HL7 v2 and FHIR. Medical devices that connect to "the chart" almost always connect to an EHR, because that is where the interoperable interfaces live.

Which EHRs do medical devices most commonly integrate with?

In US hospitals, Epic and Oracle Health (Cerner) dominate, with MEDITECH a strong third in community hospitals. In ambulatory care, Allscripts/Veradigm, athenahealth, eClinicalWorks, and NextGen cover most of the market. Most device manufacturers do not write a per-vendor connector; they integrate once with a hospital integration engine or with an API broker such as Redox.

Is HL7 v2 secure on its own?

No. HL7 v2 over MLLP is cleartext TCP with no built-in authentication, encryption, or integrity checks. It is safe only when wrapped in TLS, restricted to authenticated peers, and segmented onto a trust-boundary-controlled network. Assuming the hospital VLAN is "internal and therefore safe" is the most common interoperability finding on pen tests.

Does FHIR fix the security issues with HL7 v2?

Mostly, yes. FHIR uses HTTPS, OAuth 2.0, and SMART on FHIR scopes, which gives you authentication, encryption, and granular authorization out of the box. The recurring problems are operational: over-broad scopes, long-lived refresh tokens, and weak certificate validation. The protocol gives you the tools; the integration team has to use them correctly.

Do I need to document EHR integration in my FDA submission?

Yes. Under the Feb 3, 2026 premarket cybersecurity guidance, every external interface, including EHR connections, must appear in the device's data flow diagram, Security Architecture Views, threat model, and labeling to the HDO. "We hand the data to the hospital's integration engine" is not sufficient on its own.

What is an integration engine and do I need one?

An integration engine (Rhapsody, Mirth Connect, Corepoint, InterSystems) is hospital-side middleware that brokers messages between devices, the EHR, the LIS, and other systems. The device does not own it, but the device's threat model has to include it as an external entity with a trust boundary, because compromising the engine is a realistic path to compromising the device fleet.

CTA

Building or revising a connected device that touches an EHR? We'll map every interface to a DFD, Security Architecture View, and STRIDE entry, and pen-test the actual protocol behavior so the FDA does not find it first. Schedule a discovery session →