If you’re a business owner planning a “health app,” here’s the moment things get expensive:
You write one sentence that sounds like a medical claim.
“Detects arrhythmia.” “Helps diagnose.” “Guides therapy.” “Predicts deterioration.”
Now you’re not building an app. You’re building a regulated medical device—and the rules will shape your roadmap more than your feature list.
This is the business-owner version of the truth: what triggers regulation, what standards matter, how approvals work in 2026, and how to avoid the #1 failure mode: building a product that can’t be cleared because compliance was an afterthought.
First: when does software become a “medical device”?
Regulators don’t care if it’s mobile, web, cloud, or AI. They care about intended use—what you claim the software does.
A useful shortcut:
- If your product informs clinical decisions (diagnosis, treatment, monitoring of a condition), it’s likely medical device software.
- If it’s general wellness (habit tracking, generic education, non-clinical coaching), it may stay outside strict medical device regulation—but the line is thin.
FDA uses the IMDRF definition for Software as a Medical Device (SaMD): software used for a medical purpose that performs that purpose without being part of a hardware medical device.
Business move: Decide your claims strategy early. You can build a wellness product faster—or build a regulated product with stronger clinical value and a harder path to market. Mixing both usually ends in delays.
The 2026 regulatory map (US, EU, UK)
You don’t “get approved globally.” You choose markets and plan accordingly.
A notable 2026 twist in the EU
On December 16, 2025, the European Commission proposed a targeted simplification of MDR/IVDR to reduce burden, digitize procedures, and improve predictability—including changes that can affect assessments and timelines. It’s a proposal, not an overnight rule change, but it matters for 2026 planning.
The standards you’ll hear about (and why they matter)
Think of standards as “how you prove you built it responsibly.”
- ISO 13485—Quality Management System (how you run development and control changes).
- ISO 14971—Risk management (how you identify hazards, reduce risk, and monitor residual risk).
- IEC 62304—Software lifecycle processes (planning, development, maintenance).
- IEC 62366-1—Usability engineering for safety (human factors, use errors).
- IEC 81001-5-1—Secure health software lifecycle processes (security built into SDLC).
For a deeper breakdown of SaMD-specific standards, see here.
Step-by-step: how regulated medical software is built (business-owner edition)
Step 1: Lock the “intended use” and claims
This is your regulatory destiny.
Your claims decide:
- whether it’s a device
- how it’s classified
- what evidence you need
- how long approvals will take
Tip: Write claims in two versions: “Marketing version” (what you want to say) and “Regulatory version” (what you can prove).
Step 2: Classify the product (risk class drives cost)
In the EU, software classification guidance is actively maintained, and software can land in higher classes depending on how it supports diagnosis/therapy decisions (MDR Rule 11 is the famous pain point). The June 2025 update to MDCG 2019-11 is a key reference teams use when qualifying and classifying software.
Business implication: higher class usually means more documentation, more external review (e.g., notified body involvement in the EU), and more time and cost.
Step 3: Set up your Quality Management System early
If you wait to “add QMS later,” you’ll pay twice.
ISO 13485 is the commonly recognized QMS standard in the medical device world.
What this means in plain language:
- documented processes for requirements, testing, releases
- change control (you can’t “ship hotfixes” like a normal SaaS)
- supplier controls (vendors become part of your compliance story)
Step 4: Do real risk management (not just a spreadsheet)
ISO 14971 frames how you identify hazards, estimate and evaluate risk, control risk, and monitor controls across the lifecycle—including for software.
Business-owner takeaway:
- risk management is not paperwork—it defines design decisions
- risk controls become requirements
- requirements drive verification evidence
Step 5: Build with a medical-grade software lifecycle
IEC 62304 is the anchor standard for medical device software lifecycle processes.
You don’t need to memorize the standard. You need to run a process that produces traceable requirements, documented architecture decisions, test evidence tied to risk, and a maintainability plan (updates are part of the device).
Step 6: Treat usability as a safety requirement
IEC 62366-1 focuses on usability engineering tied to safety—i.e., preventing harm from use errors under normal use.
This matters because many failures aren’t “bugs.” They’re confusing UI that causes wrong input, misread results, unclear warnings, or workflow mismatch in clinics.
For more on validation thinking (relevant even if your device is software-only), see this.
Step 7: Cybersecurity isn’t optional anymore
If your device contains software (or is software), regulators increasingly expect structured cybersecurity work.
In the US, FDA guidance on cybersecurity includes what to design for and what to include in premarket submissions, and FDA also maintains FAQs tied to “cyber device” requirements.
At the process level, IEC 81001-5-1 is a recognized framework for secure health software lifecycle activities.
Business-owner reality:
- cybersecurity is now part of your evidence package, not a “nice to have”
- patching, vulnerability handling, and security documentation are part of the product
Step 8: Plan your clinical evidence (what you must prove)
For SaMD, clinical evaluation expectations exist, including FDA guidance that reflects an internationally aligned approach to clinical evaluation planning.
Translation: you need a plan for how you prove the software is safe and effective for the intended use, which can include analytical validation (does it compute correctly?), clinical validation (does it improve or enable the clinical outcome you claim?), and real-world performance monitoring (post-market).
Step 9: Assemble “the dossier” as you build, not at the end
Approval is documentation plus evidence, not hope.
Typical artifacts you should expect to produce:
- intended use plus labeling/IFU language
- risk management file
- software lifecycle documents and test evidence
- usability engineering file
- cybersecurity documentation and maintenance plan
- clinical evaluation evidence
Step 10: Post-market is where many teams fail
Once you’re on the market, you’ll need processes for incident handling, complaint handling, security vulnerability monitoring, updates under change control, and periodic reviews.
For building software that holds up under audits and enterprise procurement, see this.
Timelines and budgets (what business owners can realistically expect in 2026)
These ranges vary by class, market, and evidence needs—but they’re useful for planning.
Most common budgeting mistake: teams fund development but underfund evidence and compliance operations (QMS, testing infrastructure, documentation, post-market).
Vendor/partner checklist (what to ask before you sign)
If you’re hiring an agency or building with contractors, ask these blunt questions:
- Have you shipped regulated medical software before (not just “health apps”)?
- Who owns the QMS setup and documentation pipeline?
- How will you manage requirements traceability (from risk to tests to release)?
- What’s your plan for usability engineering and evidence capture?
- What’s your cybersecurity approach aligned to FDA expectations and secure lifecycle processes?
- Who supports post-market obligations (monitoring, patching, incident handling)?
If answers are vague, you’re not buying expertise—you’re buying enthusiasm.
Final take: treat regulation as a product constraint, not a paperwork phase
In 2026, medical device software success looks like this:
- claims that match evidence
- a QMS that makes your team faster, not slower
- risk controls baked into design
- cybersecurity handled as a lifecycle responsibility
- documentation produced continuously, not retroactively
Do that, and “regulatory” stops being a blocker—it becomes a moat.
