On this page
- What is AI medical device software development?
- The AI medical device software development process, step by step
- Why an AI medical device MVP is not a normal MVP
- Start with intended use and risk class, not features
- The regulatory guardrails you build around, not after
- Your data and model are the real MVP
- Architecture and compliance by design
- What to ship in your AI medical device MVP, and what to defer
- Timeline and cost: what drives the budget
- Conclusion
- FAQ
AI medical device software development is different from building any other product, and that difference is expensive to learn late. A consumer MVP tests whether people want the product. An AI medical device MVP has to test that and also prove the software is safe, effective, and auditable. Regulators review how you built the software, not only what it does. That makes “move fast and fix later” a compliance liability in this category. This guide explains what AI medical device software is, how to scope it, which regulatory guardrails to design in from day one, and what to ship in version one versus what to defer.
What is AI medical device software development?
AI medical device software development is the process of designing, building, validating, and maintaining software that uses artificial intelligence for a medical purpose, under the controls regulators require. The software may diagnose, triage, monitor, or support treatment decisions. The International Medical Device Regulators Forum (IMDRF) calls standalone medical software Software as a Medical Device (SaMD). Software that runs inside or controls a physical device is often called Software in a Medical Device (SiMD).
The AI part changes the work. Deterministic software behaves the same way on every release. A machine learning model learns from data, so its behavior depends on the data it saw and can drift after launch. That is why regulators look at the model’s whole lifecycle, from data collection to field monitoring, and not only at launch-day accuracy.
AI medical devices are most mature in imaging. Radiology accounts for roughly three-quarters of FDA-authorized AI devices (about 76% of the FDA’s AI-Enabled Medical Device List as of mid-2026). Cardiology, neurology, and pathology are the next areas to watch. A well-known early example is IDx-DR, an autonomous diabetic retinopathy screening system authorized through De Novo in 2018 and now marketed as LumineticsCore. For a wider view of clinical use cases, see our guide to AI in medical diagnostics.
The AI medical device software development process, step by step
A compliant build follows the same order every time: intended use first, evidence throughout, submission last. Each step below is covered in detail later in this guide.
- Define the intended use. Write what the software does, for whom, and in what clinical setting. Confirm whether it is a regulated device at all.
- Classify the risk. Set the FDA device class, the IEC 62304 software safety class, and, for Europe, the EU MDR class.
- Choose the regulatory pathway. Pick 510(k), De Novo, or PMA. Ask the FDA for early feedback through a Pre-Submission (Q-Sub).
- Stand up the quality system. Put design controls, a risk management file under ISO 14971, and document control in place before the first sprint.
- Build the data pipeline and model. Follow Good Machine Learning Practice (GMLP), with documented data lineage and a locked, independent test set.
- Design the architecture for traceability and security. Version data and models, log for postmarket monitoring, and meet FDA cybersecurity expectations.
- Verify and validate. Run software verification, clinical performance testing tied to your claim, and usability testing under IEC 62366-1.
- Write the PCCP and the monitoring plan. Define which model updates you want pre-authorized and how you will watch real-world performance.
- Submit and maintain. File the submission, then run postmarket surveillance under your QMS.
Why an AI medical device MVP is not a normal MVP
An AI medical device MVP differs from a standard MVP in two ways, and neither can be added later. The first is the quality management system (QMS). A QMS is the documented process that shows your software was designed, tested, and controlled in a disciplined way. The second is the AI change-control story, which is your plan for how the model will change over time without becoming unsafe.
Regulators care about the model’s trajectory, not just its accuracy on day one. Take a triage model that scores well in the lab. It is not a finished MVP milestone if you cannot show that the training data matched the real patient population. You also need a plan to monitor its performance in the field. Teams that ship smoothly treat evidence as a feature of version one, not paperwork for later. That discipline is the core of AI medical device software development. It is also why teams that come to us for MVP development services in this space get a scope built around evidence, not just features.
Start with intended use and risk class, not features
The most expensive early mistake in an AI medical device MVP is scoping features before intended use. The intended use statement is a plain description of what the software does, for whom, and in what clinical context. It drives your risk class, your regulatory pathway, and how much you have to prove.
Risk scales with two factors: how serious the condition is, and how much the software drives the clinical decision. Software that flags an image for a specialist to review carries less risk than software that makes an autonomous call.
Check first whether your software is a device at all. On January 6, 2026, the FDA issued revised final guidance on clinical decision support (CDS) software and on general wellness products. Under these documents, some CDS software meeting all the criteria falls outside the device definition, and some low-risk wellness products fall under enforcement discretion. Others clearly do not qualify, so read the criteria against your exact intended use. The CDS update loosened the time-critical exclusion, added a single-option enforcement policy, and relaxed the transparency requirement.
For software that is a device, the FDA offers three main pathways.
| Pathway | What it is | Best for |
|---|---|---|
| 510(k) premarket notification | Shows the device is substantially equivalent to a legally marketed predicate device | Class II AI software with a clear predicate, such as image triage tools |
| De Novo classification | Creates a new classification for a novel low-to-moderate risk device with no predicate | First-of-its-kind AI functions with moderate risk |
| Premarket approval (PMA) | The FDA’s most rigorous review, usually with clinical data | Class III, high-risk devices where errors could cause serious harm |
FDA has now authorized more than 1,600 AI-enabled devices (1,614 on its AI-Enabled Medical Device List as of mid-2026). About 96% were cleared through 510(k). The lesson for an MVP is to narrow the intended use hard. A tightly scoped indication is typically faster to validate and easier to expand once you have real-world evidence. Where possible, choose one with an existing predicate, because a novel indication may need the slower De Novo route.
The regulatory guardrails you build around, not after
Regulatory guardrails decide whether an AI medical device MVP clears or stalls, so make these decisions early rather than discovering them mid-submission. The table below shows the frameworks that matter most in 2026.
| Framework | Status | What it means for your MVP |
|---|---|---|
| Good Machine Learning Practice (GMLP) guiding principles (FDA, Health Canada, UK MHRA) | 10 principles, published 2021 | The shared vocabulary for data, training, and testing practice |
| PCCP guidance for AI-enabled device software functions | Final, December 2024 | Lets you pre-authorize specific model updates |
| AI-enabled device software functions: lifecycle management and marketing submission recommendations | Draft, January 2025 | Shows what reviewers expect across the total product lifecycle |
| CDS software and general wellness guidance | Revised final, January 6, 2026 | May move some functions outside device oversight |
| QMSR (21 CFR Part 820 aligned with ISO 13485:2016) | Effective February 2, 2026 | Design controls and records apply from the first build |
| Cybersecurity in medical devices guidance | Final, February 3, 2026 | Sets premarket security evidence for connected devices |
| EU AI Act high-risk obligations for AI in medical devices | Apply from August 2, 2028 | Adds AI-specific duties on top of EU MDR in Europe |
IEC 62304 is the international standard for the medical device software lifecycle. Its safety classification sets how rigorous your documentation must be. Class A covers software that cannot contribute to injury, Class B covers non-serious injury, and Class C covers serious injury or death. Higher risk means more evidence.
The QMSR replaced the FDA’s old Quality System Regulation by aligning 21 CFR Part 820 with ISO 13485, the international QMS standard for medical devices. It took effect on February 2, 2026. In plain terms, design controls and records apply to your MVP, not only to your commercial release. A quality scaffold in version one is no longer optional.
A Predetermined Change Control Plan (PCCP) lets you pre-authorize specific model updates as part of your marketing submission, so changes within the plan don’t need a new submission each time. The FDA finalized its PCCP guidance for AI-enabled device software functions in December 2024. In October 2023, the FDA, Health Canada, and the UK MHRA jointly published five guiding principles for PCCPs: focused and bounded, risk-based, evidence-based, transparent, and a total product lifecycle perspective. Your PCCP scope shapes your data pipeline and model versioning, so it belongs in MVP planning.
The FDA’s January 2025 draft guidance on AI-enabled device software functions signals what reviewers want. That includes a model description, data lineage, performance tied to your claims, bias analysis, a clear human-and-AI workflow, and a monitoring plan. It is still a draft, so treat it as direction rather than final policy.
Cybersecurity is now a safety requirement in its own right. The FDA’s final guidance of February 3, 2026, aligned to the QMSR, sets the premarket evidence for “cyber devices” under Section 524B of the Federal Food, Drug, and Cosmetic Act. In practice, that means a secure product development framework, threat modeling, an SBOM, and a postmarket vulnerability plan. If your product pairs with wearables or Bluetooth sensors, our guide to HIPAA-compliant healthcare app development covers the device-to-cloud data path.
In Europe, the EU Medical Device Regulation (EU MDR) classifies most diagnostic and monitoring software under Rule 11. Most of it lands in Class IIa or higher, which requires a notified body. Under the EU AI Act, AI in devices that need notified-body assessment is high-risk (Article 6(1)). The Digital Omnibus on AI (Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026) moved those high-risk obligations to August 2, 2028. The AI Act applies on top of the MDR, not instead of it, and Article 50 transparency duties have applied since August 2026.
The through-line is simple. The MVP’s job is to start the evidence trail, not to postpone it. Building on HIPAA-ready infrastructure from the first sketch is part of that. Our breakdown of HIPAA-compliant hosting costs shows what that layer costs.
Your data and model are the real MVP
For an AI medical device, the model and its data provenance are the product. The interface matters, but it comes second to whether the model can be trusted and defended. Four things carry the most weight with clinicians and reviewers alike.
- Representative training data. Training data must match the intended-use population. A model trained on a narrow cohort will fail on patients it was never shown.
- Independent test data. Keep the test set fully separate from training, and lock it before final evaluation, so your performance numbers mean something.
- Claim-linked performance. Report the metrics your clinical claim depends on, such as sensitivity and specificity for a triage claim, not a generic accuracy figure.
- Bias analysis with real mitigation. Measure performance across subgroups such as age, sex, ethnicity, and device type, and fix the gaps. A disclaimer is not mitigation. Our guide to the ethical concerns of AI in healthcare covers how bias enters clinical models.
These practices map to Good Machine Learning Practice (GMLP), the ten principles the FDA, Health Canada, and the MHRA published jointly in October 2021. When real patient data is scarce, synthetic records can support stress testing and edge-case coverage. Regulators expect synthetic data to be validated against real data, and the more it carries in a submission, the more evidence you will need. Learn how in our guide to synthetic EHR data for clinical ML validation.
The practical lesson for AI medical device software development is this: ship a narrow model on clean, well-documented data rather than a broad model on data you cannot account for. Data governance is a version-one feature here, not technical debt to clean up later.
Architecture and compliance by design
Compliant architecture for an AI medical device is built for traceability from the first commit. Each element below supports either your submission or your postmarket obligations.
- Version control on data and models, not just code. You must be able to reconstruct exactly which data and model version produced a given result.
- Logging designed for postmarket monitoring. The FDA increasingly wants proof that guardrails work as designed in the real world.
- A traceability matrix. Map every requirement to the risk control and the test that verifies it.
- A deliberate human-in-the-loop workflow. A well-placed clinician check is one of the strongest risk controls available to an MVP.
- Security in the data layer. Build encryption and access controls into the data layer rather than wrapping them around a finished app. We cover this approach in more depth in our guide to wearable app development.
- Modular model components. Keep the model covered by your PCCP separable, so you can update it without revalidating the entire healthcare software system.
What to ship in your AI medical device MVP, and what to defer
An AI medical device MVP stays honest with a clear keep-and-cut line. Ship what proves the clinical claim and the evidence trail. Defer everything else.
| Ship in version one | Defer to later releases |
|---|---|
| A narrow intended use | Multi-indication expansion |
| The core validated model | Automated retraining beyond your PCCP scope |
| The audit and logging spine | Extra EHR and third-party integrations |
| A basic clinician workflow | Polish features that do not affect safety or the clinical claim |
| The quality-system scaffold and risk file | Secondary user roles and dashboards |
Integrations are a common thing to defer. When you add them, standards such as HL7 FHIR keep EHR connections maintainable. See our guide to choosing a FHIR integration solution.
One rule never bends: “defer” never means skipping documentation. You can ship fewer features, but the evidence trail for whatever you do ship has to be complete. A smaller, fully documented AI medical device MVP will clear faster and cost less than a broad one whose paperwork you must reconstruct after the fact.
Timeline and cost: what drives the budget
The timeline and cost of an AI medical device MVP depend mostly on risk class, data readiness, and regulatory pathway, not on feature count. Evidence work, meaning data curation, validation, and documentation, usually takes more time than writing code.
Review time adds to the build time. Under the FDA’s MDUFA V performance goals, the target for a 510(k) decision is 90 FDA days, and the target for a De Novo decision is 150 FDA days for most requests. Time the file spends on hold while you answer an additional-information request doesn’t count toward those goals, so real calendar time runs longer. The FDA’s shared goal for average total time to a 510(k) decision is about 112 days.
The main cost drivers are:
- Data acquisition and labeling, especially when specialist clinicians must annotate images or records
- Clinical validation studies, which grow with the risk class and the strength of your claim
- Quality and regulatory work, including the QMS, risk file, and submission
- Cybersecurity testing, including penetration testing and SBOM management
- Postmarket monitoring infrastructure
For a fuller view of where the budget goes, see our breakdown of medical device software development cost.
Ailoitte
/
Insight
From delivering connected-device and healthcare products end to end, our medical device software development practice sees a few patterns hold. Projects that stall are rarely blocked by the model. They are blocked by data readiness and by regulatory and clinical expertise arriving too late. The teams that ship put a regulatory affairs lead and a clinical advisor in the room on day one, alongside the ML and software engineers.
Ailoitte’s AI Velocity Pods are built around exactly this. They combine senior architects, governed AI development workflows, and Agentic QA automation in a fixed-price, outcome-based model, with human oversight for quality and compliance. Ailoitte has shipped more than 300 products in 22+ countries, backed by ISO 27001 and ISO 9001 certification, SOC 2 Type II, and HIPAA-ready infrastructure. The consistent lesson for AI medical device software development is that compliance built in from the start is faster than compliance added at the end.
Conclusion
The winning AI medical device MVP is the smallest build that proves clinical value and produces regulatory evidence at the same time. Scope the intended use narrowly. Document everything you ship. Design the model’s change-control story before you write the first line of model code. Do that, and version one becomes the foundation for clearance rather than a rewrite waiting to happen. AI medical device software development rewards teams that treat evidence as part of the product from day one.
Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering.
About Ailoitte
