Smart infusion pumps sit in nearly every American hospital. Only 10% to 15% of those hospitals have the pumps talking to the patient record, according to a 2025 health economic analysis published in ClinicoEconomics and Outcomes Research. Where hospitals did connect the two, nurses stopped retyping infusion data: one eight-hospital system cut roughly 42 million manual keystrokes a year. The distance between a device that can send data and a device whose data lands in the right field is where medical device integration lives.
The same distance shows up in healthcare apps, at smaller scale and with different hardware. A patient inflates a Bluetooth blood pressure cuff at home, and between that cuff and their clinician’s dashboard sit half a dozen steps that each have their own failure mode. This article follows one reading along that path, then covers what repeats for every additional device type you support, which regulations apply, and how to scope the work before anyone writes an estimate. Budget and risk scale with the number of device types you support, not with patient numbers or units in the field. We have been building healthcare software with BLE device integration for clinics, diagnostics providers and US health companies for over a decade, so the detail below comes from shipping this work rather than from a vendor datasheet.
Medical device integration, defined
Medical device integration covers two engineering jobs that share a name and little else. One happens on a hospital floor, where a ventilator or a bedside monitor feeds a hospital information system through middleware. The other happens inside an application, where a phone or a backend talks to a device the patient owns. Buyers routinely get quoted for the first when what they need is the second.
A working definition of medical device integration
Medical device integration is the engineering work that moves measurements from a medical device into software that stores, displays or acts on them, with nobody typing the numbers in. It spans three things: the connection to the device, the translation of the manufacturer’s data format into your own, and the delivery of each reading to the correct patient record.
Break any one of those and you are back to manual entry. A cuff that pairs but returns a payload you cannot decode is as useless as one that never connects, and a perfectly decoded reading attached to the wrong patient is worse than no reading at all.
Integration against interoperability
The two words get used interchangeably in vendor marketing, and the distinction matters once you are writing a contract. Integration is point-to-point: this device model, this firmware, this system. Medical device interoperability is a property of a system that accepts data from any device conforming to a published standard, which the FDA treats as a design goal for manufacturers rather than something that happens by accident.
Medical device connectivity sits underneath both and describes only the link: the device is able to transmit. Connectivity without integration gives you a cuff that talks to nothing in particular.
Almost every healthcare app buys integration and hopes for interoperability. A monitor implementing the standard Bluetooth Blood Pressure Profile can be read by any app that speaks it. One shipping a proprietary format needs code written against that manufacturer, and that code stops working the day they change it.
Two paths: hospital middleware and app-side integration
Where the device physically sits decides nearly everything else about a medical device integration project, including who pays for it.
| Hospital middleware | App-side integration | |
|---|---|---|
| Typical devices | Ventilators, infusion pumps, bedside monitors | Home cuffs, glucose meters, scales, pulse oximeters |
| Transport | Wired serial, hospital network, vendor gateways | Bluetooth Low Energy to the patient's phone |
| Who owns the connection | Hospital IT and a middleware vendor | Your application |
| Destination | Hospital information system, EHR flowsheet | Your backend, then optionally an EHR |
| Main failure mode | Device mapping, network policy, procurement | Backgrounding, pairing, patient assignment |
| Who pays | The hospital | The product owner |
Volume is moving toward the right-hand column. Primary care practices that took up remote physiologic monitoring grew Medicare revenue by 20% against matched non-adopters, with remote monitoring reaching 12.4% of their traditional Medicare revenue, according to a Health Affairs study of 754 practices published in November 2025. Remote patient monitoring programs run on consumer-grade devices in patients' homes, which puts the medical device connectivity burden on the app rather than on hospital IT.
The path of one blood pressure reading
A single measurement crosses more boundaries than most product owners expect, and medical device integration is the sum of what happens at each one. Here is the whole path for a home blood pressure cuff, the usual starting point for a remote patient monitoring product:
- The patient inflates the cuff and the device stores a reading in its own memory.
- The cuff advertises over Bluetooth Low Energy, and the app discovers and connects to it.
- The app reads the relevant characteristic and receives a byte array.
- Those bytes get parsed into systolic, diastolic, pulse, a timestamp and a unit.
- The reading is encrypted, stamped with a patient identifier and queued for upload.
- The backend validates it, stores it, and passes it to a dashboard or an EHR.
Steps three and four are where standards help. Step five is where products quietly fail.
Pairing and reading data over Bluetooth Low Energy
BLE devices expose their data as services, each holding characteristics with a numeric identifier. The Bluetooth SIG publishes assigned numbers for common medical measurements, so a cuff implementing the Blood Pressure Service exposes a known characteristic returning systolic, diastolic and mean arterial pressure in a defined layout. Read it, decode the flags byte to learn whether the values are in mmHg or kPa, and you have something usable.
Plenty of devices skip the standard. Manufacturers ship proprietary services with undocumented payloads, sometimes because the hardware predates the profile, sometimes to keep customers inside their own app. Getting data out of one of those means obtaining the vendor's SDK under an NDA, or reconstructing the format from captured traffic. The second route is slow, fragile, and occasionally forbidden by the license you agreed to.
iOS and Android expose BLE through their own APIs, and they differ enough that a shared codebase still needs platform-specific handling. One cross-platform codebase in React Native covers the interface and the business logic for both, with a thin native layer where the Bluetooth stack demands it. Most of the per-device work lives in that thin layer.
Background delivery, the part that breaks
Ask patients to open an app before every measurement and a share of them will not, which turns a clinical dataset into a partial one. Keeping the pipeline alive without their attention is the hardest engineering problem in remote patient monitoring, and it gets almost no coverage in guides to this subject.
iOS will hold a background Bluetooth connection under specific conditions. An app declares the central background mode, and Core Bluetooth relaunches it in the background when a known peripheral delivers data, provided state preservation and restoration are implemented properly. Android brings its own constraints: Doze mode, foreground service rules that have tightened with almost every release, and manufacturer-specific process killing that ignores the documented behavior entirely.
What that means for the product:
- Readings will arrive late. Build the backend around out-of-order timestamps instead of assuming arrival order matches measurement order.
- Devices hold a backlog. A cuff with onboard memory hands over everything it stored on the next connection, so the app has to deduplicate against what the server already holds. That gets harder the moment two phones share one patient account.
- Battery complaints are a product risk. An aggressive scan interval drains a phone and gets the app deleted.
- Emulators prove nothing here. Test on a three-year-old Android handset with a vendor battery manager, because that is what a real patient is holding.
Assume the data path will be interrupted and design for reconciliation, because a remote patient monitoring product is worth exactly as much as the readings that reach the server.
Sending readings onward with HL7 FHIR
Your own database is enough for your own dashboard. The moment a clinician wants those numbers in the chart they already work in, the job becomes EHR integration, and that conversation happens in HL7 FHIR or in older HL7 v2 messages.
A blood pressure reading becomes an Observation resource, coded with LOINC, referencing a Patient and usually a Device. FHIR is a national standard in the US and the API layer most vendors now expose, which makes the mechanics fairly predictable. The politics are less so. Write access to a hospital's EHR depends on that hospital's policy, the vendor's app review process and often a commercial agreement, none of which is an engineering problem you can solve in a sprint.
Scope medical device EHR integration early for that reason. Sending an Observation is a week of work. Being allowed to send it can take months.
Per-device work and the regulatory envelope
The second device type costs nearly as much as the first, which surprises most buyers. The list below is why. Regulation wraps around all of it, and medical device integration crosses into regulated territory further upstream than product teams tend to assume.
The work that repeats for every device type
Supporting a new device means running the whole medical device integration sequence again from the beginning:
- Obtain the unit, the documentation and, where the format is proprietary, the SDK plus whatever license comes attached to it.
- Implement discovery, pairing and reconnection for that model's quirks. Devices differ in whether they bond, whether a button press is needed to enter pairing mode, and how they behave when a second phone tries to connect.
- Parse the payload and handle units, precision and time zones. A scale reporting in stones is a real support ticket.
- Assign every reading to the right person, which matters most in households where two people share a cuff.
- Test against the physical unit across firmware versions. We keep the actual hardware on desks for this, because an integration that passes on a simulator and fails on real equipment is the normal outcome.
The transport layer and the upload pipeline carry over between devices. The parsing, the pairing behavior and the test cycle start again each time.
Our own projects show the spread. The Vheda Health platform, which we have been developing since 2014, consists of a backend API and a clinician web application connecting four device categories: glucose meter, pulse oximeter, blood pressure monitor and thermometer. On the mobile side we built a patient-facing app for a US healthcare provider with over 40 features and eight integrated medical devices, streaming weight, pulse, blood pressure and glucose readings over BLE. Same domain, integration effort an order of magnitude apart, and the device count explains most of the gap.
Security and compliance under HIPAA and GDPR
Device-sourced data is patient data from the moment it leaves the device, which puts the entire pipeline in scope. Encryption starts at the BLE link and continues to the backend. Readings need the same audit trail as anything a clinician types, with one addition: the record should show which device produced the value and when it arrived, because a reading that surfaces six hours late looks like a clinical event if nobody logged the delay.
HIPAA loads the work onto the Security Rule safeguards in 45 CFR Part 164: access controls, audit controls, transmission security, and business associate agreements with every subprocessor. GDPR pushes elsewhere. Article 32 asks for security appropriate to the risk, while the surrounding regulation adds lawful basis, data minimization, erasure and portability. A continuous stream of vitals turns minimization into a genuine design question, so decide up front what you keep, at what resolution, and for how long. We go through what compliance adds to a healthcare budget separately.
The point where your app becomes a regulated medical device
A cleared blood pressure monitor arrives with its manufacturer's regulatory paperwork. That clearance covers the hardware. Your software gets assessed on its own terms.
In the US, the FDA looks at what your software does with the data under its Software as a Medical Device framework. Displaying a reading and storing it generally sits outside the definition. Interpreting it, raising an alert that drives a clinical decision, or calculating a score a clinician acts on moves you toward being a regulated product. In the EU the Medical Device Regulation applies, and its Rule 11 classifies decision-support software more strictly than many teams expect, putting software intended to inform diagnostic or therapeutic decisions in Class IIa or above.
The useful advice here is dull and saves a great deal of money: get a regulatory opinion on your intended purpose before you build the feature that triggers classification. Retrofitting a quality management system around a shipped product costs multiples of doing it in the right order.
Planning a medical device integration project
Three decisions move a medical device integration budget more than anything else: which devices you support, how you connect to them, and who does the work. Taking them in that order is what keeps an estimate stable once the hardware arrives.
Questions for the device manufacturer before you commit
The device vendor holds most of the risk in this project, and one call before selection surfaces nearly all of it. Ask:
- Is the data exposed through a standard Bluetooth profile, or a proprietary service?
- Is protocol documentation published, and can we read it before signing anything?
- Is there an SDK, what does it cost, and what does the license permit?
- How often does firmware change, and are older protocol versions supported afterwards?
- Can we buy loaner units for a test lab, and how do replacements work?
- Which regulatory clearances does the device hold in our target markets?
A vendor answering all six quickly is worth paying more for. One who routes you to a sales engineer and an NDA for question two has told you something useful about the next twelve months.
Those answers belong in the needs analysis stage, before anyone commits to a number.
Medical device integration software: build, buy, or platform
Three routes exist, and the right one depends mostly on how central device data is to what you sell.
| Build it yourself | Buy an SDK layer | Use a connectivity platform | |
|---|---|---|---|
| What it is | Your own BLE and parsing code per device | A vendor SDK covering many models | A hosted service with devices, connectivity and an API |
| Best when | Few device types, data is your differentiator | Many device types, standard measurements | Speed matters more than margin |
| Cost shape | Engineering time up front | License plus integration work | Per-device or per-patient, indefinitely |
| Control | Full | Partial | Limited |
| Main risk | You own every firmware change | Their device list may not match yours | Lock-in, and pricing that scales with your success |
Medical device integration software from a third party solves a real problem when you support fifteen models and none of them differentiate you. It gets expensive when per-patient margin is thin and the platform takes a cut of every patient. Buy the commodity, build the differentiator: the rule applies here as cleanly as anywhere else in software.
Budget, timeline and the team you need
Ranges for this work are wide because the variable that matters is the device rather than the feature list. A device with a standard profile and published documentation is a contained piece of work. An undocumented one, with an NDA-gated SDK and a manufacturer in another time zone, can absorb more calendar time than the rest of the app, and most of that time goes nowhere near a code editor.
Cover these four roles before the first sprint:
- A mobile developer who has debugged a BLE connection before. Building screens is a different skill.
- Backend work for ingestion, deduplication and out-of-order handling.
- QA with the physical devices, running the full cycle on real handsets rather than emulators.
- Someone accountable for regulatory classification, consulted before the roadmap commits to alerting or scoring features.
Rates for that team run $25 to $60 an hour in Poland and Central Europe against $100 to $180 for a US agency, and the gap is large enough that most US digital health companies now split the work across regions. A dedicated development team on time and material fits the first device better than a fixed price does, because until the hardware is in someone's hands nobody can quote the parsing honestly. Ship one device properly, then estimate the rest from what it taught you, because the second integration is the one that tells you what the tenth will cost.
FAQ – medical device integration
These come up on almost every first call about medical device integration. The answers assume an app-side build rather than a hospital deployment, and the figures are market ranges rather than quotes.
What is medical device integration?
Medical device integration is the work of getting measurements from a medical device into software automatically: the connection, the translation of the manufacturer's data format, and the delivery of each reading to the correct patient record. It is narrower than medical device interoperability, which describes a system able to accept data from any standards-conformant device, and narrower than EHR integration, which concerns records rather than hardware. A device that displays a number on its own screen sits outside all three.
How long does it take to integrate one medical device into a healthcare app?
The device sets the timeline, so the honest answer is a set of factors rather than a number. Four of them account for most of the variation:
- Whether the device uses a standard Bluetooth profile or a proprietary one
- Whether protocol documentation is public, NDA-gated, or absent altogether, which is the single largest swing factor of the four
- How it behaves in the background on both platforms
- How many firmware versions are already in patients' hands
Sequence the roadmap around that. Scope the least documented device first, while there is still room to drop it, and keep any device you have not physically held off the launch-critical path.
Does connecting a medical device to your app require FDA clearance?
The device's own clearance does not extend to your software, which gets assessed separately on its intended purpose. That phrase has a specific regulatory meaning, and regulators read your marketing copy to establish it. A landing page promising to detect early warning signs can place an app inside the medical device definition even when the code only draws a chart, which is why the claims your website makes belong in the same review as the feature list.
Can a healthcare app pull data from consumer wearables like Apple Watch or Fitbit?
Yes, through the platform health stores rather than device by device. Apple HealthKit and Android Health Connect both let an app request read access to heart rate, steps, sleep and similar metrics with the user's explicit consent, which removes the per-device Bluetooth work entirely. The trade-off is provenance: a consumer wearable is usually a wellness device rather than a cleared medical one, so its accuracy carries no clinical guarantee and readings arrive without the audit trail a regulated device provides. Plenty of products run both, using wearables for engagement and cleared devices for anything clinical.
What does medical device integration software do?
Medical device integration software sits between the devices and your application, handling what you would otherwise write once per device. A typical product covers:
- Connection and pairing across a catalog of supported models
- Normalization of vendor data formats into a single schema
- Delivery to your backend or onward to an EHR over HL7 or FHIR
Check the supported-device list against your actual shortlist before anything else. Most of these products grew out of hospital medical device connectivity, so they are strongest on bedside equipment and thinner on the consumer-grade home devices a remote monitoring program usually runs on.
What happens when a device manufacturer updates its firmware?
Sometimes nothing, sometimes your parser breaks for every patient holding that model. Manufacturers are under no obligation to keep a proprietary data format stable, and there is rarely a notification channel that reaches your engineering team in time. Budget for regression testing against the physical devices whenever a vendor ships an update, and treat it as a permanent maintenance line rather than a one-off cost.
