A medical device competes on its measurements only until a competitor matches them. In most categories, one eventually does. Once the hardware is comparable, the decision comes down to price, and a clinically precise device loses its margin to cheaper rivals.
What protects that margin is a digital component clinicians rely on: software that closes a gap they feel every day and makes the device the one they want to keep. The previous article in this series showed how to find that gap. Workflow analysis locates where care breaks down and defines the role the digital component should play.
Defining the role is the commitment step. Delivering on it depends on the data underneath. A monitoring or decision-support component is only as good as the intelligence feeding it, and that intelligence doesn't come from telemetry alone. It comes from a multimodal data pipeline that fuses device signal with clinical context the way a clinician does. That pipeline, not the hardware, is what turns a replaceable device into one clinicians won't give up.
Device telemetry is often the starting point for medical OEMs because it is readily available. However, telemetry alone shows device activity, not patient outcomes. To support monitoring, decision support, or care coordination, this data needs to be combined with clinical context from imaging, lab results, and care notes. A multimodal data pipeline is required to create this level of clinical context.
There are five key challenges between defining a digital component and delivering intelligence that clinicians can actually use. How OEMs address these challenges will determine whether their software becomes a defensible capability that is difficult for competitors to match.
Five stages between device data and useful intelligence
Understanding how to build a multimodal medical device data pipeline involves more than connecting systems. For Software as a Medical Device (SaMD) to deliver measurable value, the pipeline must safeguard patient information, handle incomplete or inconsistent data, and deliver actionable outputs directly into the systems clinicians rely on.
At a high level, this includes five stages:
- Ingest and fuse: Combine device telemetry with relevant clinical context.
- Scrub and secure: Protect identifiable patient information before it crosses organizational boundaries.
- Process and interpret: Account for incomplete, irregular, and potentially meaningful data gaps.
- Translate and deliver: Return findings through the systems clinicians already use.
- Learn and protect: Improve the model through a governed architecture that respects patient privacy and device intellectual property.
The sections below explain why each stage is important.
For a detailed look at the technical workflow and common implementation challenges, download Five stages to a defensible multimodal data pipeline.
1. Ingest and fuse: Device telemetry is only half the clinical picture
Connected medical devices generate a range of data, including temperature, pressure, movement, dosage, and usage events. However, these signals are limited in value when taken in isolation.
Connected wound care shows the gap. A smart dressing reports a temperature rise, but the reading means little in isolation. Fuse it with moisture and pH from the same sensor, a 3D wound photograph or OCT scan, and a nurse's note on exudate, and a pattern surfaces: warmth climbing, tissue discoloring, drainage documented — an early infection no single signal could establish with confidence. The pipeline reads them together, the way a clinician does.
The same applies to orthopedic implants. Joint-load data can show how an implant is being used, imaging can reveal changes at the bone-implant interface, and physical therapy notes provide context about pain and recovery. Together, those sources may identify loosening or instability earlier than telemetry alone.
The objective is not to amass more data, but to build a more complete picture of the patient’s condition, connecting the signals that allow clinicians to understand what is happening and decide what to do next. For OEMs, that creates an opportunity to move beyond reporting device performance and support informed decisions across the wider care pathway.
2. Scrub and secure: Compliance must be built into the pipeline
When device data is combined with hospital imaging, lab results, or clinical notes, privacy and security become core product and architecture requirements.
Removing standard identifying fields from an imaging file may not be enough. In real-world clinical environments, up to 1.5% of medical image files may contain burned-in patient identifiers, such as names or medical record numbers embedded directly within the image pixels. Clinical notes may contain identifiers that do not appear in predictable metadata fields.
A secure ingestion boundary must be in place to protect sensitive information in both images and text. PHI de-identification for connected medical devices must remove identifiers while preserving the clinical detail needed for effective modeling.
If de-identification is insufficient, organizations face privacy and regulatory risks. If too much detail is removed, critical time relationships, imaging features, or clinical information may be lost, reducing the value of the data.
The real issue is not just accessing data, but ensuring it can be processed safely while retaining the clinical context that makes it meaningful and actionable.
3. Process and interpret: Missing data may be part of the signal
In reality, clinical and at-home data are never as orderly as development datasets. Patients may forget to sync devices, batteries can fail, tests are ordered at different intervals, and clinical documentation may be incomplete.
A resilient pipeline must distinguish between technical gaps and clinically meaningful absences. A missing reading might be due to a connectivity failure, but it could also signal something important about the patient or care process.
Take a smart inhaler. A missing sync event could indicate that the patient’s phone was offline or that the patient stopped using the device. Filling the gap with a historical average could mask an adherence issue, but recognizing a change in pattern could prompt appropriate or timely intervention.
An external validation of the first Epic Sepsis Model found that, at the evaluated threshold, it missed 67% of sepsis cases while generating alerts for 18% of hospitalizations. The study shows how model performance can deteriorate when development assumptions do not match a live clinical environment.
Strong performance in development does not guarantee clinical value. Assumptions about data quality, local workflows, and alert thresholds must be validated in real-world clinical settings.
4. Translate and deliver: An insight outside the workflow is an insight no one uses
A technically accurate model can still fail if clinicians are forced to leave the electronic health record, use separate portals, or manually re-enter information. If the digital solution adds to their workload, it is likely to be ignored over time. Medication-related clinical decision support alerts are overridden in up to 96% of cases, showing how quickly tools lose value when they interrupt workflows with information that is not sufficiently relevant or actionable. Healthcare data interoperability must be part of product adoption, not just backend infrastructure. The pipeline must translate its outputs into formats the hospital’s existing systems can receive and that clinicians can act on.
Standards such as Fast Healthcare Interoperability Resources (HL7 FHIR) and Digital Imaging and Communications in Medicine (DICOM) support the exchange of structured findings with electronic health record (EHR) and imaging systems. Implementation will vary, but the principle is consistent: insights should appear where the clinician is already working and in a form that supports the next decision.
For a radiologist, that might mean incorporating an AI-generated finding into the existing reporting workflow as editable draft text. For another care team, it may mean presenting a risk indicator in the relevant EHR view rather than sending a separate alert through an OEM portal.
The goal is to create an output that reduces the effort required for clinicians to understand and act, not to burden them with more data or additional monitoring systems.
5. Learn and protect: Create a governed path to improvement
A multimodal pipeline gains value as it is validated and improved over time, but it creates governance challenges.
OEMs need appropriate access to data and feedback to understand model performance. Health systems must protect patient records, while OEMs must safeguard proprietary telemetry, models, and software intellectual property.
A centralized repository of raw patient data is unlikely to be acceptable to many hospital legal, privacy, and security teams. A fully decentralized model can be difficult and expensive to operate across multiple health systems.
A hybrid governance architecture is the most practical solution. Privacy-sensitive processing and de-identification can occur within the hospital or at a controlled edge. Approved and protected data can then be transferred to a centralized infrastructure for model processing, validation, and improvement.
This approach does not eliminate the need for clear agreements, access controls, auditability, or ongoing monitoring. However, it separates two competing requirements: keeping identifiable patient data within defined boundaries and building a scalable learning system.
The feedback loop should also show how outputs perform in practice. Do clinicians accept, change, or reject them? Do they lead to the intended action? These signals help the OEM improve both the model and the way its intelligence is presented.
The defensible asset is the data layer beneath the device
Hardware telemetry provides value, but it is not enough for lasting differentiation. Competitors with similar devices can often generate comparable measurements, usage events, or operational data.
What is harder to copy is the surrounding system: clinical partnerships, secure data access, healthcare data interoperability, validated models, and integration into day-to-day clinical work. Together, these capabilities create a proprietary multimodal data layer that becomes more useful as evidence and adoption grow.
That layer can make the device more clinically relevant and less vulnerable to price-based substitution. It can also strengthen relationships with clinicians and health systems because the OEM contributes to decisions and outcomes, not just supplies hardware.
Workflow analysis defines the intended role of the digital component. The multimodal pipeline determines whether the OEM has the data, infrastructure, and operating model to deliver on that role and make it defensible.
How Star can help
Building a multimodal medical device data pipeline requires expertise in clinical data modeling, FHIR and DICOM interoperability, regulatory compliance, data governance, cloud and edge architecture, and clinician workflow design.
Star brings these disciplines together in an integrated team. We partner with medical device OEMs to define clinical and commercial objectives, design the supporting architecture and workflows, and build the compliant software and infrastructure required for real-world deployment. Our approach moves beyond telemetry to create intelligence that reflects clinical context, integrates into existing workflows, and improves through governed use.
Build the data layer behind your clinical advantage
Turn device telemetry and clinical context into secure, workflow-ready intelligence that competitors cannot easily replicate.
FAQ
A multimodal medical device data pipeline combines device telemetry with clinical information such as imaging, lab results, and care notes. This provides the context needed to turn isolated device signals into intelligence that can support clinical decisions.
