58 in-depth guides in this cluster
Software is a medical device when its intended purpose meets MDR Article 2(1). Here is how SaMD qualification works and why Rule 11 pushes most software to Class IIa or higher.
SaMD is standalone software that is itself a medical device. SiMD drives a hardware device. The distinction changes classification and lifecycle. Here is how to tell them apart.
MDR Article 2(1) and MDCG 2019-11 Rev.1 together answer when software qualifies as a medical device. Here is the decision flowchart in plain text.
MDCG 2019-11 Rev.1 is the definitive EU guidance on when software is a medical device and how to classify it. Here are the key takeaways for startups.
Not every health app is a medical device, but the line under MDR is sharper than founders realise. Here is when your mobile app needs CE marking.
MDR Annex I Section 17 requires software to be developed under a lifecycle process. EN 62304:2006+A1:2015 is the harmonised standard that gets you there.
EN 62304 classifies software by safety impact, Class A (no injury), B (non-serious injury), C (death or serious injury possible). Here is how the class drives what you must do.
EN 62304 scales activities by software safety class. Here is what changes between A, B, and C and how much effort each level actually requires.
EN 62304 Section 5.1 requires a software development plan. Here is what must be in it, how to keep it proportionate, and the startup-scale version.
EN 62304 Section 5.2 requires software requirements analysis and documentation. Here is how to write software requirements that satisfy both MDR and the standard.
EN 62304 Section 5.3 requires software architecture documentation. Here is what it must contain, how SOUP is flagged, and how startups keep it lean.
EN 62304 Section 5.4 detailed design is required for Class B and C software only. Here is how much depth each class needs and when Class A can skip.
EN 62304 Section 5.4 requires detailed design for Class B and C software units. Here is what to document and when to skip it.
EN 62304 Section 5.5 defines software unit verification. Here is what unit testing requires for medical software at each safety class.
EN 62304 Section 5.6 defines software integration and integration testing. Here is how to scope, run, and document it for MDR.
System testing under EN 62304 Section 5.7 verifies software against its system requirements. Here is how to scope, execute, and document it.
How to run a compliant medical software release under EN 62304 clause 5.8 and MDR Annex II, with a worked example and a startup release playbook.
EN 62304 clause 6 defines the software maintenance process: bug fixes, updates, problem analysis. Here is how to run it under MDR without re-doing the whole lifecycle.
EN 62304 clause 8 defines software configuration management: identification, change control, status accounting. Here is how startups apply it without overhead.
EN 62304 clause 9 defines software problem resolution: prepare, investigate, advise, change control, record, trend. Here is the startup playbook.
SOUP (Software of Unknown Provenance) and OTS components are in almost every medical software stack. EN 62304 defines how to qualify and control them under MDR.
SOUP and OTS components require structured evaluation under EN 62304. Here is the evaluation and documentation method that satisfies MDR.
How open source software medical devices MDR EN 62304 SOUP rules, SBOM, licensing, and cybersecurity fit together for compliant SaMD.
Running a medical device on cloud infrastructure brings lifecycle, cybersecurity, and data protection obligations. Here is what MDR requires for cloud-hosted medical software.
A medical device delivered as SaaS changes release cadence, PMS, and change control. Here is how MDR applies to multi-tenant SaaS medical software.
EN 82304-1 covers health software product safety, complementing EN 62304's process standard. Here is how the two fit together for SaMD startups.
Agile development and EN 62304 can coexist. Here is how to map sprints, releases, and design controls so MDR audit holds.
CI/CD can coexist with EN 62304 if the pipeline captures the right evidence at each stage. Here is the DevOps pattern that satisfies MDR.
Verification asks did we build the software right. Validation asks did we build the right software. Here is how the two split for SaMD under MDR.
Computer System Validation under EN ISO 13485:2016+A11:2021 clauses 4.1.6 and 7.5.6. Risk-based CSV for startups, with a label printer worked example.
How to validate eQMS, document control, training, and CAPA tools under EN ISO 13485 clause 4.1.6, risk-based, proportionate, audit-ready.
EN 62304 Amendment 1 (2015) added legacy software rules, refined problem resolution, and clarified security. Here is what changed and why it matters for MDR.
The 4-way traceability matrix under EN 62304 and EN ISO 14971, linking requirements, architecture, tests, and risk controls. With a startup playbook.
An SBOM is now a baseline expectation for MDR cybersecurity. Here is what to include, which format to pick, and how to keep it alive.
How to write a software test strategy that satisfies EN 62304 clauses 5.5, 5.6, and 5.7 without drowning a small team in documentation.
CI/CD for medical software is compatible with EN 62304 if you qualify tools under EN ISO 13485 clause 4.1.6 and capture evidence as records.
Regression testing medical software MDR: how to scope, select, and evidence regression runs under EN 62304 so updates do not break compliance.
Code review medical software EN 62304: what EN 62304 clause 5.5 actually requires, how to record peer reviews, and how to make PR workflow audit-ready.
Static code analysis medical software MDR: how SAST fits EN 62304 verification, how to pick rule sets, triage false positives, and capture evidence.
EN 62304 lets you release medical software with known anomalies if they are documented and risk-evaluated. Here is how to handle them.
Not every software update under MDR requires a new conformity assessment. Here is how to decide whether your update is significant under Annex IX.
Not every software update is a significant change under MDR. Here is the evaluation framework that decides whether your update needs NB notification.
The complete EN 62304 software documentation package for MDR conformity: every artefact, every clause, and what each document must contain.
How to write a software requirements specification for MDR conformity using EN 62304 clause 5.2: the six requirement types, quality rules, and traceability.
An audit-ready software architecture document under EN 62304 clause 5.3: decomposition, SOUP, segregation of safety items, and the diagrams auditors expect.
How to write software test protocols and reports under EN 62304 clauses 5.5-5.7 that survive an MDR notified body review.
The complete regulatory path for a Software as a Medical Device startup in 2026: from intended purpose to CE mark, with every standard and article in sequence.
Pre-certification strategies for SaMD startups under MDR: parallel R&D and regulatory build, what to lock, what to defer, when to engage a notified body.
How MDR Annex I §14.2(d) and §17.1 shape interoperability obligations for medical software, and how to verify interfaces like HL7, FHIR, and DICOM.
How API design for medical devices under MDR creates a regulated boundary, affects intended purpose, and triggers change control and manufacturer liability.
Legacy software under MDR can be brought into compliance using the Section 8 legacy path. Here is the process for retroactive documentation.
Wearables span hardware electrical safety, embedded software, and mobile companion app rules. Here is the MDR-compliant approach for wearables.
Set up a medical software development environment that satisfies EN 62304 and EN ISO 13485 clause 4.1.6, source control, CI, tickets, tool validation.
The 10 most common MDR software audit findings against EN 62304, from missing problem-resolution records to broken traceability, and how to fix each.
The complete MDR software compliance checklist for MedTech startups, from Rule 11 classification through release, using EN 62304 and the related standards.
How MDR Annex I §14.2(d) and §17.1 shape interoperability obligations for connected medical devices, with FHIR, HL7, DICOM, and IHE in context.
Digital therapeutics DTx MDR path: qualification, Rule 11 classification, clinical evidence, and the CE-marking spine every DTx startup must build.
A phase-by-phase digital health compliance checklist 2026 for founders building software that may qualify as a medical device under MDR.