What's the difference between FHIR and HL7 v2?

HL7 v2 is a legacy, pipe-delimited messaging standard that relies on a client-server model and is still used in over 80% of US hospitals for basic data exchange. FHIR (Fast Healthcare Interoperability Resources) is a modern, RESTful API standard that uses JSON or XML, allowing for granular, web-based data queries. While v2 is great for batch processing, FHIR enables real-time, mobile-friendly integration and is the mandated standard for new US hospital systems under the 21st Century Cures Act.

Does wearable device data entering EHR require FDA approval?

The data transmission itself does not require FDA approval, but the wearable device generating the clinical data usually does. If the device is intended to diagnose, treat, or monitor a medical condition, it requires FDA 510(k) clearance or De Novo classification in the US, or CE MDR approval in Europe. The EHR integration software acting as a simple data pass-through is generally considered non-medical device software (MDS), but if it alters or interprets the data, it may trigger regulatory scrutiny.

Does your API support Epic?

Yes, our native FHIR R4 API is fully compatible with Epic's SMART on FHIR framework. We provide pre-built connectors and comprehensive SDKs that map our wearable data payloads directly to Epic's required FHIR resources, specifically targeting the Epic Clarity database and SMART app integration. We also support Oracle Health (Cerner) and Meditech through similar FHIR-based workflows.

How long does a typical EHR integration project take?

A realistic timeline for a full clinical integration with a major EHR like Epic or Cerner is 12 to 16 weeks. This includes 2-3 weeks for environment setup and sandbox testing, 4-6 weeks for API mapping and development, 3-4 weeks for User Acceptance Testing (UAT) with clinical staff, and 2-3 weeks for go-live preparation and security audits. Beware of vendors promising integration in under 4 weeks; they are likely only offering a basic data dump, not a true clinical workflow integration.

What patient data security certifications should I look for?

Look for vendors who can sign a HIPAA Business Associate Agreement (BAA) in the US, or a GDPR Data Processing Agreement (DPA) in Europe. For technical security, SOC 2 Type II compliance is the industry baseline. Additionally, under the FDA's October 2023 cybersecurity guidance, the vendor must provide a Software Bill of Materials (SBOM) and demonstrate a secure Software Development Life Cycle (SDLC) with regular penetration testing and vulnerability disclosure protocols.

How to Integrate Wearable Health Data with Hospital EHR Systems: HL7 FHIR Guide for Medical Device Buyers

Why EHR Integration Is the Core Hospital Procurement Requirement in 2026

In late 2024, a mid-sized hospital network in Ohio purchased 500 smartwatches for a remote patient monitoring pilot. The hardware was excellent, measuring continuous heart rate and SpO2 with clinical-grade accuracy. But the IT department hadn’t properly vetted the data export capabilities. Nurses ended up spending 45 minutes per shift manually transcribing readings from a patient portal into Epic. The pilot collapsed in three months, wasting roughly $120,000 in hardware and administrative costs.

That failure wasn’t about the sensors. It was about data plumbing.

When we started manufacturing medical wearables back in 2011, hospital procurement officers rarely asked about data integration. They cared about battery life, sensor accuracy, and strap comfort. Those metrics still matter, but the procurement landscape has fundamentally shifted. Today, the integration question comes before the hardware question in hospital RFPs. If your device cannot push data directly into the hospital’s Electronic Health Record (EHR) system, it is essentially a consumer gadget, not a medical tool.

This shift is heavily driven by the 21st Century Cures Act and the subsequent information blocking rules enforced by the Office of the National Coordinator for Health IT (ONC). Hospitals face severe financial penalties if they restrict patient access to their health data or fail to adopt interoperable systems. According to a 2025 report by MarketsandMarkets, the global healthcare interoperability solutions market is projected to reach $4.5 billion by 2028, growing at a CAGR of 11.2%. Hospitals are actively consolidating their vendor lists, preferring medical device manufacturers who can prove seamless EHR connectivity over those who offer standalone apps.

If you are sourcing OEM wearable devices for a digital health initiative, evaluating the vendor’s API architecture is just as important as evaluating their ISO 13485:2016 quality management system.

Medical Data Interoperability Standards Overview

Navigating healthcare data standards can feel like learning a new language while the conversation is already happening. Over the last 15 years, I have watched the industry transition from proprietary serial cables to modern RESTful APIs. To make informed purchasing decisions, you need to understand the four primary standards governing medical data exchange.

**HL7 v2 (Health Level Seven Version 2)**
This is the legacy workhorse of healthcare IT. Introduced in the 1980s, HL7 v2 uses a pipe-delimited text format (e.g., `PID|1||12345^^^MRN…`). Despite its age, it still powers over 80% of US hospitals for basic admission, discharge, and transfer (ADT) messaging, as well as order and result reporting. It is highly reliable for batch processing but terrible for real-time, granular queries. Integrating a modern wearable directly via HL7 v2 requires a middleware translation layer, which adds latency and maintenance overhead.

**HL7 FHIR (Fast Healthcare Interoperability Resources) R4**
FHIR is the modern standard mandated for new US hospital systems. It uses a RESTful API architecture and transmits data in JSON or XML formats. Instead of sending massive, monolithic messages, FHIR breaks data down into modular “Resources” (like Patient, Observation, and DiagnosticReport). This allows a smartwatch to query just the patient’s heart rate observation without downloading their entire medical history. FHIR R4 is currently the most widely adopted version and the baseline for any serious medical device integration.

**DICOM (Digital Imaging and Communications in Medicine)**
DICOM is strictly for medical imaging. You might wonder why a wearable manufacturer cares about it. The answer is ECG waveforms. When a smartwatch like our TK67 Smartwatch records a 30-second single-lead ECG, the raw waveform data is often packaged in a DICOM format for storage in the hospital’s PACS (Picture Archiving and Communication System) or VNA (Vendor Neutral Archive).

**IEEE 11073 PHD (Personal Health Devices)**
This standard is specifically designed for personal health devices communicating over Bluetooth Low Energy (BLE). It defines how a blood pressure cuff or a smart ring talks to a smartphone or a hub. While IEEE 11073 handles the local device-to-gateway communication, it is increasingly being used as a bridge to map local BLE data into FHIR resources for cloud transmission.

Here is a quick-reference comparison to help you evaluate vendor claims:

Standard	Architecture	Data Format	Primary Use Case	Modern Relevance
HL7 v2	Client-Server / Messaging	Pipe-delimited text	ADT, Order/Result batching	High (Legacy systems)
HL7 FHIR R4	RESTful API	JSON / XML	Real-time clinical data, mobile apps	Critical (Current standard)
DICOM	Client-Server / Storage	Binary / JSON (DICOMweb)	Medical imaging, ECG waveforms	High (Specialized data)
IEEE 11073 PHD	Device-to-Gateway	Binary (BLE) / XML	Local wearable/sensor communication	Medium (Bridge technology)

Data Flow Architecture: From Wrist to EHR

Understanding the physical and logical path your data takes is essential for troubleshooting latency and security issues. A robust integration pipeline involves five distinct hops. Let’s walk through the complete data flow, using our TK35Pro vital signs monitor as a practical example.

**Hop 1: BLE Wearable to Phone Gateway**
The wearable device collects raw sensor data and packages it into BLE GATT (Generic Attribute Profile) characteristics. For heart rate, this is typically UUID 0x2A37. The phone app acts as the central gateway, reading these characteristics via Bluetooth. This step is notoriously tricky on mobile operating systems due to aggressive background battery restrictions on iOS and Android. The OEM must provide a highly optimized mobile SDK to maintain the BLE connection without draining the phone battery.

**Hop 2: Phone Gateway to Cloud API**
Once the phone app normalizes the raw BLE data into standard metrics (e.g., converting ADC counts to beats per minute), it transmits the payload to the cloud via HTTPS. This transmission must include device metadata, timestamp, and a secure token. The cloud API acts as the traffic cop, authenticating the device, validating the payload structure, and pushing the data into a message queue (like Apache Kafka or RabbitMQ) to handle bursts of thousands of devices syncing simultaneously.

**Hop 3: Cloud API to FHIR Server**
The message queue feeds the data into the FHIR mapping engine. This is where the magic happens. The engine translates the proprietary JSON payload from the wearable into standard FHIR R4 resources. It assigns the correct LOINC codes, maps the patient identifier, and structures the data according to the FHIR specification.

**Hop 4: FHIR Server to EHR Inbox/Flow Sheet**
The FHIR server pushes the mapped resources to the hospital’s EHR via a SMART on FHIR application or a direct backend API integration. The EHR ingests the data, performs patient identity matching against its Master Patient Index (MPI), and routes the values to the correct clinical flow sheet or inbox for the nursing staff to review.

Here is a text-based architecture diagram illustrating this pipeline:

If any single hop in this chain fails, the data never reaches the nurse. This is why you must demand detailed architecture documentation from your OEM, not just a marketing brochure claiming “EHR compatible.”

FHIR Resource Mapping in Practice

Mapping data to FHIR is not a simple copy-paste exercise. It requires strict adherence to clinical coding systems like LOINC (Logical Observation Identifiers Names and Codes) and SNOMED CT. A poorly mapped FHIR resource will be rejected by the EHR’s ingestion engine, or worse, it will be accepted and display incorrect clinical data.

Let’s look at actual FHIR JSON snippets for the three most common wearable data types.

**Heart Rate (Simple Observation)**
Heart rate is a single-value metric. In FHIR, it maps to a simple `Observation` resource. The critical element here is the `code` field, which must use the correct LOINC code for body site and measurement method.

**Blood Pressure (Observation with Components)**
Blood pressure is more complex because it contains two distinct values: systolic and diastolic. In FHIR, this is represented as an `Observation` resource that contains `component` arrays. Using LOINC 85354-9 (Blood pressure panel) as the parent code, and 8480-6 (Systolic) and 8462-4 (Diastolic) for the components, ensures the EHR parses it correctly into the BP flow sheet.

“`json
{
“resourceType”: “Observation”,
“status”: “final”,
“category”: [
{
“coding”: [
{
“system”: “http://terminology.hl7.org/CodeSystem/observation-category”,
“code”: “vital-signs”
}
]
}
],
“code”: {
“coding”: [
{
“system”: “http://loinc.org”,
“code”: “85354-9”,
“display”: “Blood pressure panel”
}
]
},
“subject”: {
“reference”: “Patient/12345”
},
“effectiveDateTime”: “2026-08-10T08:35:00Z”,
“component”: [
{
“code”: {
“coding”: [
{
“system”: “http://loinc.org”,
“code”: “8480-6”,
“display”: “Systolic blood pressure”
}
]
},
“valueQuantity”: {
“value”: 120,
“unit”: “mmHg”,
“system”: “http://unitsofmeasure.org”,
“code”: “mm[Hg]”
}
},
{
“code”: {
“coding”: [
{
“system”: “http://loinc.org”,
“code”: “8462-4”,
“display”: “Diastolic blood pressure”
}
]
},
“valueQuantity”: {
“value”: 80,
“unit”: “mmHg”,
“system”: “http://unitsofmeasure.org”,
“code”: “mm[Hg]”
}
}
]
}
“`

**ECG Waveform (DiagnosticReport referencing Observation)**
When a device like our GE54 ECG monitor records a waveform, the raw data is too large for a standard Observation. Instead, the waveform is stored as a referenced `Observation` with a `valueAttachment` or `component` containing sampled data, and wrapped in a `DiagnosticReport`.

Here is a nuance I have learned the hard way: EHRs handle ECG waveforms differently. Epic prefers the waveform in a specific proprietary format wrapped in a FHIR document reference, while Cerner might accept a standard FHIR Observation with base64 encoded binary data. Your OEM must know the specific EHR target’s quirks. A generic FHIR ECG payload will often fail validation in Epic’s Inbasket.

“`json
{
“resourceType”: “DiagnosticReport”,
“status”: “final”,
“code”: {
“coding”: [
{
“system”: “http://loinc.org”,
“code”: “131328”,
“display”: “Electrocardiogram (ECG) study”
}
]
},
“subject”: {
“reference”: “Patient/12345”
},
“effectiveDateTime”: “2026-08-10T09:00:00Z”,
“result”: [
{
“reference”: “Observation/ecg-waveform-987”
}
]
}
“`

Compliance Requirements: Security and Regulatory Boundaries

Data integration is not just an IT problem; it is a legal and regulatory minefield. When patient data leaves the secure perimeter of the hospital EHR and enters a cloud-based wearable platform, you trigger a cascade of compliance requirements.

**HIPAA and the Business Associate Agreement (BAA)**
In the United States, any cloud vendor storing or transmitting Protected Health Information (PHI) must sign a HIPAA Business Associate Agreement (BAA). This is non-negotiable. A BAA legally binds the OEM to implement specific administrative, physical, and technical safeguards. If your OEM refuses to sign a BAA, they are either not handling PHI (meaning they are using a de-identified data model, which limits clinical utility) or they are operating outside the law. Ensure the BAA covers all sub-processors, including their cloud hosting provider (e.g., AWS, Azure).

**GDPR and Data Processing Agreements (DPA)**
For European hospitals, the General Data Protection Regulation (GDPR) applies. You need a Data Processing Agreement (DPA) that explicitly outlines data residency requirements. Many EU hospitals mandate that health data never leaves the European Economic Area (EEA). If your OEM’s cloud servers are located in US-East, your integration will be blocked by the hospital’s Data Protection Officer. You must verify that the OEM offers EU-hosted instances, typically in regions like Frankfurt or Dublin.

**FDA Cybersecurity Guidance**
The FDA released updated cybersecurity guidance in October 2023, which fundamentally changed how medical devices are evaluated for software security. Under the Consolidated Appropriations Act, the FDA now requires a Software Bill of Materials (SBOM) for all pre-market submissions. An SBOM is a formal record of all third-party and open-source software components used in the device and its cloud backend.

When evaluating an OEM, ask for their SBOM and their secure Software Development Life Cycle (SDLC) documentation. They should be able to demonstrate regular penetration testing, a formal vulnerability disclosure program, and a patch management strategy. Our manufacturing processes support ISO 13485:2016 compliance and align with FDA 21 CFR 820 quality system regulations, which now explicitly incorporate these cybersecurity expectations.

Let’s be honest about a gap in the current system: security certifications like SOC 2 Type II are excellent for proving cloud infrastructure security, but they do not cover clinical data accuracy. A vendor can have perfect cybersecurity but still map a blood pressure reading to the wrong LOINC code, causing a clinical error. Always pair your security audit with a clinical accuracy audit, referencing standards like ISO 81060-2 for non-invasive sphygmomanometers or AAMI/ESH guidelines.

Five Key Questions to Evaluate an OEM’s Interoperability Capability

When you are interviewing potential OEM partners for a hospital deployment, do not let them dazz you with buzzwords. Ask these five specific questions. Their answers will quickly separate the true medical device manufacturers from the consumer electronics companies playing in the healthcare space.

**1. Does the API use FHIR R4 natively, or does it require a translation layer?**
Many vendors claim to support FHIR, but their backend database is built on a proprietary schema. They use a middleware translation layer to convert their proprietary JSON into FHIR on the fly. This adds latency, creates a single point of failure, and makes debugging a nightmare. You want an OEM whose database and API are built natively around FHIR R4 resources from the ground up.

**2. What is the typical integration timeline with Epic, Cerner, or Meditech?**
A realistic timeline for a full clinical integration with a major EHR is 12 to 16 weeks. This includes environment setup, API mapping, User Acceptance Testing (UAT) with actual clinical staff, and security audits. If a vendor promises integration in two weeks, they are likely just offering a basic data dump into a generic inbox, not a true workflow integration. For more details on navigating the regulatory side of these deployments, check out our medical device certification roadmap.

**3. How is patient identity matching handled?**
This is the most dangerous part of wearable integration. If the wearable sends data for “John Smith, DOB 1950-01-01”, but the EHR has “John A. Smith, DOB 1950-01-01”, the EHR’s Master Patient Index (MPI) might fail to match them, resulting in orphaned data or a duplicate medical record. The OEM must support robust identity matching protocols, ideally using SMART on FHIR launch sequences where the patient is already authenticated within the EHR context.

**4. What is the data latency from device to EHR?**
In a remote patient monitoring scenario, a 5-minute delay is acceptable. In a continuous ICU monitoring scenario, a 5-minute delay is patient safety hazard. Ask the OEM for their 95th percentile latency metrics. The BLE-to-EHR pipeline should ideally operate in under 3 seconds for critical alerts.

**5. Can the vendor provide a reference hospital that has completed integration?**
Do not accept a reference to a clinic that is “currently testing” the integration. Ask for the name of a hospital that has completed UAT and is actively using the integrated data in production. Call their IT director. Ask them about the OEM’s responsiveness during the UAT phase. If the OEM cannot provide a live reference, walk away. For a broader look at how to structure these vendor relationships, read our OEM guide for medical wearables.

xdunmedical Data Integration Solution: FHIR R4 Interface and EHR Support

At Geyan Technology Innovation, we understand that hardware is only half the battle. Since 2011, we have refined our manufacturing and software engineering processes to ensure our devices are not just clinically accurate, but digitally interoperable.

Our integration approach is built on a native FHIR R4 API. We do not rely on clunky translation layers. Our cloud infrastructure is designed to ingest, map, and route data according to strict HL7 FHIR specifications. We provide pre-built connectors for major EHR systems, including Epic, Oracle Health (Cerner), and Meditech. These connectors handle the specific quirks of each EHR’s ingestion engine, ensuring that data flows smoothly into the correct clinical flow sheets.

To make life easier for your IT and integration teams, we provide a comprehensive SDK with sample code in Python, Java, and Node.js. Our API documentation is fully interactive, built with Swagger/OpenAPI, allowing your developers to test endpoints directly in the browser. We also provide a dedicated sandbox environment where your team can simulate device data and test EHR mapping without touching production systems.

Whether you are deploying our TK30 Smart Ring for continuous sleep and temperature monitoring, the V80 Smart Ring for SpO2 and heart rate tracking, or scaling up a large remote patient monitoring program, our integration team is with you from sandbox to go-live. You can read more about how our devices fit into broader clinical workflows in our Remote Patient Monitoring (RPM) guide, or learn about our regulatory approach in our detailed FDA 510k medical wearables article.

We have spent 15 years perfecting the hardware. We have spent the last five years perfecting the data pipeline. When you source from xdunmedical, you are getting a complete, clinically validated, and digitally integrated solution.

***

**Need EHR-ready wearables? Our integration team has connected devices to Epic, Cerner, and Meditech. SDK + API docs available.**

**→ Request Technical Consultation: jine@xdunmedical.com**