IoT data integration for MedTech, covering everything that happens after the telemetry lands and before anybody outside engineering can use it.
Connected device programmes reliably succeed at the first half. Devices connect, telemetry flows, a cloud platform receives it and a data lake fills up. Then the programme stalls, usually without anybody declaring it stalled, because the data is structured for the device and every system that wants it is structured for the business. Telemetry knows a serial number, an error code, a sensor reading and a timestamp from the device clock. The ERP wants a customer and a contract. The PLM wants a part and a revision. The service system wants an asset under an entitlement. The EHR wants a patient and an observation. Nothing in the pipeline performs that translation, so the data sits in a lake that engineering queries and nobody else opens.
The pipe is a solved problem. The translation is the work, and it is the part that gets scoped last.
One physical device carries a hardware serial, a manufacturing lot, a product model, a firmware version, a cloud device identifier, a service asset number, an enterprise equipment record, a customer installation identifier, a deployment location and, in some products, an authorised patient or care-context association. These are not alternative names for one thing. They are maintained by different functions, change on different triggers and are valid over different periods, and the integration layer is where they have to be reconciled because nowhere else will do it.
Underneath that sits a more basic mismatch. A device emits events. An enterprise system holds records. Those are different kinds of object and the difference runs through everything. Events arrive continuously and records change at business cadence. Events are identified by whatever the device knows about itself, which is a serial number and possibly a hardware identifier, while records are identified by customer, contract, asset tag, part number or patient. Events carry a timestamp from a clock nobody manages, while records carry business dates somebody is accountable for. Events arrive out of order, duplicated and sometimes days late, while records assume a single current truth.
Each of those gaps has to be closed by something, and in most programmes that something is a person writing a query when a question comes up. The programme is reported as delivered because telemetry is flowing and a dashboard exists. What was not delivered is any route by which a service planner, quality engineer, commercial team or clinician gets device-derived information inside the system they actually work in, which was the point.
Device identity is not business identity
A serial number is not a customer, an asset, a contract or a patient, and nothing in the stream knows the difference.
Device time is not business time
Clock drift, timezones, transmission delay and out-of-order arrival all affect when something is recorded as having happened.
Cadence is incompatible
A device emits per second and an ERP expects per transaction, so direct connection is not an option.
Formats differ by generation
Each device generation and firmware version structures its payload slightly differently, and all of them are still in the field.
Every consumer builds its own transformation
Each downstream system invents its own mapping, so the same event means three slightly different things.
Nobody owns the data once it lands
Engineering owns the pipe, business systems own their domains, and the layer between them has no owner.
Ask who outside engineering has used the device data this month.
Not whether a dashboard exists, and not whether the data is available. Ask which service planner, quality engineer, commercial analyst or clinician actually used device-derived information to make a decision in the last thirty days, inside the system they normally work in.
The order is deliberate and it is the opposite of how these programmes usually run. Beginning at the device produces a pipeline that delivers what the device happens to emit. Beginning at the consuming system produces a pipeline that delivers what somebody needs, and the difference is whether the data gets used.
Step 1
Name the decisions the data is supposed to support
Step 2
Define what each consuming system needs
Step 3
Establish the identity mapping
Step 4
Agree the time model
Step 5
Design the aggregation contract
Step 6
Normalise across generations and firmware
Step 7
Build the ingestion and streaming layer
Step 8
Integrate into the systems of record
Step 9
Instrument the data itself
Step 10
Operate it as a product with an owner
A field name is not a definition. Without these, every consuming system will invent its own interpretation and all of them will be slightly different.
- The device family and firmware version the field originates from
- What the field means, in words somebody outside engineering can check
- Unit of measurement, and whether conversion happens upstream or downstream
- Valid range, and what the system does with a value outside it
- Sampling or event frequency, and whether it varies by configuration
- Which timestamp applies, and the timezone convention behind it
- Quality indicator, where the device knows its own confidence
- Missing value behaviour, since absent and zero are not the same fact
- Schema version, so a payload can always be read with the right interpretation
- Expected downstream interpretation, which is the part that prevents divergence
One of the few near-universal decisions here: the original payload should stay distinguishable from everything derived from it. Keep distinct stages for the raw payload as received, the parsed event, the standardised measurement, the quality-checked record, the curated dataset and the application output The cost is storage, which is negligible. The benefit is that a problem can be traced to the stage that introduced it, a mapping error is corrected by reprocessing from raw rather than patching downstream, and a disputed figure can be reconstructed from the original.
If the output is a new dashboard, the integration has not happened.
The measure of success is whether device-derived information appears inside the systems people already use: a service case that opens with the device history attached, a complaint record that arrives with the error log, an asset in the ERP whose utilisation is current, an EHR observation that a clinician sees without leaving the chart.
Three groups. The first is the one most vendors sell, the second is where the value is, and the third is the one that determines whether anybody uses the result.
Ingest
Device and gateway connectivity across the protocols the fleet actually uses, including the older generations
Streaming ingestion sized for the reconnection peak, which is several times steady-state load
What the device decides alone, what it buffers and for how long, which determines behaviour when the platform is unreachable.
Store-and-forward and backfill handling, so an outage produces late data rather than lost data
Deduplication and idempotent processing, because a device that did not get an acknowledgement will send again
Schema handling across firmware versions and device generations, all of which remain in the field
Edge pre-processing where bandwidth, latency or cost makes sending everything the wrong choice
Translate
Device identity resolution to asset, customer, contract, site and part, with effective dating throughout
The time model: occurrence, transmission and receipt held separately, with clock offset tracked per unit
Normalisation to one canonical event shape, so consuming systems do not learn the device catalogue
Aggregation to the contract each consuming system agreed, rather than to whatever the pipeline finds convenient
Clinical mapping to FHIR or HL7 where device data is destined for a clinical system, which is a separate path
Lineage retained from a delivered value back to the events and the mapping version that produced it
Deliver
Integration into ERP, PLM, CRM, service and quality systems, writing into the records people already use
EHR integration through the appropriate clinical interface, where the data is clinical rather than operational
APIs and event feeds for internal product teams, so the platform serves builders as well as business systems
Lakehouse and analytical delivery, including Microsoft Fabric and Power BI where that is your environment
Data quality instrumentation surfaced to consumers, since a figure without a coverage number is not interpretable
Operating model and ownership design for the layer itself, which is the part that is normally left unassigned
Never Correct Device Data Silently
When a value arrives invalid, incomplete or inconsistent, the pipeline has a choice and the wrong one is to quietly fix it. A unit that looks wrong gets converted, a missing field gets a default, an outlier gets smoothed, and the record now says something the device never said with nothing to indicate it.
The destination determines the engineering far more than the device does. The third column is where the data has to end up, which is what should shape the pipeline rather than what the device happens to emit.
| Device Type | What It Emits | Where It Has to Land |
|---|---|---|
| Capital Diagnostic Equipment | Utilisation, errors, consumables, calibration state | Service and ERP, for entitlement, planning and consumable supply. |
| Remote Patient Monitoring | Physiological measurements between visits | The clinical record, which is a different path with different rules. |
| Wearables and Consumer-Grade Sensors | High-volume continuous measurement | Aggregated summaries, because raw volume helps nobody downstream. |
| Smart Therapy Equipment | Delivery events, settings, alarms, adherence | Clinical and operational at once, which needs two models not one. |
| Laboratory and Analyser Systems | Results, QC, instrument state, throughput | LIS and quality, with result integrity as the dominant requirement. |
| SaMD and Software Products | Usage, workflow completion, errors, version | Product analytics, support and surveillance, rarely integrated at all. |
Capital Equipment Is the Case With the Clearest Payback
A diagnostic or therapy system under a service contract generates data with immediate commercial value, and the integration is operational rather than clinical, which makes it considerably simpler. Utilisation against contracted volume tells the commercial team what is happening in each account.
The architecture is conventional and the effort distribution is not. Most of the engineering attention in these programmes goes to the first two layers, which are largely solved problems with mature tooling, and the third layer is where the difficulty actually lives.
| Layer | What It Does | Effort It Needs Versus Effort It Gets |
|---|---|---|
| Device and Edge | Connectivity, buffering, local processing | Moderate need, heavy attention. Mature tooling and well understood. |
| Transport and Ingest | Protocols, streaming, store and forward | Moderate need, heavy attention. Largely a platform selection. |
| Identity, Time and Semantics | Device to business translation, the canonical model | The dominant need and the least attention. This is the project. |
| Enterprise Delivery | Writing into ERP, PLM, service, quality and clinical systems | High need, late attention, usually descoped when time runs out. |
| Analytics and Lakehouse | Lakehouse, Fabric, Power BI, modelling and reporting | Moderate need, early attention, built before the semantics exist. |
Model the canonical event before writing any pipeline
Otherwise the pipeline encodes whatever the first device generation emitted and every later one is an exception.
Resolve identity as at event time, not query time
Current mappings applied to historical events produce confidently wrong attribution.
Carry occurrence, transmission and receipt separately
One timestamp field is an ambiguity that will eventually matter.
Size the ingest for reconnection, not for steady state
The fleet coming back after an outage is the load that takes the platform down.
Make backfill a normal path, not an incident
Late data is routine in this domain and the downstream systems have to accept correction.
Version the semantic mapping and keep its history
A changed mapping changes historical figures, which is a controlled change, not a deployment.
A lakehouse is where the data lives, not where the integration finishes.
Landing device data in a lakehouse and building reporting over it is a legitimate and useful layer, and in a great many programmes it is mistaken for the destination. Analytics serves people who go looking for answers
The question that governs this page is where device scope ends. Few people assume it extends into an integration layer, and depending on what that layer does it sometimes does. A pipeline that moves and reformats data for operational reporting is ordinary enterprise engineering. A component that derives a value a clinician acts on, applies a threshold, suppresses an alert or feeds a device behaviour is a different proposition, and the distinction is about function rather than about where the code runs. Your quality and regulatory functions determine where the line falls. We build to that determination and we raise the question early, because discovering it late is expensive.
Frameworks the controls may need to support
- FDA cybersecurity expectations for connected devices, covering the device and the services it depends on
- FDA QMSR and ISO 13485 where the integration sits inside the quality system
- IEC 62304 and ISO 14971 for any component determined to be within device scope
- IEC 81001-5-1 for health software security lifecycle activities, where applicable
Security
- Device identity and authentication, with credential rotation that works on units you cannot physically reach
- Encryption in transit and at rest, with key management treated as an operational process rather than a setting
- Least privilege between the ingest layer, the semantic layer and every consuming system
- Component inventory and vulnerability management across the pipeline, since it is as much of the attack surface as the device
Patient data
- Classification before storage, because retention, residency and access obligations follow from it
- Minimisation at the edge where possible, since the cheapest data to protect is the data never collected
- HIPAA where applicable, with the business associate position and sub-processor chain documented
- GDPR and other privacy obligations where the data concerns identifiable individuals, as your counsel determines
Traceability
- Lineage from any delivered value back to the source events and the mapping version applied
- Audit trails over the semantic mappings, since changing one changes what every downstream system was told
- Reproducibility, so a figure delivered six months ago can be regenerated as it was
- Validation of the integration path scoped with your quality function and proportionate to what it does
Changing a mapping rewrites history, and that should require a decision
The semantic layer is where device events become business facts, and a change to it alters what every downstream system was previously told. Correcting an identity mapping reassigns historical events to a different customer. Revising a derivation changes a figure somebody reported last quarter.
This is the characteristic hazard of the domain and it deserves stating on its own. When a device stops reporting, downstream systems see fewer errors, lower utilisation and no alerts, which is indistinguishable from the equipment working well. Every other failure mode below shares the property of being silent, which is why instrumenting the data itself matters more here than in most integration work.
A device stops reporting
Fewer errors and lower utilisation, which reads as improvement everywhere downstream
Identity mapping is stale
Events attributed to the previous customer, contract or site after a transfer
A clock is wrong
Events ordered incorrectly, or attributed to the wrong day, shift or billing period
A firmware release changes the payload
A field moves or changes meaning and the pipeline keeps parsing confidently
A schema change drops a field silently
The pipeline stays green and information simply stops arriving
A Downstream Delivery Fails After Ingest Succeeds
The platform reports success and the consuming system never received it
Aggregation Hides the Signal
The summary the enterprise receives is smooth and the condition was visible only in the raw data
Coverage Falls and the Rate Improves
The denominator shrank, the chart looks better, and nobody reported the coverage
Publish Coverage Next to Every Number
Any figure derived from fleet data is uninterpretable without knowing what proportion of the fleet it represents, and that proportion moves constantly as units go offline, updates fail and devices are decommissioned without being deregistered. Coverage belongs on the same view as the number: devices in scope, devices reporting, devices with gaps, and the comparison with the previous period. A utilisation figure that fell because coverage fell is a different fact from one that fell because usage fell, and nothing in the figure distinguishes them.
Alert on absence, not only on error
Silence is the failure mode that looks like success in every downstream view
Monitor the identity match rate continuously
Unmatched events are the leading indicator of a mapping going stale.
Reconcile counts end to end on a schedule
Events emitted, received, processed and delivered should tie out, and when they stop, something is being dropped.
Track clock offset per unit as a monitored metric
Drift is gradual and the day it matters is the day somebody disputes a timestamp.
These programmes are reported as devices connected and data volumes ingested. The outcome that matters is whether anybody outside engineering changed what they did because of device data, which requires it to arrive somewhere they already are.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Consuming Systems Integrated | Enterprise and clinical systems receiving device data inside their own records | The actual deliverable, and the one most programmes never reach. |
| Non-Engineering Usage | People outside engineering acting on device-derived information monthly | Distinguishes a delivered capability from an available dataset. |
| Identity Match Rate | Events resolvable to asset, customer and contract as at event time | Determines whether any downstream figure can be trusted. |
| Fleet Coverage | Devices reporting against devices in service, trended | Without it, every rate is uninterpretable and silence reads as good news. |
| Data Freshness by Destination | Lag from occurrence to availability in each consuming system | Different destinations need different latency and most are over-engineered. |
| Reconnection Headroom | Ingest capacity against the fleet returning after an outage | The load that takes the platform down, and rarely the one it was sized for. |
| Mapping Change Control | Semantic changes made with assessment and preserved history | A mapping change restates history, which should be a decision. |
Honest Expectation Setting
Expect identity resolution to be the largest piece of work and the least visible. Expect the fleet inventory to be wrong. Expect the aggregation contract to require business decisions that have not been made and will take longer than the engineering.
We will start from the decisions the data should support, define what each consuming system needs and in which of its records, build the identity and time model that makes the data trustworthy, and integrate it into the systems people already work in rather than into another place for them to visit.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
