A connected blood pressure cuff is the easy part of a remote monitoring program. The hard part comes after the reading: which standard carries it, which system stores it, and who answers for it if the pipeline is breached.
Healthcare IoT software development is mostly the work of settling those questions before a device ships. Below: how data should travel from sensor to record, what the FDA expects of networked devices, and where the written guidance runs thin enough that your own engineering has to fill the gap.
Healthcare IoT software development starts with the data path
A device pipeline has four hops: the sensor itself, a relay such as a gateway or a patient's phone, a cloud service that validates and stores the reading, and the EHR or analytics system at the end. Every hop can lose data, mistranslate it or expose it, so each one needs its own design decision instead of a shared assumption that the platform will handle it.
In the research, short-range radio carries the first hop. A 2025 scoping review in Frontiers in Digital Health screened 861 studies and kept 25, and ten of those referenced Bluetooth, RFID or ZigBee as the transport.
When the relay is a patient's phone, your mobile app becomes part of the medical data path. Its behavior on a dropped connection or a killed background process decides whether a reading arrives at all.
That patient-facing layer is the part we know best. We designed and built OptimalMD's website, members portal and mobile app end to end, from design through launch.
Which standards connect a device to the record?
Three families come up again and again: ISO/IEEE 11073 for communicating with the device, HL7 FHIR and CDA for exchanging data with clinical systems, and IHE profiles as the infrastructure framework around them. In the same review, 11073 appeared in more studies than FHIR and CDA did, and IHE profiles trailed both.
Having the standards hasn't produced harmony. The authors reported a lack of harmonization, with no common standard for device-to-EHR data exchange despite the protocols being available, and 52% of the studies were conceptual designs rather than live deployments.
The review looked at cross-border telemonitoring, and its authors called for European-level standards, so read it as a signal rather than a verdict on every US deployment.
The practical lesson holds either way. Choose one internal data model, translate each device's format into it at ingestion, and translate out to FHIR or HL7 only at the edges, so a new device never forces a change to the EHR connection.
Why the EHR end is where projects stall
Fifteen of the 25 studies flagged the need to exchange data between different applications and IT providers. Your code is rarely the only moving part.
Plan for that in the contract and the schedule. Ask each EHR vendor which interfaces they expose before you design the ingestion layer, because a pipeline built around the wrong one gets rebuilt. Our write-up on what EHR software development requires for compliance and the broader healthcare software development guide cover the surrounding system.
Alerting belongs in this stage too. Decide who receives an out-of-range reading, through which channel, and what happens when nobody acknowledges it.
What the FDA expects once a device is networked
For wireless and network connected medical devices, the FDA expects cybersecurity to be demonstrated in the premarket submission. The statute behind that, Section 524B, was enacted in December 2022 as part of the Food and Drug Omnibus Reform Act, and the agency's guidance was finalized in June 2025 and revised on February 27, 2026.
What Section 524B asks for
According to Morgan Lewis's summary, manufacturers must provide a reasonable assurance of cybersecurity and maintain cybersecurity processes across the device's lifecycle. They also have to generate and manage a software bill of materials inside their quality system.
Vulnerability monitoring is part of it as well, along with making updates and patches available either regularly or as soon as possible, depending on how the vulnerability is categorized.
For a software team, the patching duty is the expensive one. Every device in the field needs an update path from day one, and a pipeline with no way to push an update has a compliance gap built in.
What changed in February 2026
The revision, as DLA Piper describes it, aligns the guidance with the new Quality Management System Regulation. It replaces references to specific subsections of Part 820 with subclauses of ISO 13485:2016 and states that cybersecurity risk management is a component of overall quality management.
If you write software for a device maker, expect their quality system to reach into your development process, since your risk assessments and component inventories may become inputs to theirs. Whether a given product counts as a regulated device is a question for regulatory counsel, and none of the sources we read settles it.
Where the security guidance runs thin
Photo by Dávid Lehoczki on Pexels
The FDA guidance leaves gaps that your own requirements have to close. A July 2025 comparison in Computational and Structural Biotechnology Journal of the FDA's premarket guidance and the EU's MDCG 2019-16 found that the FDA document has too little detail on network security and third-party component management.
The same paper says both documents inadequately address hard-coded credentials, and it lists missing requirements for multi-factor authentication and supply chain security among its gaps.
Turn each gap into a requirement of your own: no credentials baked into firmware or app builds, multi-factor authentication on every clinician login, and an inventory of every third-party library that doubles as your software bill of materials.
HIPAA sits on top of all this, and our guide to HIPAA compliant app development covers what that takes in practice.
A build order that limits rework
Sequence matters more than speed here, because the expensive mistakes are the ones baked into the first device choice. Decide early whether to build or buy the monitoring layer; our comparison of remote patient monitoring software, build vs buy sets out the trade-offs, and our apps and SaaS development team builds this kind of product when building is the answer.
A workable order:
- Fix the device list and transports first, since each one dictates what the relay has to do.
- Define the internal data model and its mapping to FHIR or HL7 before building any screen.
- Get the interfaces your EHR vendor exposes confirmed in writing.
- Put the security requirements above into the backlog, together with the update path and the component inventory.
- Pilot with one device type at one site and read the failure log before widening it.
Frequently asked questions
Does FDA cybersecurity guidance apply to every connected health product?
The revised guidance, as DLA Piper describes it, covers wireless and network connected medical devices. Whether a particular app or platform counts as a medical device is a regulatory question, so settle it with counsel before the design is frozen.
What is a software bill of materials?
It's an inventory of the components inside a piece of software. Section 524B requires one to be generated and managed within the manufacturer's quality system.
Can weak cybersecurity create legal risk beyond FDA review?
Yes. Morgan Lewis points to a DOJ settlement with Illumina, which allegedly ignored and failed to mitigate cybersecurity vulnerabilities in products sold under federal grants and contracts, as an example of False Claims Act exposure.
Cover photo by MedPoint 24 on Pexels
