Integrating Wearables & IoT with Epic: HL7 V2 vs FHIR Approaches

Posted in EPIC

The wearables market in healthcare is projected to reach $69.2 billion by 2028, with continuous glucose monitors, smartwatches, and IoT-enabled vital sign devices feeding patient data directly into clinical workflows. When your medical device or health app needs to connect to Epic, you face a critical decision: use HL7 V2 vs. the FHIR standard. HL7 V2 dominates existing healthcare infrastructure, which means most Epic integrations are deep with pipe-delimited messages and event-driven interfaces. But FHIR offers what device makers increasingly need: real-time bidirectional data flow, lightweight JSON payloads, and the ability to push observations directly into patient records without custom ETL pipelines. The choice affects your time-to-market, maintenance costs, and whether your integration scales across multiple EHR vendors.

Understanding Device Integration Requirements

Before comparing protocols, understanding what device integration actually demands is a given. When a connected glucose monitor sends a reading, that data isn’t simply pushed into Epic. It requires translation, validation, authentication, and mapping into Epic’s internal data model.

• The raw sensor data from the device travels over cellular or Bluetooth to a cloud platform
• It is then shaped into either an HL7 V2 message or a FHIR request, and crosses network boundaries with security validation
• The data arrives at Epic’s integration engine, gets parsed and normalized, and finally lands in the patient’s chart. 

At any of these steps, your choice of protocol defines whether the process takes weeks or months to implement or whether it handles real-time updates or batch jobs. 

Most healthcare IT teams treating HL7 V2 as the default aren’t wrong, but they’re often overlooking what’s changed. Epic now natively supports FHIR, newer devices expect REST APIs rather than persistent TCP connections, and patients increasingly own wearables that no one designed keeping HL7 integration in mind.

HL7 V2

HL7 V2 remains the foundation of healthcare data exchange. It’s the protocol your IT department already knows. Nearly every hospital has HL7 V2 interface engines running 24/7, converting patient admissions, lab results, and orders between systems.

How HL7 V2 Device Integration Works

When a device needs to send data via HL7 V2, you’re creating structured messages using a pipe-delimited format. An observation from a connected patient monitor might arrive as:

MSH|^~\&|DeviceApp|CloudPlatform|EpicApp|Hospital|202405201400||ORU^O01|MSG0001|P|2.5

PID|1||PatientID123^MRN||Patient^John^^||19700101|M

OBX|1|NM|HR^Heart Rate|1|72|bpm|60-100|N|||F

OBX|2|NM|BP^Blood Pressure|1|138/88|mmHg|<140/90|N|||F

This message notifies Epic that it’s receiving observation results (ORU) from a device, here’s the patient ID, and here are two vital signs. Epic’s integration engine decodes this format, maps it to internal fields, and stores it.

Epic expects HL7 V2. Your hospital’s integration team has years of experience with it. Message types like ORU (Observation Result Unsolicited) were literally designed for this use case—a device sending unsolicited clinical data.

But three problems emerge with device integration specifically:

Problem 1: Connection Model

HL7 V2 is event-driven, not query-driven. Your device sends a message; the system receives it. You can’t easily ask “what’s the patient’s current glucose reading?” You can only send new readings. For wearable integrated solutions that update every 5 minutes, that’s hundreds of messages daily per patient, hitting database row limits and creating chart bloat.

Problem 2: Custom Mapping 

Each device manufacturer formats data slightly differently. A Fitbit sends steps and heart rate; a continuous glucose monitor sends glucose readings with trend arrows; a blood pressure cuff adds SpO2. Your HL7 V2 interface requires custom Z-segments (proprietary extensions) for each device type, and those extensions need out-of-band documentation so Epic’s team understands them.

Problem 3: Bidirectional Friction 

If you need to push settings back to the device (e.g., alert thresholds configured in Epic), HL7 V2 forces you to build a separate outbound message type. It wasn’t designed for request-response patterns.

When HL7 V2 is Still Valid 

You should stick with HL7 V2 if you’re integrating with Epic installations that explicitly mandate it, or if your device architecture already sends batch data once daily. Are glucose logs exported from a device’s cloud account to Epic overnight? HL7 V2 works perfectly. It’s also the right choice if your target hospitals have legacy IT departments with HL7 expertise but limited FHIR implementation.

The cost difference also matters: HL7 V2 integration tooling is cheaper and faster to prototype. You can build a proof-of-concept in 2-3 weeks using standard interface engine templates.

FHIR: The Modern API-First Alternative

FHIR represents a fundamental rethinking of healthcare data exchange. Instead of monolithic message types, FHIR breaks healthcare data into modular “resources”: a Patient resource, an Observation resource, a Device resource, and a Goal resource. Each resource is its own entity, queryable, updatable, and referenceable.

How FHIR Device Integration Works

With FHIR, your device sends an HTTP POST request containing a JSON observation:

{

  “resourceType”: “Observation”,

  “id”: “glucose-reading-001”,

  “status”: “final”,

  “category”: [{ “coding”: [{ “system”: “http://terminology.hl7.org/CodeSystem/observation-category”, “code”: “vital-signs” }] }],

  “code”: { “coding”: [{ “system”: “http://loinc.org”, “code”: “2345-7”, “display”: “Glucose [Mass/volume] in Serum or Plasma” }] },

  “subject”: { “reference”: “Patient/12345” },

  “effectiveDateTime”: “2024-05-20T14:00:00Z”,

  “valueQuantity”: { “value”: 145, “unit”: “mg/dL”, “system”: “http://unitsofmeasure.org”, “code”: “mg/dL” }

}

This is human-readable. A clinician can glance at it and understand what it says. The patient reference (Patient/12345) directly links to the patient record. 

The LOINC code (2345-7) uniquely identifies “glucose in serum” across all healthcare systems. Epic’s FHIR server accepts this, validates it against a profile (e.g., US Core Observation Profile), and stores it.

4 Advantages of the FHIR Standard

1. REST Architecture

You send HTTP requests and get HTTP responses. No persistent TCP connections, no special interface engines needed. Standard cloud architecture tools handle it. Your device already knows HTTP.

2. Query Flexibility

You can ask Epic for current observations: “GET /Observation?patient=12345&code=2345-7&_sort=-date&_count=10” returns the 10 most recent glucose readings. With HL7 V2, you’d have to query a separate data warehouse or build custom reporting.

3. Reusability Across Vendors

The same FHIR request works for Epic, Cerner, and Athena. You don’t need vendor-specific Z-segments. This is transformative for device makers selling to multiple hospital networks.

4. Bidirectional by Design

FHIR naturally handles request-response patterns. Want to send a Goal resource to Epic (e.g., “maintain glucose below 120 mg/dL”), then later retrieve updates to that goal? FHIR was built for this.

But FHIR adoption in device integration isn’t frictionless. Epic’s FHIR capabilities are still maturing. Most of the healthcare industry still uses HL7 V2. And while FHIR reduces custom code, it increases the need for standards knowledge—you need to understand FHIR Profiles, which constrain and extend base resources for specific use cases.

Real-World Epic FHIR Limitations

Epic supports FHIR, but not equally across all workflows. FHIR read operations (pulling data from Epic) work reliably for patient demographics, allergies, and recent lab results. But FHIR write operations (pushing device data into Epic) are more variable. Some Epic instances allow direct Observation writes via FHIR; others require you to go through a legacy HL7 interface for certain data types. You need to validate this with each hospital before committing to a FHIR-only approach.

Also, FHIR requires more upfront investment in standards. Your team needs to understand US Core Implementation Guides, profile conformance, and how Epic’s FHIR server differs from the base FHIR spec. HL7 V2 expertise is cheaper to hire; FHIR expertise is still scarce.

HL7 V2 vs FHIR for Device Integration

Factor	HL7 V2	FHIR
Protocol Type	Message-based, event-driven	API-based, resource-oriented
Data Format	Pipe-delimited text	JSON or XML
Connection Model	Persistent TCP or batch file transfer	HTTP REST, stateless
Real-Time Updates	Works, but creates message volume	Native; query-driven and efficient
Multi-Vendor Compatibility	Requires vendor-specific customization	Standardized across EHR vendors
Bidirectional Communication	Custom outbound messages required	Native request-response
Implementation Time	2-4 weeks (proof-of-concept)	4-8 weeks (standards learning curve)
Maintenance Burden	Moderate; vendor updates require interface re-tuning	Lower long-term; standards-based
Epic Native Support	Deep; HL7 V2 is Epic’s foundation	Growing; varies by Epic version and workflow
Learning Curve	Low; healthcare IT knows this	Higher; requires standards education
Scalability to Multiple Devices	Each device type requires custom Z-segments	Single standardized request pattern

Hybrid Integration: When You Use Both

Many hospitals run a hybrid model. They use FHIR APIs for device data ingestion (your continuous glucose monitor sends readings via FHIR), but their downstream reporting still consumes HL7 V2 feeds from Epic into the data warehouse. 

Or they accept FHIR reads (pulling patient allergies to display in your app), but require HL7 V2 for writes into the clinical documentation system.

Build your device integration on FHIR if you control your roadmap and your target hospitals have modern Epic deployments. Use FHIR as the ingestion layer, and let Epic’s integration engine handle any downstream HL7 V2 requirements. This gives you the flexibility benefits of FHIR while protecting against older hospital installations.

If you’re forced to support hospitals with strict HL7 V2 requirements, consider using an integration platform that abstracts the protocol difference. Build your internal data model once, then output both HL7 V2 and FHIR from the same source.

Technical Mapping Challenges

HL7 V2 Mapping Decisions

With HL7 V2, you’re mapping device fields to OBX segments. A glucose device sends:

• Reading value
• Timestamp
• Trend arrow (trending up, stable, trending down)
• Signal strength (for wireless devices)

In HL7 V2, you might map signal strength to a Z-segment because it’s not a standard clinical field. Epic’s interface team sees a Z-segment labeled ZGD|SIGNAL|4, but without documentation, they don’t know if 4 means “excellent,” or if it’s a percentage, or if it even matters for the patient record. 

FHIR Mapping Clarity

With FHIR, the same signal strength becomes an extension:

“extension”: [

  {

    “url”: “http://yourcompany.com/StructureDefinition/device-signal-strength”,

    “valueDecimal”: 4.0

  }

]

The extension has a URL that points to documentation. Epic’s FHIR engine can understand what it is by resolving the URL. There’s still an implementation agreement needed, but it’s structured and standardized.

Implementation Roadmap: HL7 V2 and FHIR

Once you’ve decided between HL7 V2 and FHIR, the implementation follows a predictable path:

Phase 1: Epic Connectivity Audit (Week 1-2) 

Determine which Epic instances you’re connecting to, their versions, and whether they support your chosen protocol for device data. Many hospitals have legacy Epic installations that are HL7 V2-only. Others have newer versions with robust FHIR support.

Phase 2: Data Mapping Definition (Week 3-5)

Map your device’s output fields to the protocol. If HL7 V2, build the message schema and Z-segments. If FHIR, choose which profiles apply (US Core Observation, Apple HealthKit mapping, etc.) and define extensions.

Phase 3: Interface Engine Configuration (Week 6-8) 

Deploy and test the integration. For HL7 V2, this means setting up an HL7 sender and receiver. For FHIR, this means implementing OAuth token exchange and REST endpoint validation.

Phase 4: Pilot Testing (Week 9-12)

Run test data through with a target hospital. Send sample glucose readings. Verify they appear in the patient chart. Confirm they trigger any downstream workflows (e.g., alerts if glucose exceeds thresholds).

Phase 5: Live Deployment and Monitoring (Week 13+)

Go live with a small patient cohort, monitor error rates, and scale up.

For HL7 V2, this timeline is achievable. For FHIR, the back-loaded design phase adds time, but the testing and deployment phases move faster because the protocol is cleaner.

Security and Compliance: HL7 V2 vs FHIR

• Both protocols sit on top of HIPAA-compliant transport layers. HL7 V2 traditionally uses SFTP or SSH. FHIR uses HTTPS with TLS encryption. From a compliance perspective, they’re equivalent if configured correctly.
• But FHIR has a subtle advantage: it’s native to modern cloud architecture. HTTPS is what your device’s cloud infrastructure already uses. HL7 V2 forces you to maintain separate SFTP or HL7 over TCP infrastructure, which increases your operational security surface area.
• For authentication, FHIR uses standard OAuth 2.0 or mutual TLS. Your device makes an API request with a bearer token. HL7 V2 typically uses API keys embedded in messages or pre-shared secrets for connection setup. Both work, but OAuth is more auditable at scale.

Folio3 Digital Health’s Connector: Decode Health 

Decode Health is the missing link in your healthcare systems. Folio3 Digital Health’s smart, ready-to-use connector effortlessly bridges the gap between massive hospital platforms like Epic and your everyday imaging tools, labs, and modern apps. By translating complex data behind the scenes in real-time, Decode Health eliminates the frustrating roadblocks of disconnected software. It’s not just an integration engine; it is the key to making your entire healthcare ecosystem finally work perfectly together as one.

Closing Note

HL7 V2 remains essential for hospitals with legacy infrastructure, but FHIR represents the trajectory of healthcare IT. Within the next few years, new Epic instances will likely default to FHIR-first architectures. Your device should be prepared for both.

If you’re starting a new integration, recommend FHIR to your hospital partners and design with FHIR as your primary path. Make HL7 V2 support an afterthought that works if needed, not your main architecture. This future-proofs your integration. If you’re retrofitting an existing device into hospitals, audit each deployment, understand their protocol preferences and capabilities, and implement the path of least resistance, which is often a hybrid model where FHIR handles new data flows and HL7 V2 continues managing legacy systems.

Frequently Asked Questions

What’s the main difference between HL7 V2 and FHIR for device integration?

HL7 V2 is message-based and event-driven. Your device sends unsolicited messages to Epic. FHIR is API-based and resource-oriented. Your device sends HTTP requests to Epic’s FHIR server and can query data back. For wearables and IoT devices, FHIR’s request-response model is cleaner because devices already use HTTP.

Can a device integration be built that works with both HL7 V2 and FHIR?

Yes. Team from Folio3 Digital Health can help you work this out in detail. 

How long does FHIR integration with Epic take?

A proof-of-concept typically takes 4-8 weeks: 2-3 weeks to design the FHIR profile mapping, 2-3 weeks to build and test the API integration, and 2-4 weeks for hospital validation and deployment. HL7 V2 is slightly faster (2-4 weeks) because the tooling is more mature, but you’ll spend more time on custom field mapping.

What’s the cost difference between HL7 V2 and FHIR integration?

Initial development costs are similar (roughly $20-40K for a proof-of-concept either way). But HL7 V2 creates higher long-term maintenance costs because each hospital’s custom Z-segments and field mappings require tweaking. FHIR’s standards-based approach reduces long-term vendor lock-in and customization burden.

Does Epic natively support FHIR for observation data?

Epic supports FHIR reads for observations reliably. FHIR writes for observations depend on your specific Epic version and configuration. Always validate with your target hospital whether they allow direct Observation POST requests via FHIR, or if they require HL7 V2 for writes.

Is HL7 FHIR integration more secure than HL7 V2?

Both are equally secure if configured correctly. FHIR uses standard HTTP/TLS and OAuth 2.0, which modern security teams understand immediately. HL7 V2 traditionally uses SSH/SFTP, which is also secure but requires dedicated healthcare IT infrastructure. The advantage goes to FHIR for ease of deployment in cloud environments.

Can I use FHIR for real-time device alerts in Epic?

Yes. You can POST an Observation to FHIR with a status that flags it for alerting (e.g., abnormally high glucose). Many hospitals configure Epic workflows to trigger alerts based on observation values. This works with FHIR as effectively as HL7 V2, and often faster because you’re not waiting for message batches.

Does one need OAuth for FHIR, or can I use API keys?

FHIR can work with either OAuth 2.0 (preferred) or mutual TLS. Epic supports OAuth. Using OAuth is more scalable and auditable, especially if you’re integrating multiple hospitals. API keys work but are harder to rotate and revoke at scale.

Can wearable data (steps, heart rate, sleep) integrate via HL7 V2?

Yes, but awkwardly. Steps and sleep duration don’t map neatly to HL7 V2’s clinical focus. You’d likely use Z-segments for custom extensions. With FHIR, they map cleanly to Observation resources with standard SNOMED/LOINC codes. FHIR is better suited for consumer wearable data.

About the Author