Medical Software Foundation – Regulatory + Technical Stack

By Christoph Eberhardt · CEO, DUX Healthcare · 19 April 2026

Which foundation stack carries every Software-as-Medical-Device under MDR? This hub orders the SaMD stack: MDR (Regulation (EU) 2017/745) as the legal frame, IEC 62304 as the software lifecycle, ISO 13485 as the QMS, ISO 14971 as the risk-management backbone, IEC 62366-1 for usability engineering and IEC 82304 as the health-software standard — plus the 2026 outlook on the AI Act. DiGA-specific overlays (BSI TR-03161, BSI TR-03185, BfArM data-protection review criteria) live under /knowledge/diga/, not in this hub.

DUX practice anchor: 7 years of Software-as-Medical-Device development, five DiGAs under contract on the mHealth Suite, BSI TR-03185 as the first company in Germany to hold that certification.

What medical software foundation means for digital therapeutics

A digital therapeutic (DTx) – or more broadly Software as a Medical Device (SaMD) in the IMDRF sense of “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device” (IMDRF N10:2013↗) – is not a product category that the regulator treats differently from other medical devices. The MDR does not mention DTx, DiGA, or SaMD by name. It regulates medical-device software the same way it regulates an infusion pump: by intended use, by risk class, and by compliance with a defined set of general safety and performance requirements.

That is why the foundation stack matters before the reimbursement conversation. A company that arrives at BfArM, HAS, NICE, or MHRA with clean CE certification and a defensible clinical evaluation has solved 60–70 % of what any reimbursement pathway asks. A company that arrives with a DiGA plan but without the stack underneath rebuilds it in crisis – at 3–5× the price of having built it properly in the first place.

Three structural points:

1. The foundation is one-time-build, not per-market. MDR conformity, IEC 62304 documentation, ISO 13485 QMS, ISO 14971 risk file are all portable across EU markets. DiGA-specific layers (BSI TR-03161, BfArM data-protection criteria) sit on top in the DiGA knowledge area. NHS DTAC adds clinical-safety (DCB0129/0160) and its own interoperability expectations. PECAN adds a dossier for CNEDiMTS. None of these replace the CE foundation.
2. The foundation is not the evidence study. Clinical evaluation under MDR Annex XIV and clinical investigation evidence are separate instruments from the software lifecycle (IEC 62304), the QMS (ISO 13485), and the risk file (ISO 14971). Teams routinely conflate them. The study answers “does it work?”; the stack answers “is it safe, built to a standard, and controllable?”.
3. The foundation is where notified bodies spend their time. A notified-body technical-documentation review under MDR Annex II samples heavily into IEC 62304 evidence, ISO 14971 risk management, and the cybersecurity position (MDCG 2019-16). Teams that treat those three as box-ticking items spend significantly longer in conformity assessment than teams that treat them as engineering disciplines.

MDR Rule 11 – classification for software, with MDCG 2019-11 Rev.1 as anchor

Medical-device software classification under MDR is decided by Annex VIII Rule 11, and the interpretive anchor every notified body, auditor and BfArM reviewer uses is MDCG 2019-11 Rev.1 (June 2025) (MDCG 2019-11 Rev.1↗). The mechanics matter because they set the rest of the stack: class determines conformity-assessment route, notified-body involvement, technical-documentation depth, and clinical-evaluation expectations.

The text of Rule 11 and its three sub-rules

MDCG 2019-11 splits Rule 11 into three sub-rules (MDCG 2019-11 Rev.1 Sec. 4.2.1):

• Rule 11a – software providing information to take decisions with diagnostic or therapeutic purposes. Default class IIa. Escalates to IIb where the decisions may cause serious deterioration of health or a surgical intervention. Escalates to III where the decisions may cause death or irreversible deterioration.
• Rule 11b – software intended to monitor physiological processes. Class IIa by default, IIb where monitoring vital physiological parameters and variations could result in immediate danger.
• Rule 11c – all other software. Class I.

Almost every DTx lands in Rule 11a. The default is therefore IIa, not I. Class I software-as-medical-device is rare in therapeutic contexts and, when present, usually signals either a borderline intended-use claim (“general wellness”, “education”) or an incorrect qualification call.

The IMDRF-to-MDR correspondence table

MDCG 2019-11 Rev.1 Annex III provides a table mapping IMDRF N12:2014 SaMD risk categories (I, II, III, IV) to MDR Rule 11 classes. The table is indicative, not legally binding, but it is the reference notified bodies and manufacturers use in practice:

• IMDRF category I (non-serious condition, inform clinical management) → MDR Class IIa
• IMDRF category II (serious, inform clinical management) → MDR Class IIa
• IMDRF category III (serious condition, drive clinical management) → MDR Class IIb (Rule 11a ii.)
• IMDRF category IV (critical condition, drive clinical management) → MDR Class III (Rule 11a i.)

Two things teams get wrong here:

• “Drive” vs. “inform” is not about the UI, it is about the decision architecture. A recommendation that a clinician can override is still “inform” for IMDRF N12 and typically Rule 11a IIa. A recommendation executed automatically, or framed such that clinician review is nominal, is “drive” – and one IMDRF category higher.
• “Serious condition” is an intended-population property, not a word count. A mental-health DTx for treatment-resistant depression is a serious condition by MDCG 2019-11 even if the UI says “meditation exercises” – the intended population, not the modality, sets the seriousness bar.

Class-dependent conformity-assessment routes

MDR Art. 52 determines conformity assessment by class:

• Class I – manufacturer’s declaration of conformity, no notified body (except sterile, measuring, or reusable-surgical sub-classes).
• Class IIa – notified-body involvement via Annex IX (QMS + technical documentation review) or Annex XI Part A (QMS).
• Class IIb – notified body via Annex IX or Annex X + Annex XI Part A. Notified body reviews each representative device of each category; sampling within the generic device group applies.
• Class III – notified body via Annex IX with technical-documentation review per device, or Annex X + Annex XI Part A. Consultation with expert panel for certain sub-groups.

For DiGA specifically, the DigiG 2024 law extended DiGA eligibility to Class IIb – but the preliminary-listing route stays closed to IIb, so classification posture materially changes the evidence calendar.

IEC 62304 – software lifecycle in practice

IEC 62304:2006+AMD1:2015 – Medical device software – Software life cycle processes is the harmonised standard that operationalises MDR Annex I General Safety and Performance Requirements 17 (programmable electronic systems / software). Complying with 62304 is the default way to demonstrate those requirements; manufacturers may use alternative means but must justify the deviation, and no notified body is enthusiastic about that conversation.

Software safety classification A / B / C

62304 defines three safety classes:

• Class A – no injury or damage to health is possible.
• Class B – non-serious injury is possible.
• Class C – death or serious injury is possible.

The classification applies per software item after risk-control measures are in place – which means architectural segmentation can reduce effective class. A DTx whose system-level classification would be B can have large Class A portions (UI layer, analytics) and a small Class B core (the therapeutic algorithm, the dose calculation, the alert logic). That segmentation matters because the lifecycle obligations scale with class.

What the lifecycle requires

• Class A – planning, requirements, architectural design, implementation, system testing, release, and post-release activities. Unit-test and integration-test depth is flexible.
• Class B – adds software unit verification, integration testing with documented procedures, and more rigorous anomaly resolution.
• Class C – adds detailed design for each unit, verification at every level, and the strictest change-control and anomaly-resolution regimes.

All three classes require a defined software development plan, documented architecture, requirements traceability, problem-resolution process, and configuration management. The difference is in depth of evidence, not in presence/absence of practices.

Why IEC 62304 is where notified bodies spend their time

A Class IIa Rule-11a DTx with software safety class B is a typical DiGA profile. A notified-body technical-documentation review focuses on:

• the software requirements specification and its traceability to intended use and risk-control measures;
• the software architecture document and the segmentation of software items by safety class;
• the integration test and system test evidence;
• the problem-resolution process and the anomaly log;
• the Software of Unknown Provenance (SOUP) inventory and justification – third-party libraries, operating-system components, open-source frameworks; their selection, verification, and integration into the risk file.

The SOUP conversation is the one international teams most systematically underestimate. A DTx with 400 npm dependencies and a dozen mobile SDKs has a large SOUP surface, and every item must be mapped: version, supplier, intended use inside the device, assessment against 62304 Sec. 5.3.3, risk assessment against ISO 14971, update discipline. Retrofitting this on a three-year-old codebase is weeks of archaeology.

ISO 13485 + ISO 14971 – QMS and risk management as baseline

ISO 13485 – the QMS that MDR presumes

ISO 13485:2016 – Quality management systems – Requirements for regulatory purposes is the QMS standard for medical devices. MDR Art. 10(9) requires every manufacturer to establish, document, implement, maintain, keep up to date and continually improve a quality management system. Compliance with ISO 13485 is the practical route to that requirement – and for Class IIa and above, a notified body certifies the QMS as part of the Annex IX route.

A common misunderstanding from software teams: “we have ISO 9001, do we need 13485?” ISO 9001 is about customer satisfaction; ISO 13485 is about regulatory compliance and medical-device safety. They overlap on structure – management responsibility, resource management, process control – but 13485 has medical-device-specific requirements that 9001 does not: design and development controls (Clause 7.3), validation of processes (Clause 7.5.6), medical-device files (Clause 4.2.3), post-market surveillance inputs into the QMS. “ISO 9001 compliant” does not pass a notified-body audit for a medical device.

ISO 14971 – risk management as the spine

ISO 14971:2019 – Medical devices – Application of risk management to medical devices is the harmonised standard for MDR Annex I GSPR 3 (risk-management requirements). 14971 is not optional – it is the language in which the notified body asks every question about hazards, foreseeable sequences of events, harm, and risk-control measures.

The workflow is well known but rarely executed cleanly on first pass:

1. Intended use and reasonably foreseeable misuse – the starting point, and where most 14971 files weaken under audit because misuse is under-specified.
2. Identification of characteristics related to safety – the 14971 Annex C list is a good forcing function.
3. Identification of hazards and hazardous situations – systematic, not anecdotal.
4. Risk estimation – probability × severity, with documented methodology for estimating probability for software hazards.
5. Risk evaluation against acceptance criteria – defined in the risk-management plan, not invented per file.
6. Risk-control measures – inherently safe design, protective measures, information for safety. Then re-estimation.
7. Residual risk evaluation and benefit-risk analysis.
8. Post-market risk management – fed from complaints, vigilance, post-market surveillance, and (for some products) clinical follow-up.

ISO 14971 connects directly to IEC 62304: the software safety classification (A/B/C) is derived from the risk analysis, and the severity of potential harm from software failure is the load-bearing input. Class A is not a decision about how heavy the testing is; it is a conclusion from a risk analysis that shows no injury or damage to health is possible.

ISO 13485 and ISO 14971 together are the baseline every medical-software company must have. DiGA, PECAN, NHS DTAC and FDA all presume it – differently, but presume it.

BSI TR-03185 – organisational secure-SDLC certification

BSI TR-03185 – Sicherer Software-Lebenszyklus is an organisation-level certification of the manufacturer’s software development lifecycle. Binary outcome (pass/fail). It evaluates project management, configuration and change management, secure-coding requirements, third-party software management, test methodology, incident management, and the operations/maintenance phase. The Cyber Resilience Act (Regulation (EU) 2024/2847)↗ runs in the same direction, addressing cybersecurity across the entire product lifecycle – TR-03185 is one of the practical German implementations. DUX Healthcare is the first company to hold the TR-03185 certification.

TR-03185 and the DiGA-specific BSI TR-03161 are complementary instruments: a TR-03185-certified SDLC pre-attests the process evidence that every subsequent TR-03161 assessment would otherwise have to re-examine. Per-DiGA TR-03161 assessment remains mandatory under § 139e Abs. 10 SGB V – see BSI TR-03161 certification – a practitioner’s guide in the DiGA knowledge area.

Two further standards that show up in architecture conversations:

• ISO 27001 – information security management system. For DiGA, an accredited ISO 27001 certificate (or equivalent) is mandatory at the organisation level (DiGA Guide v3.6 Sec. 3.4.1). Not a substitute for TR-03161; in TR-03161 Part 3, ISO 27001 (or IT-Grundschutz, or equivalent) is required as a precondition.
• BSI C5 – cloud computing criteria catalogue. Cloud-hosted DiGA backends should run on providers that meet C5 (or equivalent) per BSI recommendation. Major hyperscalers typically meet that bar; smaller or self-built infrastructure often does not.

BfArM data-protection criteria – how they fit the stack

A common misconception from foreign teams: “we have GDPR covered, that is the data-protection block.” It has not been true for Germany since 1 August 2024.

§ 139e Abs. 11 SGB V authorises the BfArM to publish a data-protection review criteria catalogue against which DiGAs are tested. Since 1 August 2024 that catalogue – roughly 150 individual criteria across 12 thematic blocks, written with RFC 2119 keywords (MUSS / MUSS NICHT / SOLL / KANN) – is binding through DiGAV § 4 Abs. 8: the manufacturer MUST implement the catalogue and declare implementation in the application-bound declaration under Annex 1 DiGAV. The BfArM reviews the declaration as part of the application. Formal third-party certification by an accredited ISO/IEC 17065 body is not yet operational because no body has been DAkkS-accredited for this purpose; once accreditation is in place, BfArM will require formal certificates with appropriate lead time.

The controller under GDPR Art. 4 No. 7 is the manufacturer of the DiGA – not a platform service provider. DUX implements the technical requirements (TOM_, AV_1.3 TOMs, ACC_, pseudonymisation, access control, logging, deletion) on the platform side; the process-side obligations (DSB appointment under CTRL_1.2, EU representative under CTRL_1.4 where applicable, AV_2 processor agreements with sub-processors, DSFA review cadence under DSFA_1.8) remain manufacturer responsibilities, with operational support from DUX.

This layer lives primarily in the DiGA knowledge area – see BfArM data-protection review criteria in detail.

For the foundation perspective, three interfaces with the technical stack:

1. The RFC 2119 grammar of the BfArM criteria mirrors TR-03161. MUSS items are non-negotiable; SOLL items are skippable only with a documented no-risk justification.
2. The criteria interlock with the IEC 62304 architecture. Pseudonymisation, access control, logging, and deletion are not just compliance items – they are software requirements that must appear in the architecture document, the risk file, and the test record.
3. The criteria run parallel to TR-03161, not sequentially. Both are filed; both are reviewed independently; both can map to the same technical mechanism (e.g. an audit trail) – but they ask different questions.

AI Act × MDR – the 2026 / 2027 outlook

The AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and phases in over a multi-year transitional period. For medical-device software – and for DTx specifically – the load-bearing guidance is MDCG 2025-6 / AIB 2025-1 published jointly by the Medical Device Coordination Group and the EU AI Board on 19 June 2025 (MDCG 2025-6↗).

The high-risk classification mechanism

MDCG 2025-6 Q2 sets out the test for whether an AI-enabled medical device (MDAI) is a high-risk AI system under Art. 6(1) AIA. Two cumulative conditions:

1. The MDAI is a safety component of a medical device, or the AI system is itself a medical device, and
2. The MDAI is subject to a third-party conformity assessment by a notified body under MDR/IVDR.

Consequence: almost every AI-enabled Class IIa, IIb or III medical device triggers high-risk AIA status. Class I non-sterile/non-measuring/non-reusable-surgical escapes, but that is a narrow cohort for AI-enabled software and rarely applies to DTx.

What does not change

MDCG 2025-6 Q4 answers cleanly: “Does AIA high-risk classification push my MDR classification up?” No. AIA high-risk status does not change MDR/IVDR classification. A Class IIa DTx stays Class IIa under MDR regardless of its AIA high-risk status (MDCG 2025-6 Q4).

What does change – the additional obligations layer

For high-risk MDAI, the AIA adds obligations on top of MDR:

• Art. 9 AIA – risk-management system (complementary to ISO 14971 / MDR Annex I, with AI-specific dimensions).
• Art. 10 AIA – data governance for training, validation and test datasets.
• Art. 13 AIA – transparency and provision of information to deployers.
• Art. 14 AIA – human oversight measures.
• Art. 15 AIA – accuracy, robustness, and cybersecurity.
• Art. 17 AIA – quality management system additions to ISO 13485-style QMS.
• Art. 72 AIA – post-market monitoring for high-risk AI systems.

Operationally, a high-risk MDAI has two parallel evidence stacks: the MDR technical documentation + IEC 62304 + ISO 14971 + ISO 13485 on the device side, and the AIA Annex IV technical documentation + data-governance documentation + post-market-monitoring plan on the AI side. MDCG 2025-6 encourages integration where possible, and notified bodies designated under both regimes will expect a single coherent file rather than two disconnected ones.

Transitional timing

Art. 113 AIA sets the general applicability date at 2 August 2026, with specific provisions moving earlier or later. For high-risk AI systems in the sense of Art. 6(1) – i.e. AI embedded in regulated products including MDR/IVDR devices – obligations apply from 2 August 2027. Guidance on the specific interaction with ongoing MDR conformity assessments is still being issued; verify the current Commission position before committing to a transition plan.

Platform vs. custom build – the foundation economics

The foundation stack walked through above is expensive to build once and cheap to re-use. The question every CTO with a DTx roadmap should be asking is not “how fast can we produce one DiGA?” but “how many medical-software products do we plan to ship in the next five years, and where does that put the break-even on foundation investment?”

The rough economics:

• First product on a custom build. MDR technical documentation from scratch, IEC 62304 evidence from scratch, ISO 13485 QMS, ISO 14971 risk file, BSI TR-03161 architecture and certification, BfArM data-protection criteria operationalised from scratch, ePA integration built from scratch. Twelve to eighteen months of regulatory and engineering work before meaningful product iteration begins. €500k–€2M absorbed into the foundation rather than into the therapeutic intent.
• Second product on the same custom foundation. Meaningfully cheaper – perhaps 40–60 % of the first – but still rebuilds the product-specific slice of everything: technical documentation, IEC 62304 evidence for the new software, 14971 risk file, TR-03161 per-DiGA assessment.
• First product on a platform. Platform pays foundation once. Per-product work is the intended-use definition, the therapeutic software module, the product-specific IEC 62304 evidence (scoped to the module and its interactions with the platform), the product-specific 14971 risk file, the product-specific TR-03161 assessment, and the product-specific clinical evaluation or study. Twelve weeks rather than twelve months to a DiGAV-compliant, CE-marked product.

DUX built the mHealth Suite as a platform rather than a collection of delivery projects. Five DiGAs are currently under contract and being developed on it, each platform-engineered, each individually tested against BSI TR-03161 per DiGA, all CE-marked under MDR. The software development lifecycle is certified under BSI TR-03185 — DUX is the first company in Germany to hold that certification. Platform mechanics in detail: /build/.

Frequently asked questions