HL7 FHIR for Healthcare IoT: Practical Integration Guide

Connected medical devices have to integrate with electronic health records eventually, and in 2026 that conversation is almost always about FHIR. Knowing the protocol’s shape — what it does well, where it’s awkward, and how to integrate without setting up months of standards-committee work — pays back fast on healthcare IoT projects.

What FHIR actually is

FHIR (Fast Healthcare Interoperability Resources) is HL7’s modern healthcare data exchange standard. Three parts:

1. A resource model — every clinical concept (Patient, Observation, MedicationRequest, Device, DeviceMetric) is a JSON or XML document with a defined schema. ~150 resources in the latest spec.

2. A REST API — resources have URLs, support standard CRUD, and follow consistent search semantics.

3. A conformance / profile system — implementations declare which resources they support, with what extensions. US Core, IPS, IPS-UV, and many country-specific profiles narrow the spec to interoperable subsets.

The simple version: FHIR is HTTP + JSON for healthcare data, with strict schemas.

Why connected medical devices integrate with FHIR

Three flows are common:

1. Device readings → EHR — vital signs, glucose readings, weight, blood pressure. The device or its cloud sends Observation resources to the hospital’s FHIR server.

2. EHR context → Device — patient demographics, care team, current medications. The device retrieves Patient and Practitioner resources.

3. Device metadata → EHR — Device resources representing the connected device itself, useful for asset management and audit trail.

The first flow is the most common and most impactful. A connected blood-pressure cuff, a continuous glucose monitor, a wearable ECG — all of these earn their integration value by writing to the patient’s record.

The Observation resource — what most IoT integrations send

Vital sign data flows through the Observation resource. The fields that matter:

• status — usually final for IoT readings (vs preliminary or corrected)
• category — coded category like vital-signs
• code — specifies what was measured, typically a LOINC code (e.g. 8867-4 for heart rate, 8480-6 for systolic blood pressure)
• subject — reference to the Patient resource
• device — reference to the Device resource that produced the reading
• effectiveDateTime — when the reading was taken
• valueQuantity — the actual measurement, with value and unit

A defensible Observation from an IoT device:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "vital-signs" }] }],
  "code": { "coding": [{ "system": "http://loinc.org", "code": "8867-4", "display": "Heart rate" }] },
  "subject": { "reference": "Patient/12345" },
  "device": { "reference": "Device/glucose-monitor-001" },
  "effectiveDateTime": "2026-05-09T14:32:18Z",
  "valueQuantity": { "value": 72, "unit": "beats/minute", "system": "http://unitsofmeasure.org", "code": "/min" }
}

This shape is the difference between data that integrates and data that doesn’t. LOINC for the code, UCUM for the unit, ISO 8601 for the timestamp — all required.

Transport options

FHIR REST is the default. The IoT-specific question is who calls whom.

Option A — Device’s cloud calls EHR’s FHIR API (most common): the device sends data to the manufacturer’s IoT cloud, which then forwards to the hospital’s FHIR server via HTTPS POST. Authentication usually via SMART on FHIR with a registered backend service.

Option B — EHR pulls from device cloud’s FHIR endpoint: the manufacturer’s cloud exposes a FHIR-compliant endpoint, and the EHR pulls resources on a schedule. Less common but useful when the EHR is restrictive about outbound connections.

Option C — Pub/Sub via FHIR Subscription: emerging pattern where the EHR can subscribe to device events and receive notifications. Still rare in production but worth knowing about.

For most projects in 2026, Option A with SMART on FHIR backend service auth is the right path.

Authentication — SMART on FHIR

SMART on FHIR is the OAuth 2.0 / OpenID Connect profile for FHIR. Two relevant flavours:

• EHR launch / standalone launch — for clinician-facing apps; not relevant for IoT devices
• Backend services — for cloud-to-cloud integrations using JWT-based asymmetric client authentication

For IoT, you almost always want backend services. The flow:

1. Manufacturer’s IoT cloud is registered with the EHR’s authorisation server, providing a public key
2. The cloud generates a signed JWT (using the corresponding private key) and exchanges it for an access token
3. Access token authorises FHIR API calls

The private key lives in an HSM or equivalent. Per-tenant key rotation is part of the operational lifecycle.

Conformance and profiles

The FHIR spec is large; most EHRs support a constrained subset.

The profile system handles this. A profile specifies which resources are required, which fields, which value sets, which extensions. The dominant profiles:

• US Core — the de facto profile for US EHRs (Epic, Cerner, Athena, etc.)
• International Patient Summary (IPS) — increasingly common for cross-border
• Various national profiles — UK Core, AU Core, India NDHM-FHIR, etc.

Before integrating, ask the target EHR which profiles they conform to. Validate your Observation resources against the profile (the open-source fhir-validator from HL7 does this).

Compliance overlay

Healthcare IoT integrations sit on top of regulatory and contractual obligations:

• HIPAA (US): Business Associate Agreement signed before any PHI flows; audit logging of every access; encryption at rest and in transit; breach notification timelines
• GDPR (EU): lawful basis for processing; data minimisation; subject access requests
• EU MDR / FDA cybersecurity guidance: device-side security as a regulatory expectation; SBOM, vulnerability management, secure boot

See our healthcare wearables post for the broader compliance landscape.

What we typically deliver

For a healthcare IoT FHIR integration in 2026:

• Resource mapping document — for every device data type, the mapped FHIR resource, code system (LOINC), and unit (UCUM)
• Profile conformance report — validation against US Core or the relevant target profile
• SMART on FHIR backend services flow with key management and rotation
• HIPAA-aligned operational runbook — audit logging, BAA references, incident response
• Integration test harness — simulated FHIR server to test against in CI

If you are integrating a connected medical device with an EHR via FHIR, we have shipped this combination several times.