How to Develop a Healthcare IoT App

Healthcare IoT app development is a system build, and the mobile app is the smallest piece of it. A connected device generates readings. The mobile app pairs with it and passes them on. A cloud backend ingests and stores them, and a provider dashboard is where they become a decision. Miss a layer and the product doesn’t work.

The name for that system is IoMT, the internet of medical things. Worth using, because the FDA and everyone chasing the same buyer already do.

What follows, in order: architecture, connectivity, build order, FDA cybersecurity and HIPAA, what Medicare reimburses, and what the whole thing costs. If your project isn’t healthcare-specific, start with our guide to developing an IoT app instead. If it is, and you want to know what working with us looks like, that’s how we build a healthcare IoT app.

Key takeaways

• An IoMT app is four layers. Device, mobile app, cloud backend, provider dashboard. How many of them you’re building is what sets your timeline.
• Two regulatory regimes apply. HIPAA from the first byte of patient data. The FDA joins when your software interprets device readings to drive a clinical decision, which makes it Software as a Medical Device.
• Section 524B is the change most teams miss. Since October 2023, cybersecurity is a premarket gate: a software bill of materials, a vulnerability management plan, and a validated update mechanism, or the FDA can refuse your filing.
• Scope decides cost. A companion app for a device that already exists runs $30,000 to $50,000, a full IoMT system $70,000 to $200,000 or more, and a regulated build with IEC 62304 and 524B artifacts starts at $250,000.
• Reimbursement opened up in 2026. CMS added RPM and RTM codes with floors of 2 days of data and 10 minutes of clinician time, making short-course monitoring products billable for the first time.
• We’ve built these. Dedica Health for remote patient monitoring, iFaint with the Stanford University School of Medicine, JOOVV for connected light therapy, plus glucometers, breath meters, and smart pillboxes.

Table of contents:

1. What is a healthcare IoT (IoMT) app?

2. IoMT system architecture: the web layer decides what the product can do

• Health kits on mobile platforms fill the gaps your device doesn’t measure
• Managed cloud platforms are down to two real defaults
• Open-source IoT platforms: the list is shorter than it looks
• Which of these will sign a BAA

3. Connectivity choices decide whether your device needs a phone at all

4. How to develop a healthcare IoT app: step by step

5. Compliance and cybersecurity for connected medical devices after Section 524B

6. RPM and RTM reimbursement for IoMT devices

7. AI and edge computing in IoMT: inference moved to the device

8. Types of medical IoT apps, by who actually uses them

9. How much does a healthcare IoT app cost?

• What firmware co-development costs you
• Certification is calendar time
• Fleet infrastructure never stops
• Where regulated budgets go

10. Our experience developing healthcare IoT apps

What is a healthcare IoT (IoMT) app?

Internet of medical things, or IoMT, covers connected medical devices and the software that reads them and moves their data. NIST has a formal definition in its security glossary, traced back to its guidance on securing wireless infusion pumps.

Regulation is what separates IoMT from general IoT. A connected thermostat and a connected glucose meter can run the same radio stack and the same cloud broker. Only one of them puts you in front of the FDA and inside HIPAA, and that difference shows up in your architecture and your schedule.

A healthcare IoT app is a system with three parts: a consumer-facing mobile app, the sensor or instrument taking the readings, and a web application for providers.

Take a medication reminder app wired to a smart pillbox. It knows when a dose is taken and when one is skipped, and it nudges the patient when the next one is due. Miss a dose and the doctor gets a text, while the patient record picks up the event.

The app itself talks to two things: the pillbox and a web application. Everything past the phone happens in the web app, which is also what holds the connection to a clinic’s EHR system:

• sends a text (or notification) to the doctor
• updates the patient record in EHR
• silently reports back to the IoT app that it’s completed these actions
• runs analysis over the dose history to surface trends in treatment

That system framing has teeth. In March 2024, Fresenius Kabi issued an urgent field correction after multiple software anomalies in its Ivenix large volume infusion pump created a risk of serious injury or death. The FDA classified it Class I, the most serious recall category the agency has. The fix shipped as a software version, 5.9.1.

IoMT app development starts from that premise: when software drives the device, the software carries the device’s risk class.

IoMT system architecture: the web layer decides what the product can do

Every IoT medical app we’ve built has the same four layers, and teams underinvest in the last two almost every time. The device generates readings and the mobile app pairs with it. The cloud backend and the provider dashboard, the web layer, are where those readings turn into something a clinician can act on.

The IoMT system architecture in flow order:

1. A sensor or connected device captures readings and transmits over BLE, Wi-Fi, or cellular.
2. A mobile app pairs with the device and buffers readings when the connection drops, then passes them upstream.
3. A cloud backend ingests the stream, usually over MQTT, stores it, runs rules against it, and maps it to FHIR resources the EHR can read.
4. A provider-facing web app reads from that backend.

Strip out the web layer and you leave patients alone with numbers they can’t interpret, and clinicians with nothing to act on. It’s also the layer carrying most of your compliance exposure, which is why platform selection deserves more scrutiny than it usually gets.

Health kits on mobile platforms fill the gaps your device doesn’t measure

The mobile layer rarely owns the data by itself. An IoMT app connects to HealthKit, Google Fit, or Samsung Health depending on where it runs. That’s where you pick up context the device never captures, like sleep and weight from a scale you didn’t build. If the product has a study or care-plan component and you’re on Apple, ResearchKit and CareKit are worth knowing about.

Managed cloud platforms are down to two real defaults

AWS IoT Core and Azure IoT Hub are both active and both reasonable defaults. Google’s option is gone: Cloud IoT Core shut down in August 2023 and Google never shipped a successor, going partner-led instead. ClearBlade is the approved route, with a drop-in replacement matching the legacy feature set and more than 250 Google Cloud customers migrated by January 2024. Soracom and akenza are also named partners.

Two things to know before committing. On AWS, the pruning is happening one layer below IoT Core: IoT Analytics reached end of support in December 2025 with users pointed at Kinesis Data Streams, S3, Glue, and QuickSight, and IoT Events shut down in May 2026. Device fleets outlive services, so read “AWS IoT” as a set of independently mortal products.

On Azure, a February 2024 console message announcing IoT Central’s retirement was widely reported, then publicly retracted by Microsoft as inaccurate. Both IoT Hub and IoT Central are alive in 2026. Builders still repeat the retirement claim.

Open-source IoT platforms: the list is shorter than it looks

If you’d rather not lock into a hyperscaler, 4 names are worth the evaluation.

ThingsBoard

Apache 2.0, shipping releases through 2026 including CVE fixes. The default pick.

Magistrala

Apache 2.0, maintained by Abstract Machines. You’ll still see it called Mainflux; it was renamed in 2023.

EMQX

Read the license before you build on it. EMQX moved from Apache 2.0 to Business Source License 1.1 at version 5.9.0 in May 2025. Single-node production stays free, production clustering past one node now needs a license, and each version reverts to Apache 2.0 4 years after release. On a high-availability medical fleet that’s a budget line nobody planned for.

Thinger.io

MIT licensed and still committing in 2026. The community behind it is a fraction of ThingsBoard’s.

Which of these will sign a BAA

This is the question that should drive the decision, and it’s the one that gets skipped.

AWS signs a BAA self-service through AWS Artifact, covering only its HIPAA-eligible services. IoT Core and IoT Device Management have been on that list since July 2018. Here’s the trap: a service that isn’t on the eligibility list can’t touch PHI even with a signed BAA sitting in your account.

EMQX Cloud will sign one. ThingsBoard Cloud shows no public evidence of signing a BAA, and its terms place compliance on the customer without mentioning HIPAA at all. Self-hosting ThingsBoard sidesteps the question, since the compliance obligation lands on you either way.

Connectivity choices decide whether your device needs a phone at all

Connectivity choices land early, usually with the hardware engineers, and then quietly set the shape of the software for the rest of the project. The table sorts the options by the question that matters most: does the device need a phone nearby to work at all?

BLE connectivity is the default for anything the patient carries a phone for anyway. Power draw is minimal, and iOS and Android both support it well. The phone handles display, storage, and upload. The cost is that your device goes silent the moment the patient leaves their phone on the kitchen counter.

Related Article: How to Develop a BLE App

Zigbee and Z-Wave swap the phone for a hub. Good in a home health setup where several devices report to one gateway, useless the moment the patient travels.

Wi-Fi looks like the free option until you hit provisioning. A headless medical device has no keyboard, so getting network credentials onto it means a pairing dance over BLE or a temporary soft access point. That’s real firmware and app work, plus a support ticket every time a patient changes routers.

Cellular IoT removes the phone from the picture. LTE-M and NB-IoT let a device ship standalone and report from anywhere with coverage, which is the right answer for anything worn outside the house or deployed where you can’t assume a phone exists. You pay in carrier certification and a per-device data plan that runs for the life of the device.

Power draw sits underneath all of it. Any IoT in healthcare app has a power budget, and continuous sensor polling blows it. Drain the phone by lunch and patients uninstall you, which is why the low-power protocols exist and why sampling rate belongs on the product roadmap.

How to develop a healthcare IoT app: step by step

Every healthcare IoT app we’ve shipped has run through the same 7 decisions, and each one closes off options in the next. If you’re working out how to build a healthcare IoT app for the first time, start with the dependencies: the table maps what blocks what, and what it costs to take a step out of order.

Step 1 decides the other 6.

Step 1: Define the regulatory posture before the feature set

Wellness product or medical device? If your software interprets sensor data to drive a clinical decision, you’re building SaMD and the FDA is in scope. If it displays and logs, usually you’re not. Teams that answer this in month 6 rebuild.

Step 2: Choose the device and connectivity strategy

It comes down to whether the device ships paired to a phone:

• BLE assumes a phone is in the loop
• LTE-M or NB-IoT removes it, and adds a per-device data cost plus carrier certification

Step 3: Design the data pipeline

Decide where readings land, what transforms them, who owns retention, and whether FHIR mapping happens at ingest or at the EHR boundary. Picking MQTT for transport is the least interesting decision in this step.

Step 4: Write the compliance artifacts while you write the code

HIPAA applies from the first byte of PHI. Section 524B wants an SBOM and a vulnerability management plan at submission, which means both have to exist while you build. IEC 62304 sets the lifecycle around all of it, and it’s the same lifecycle that governs medical device software development generally.

Step 5: Build mobile, cloud, and firmware in lockstep

This is where schedules break, and the cause is almost always firmware. The app team and the firmware team are usually different people, sometimes at different companies, on different clocks. On a light therapy IoT app we built, the recurring problem was version drift: the app has to talk to the firmware sitting on the device in front of the patient, not the build the firmware team is testing against.

Step 6: Test to produce evidence a reviewer can read

4 artifacts to pay attention to:

• threat model
• penetration test results
• fuzzing on the device interface
• a traceability matrix tying each test back to a requirement

Verification you can’t trace back to a requirement doesn’t count as verification.

Step 7: Plan for the fleet you’ll be operating

How do you push a fix to devices already sitting in patients’ homes? 524B requires a secure update mechanism, so firmware OTA updates and device fleet management are design inputs.

Compliance and cybersecurity for connected medical devices after Section 524B

Connected medical device app development picked up a hard gate in October 2023. Section 524B of the Food, Drug, and Cosmetic Act made cybersecurity a premarket requirement, and the FDA can refuse to accept a filing for a cyber device that doesn’t clear it. A cyber device, in the statute’s terms, is any device with software that connects to the internet and could be exposed to a threat. That’s most of what you’re building.

Three artifacts have to exist by the time you file:

• a software bill of materials covering commercial and open-source components
• a plan for identifying and addressing postmarket vulnerabilities on a defined timeline
• a mechanism for shipping validated updates and patches, both scheduled and out of cycle

CISA publishes ICS Medical Advisories against connected medical devices from named manufacturers as routine practice, with BD and Baxter both appearing across 2024 and 2025. Getting one is an ordinary event in this market. Regulators look at whether you had a response process ready before it arrived.

HIPAA compliance applies to device telemetry the way it applies to anything else touching PHI, with one wrinkle specific to IoMT. Readings rarely stay in the service that ingested them, and the pipe into an analytics product is usually built by someone who never read the eligibility list. The rest of the HIPAA compliant application playbook carries over unchanged.

Underneath both sits IEC 62304, the software lifecycle standard: development planning, requirements, architecture, verification, and the traceability connecting them. Follow it from the start and assembling a submission is a filing job. Skip it and it’s an archaeology project. We’ve written up what IEC 62304 compliance costs a small team.

Firmware OTA updates are where 524B stops being paperwork. A secure update mechanism is statutory, which puts OTA infrastructure in the architecture from day one.

Memfault, Golioth, and Mender are the names you’ll run into for that job. All three market to medical. None has a public case study naming an FDA-cleared production device, so treat the medical positioning as marketing and judge the tooling on engineering merits.

RPM and RTM reimbursement for IoMT devices

An IoMT device that generates billable data is a different business than one that doesn’t. Two Medicare programs cover it. Remote patient monitoring pays for physiological data: blood pressure, pulse oximetry, weight, glucose. Remote therapeutic monitoring pays for the rest, including therapy adherence, musculoskeletal and respiratory status, and cognitive behavioral data.

The CY 2026 Physician Fee Schedule, finalized October 31, 2025, changed the math on both. Billing used to require at least 16 days of data inside a 30-day period and at least 20 minutes of clinician management time per month. CMS added codes on the RPM and RTM sides that drop those floors to 2 days of data and 10 minutes of management time.

What the 2026 CMS fee schedule pays for those codes is its own article.

That opens a category of product that was unbillable until this year. Post-surgical recovery windows and short-course rehab generate real signal over days instead of weeks, and none of it qualified before. If your device produces something useful in under 2 weeks, 2026 is the first year that data has a code attached to it.

One constraint worth designing around: RPM and RTM can’t both be billed for the same patient in the same month, and only one clinician can submit the claim. Which one your product supports follows the care model, so that call comes first.

One constraint worth designing around: RPM and RTM can’t both be billed for the same patient in the same month, and only one clinician can submit the claim. Which one your product supports follows the care model, so that call comes first. We’ve gone deeper on how to build a remote patient monitoring app and what remote therapeutic monitoring app development involves.

AI and edge computing in IoMT: inference moved to the device

Smart sensors produce more data than anyone reads: steps, heart rate, glucose, blood pressure, sleep staging. AI and edge computing in IoMT turns on where the interpretation happens.

For most IoMT products now, it happens on the device or on the phone. Four reasons, and power is the one teams underestimate:

• latency, since a hypoglycemia alert that round-trips to a server is a worse alert
• privacy, since inference that never leaves the device puts no PHI in transit
• power, since transmitting a raw sensor stream costs more battery than computing on it locally
• connectivity, since a health IoT app that quits in a basement or a rural home quits for the patients who need it most

That leaves the cloud the work that genuinely needs scale: trend analysis across a device fleet, model retraining, and compressing months of readings into something a clinician reads in 20 seconds. Digital biomarkers come from both places, with raw signal processing on the device and longitudinal pattern detection in the backend. We’ve covered digital biomarker tracking separately.

Running inference on the device doesn’t shrink the regulatory surface. A model driving a clinical decision is regulated software wherever it runs, and a model you intend to retrain after launch needs a change control story before launch. The machine learning techniques are the ones used across healthcare. You just run them in a much smaller compute budget.

Types of medical IoT apps, by who actually uses them

The types of medical IoT apps sort by who’s holding the screen, and the split decides your regulatory exposure. Patient-facing medical IoT app development tends to put you in front of the FDA. Staff-facing work usually doesn’t.

Patient-facing apps

These make up most of what we’ve built at Topflight Apps. They track vital signs and feed something back to the patient. Dexcom’s Stelo put a continuous glucose monitor over the counter in August 2024. Medtronic’s MiniMed Go app cleared FDA in January 2026, pairing an InPen smart insulin pen with an Abbott Instinct CGM, and the app itself is the cleared component. Propeller Health’s sensors clip onto named inhalers including AstraZeneca’s Symbicort and GSK’s Ellipta, each with its own 510(k).

One sub-group points at the doctor instead: same device data, different screen, showing adherence to a treatment plan and progress over time. That sub-group has a name, its own CPT codes, and a dedicated guide: remote patient monitoring app development.

Apps for healthcare staff

These handle asset tracking and personnel tracking, usually with indoor navigation underneath: Bluetooth beacons, NFC, or RFID tags.

Equipment tracking often skips the mobile app entirely, since a map of asset locations reads better in a web application. The phone earns its place at the scanning step: a QR code on the asset pops a card with the item’s details.

How much does a healthcare IoT app cost?

Healthcare IoT app development costs vary more than they do on ordinary app work, because the scope word “app” hides three different projects. The table splits them by what you’re actually commissioning.

Four cost drivers show up here that don’t exist in ordinary app development costs.

What firmware co-development costs you

If the device is being built alongside the app, your mobile schedule is hostage to the firmware schedule, and every slip on one side idles the other. Even when the device already exists, budget from $9,000 per external device integration, and that’s the clean low-code case.

Certification is calendar time

FCC for the radio, carrier certification on top of that for anything cellular, and for a regulated device the submission work itself. All of it is calendar time.

Fleet infrastructure never stops

OTA update tooling and fleet monitoring are build costs and then permanent operating costs. Cellular data plans and cloud ingestion scale with every device you ship, which puts them in your unit economics.

Where regulated budgets go

A wellness product tests until it works. A regulated one tests until every result traces back to a written requirement, and that documentation is a real fraction of the budget.

Settle the wellness-or-medical-device question first. It moves the number more than any feature on your roadmap. For the monitoring-specific version of this math, see health monitoring app development cost.

Our experience developing healthcare IoT apps

We’ve shipped healthcare IoT apps for 11+ years, on both sides of the system: the app in the patient’s hand, and the dashboard the clinician reads.

Dedica Health. A provider-facing web application reading data off a remote sensor for remote patient monitoring. The device produces readings; Dedica is where a clinician does something with them.

iFaint. We worked with the Stanford University School of Medicine on a mobile app for a study on fainting spells. It connects to a wearable tracking heart rate, then shows participants their own data alongside symptom feedback. Geofencing prompts participants for input after a hospital visit.

Related: How to Build a Wearable App

JOOVV. Companion app for a connected light therapy device. The classic connected medical device app shape, where the phone is the remote control and the data log while the hardware does the work.

Beyond those three, we’ve built healthcare IoT apps connecting patients and doctors to glucometers, breath meters, and smart pillboxes.

If you’re weighing a medical IoT app development project and want a read on scope or cost, reach out.

Related Articles:

1.  Complete Guide to Developing a Healthcare App
2. How to create and build a healthcare startup
3. Healthcare Cloud Computing: Use Cases, Best Practices, More
4. Building a Remote Patient Monitoring Application: The Complete Guide
5. Computer Vision in Healthcare: Big Changes in Healthcare
6. Guide to building a HIPAA compliant application
7. Blockchain in Healthcare
8. How to create a telehealth application