A patient with a Dexcom CGM strapped to their arm, an Apple Watch on their wrist, and a connected blood pressure cuff on the nightstand is generating continuous physiological data around the clock. But their care team sees almost none of it. A 2025 Journal of Medical Internet Research study found that 78.4% of wearable device users are willing to share their health data with their providers but only 26.5% actually do.
The devices are generating the data but the problem is that almost none of it arrives in a clinical chart in a form that a clinician can act on, an AI model can train on, or a visualization layer can render consistently.
The organizations building remote patient monitoring platforms, chronic care applications, and clinical AI products on top of IoMT device data are running into the same wall: the integration layer produces output that looks correct and behaves unpredictably. FHIR writes that validate locally and get rejected by Epic in production. Glucose observations carrying the wrong LOINC code because the pipeline mapped interstitial fluid glucose to the serum/plasma glucose code are two clinically distinct measurements that a normalization layer built on templates will conflate without flagging an error. Dashboards that contradict the EHR because unit handling differed across device types.
All of it traces back to the same place: the normalization layer.
An IoMT device data platform is the software infrastructure that connects a fleet of medical-grade and consumer health devices to clinical systems. Most product descriptions focus on the device side: connectivity protocols, hardware management, fleet administration. The component that determines clinical value is the data layer: the pipeline that ingests raw device payloads, transforms them into structured clinical observations, and writes them to an EHR.
Each device type arrives with a different payload structure, a different SDK schema, different authentication requirements, and a different transmission frequency. A Dexcom G7 transmits via Bluetooth to a hub that forwards a JSON payload. An Apple Watch surfaces data through HealthKit with its own schema. A connected BP cuff from a home care patient may transmit through a proprietary cloud API with field naming conventions that share no common vocabulary with any clinical coding system. None of these devices natively produce FHIR R4 Observation resources. None of them agree on what a heart rate reading or a glucose value should look like in a patient record.
The normalization layer is the engineering between those raw device outputs and a clinical observation that a specific EHR will accept, a specific AI architecture can train on, and a specific visualization layer can render without a data preparation pass first.
Most IoMT pipeline failures do not announce themselves with an error. The FHIR Observations are structurally valid, the EHR write-back appears to succeed, and the AI model trains without complaint. The failure shows up six months later in a model drift report, or when a clinician stops trusting the dashboard, or when the EHR team traces a run of rejection logs back to observations that have been malformed since the pipeline went live. By that point the root cause is several steps upstream and the bad data has been accumulating long enough to have reached training datasets. The break points are structural, and they occur at the same three places in almost every pipeline that was not engineered to prevent them.
Device manufacturers maintain proprietary data dictionaries. Garmin, Apple, Dexcom, and Abbott each define their own field names, value formats, and measurement identifiers. None of them use LOINC or SNOMED CT natively. A normalization layer that relies on generic mapping templates will produce FHIR Observations that are structurally valid and clinically wrong.
The Dexcom G7 is the clearest example. It measures glucose in interstitial fluid, the fluid in the spaces around subcutaneous cells instead of serum or plasma. The correct LOINC code for an interstitial fluid glucose reading is 41651-9. The serum/plasma glucose code is 2345-7. A pipeline built on generic FHIR templates will map a Dexcom reading to 2345-7 because that is the more common glucose LOINC code. The resulting Observation passes validation, reaches the EHR, and is interpreted as a lab glucose measurement by any downstream clinical decision support system that distinguishes between CGM readings and lab values.
The problem compounds with firmware. When a device manufacturer updates payload structure, a field renamed, a unit changed, a timestamp format shifted the mapping table breaks silently. While the pipeline continues to run and the observations continue to flow, the vocabulary error continues to propagate into training data until someone notices the model behaving unexpectedly on a specific patient cohort and traces it back.
Valid FHIR R4 is not the same as accepted FHIR. The base R4 specification defines what a conformant FHIR Observation looks like. Epic's SMART on FHIR implementation, Cerner's Ignite APIs, and athenahealth's cloud-native FHIR endpoints each define what they will accept and those definitions differ from the base spec and from each other. An Observation that passes FHIR validation can be rejected at the EHR write-back stage because it does not conform to the specific EHR's implementation guide.
A pipeline built to produce valid R4 without being built to the target EHR's profile will hit this wall at scale. The rejections appear sporadic initially some Observations pass, some fail because different EHR configurations apply different validation rules depending on the data type, the patient context, and the FHIR profile version. Debugging rejection patterns at the write-back stage is expensive engineering time spent solving a problem that should have been designed out at the Observation construction step.
An Apple Watch knows a user by their Apple ID. A hospital EHR knows a patient by MRN, date of birth, and insurance ID. Resolving these two identity systems requires a Master Patient Index with probabilistic matching logic built into the pipeline architecture. It is an active matching process that accounts for name variations, address changes, and the fact that a single patient may have multiple device accounts across a monitoring program.
A wrong match does not surface as a pipeline error. It surfaces as a heart rate reading in the wrong patient's chart, a patient safety issue or as cross-patient contamination in a training dataset that no downstream cleaning pass will catch because the records are structured correctly and attributed incorrectly. Teams that defer identity resolution until after the pipeline is live are deferring a patient safety problem and a model integrity problem simultaneously.
All three failures produce the same downstream consequence: device data that reaches the AI layer in a state that prevents reliable aggregation across patients, consistent comparison across device types, and trustworthy model training at scale.
There are seven engineering steps between a raw device payload and a FHIR Observation that an EHR will accept and an AI model can train on. The steps are sequential and a failure at any point propagates forward into every step after it. Most teams handle ingestion and write-back reasonably well. The failures described in the previous section consistently originate in steps three, four, and six: vocabulary mapping, unit standardization, and identity resolution. Those are the steps worth auditing first if your pipeline is already in production.
A model trained on IoMT observations requires that every instance of the same physiological parameter, from the same device type, carries the same LOINC code and the same UCUM unit declaration across the entire training dataset. When it does not, the model is learning from a mixture of interstitial fluid glucose readings coded as 41651-9, serum glucose readings coded as 2345-7, and glucose readings with no explicit unit declaration treated as three distinct features by any model that does not have a data preparation step to reconcile them.
The table below lists the verified LOINC codes and UCUM units for the device parameters most commonly flowing through IoMT pipelines. Use it to check whether your current pipeline is mapping to the correct code for each device type the CGM glucose distinction in row two is the most common error in template-built pipelines:
Maintaining this mapping correctly is ongoing engineering work like mapping tables must be versioned, tested against new device firmware before deployment, and audited when model behavior changes unexpectedly. This versioning and maintenance requirement is precisely the gap that generic integration tools do not solve by configuration, which is what the next section covers.
Not all IoMT device data has the same latency requirement, and designing a single pipeline architecture for both use cases without separating the processing paths creates unnecessary complexity and operational risk.
Acute monitoring scenarios: continuous ECG for arrhythmia detection, real-time SpO2 for post-surgical patients, glucose monitoring for hospitalized diabetics require streaming architecture. These pipelines use MQTT brokers or event-driven ingestion, process each reading through the normalization steps immediately on arrival, and write to the EHR within seconds. Latency above a defined threshold in these contexts is a clinical risk, not a performance inconvenience.
Wellness wearable data: step counts, sleep stages, resting heart rate trends, weight logs from connected scales does not carry the same urgency. Batch ingestion on a nightly sync cycle is appropriate and significantly reduces infrastructure cost for high-volume, low-urgency device streams. The normalization pipeline is identical across both paths. What changes is the trigger: event-driven for acute, scheduled for wellness.
The architecture decision that matters is building both paths from the start rather than adding streaming capability to a batch pipeline later. A pipeline designed for nightly sync does not extend cleanly to real-time delivery the identity resolution step, the EHR rate limit handling, and the error recovery logic all behave differently under continuous load. Organizations that anticipate adding acute monitoring use cases should architect for both paths upfront even if only the batch path is active initially.
Step seven of the normalization pipeline, the EHR write-back, is where pipelines that were built correctly through steps one through six can still fail. The reason is that each major EHR exposes a different FHIR implementation with distinct profile requirements, authentication behavior, and rate limit enforcement.
Epic's SMART on FHIR implementation requires Observations to conform to the US Core Observation profile. This means specific required fields beyond the base R4 spec, a category code drawn from the US Core value set, a subject reference that resolves to a Patient resource in Epic's system, and a status of "final" for write-back to be accepted in most Epic configurations. Epic also enforces application-level scopes at the SMART authorization layer, which means the pipeline's OAuth credentials must be scoped specifically for the resource types being written. A pipeline writing device observations without the correct observation write scope will receive authorization errors that look like profile failures.
Cerner's Ignite APIs handle FHIR write-back differently. Cerner enforces its own Millennium FHIR profile, which has specific requirements around Observation component structure for multi-value observations like blood pressure systolic and diastolic must be represented as components within a single Observation resource. Cerner also applies throttling at the API level with documented rate limits that vary by environment tier. Pipelines that write at volume without rate limit handling will hit 429 errors under load.
Athenahealth's cloud-native FHIR API is most commonly relevant for ambulatory and home care IoMT contexts. athenahealth requires observations to reference a valid Encounter or be explicitly flagged as ambulatory standalone readings. The authentication model uses OAuth 2.0 with athenahealth-specific scope definitions that differ from Epic's SMART scopes. For RPM platforms integrating with independent physician practices on athenahealth, the per-practice API credential management adds a configuration layer that must be built into the pipeline's write-back architecture.
Building a pipeline to the base FHIR R4 spec and assuming it will write cleanly to all three EHRs is the source of most write-back rejection patterns.
Ideas2IT has built IoMT data pipelines for a US-based RPM platform, and digital health products across wearable, Bluetooth, and SDK-based device architectures.
If your pipeline is producing valid FHIR but your AI layer is inconsistent or your EHR keeps rejecting writes, the gap is upstream. A $0 Data Pipeline Working Session with Ideas2IT gives you a structured gap analysis across your current normalization architecture so you know exactly what to fix before it compounds at scale.
Generic integration tools solve the connectivity problem well. Azure Health Data Services, Mirth Connect, and similar platforms provide pre-built connectors, FHIR transformation capabilities, and cloud-native deployment. For organizations that need to connect a small number of common device types to a single EHR target and do not have AI model training requirements, they are a reasonable starting point. The problem is that their output ceiling is generic FHIR R4 and generic FHIR R4 is not the same as AI-ready, EHR-accepted, identity-resolved observations at production scale.
Most teams at this decision point are evaluating one of three options: build the normalization layer from scratch, extend a generic tool with custom work, or bring in an engineering partner who has already solved this for their specific device-EHR combination. The comparison below covers the five dimensions where that choice has the most consequence:
If the pipeline needs to produce observations that an AI model can train on without a data preparation pass and that an EHR will accept without a profile correction, a generic tool cannot deliver that through configuration. The organizations that get this right make the architecture decisions, vocabulary mapping strategy, EHR profile target, identity resolution approach before the first device connection is built.
If the build-vs-configure analysis above points toward bringing in an engineering partner, the evaluation criteria matter. Four capabilities separate partners who will solve the normalization problem from partners who will move it downstream.
Ideas2IT builds IoMT data pipelines for RPM platforms, chronic care applications, and clinical AI products integrating Apple Watch, Dexcom, Abbott CGMs, and connected BP cuffs into Epic, Cerner, and athenahealth environments. The difference between their pipelines and a generic FHIR adapter is where the architecture decisions get made at the design stage, against the specific EHR environment, the specific device set, and the specific AI architecture the data layer needs to feed.
Ideas2IT deploys Forward Deployed Engineers who embed in the client's existing stack from the start of the engagement: their Epic or Cerner FHIR implementation profile, their specific device SDK versions, their cloud data platform. The normalization layer they build is not configured to a template. It is built to the vocabulary mapping requirements of the client's exact device types, the profile requirements of their specific EHR, and the consistency requirements of the AI models their data layer needs to train. Ideas2IT's data engineering practice covers the full pipeline batch and real-time ingestion, ETL/ELT framework development, ML and GenAI-ready data pipelines, data quality and lineage, and cloud-native deployment with observability and schema drift alerts built into every layer.
Two production engagements illustrate what this looks like at scale.
SPICE, the NCD care platform Ideas2IT built for other clients, is now deployed across seven countries and has screened 1.9 million patients. The data engineering work that made that possible included a FHIR HL7 R4 migration of five years of patient records, ICD and SNOMED clinical term standardization, and IoT device integration for BP monitors and connected devices via Bluetooth and SDK. Once the normalized data layer was in place, Ideas2IT built predictive enrollment and retention models and GenAI diagnostic tools deployed at medical camps. NCD program enrollment increased 815% post-modernization. The AI layer produces reliable output because the data layer was engineered correctly before the first model was trained.
For a US-based RPM platform, Ideas2IT built the iOS application and bidirectional data architecture connecting Apple Watch HealthKit data like heart rate, blood oxygen, ECG, sleep, and steps to a clinic database handling data for enrolled patients across a growing RPM program. Passive transmission with no patient-initiated action required after enrollment, per-patient threshold configuration, and HIPAA-compliant bidirectional write-back. The pipeline was built to clinical workflow requirements from the start.
If you are building an IoMT platform and want to know whether your current normalization architecture will hold at production scale, Ideas2IT offers a $0 Data Pipeline Working Session which is a structured review of your device ingestion setup, LOINC mapping coverage, and AI-readiness gaps. For context on related architectural decisions, the custom FHIR integration hub piece covers the integration layer that sits alongside the normalization pipeline.
Ideas2IT has engineered IoMT data pipelines from device SDK ingestion through FHIR write-back to AI model training data where wearable data needs to reach a clinician's workflow without manual intervention.
If your IoMT pipeline is producing device data your AI layer cannot reliably train on or your dashboards cannot consistently trust, the normalization layer has a gap that will compound as your device count and patient population grow.
Fill in the form below to claim your $0 Data Pipeline Working Session. Ideas2IT will review your current architecture and deliver a gap analysis covering:
Full device-to-FHIR normalization audit
LOINC and UCUM mapping gaps across active device types
Patient identity resolution architecture assessment
EHR-specific FHIR profile alignment review for Epic, Cerner, or athenahealth
Claim Your $0 Pipeline Working Session
Didn't find what you were looking for?
.png)
