Interoperability Standards and Data Flows for Medical IoT
Medical IoT devices generate continuous streams of health data that must flow through collection, transmission, storage, processing, and ultimately integration with clinical systems. Managing this data lifecycle effectively determines whether IoMT delivers clinical value.
The data journey presents challenges at each stage: ensuring measurement accuracy at collection, maintaining integrity during transmission, enabling efficient storage at scale, supporting real-time processing for alerts, and achieving semantic interoperability for clinical use.
Interoperability enables IoMT data to flow between devices, platforms, and clinical systems with shared meaning.
| Standard | Scope | Application |
|---|---|---|
| HL7 FHIR | Healthcare data exchange | EHR integration, clinical data |
| IEEE 11073 | Personal health devices | Device data formats, PHD profiles |
| Continua (IHE PCD) | Connected health devices | End-to-end interoperability |
| LOINC | Observation codes | Standard measurement identifiers |
| SNOMED CT | Clinical terminology | Clinical concepts, conditions |
| HL7 v2 | Legacy messaging | ADT, ORU messages to legacy systems |
HL7 FHIR (Fast Healthcare Interoperability Resources) has become the preferred standard for modern healthcare interoperability. For IoMT, key FHIR resources include: Observation (measurements), Device (device information), Patient (demographics), DeviceMetric (calibration), and DeviceUseStatement (device assignment). SMART on FHIR enables secure app authorization.
IEEE 11073 defines data models and protocols for personal health devices:
| Profile | Device Type | Measurements |
|---|---|---|
| 11073-10407 | Blood pressure monitor | Systolic, diastolic, MAP, pulse |
| 11073-10408 | Thermometer | Body temperature |
| 11073-10415 | Weighing scale | Body weight, BMI |
| 11073-10417 | Glucose meter | Blood glucose |
| 11073-10441 | Cardiovascular fitness | Heart rate, activity |
| 11073-10404 | Pulse oximeter | SpO2, pulse rate |
FHIR provides standardized resources for representing IoMT data:
{
"resourceType": "Observation",
"id": "bp-reading-001",
"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/123" },
"effectiveDateTime": "2025-01-15T08:30:00Z",
"device": { "reference": "Device/bp-monitor-456" },
"component": [
{
"code": { "coding": [{ "system": "http://loinc.org", "code": "8480-6" }] },
"valueQuantity": { "value": 120, "unit": "mmHg" }
},
{
"code": { "coding": [{ "system": "http://loinc.org", "code": "8462-4" }] },
"valueQuantity": { "value": 80, "unit": "mmHg" }
}
]
}The FHIR Device resource captures device metadata including manufacturer, model, serial number, UDI (Unique Device Identifier), and status. DeviceMetric represents calibration and operational information. These resources enable traceability from clinical observations back to the specific device that generated them.
Ensuring IoMT data quality is essential for clinical decision-making:
| Process | Description | Implementation |
|---|---|---|
| Validation Rules | Check plausible ranges | BP 60-260/30-150, HR 30-250 |
| Device Calibration | Regular accuracy verification | Per manufacturer schedule |
| Patient Verification | Confirm measurement context | Activity level, position, timing |
| Artifact Detection | Identify erroneous readings | Motion, interference detection |
IoMT data storage must handle high-volume time-series data efficiently:
A single continuous glucose monitor generates ~288 readings/day. A cardiac patch may generate 86,400+ samples/day at 1Hz. At scale, IoMT data volumes can overwhelm traditional EHR storage. Design for data aggregation (hourly/daily summaries vs. raw), tiered storage (hot/warm/cold), and selective EHR integration (clinically relevant vs. complete datasets).
Transforming raw IoMT data into clinical insights:
| Layer | Function | Example |
|---|---|---|
| Real-Time Alerts | Threshold-based notifications | SpO2 < 90% → immediate alert |
| Trend Analysis | Pattern detection over time | Weight gain trend in HF patient |
| Predictive Models | Risk prediction | Decompensation risk score |
| Population Analytics | Cohort insights | Program outcomes, benchmarking |
Adopt FHIR as the integration standard; use IEEE 11073 codes for device data; implement validation rules at ingestion; design for data volume from day one with appropriate storage tiers; maintain data provenance linking observations to devices and patients; and establish clear data governance policies covering retention, access, and sharing.