Medical device software development is building software that is a medical device (SaMD), runs inside one (SiMD), or connects to one to control it or analyze patient data for diagnosis, treatment or clinical alarms, under a quality system and a life cycle standard, usually IEC 62304; software that only transfers, stores or displays device data does not count. With us, the patient and clinic apps around the device, built to HIPAA and GDPR requirements, cost from $45,000 and take from 10 weeks.
Under FDA policy, features that control the device or analyze its readings to flag a patient are usually medical device software. Each of these features needs written requirements, a risk analysis and tests traced to those requirements. How much of that work a product needs depends on how much harm a failure could cause and on whether your quality system is already in place, so it shapes the estimate once the device features are written down.
This guide is for founders and device makers who have the hardware, or a plan for it, and now need the software that works with it: the phone app, the cloud, and the screen a clinician looks at.
What counts as medical device software
Software is a medical device when its intended use is medical: to diagnose, cure, mitigate, treat or prevent a disease, or to affect the structure or a function of the body, unless US law excludes that kind of function. FDA applies the same policy to an app on a phone, a program in the cloud and code inside a pump, and it reads intended use from your labeling, your advertising and what you say about the product.
The same app can be ordinary software or a device depending on the sentence on its landing page, which is why the intended use is written and agreed before the first sprint.
FDA sorts software related to medical devices into three types:
- Software as a medical device (SaMD). The International Medical Device Regulators Forum defines it as software intended for medical purposes that performs them “without being part of a hardware medical device”.
- Software in a medical device (SiMD). Code that is part of the hardware and runs it, such as the firmware of an infusion pump or a blood pressure monitor.
- Software used to make or maintain devices. Tools for production and service. This guide does not cover them.
A lot of health software is none of these. FDA's own examples of software that is not a device include appointment reminders, billing code tools and shift planning for doctors, and its guidance on device software functions (September 2022) lists examples on both sides of the line. Read those lists before you decide what you are building.
Connected medical devices: which parts are regulated
A connected medical device sends its readings over a network. A blood pressure cuff or a glucose meter at home talks to a phone, the phone talks to the cloud, and a clinician sees the result on a screen. Only some of those parts are device software. Under FDA policy, the line depends on what each part does with the data.
Two FDA documents draw that line. Software that connects to a device “for purposes of controlling the device(s) or analyzing medical device data” is device software; FDA's examples are an app that inflates and deflates a blood pressure cuff and an app that sends control signals to an insulin pump. Software that only transfers, stores, converts formats or displays device data is what FDA's guidance on medical device data systems calls a Non-Device-MDDS, and since the 21st Century Cures Act it is not a device.
| Part of the system | What it usually does | Device software under FDA policy? |
|---|---|---|
| Firmware on the device | Takes the measurement and runs the hardware | Yes: it is SiMD |
| Phone app that relays readings | Receives readings from the device and uploads them | Not while it stays a Non-Device-MDDS |
| Phone app that controls the device | Starts a measurement, changes a setting, sends a dose | Yes: controlling a connected device is a device function |
| Cloud backend | Stores the history, syncs devices, feeds other systems | Not while it only stores, transfers, converts, or displays device data; summaries, trends, and any analysis need an intended-use review; yes when it diagnoses, raises clinical alarms, or controls the device |
| Clinician dashboard | Shows patients and their readings | Not while it only displays them; yes once it raises clinical alarms. Ranking patients by clinical risk can make it one too |
| EHR integration | Sends readings into the clinic's record system | Not while it only transfers them |
Read the table as a screening hint, not legal advice. The final decision belongs to your regulatory lead.
The expensive surprise sits in the dashboard row. FDA does not count software that generates alarms or alerts, or prioritizes patient information on screens that show many patients, as a Non-Device-MDDS, because those functions analyze the data. A remote monitoring dashboard can therefore start as non-device software and become a device on the day someone adds “notify the nurse when a reading goes above the limit”. Put that feature on the roadmap from the start, even if it ships a year later.
“Treat the phone as the least reliable part of the system. Bluetooth drops, the operating system stops background apps, and patients forget to open the app for days. Design the device and the backend so that a reading survives without the phone, and the app becomes a courier rather than a single point of failure.”
Alexander Storozhevsky, Lead developer at Ronas IT
If your device is a consumer wearable that makes no medical claim, the job looks more like wearable app development, with its own platform limits and store rules.
The rules that shape medical device software
Most of these rules bind the manufacturer rather than the developer. A quality management system, the IEC 62304 software life cycle and risk management under ISO 14971 shape how the work is done and recorded. The regulators add their own requirements: the documentation level and the cybersecurity information of a US submission, and the device class in the EU. Which type of US submission the device needs is a decision for your regulatory lead. Patient data brings privacy law on top.
Quality management system
In the US, the Quality Management System Regulation took effect on February 2, 2026 and incorporates ISO 13485:2016 by reference into 21 CFR Part 820. The quality system belongs to the manufacturer. A partner who writes device software works inside it: its design and development procedures, its document approvals, its change process.
IEC 62304 and software safety classes
IEC 62304 is the life cycle standard for medical device software, and FDA's 2023 guidance on premarket submissions for device software lists it among the standards whose terms the guidance uses where possible. IEC 62304 sorts software into three safety classes by the harm a failure could lead to. In the simplified version, class A means no injury is possible, class B no serious injury, and class C death or serious injury. The class decides how much documentation and testing the standard asks for, and software the manufacturer has not classified falls into class C.
Risk management
ISO 14971, the risk management standard for medical devices, is on the same list in FDA's premarket guidance. In practice, each hazardous situation that the software could contribute to is evaluated. If its risk is not acceptable, it gets a control that reduces the risk and a test that checks the control, and the three stay linked through every change.
FDA documentation level
FDA's premarket guidance for device software sets two documentation levels. Enhanced documentation applies where a failure or flaw of the software could present a hazardous situation with a probable risk of death or serious injury. FDA also recommends Enhanced for Class III devices, for devices that are part of a combination product such as a drug-device product, and for several blood-safety categories, including blood establishment computer software. For a device in any of these categories, the sponsor can still submit Basic with a detailed rationale. Basic documentation applies in every other case. The risk is judged before any risk controls are counted, so adding controls does not lower the level.
Cybersecurity
Since March 29, 2023, section 524B of the Federal Food, Drug, and Cosmetic Act has required cybersecurity information in premarket submissions for devices that meet its definition of a cyber device. Manufacturers of those devices must provide a software bill of materials, or SBOM, that lists commercial, open-source and off-the-shelf components. FDA's cybersecurity guidance (February 2026 edition) quotes the full definition and expects the security architecture to show every connection of the device, including cloud connections and the patient's home network. That is how your phone app and your backend end up in the device's threat model even when they are not devices themselves.
EU MDR classification and Rule 11
In the EU, the Medical Device Regulation (EU) 2017/745 puts software that drives a device or influences its use in the same class as the device. Software that is independent of any other device is classified in its own right. Under Rule 11, software that provides information used for diagnostic or therapeutic decisions is class IIa, rising to class IIb when those decisions may cause a serious deterioration of health or a surgical intervention, and to class III when they may cause death or an irreversible deterioration of health. Software that monitors physiological processes is class IIa, or IIb when it monitors vital parameters whose changes could put the patient in immediate danger. All other software is class I.
Patient data
If you create, receive, keep or send protected health information on behalf of a covered entity, such as a health plan or a healthcare provider, HIPAA applies to you as well. Under 45 CFR 160.103, with the exceptions listed there, a person who, on behalf of a covered entity and not as a member of its workforce, “creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter” is a business associate. Our guide to US healthcare laws covers what that means for an app.
How medical device software development works, step by step
The first steps settle what the product is and how risky it is. The rest follow the IEC 62304 life cycle from development planning to maintenance, with risk management running through every step. Each step leaves documents that a reviewer can follow from a requirement to the test that proves it was met.
- Write the intended use. One paragraph, agreed with whoever owns regulatory affairs. Every later decision follows from it, including what the marketing site is allowed to say.
- Map the functions. List every function of every part of the system and mark each one as device or non-device, using FDA's examples. This is the table above, filled in for your product. Our analysis phase can produce the function map and draft requirements; the intended use, the classification and the risk file stay with your regulatory lead.
- Classify. Assign the IEC 62304 safety class, the FDA documentation level and, for Europe, the MDR class, and write down the reasons.
- Analyze the risks. List the hazards, cybersecurity threats included, and give each one whose risk is not acceptable a control and a way to verify it.
- Plan the development. Write the software development plan IEC 62304 expects before requirements: the life cycle model, the documents each stage produces, and how requirements, risk controls and tests will be traced to one another.
- Define the software requirements. Write down what each function must do, in a form that every test can later be traced back to.
- Design the architecture. Keep device functions in their own components with their own interfaces, so the rest of the product can change without reopening them.
- Build in short iterations. On device functions, a change is not finished until its requirement, risk and test records are updated too.
- Verify. Unit, integration and system tests, each traced back to a requirement. Since the 2015 amendment of IEC 62304, system tests are required even for class A software.
- Prepare the release. The version history, the list of unresolved anomalies with their impact on safety, the SBOM if the device is a cyber device, and the documents for the submission.
- Maintain. Every update after launch goes back through the same steps, starting with its impact on safety and security.
Medical device software development cost: starting prices and the regulated part
Our starting prices below cover the software work around the device. The first two rows cover the apps for patients and clinics, one patient app and one clinic web app. Integrations with third-party systems, such as a device vendor cloud or a lab system, are part of the app price, and so are design, project management, and testing. There is no separate fee for the regulated work on device features; it is part of the build estimate, and a higher safety class or Enhanced documentation makes that estimate larger.
| Work | Starting price | Timeline |
|---|---|---|
| Healthcare app for patients, with the backend, the admin panel, and integrations | From $30,000 | From 10 weeks |
| Clinic web app on the same backend | From $15,000 | Estimated with the scope |
| Optional analysis phase | $1,000-$2,000 | From 1 week |
Three things set the size of that regulated work:
- The safety class and the documentation level. Class C and enhanced documentation mean more design records and more tests for the same feature.
- Which features control the device or flag patients from readings. Each one adds to that work.
- Who holds the quality system. If yours is in place, the partner works inside it. If it is not, setting one up is a separate project on your side.
That is why the estimate is final only once these three are known.
How to split the work between your device team and a software partner
Keep the regulatory core with the manufacturer and hand a partner the parts that are mainly software work. The intended use, the quality system, the risk file and the submission stay with you. The phone app, the backend, the clinician portal and the integrations can go to a team that builds them to your procedures. Before you sign, ask the partner these questions.
- Will they work inside your quality system? Your templates, your approvals, your change control, and records you can hand to an auditor.
- How do they verify code? Ask for the chain from each requirement to its test, not the word “tested”.
- Can they give you an SBOM for the device software? Every commercial, open-source and off-the-shelf component contained in the device, with versions, because the submission for a cyber device must include it. A patient app or cloud backend that is not part of the device stays off that list.
- Whose cloud account will the project run in? Our projects start in the client's own cloud account. By default the code sits in repositories in the client's organization; if we host it instead, the contract sets out when it moves to you.
- How do AI agents fit into your procedures? Ask who reviews and signs off code an agent wrote, how that code is traced to a requirement and a test, and which AI services see your code and documents. With us, an engineer sets each task for an agent, reviews the result and accepts it, and the change passes the same automated tests as any other. The general AI questions for any vendor are in our guide to choosing a software development company.
“Before you ask a partner for a price, ask which of your features they think is a device function. If the answer for a dashboard that alerts nurses is ‘none’, they have not read FDA's examples, and their estimate is missing the part of the work that needs the most care.”
Roman Surikov, CEO at Ronas IT
Our closest public work is on the data side rather than inside a device. On a web platform for lab test results, patients upload their results or receive them straight from the laboratory's systems, and share them with a doctor or a coach. We built it to HIPAA requirements, with app-based two-factor sign-in, automatic logout and longer backup retention, and kept working with the client for four years after the first release. Taking data in from another system, storing it safely and sharing it with a professional are also part of what a connected device's cloud does.
That project has no device functions, so it cannot show a requirement-to-test chain. What we can show is how we test: on the backend, every change, a new feature or a bug fix alike, comes with a described test case, and the API documentation is generated from tests that pass. On device features we would work inside your quality system, with your templates and your change control.
What to do next
- Agree on the intended use with your regulatory lead. Keep it to one paragraph.
- Fill in the table for your product. Every part of the system, every function, device or not.
- Put alerts and analysis on the roadmap. Include the ones planned for later, because they decide which rules apply.
- Decide who holds the quality system. If it is yours, agree on how the partner will follow its procedures.
- If the scope is not written down yet, book an analysis phase. Ours costs $1,000-$2,000 and takes from one week. It ends with a written scope, budget and timeline to base an estimate on.
Do the first three before you talk to vendors, so that they quote the same product.
Frequently Asked Questions (FAQs)
What is medical device software development?
It is building software that is a medical device (SaMD) or runs inside one (SiMD). The work runs under a quality management system and, usually, the IEC 62304 software life cycle standard. Software connected to a device counts as device software when it controls that device or analyzes patient data to diagnose, treat, or raise clinical alarms. The engineering is familiar; what is added is the record that links every requirement to its risks and its tests.
When is software considered a medical device?
When the manufacturer intends it for a medical purpose, such as diagnosing, curing, mitigating, treating or preventing a disease, or affecting the body's structure or any of its functions. US law excludes some kinds of functions from that definition. FDA reads intended use from labeling, advertising and what the manufacturer says, so a marketing claim can turn an ordinary app into a device.
What is the difference between SaMD and SiMD?
Software as a medical device (SaMD) does a medical job on its own, without being part of a hardware device, such as software that analyzes a patient's data to support a diagnosis. Software in a medical device (SiMD) is part of the hardware and runs it, like the firmware of a pump or a monitor. FDA also names a third type: software used to make or maintain devices.
Is an app that shows data from a medical device regulated by FDA?
Not if it only transfers, stores, converts formats or displays the data. FDA calls such a software function a Non-Device-MDDS (medical device data system), and the 21st Century Cures Act took it out of the device definition. The app becomes device software when it controls the device, analyzes patient data for diagnosis or treatment, or generates alarms and alerts that clinicians act on. Administrative analytics, and decision support whose basis a clinician can review independently, can stay outside the device rules.
Does FDA treat mobile medical apps differently from other software?
No. FDA looks at what a software function does, not where it runs, so the same policy covers an app on a phone, a program on a laptop and software in the cloud. An app that turns the phone itself into a device, for example by attaching a glucose strip reader or ECG electrodes, has to meet the classification of the device it becomes.
How much does medical device software development cost?
At Ronas IT, a patient app and a clinic web app for a device, built to HIPAA and GDPR requirements, start from $45,000 with a timeline of 10 weeks or more: from $30,000 for the patient app and from $15,000 for the clinic web app. That price includes the backend, the admin panel, design, project management, testing, and integrations with a device vendor cloud, a lab system or other third-party systems. An optional analysis phase before the build costs $1,000-$2,000. Device features, meaning control of the device or analysis of its readings that flags a patient, also need documented requirements, risk analysis and tests. They carry no separate fee, but a higher safety class or Enhanced documentation adds to the estimate.
Do you need ISO 13485 to build medical device software?
The manufacturer needs a quality management system. In the US, the Quality Management System Regulation that took effect on February 2, 2026 incorporates ISO 13485:2016 by reference into 21 CFR Part 820. A software partner that writes device functions works inside the manufacturer's system and follows its procedures.
What does FDA require for the cybersecurity of connected medical devices?
Section 524B of the FD&C Act, in force since March 29, 2023, makes manufacturers of what it defines as cyber devices include cybersecurity information in premarket submissions, with a software bill of materials that lists commercial, open-source and off-the-shelf components. In its guidance, last updated in February 2026, FDA asks for a security architecture that covers each of the device's connections, including those to the cloud and to the patient's home network.
Related posts
Related Services
Cross-platform App Development
Ship to iOS and Android from one React Native codebase instead of funding two native teams. Ronas IT handles UI/UX design, development, and the releases to Google Play and the App Store, delivering high-performance, secure apps within 2 to 4 months.
DevOps Services
Accelerate your software delivery with Ronas IT's DevOps services. We streamline development and deployment through CI/CD automation, proactive monitoring, and secure cloud infrastructure. Enjoy faster releases, minimal downtime, and scalable solutions — letting you focus on growth while we handle seamless operations.
Custom Web App Development Services
Build secure, scalable web applications with Ronas IT’s custom web app development services. Our team covers the full cycle — from concept and UI/UX design to development, testing, and ongoing support — using leading tech like React and Laravel. With 200+ custom apps delivered across various industries, we ensure intuitive interfaces, smooth integration, and solutions tailored to your business goals.
Backend Development Services
Ronas IT builds the server side behind your product, from MVPs to enterprise-scale platforms: APIs, data models, integrations with third-party services, and the infrastructure they run on. Our backend team handles challenges of varying complexity and picks the technologies that fit the product rather than the fashion.