How to Build a HIPAA-Compliant IoMT Data Pipeline: From Device to EHR

Connecting a single IoMT device to a single hospital system sounds like a weekend project. Building a pipeline that holds up across hundreds of devices, multiple hospital partners, and an OCR audit is a different problem altogether.

The stakes are rising for everyone building in this space.

A typical U.S. hospital now runs 10 to 15 connected medical devices per bed, and an independent Claroty study found that 99% of hospitals and health delivery organizations manage at least one IoMT device with a known exploited vulnerability.

The average healthcare data breach now costs USD 10.22 million in the United States, and HHS has proposed updates to the HIPAA Security Rule that would make encryption of ePHI at rest and in transit, along with multi factor authentication, mandatory rather than optional, with limited exceptions.

That rule is still pending final approval as of mid 2026, but the direction is clear.

For scaleup health IT teams, this means every new device integration is a new attack surface to defend. For device manufacturers and CRO teams, it means the pipeline itself can become a regulatory liability if it's not built correctly from day one.

Let's know the exact pipelines you need to keep a close watch on.

5 Major Layers of a Compliant IoMT Pipeline

A useful way to think about this is as five distinct layers, each with its own job and its own compliance requirement.

Most pipeline failures we see don't happen at the device. They happen in the handoff between layers, especially between ingestion and storage, where teams assume "it's already encrypted upstream" and skip a step.

Read More: Epic EHR Integration for Startups: Timeline, Cost, and What Actually Breaks

Where HIPAA's Technical Safeguards Actually Apply

The HIPAA Security Rule doesn't talk about "pipelines." It talks about safeguards. Here's how those safeguards map onto the layers above.

The proposed 2025 to 2026 update to the Security Rule would also require vulnerability scans every six months and penetration testing annually, plus a 24 hour notification window for changes in workforce access. Building these checks into your pipeline now, rather than after the rule finalizes, puts you ahead rather than scrambling.

Mapping Device Data Into FHIR

Once data clears the security layer, it still has to land somewhere clinicians can use it. This is where most teams discover that wearable and IoMT data doesn't behave like a standard lab value.

A few things to plan for:

• Device resource: identifies the device, manufacturer, and software version
• Observation resource: carries the actual reading, but continuous data usually needs to be aggregated into time windows before it's sent, not streamed reading by reading
• DeviceMetric resource: defines what the device measures and at what precision

Sending raw, unaggregated readings straight into FHIR works fine in a demo and falls over once you're handling real patient volume across multiple devices. Most teams solve this by aggregating at the processing layer and keeping raw data in a separate time series store for audit purposes.

If your team hasn't mapped this out yet, with FHIR R4 integration you can get a clear resource mapping in depth, and see through the authentication layer that sits between your pipeline and the hospital's EHR.

Getting Data Into Epic, Cerner, and Athena

This is usually where scaleup teams lose the most time, since each EHR vendor has its own sandbox process and its own quirks.

Business Associate Agreements: Layer Teams Forget

If your pipeline uses a third party gateway, an aggregator, or a cloud vendor at any point, that vendor needs to be covered under a Business Associate Agreement (BAA). This is one of the most common gaps we find during audits, especially when teams add a new vendor mid project and forget to update their BAA coverage.

The proposed Security Rule update goes further, requiring business associates to directly verify their compliance with safeguards and contingency plans within 24 hours of activation. If you're still building your BAA program, make sure to check out a detailed BAA programme guide that walks through the major mistakes that most often trigger OCR enforcement.

Beyond HIPAA: When Other Frameworks Also Apply

Most pipelines built for the US market eventually need to handle data from other regions too, especially as CROs run global trials and scaleups expand into the UK or GCC.

• GDPR applies if your pipeline touches EU patient or partner data, even if your main operations are US based
• NABIDH and similar GCC frameworks apply if you're handling data from UAE or Saudi hospital partners
• ISO 13485 matters if you're a device manufacturer, regardless of which country you're selling into

You can take the help of a good GDPR for HealthTech insight that covers what your architecture needs to handle if EU data passes through your pipeline at any point.

Read More: GDPR for HealthTech in 2026: What Your Architecture Must Handle

5 Major Pipeline Mistakes That Fail Security Review

1. Assuming "encrypted upstream" covers the whole pipeline. Encryption at one layer doesn't guarantee encryption at the next.
2. Adding a new vendor without updating BAA coverage. This is the single most common gap found in audits.
3. Streaming raw device readings straight into FHIR. Works in testing, fails under real patient volume.
4. Treating audit logging as a "nice to have." It's a required safeguard, not an optional feature.
5. Building for one hospital's EHR configuration. What works at one Epic deployment may not transfer to the next.

A Pre-Build Checklist

Conclusion

A HIPAA compliant IoMT pipeline isn't one integration. It's five layers working together, each with its own safeguards, and most failures happen in the handoffs between them rather than at the device itself. Scaleup health IT teams and device manufacturers face the same underlying challenge from different angles: proving to hospital partners and regulators that data moves from device to EHR without creating a liability along the way.

The teams that map encryption, access control, and BAA coverage to every layer, and that plan FHIR mapping before they hit production volume, move through security reviews and EHR sandboxes far faster than the teams that patch these gaps after an audit flags them. With the HIPAA Security Rule update on the horizon, building this discipline in now puts you ahead rather than catching up later.