Digital health compliance in 2026 is a sequence, not a shopping list. Qualify the software as a medical device or not, classify it under MDR Rule 11, pick a conformity route, stand up a QMS that fits a small team, design cybersecurity in from day one, plan clinical evidence early, respect GDPR from the first line of code, and treat reimbursement as a separate track. Founders who follow the sequence ship. Founders who parallelise everything drown.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Qualification comes before classification. The decision whether software is a medical device under MDR Article 2 and MDCG 2019-11 Rev.1 determines whether any of the rest applies.
  • MDR Annex VIII Rule 11 rarely leaves software in Class I. Most diagnosis and therapy support software lands in Class IIa or higher, which means a Notified Body is involved.
  • A digital health QMS does not need to look like a pharma QMS. EN ISO 13485:2016+A11:2021 can be implemented lean if the team treats procedures as software artifacts.
  • Cybersecurity under MDR Annex I §17.2 and §17.4, operationalised through EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1, has to be designed in at the start, not bolted on before audit.
  • Clinical evidence for SaMD under MDR Article 61 and Annex XIV is frequently the timeline driver. Starting that work late is the single most common reason a digital health launch slips a year.
  • GDPR is not optional and not covered by MDR. It runs in parallel and has to be owned explicitly.
  • DiGA or equivalent reimbursement is a separate track that only becomes relevant after CE marking. It should not drive the regulatory design.

Why the sequence matters

Felix has coached 44 medtech startups. Tibor has audited or advised more than 50 through MDR. Between them, the recurring failure mode in digital health is founders trying to do everything at once, or in the wrong order, because a deadline ignored regulatory physics.

Digital health looks like software. It ships like a regulated device. Each phase below has a clear exit criterion. A founder who cannot pass the exit criterion should not start the next phase. The Subtract to Ship angle is direct: remove anything that does not serve the next audit, the next evidence question, or the next user safety decision. See the Subtract to Ship framework applied to MDR for the methodology.

Phase 0. Qualify the software as a medical device, or not

Exit criterion: a signed qualification decision with rationale.

Under MDR Article 2(1), a medical device is an article intended by the manufacturer for a specified medical purpose such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, which does not achieve its principal intended action by pharmacological, immunological, or metabolic means. Software that performs an action on data for a medical purpose is in scope. Software that merely stores, archives, communicates, or performs simple search is typically not, as clarified in MDCG 2019-11 Rev.1.

The qualification decision is a written artifact. Cite the intended purpose, cite MDCG 2019-11 Rev.1, sign and date. If the software is not a medical device, MDR obligations fall away but GDPR does not. Otherwise, move to Phase 1.

Phase 1. Classify under Rule 11

Exit criterion: a documented classification, cited to Annex VIII Rule 11, with a Notified Body opinion if the class is unclear.

MDR Annex VIII Rule 11 governs software. Software intended to provide information used for decisions with diagnosis or therapeutic purposes is Class IIa, unless the decisions may cause death or irreversible deterioration (Class III) or serious deterioration or surgical intervention (Class IIb). Software intended to monitor physiological processes is Class IIa, unless it monitors vital physiological parameters where variations could result in immediate danger (Class IIb). All other software is Class I.

Most digital health software lands Class IIa or higher. Class I digital health usually signals a qualification question worth a second look. See MDR classification Rule 11 for software for worked examples. The correct justification structure is to cite the intended purpose, walk Rule 11 phrase by phrase, map each phrase to the device, and conclude.

Phase 2. Choose the conformity route

Exit criterion: a chosen route under MDR Article 52, documented with rationale.

For Class I devices, self-certification is possible under MDR Article 52(7). For Class IIa and above, a Notified Body is mandatory. The most common path for SaMD is Annex IX (QMS plus technical documentation assessment). Notified Body capacity remains constrained in 2026, so applying early matters. A founder cannot engage a Notified Body seriously without a classification decision and a draft technical file outline.

Phase 3. Stand up a QMS that fits a small team

Exit criterion: EN ISO 13485:2016+A11:2021 procedures in place, in use, and producing records.

A QMS is evidence that the organisation does what it says. For a ten-person digital health startup, it can live in a git repository with markdown procedures, issue tracker workflows, and automated record generation. Tibor has audited lean setups that passed cleanly because every procedure produced a record and every record was traceable. The sections that matter most are design controls, risk management, software lifecycle, configuration management, change control, supplier management, and post-market surveillance. See MDR QMS for software companies for the practical pattern.

Phase 4. Plan cybersecurity from day one

Exit criterion: a cybersecurity plan and risk analysis in place, referenced by the software architecture.

MDR Annex I §17.2 requires software state of the art including information security. §17.4 addresses IT networks and security measures. The operational standard is EN IEC 81001-5-1:2022, with MDCG 2019-16 Rev.1 as interpretive guidance.

The common failure is to treat cybersecurity as a pre-audit cleanup task. By that point architecture is locked, and retrofitting secure update mechanisms, SBOM tracking, and threat modeling costs months. Designed in, it costs weeks. Key artifacts: a threat model, a security risk assessment aligned with EN ISO 14971:2019+A11:2021, a SBOM, a vulnerability monitoring process, a secure update mechanism, and an incident response plan. See the cybersecurity startup guide for 2026 for concrete steps.

Phase 5. Plan clinical evidence early

Exit criterion: a clinical evaluation plan (CEP) under MDR Annex XIV Part A.

Clinical evidence most often breaks a digital health timeline. MDR Article 61 and Annex XIV require clinical evaluation for every device. The evaluation combines literature review, state of the art analysis, and, frequently, prospective data generation.

Tibor has seen startups reach the end of development and only then discover the clinical evidence plan. That discovery adds six to eighteen months. The Subtract to Ship move is to write the CEP in parallel with Phase 2, so the evidence strategy constrains the product scope. If the evidence plan requires a clinical investigation under MDR Article 62, start planning it the same week classification is finalised. MDCG 2020-5 on equivalence and MDCG 2023-7 on clinical evaluation exemptions under Article 61(4) to (6) are essential reading. Equivalence claims for SaMD are harder under MDR than under MDD.

Phase 6. Handle GDPR in parallel

Exit criterion: a GDPR compliance package separate from, but cross-referenced with, the MDR technical file.

GDPR is not inside MDR. Both regulations apply in full. Digital health software almost always processes special categories of personal data under Article 9 GDPR, which raises the bar on lawful basis, consent, and data protection impact assessment.

Run a DPIA early, appoint a DPO if the processing scale requires it, document the lawful basis, map the data flows, and keep a processor register. The MDR technical file can reference GDPR artifacts but should not absorb them. A frequent trap is assuming anonymisation of clinical data bypasses GDPR. Under EDPB guidance, the anonymisation bar is high. Pseudonymisation is not anonymisation.

Phase 7. Treat reimbursement as a separate track

Exit criterion: a reimbursement hypothesis that does not distort the regulatory design.

DiGA in Germany, PECAN in France, and similar routes in other Member States offer reimbursement pathways. They are secondary to CE marking. A product cannot enter DiGA without being CE-marked, and the DiGA evidence requirements are separate from MDR clinical evaluation requirements. The order that works: achieve CE marking under MDR, then approach DiGA with the additional evidence it requires, specifically the positive healthcare effect study. See reimbursement in digital health Europe beyond DiGA for a broader view.

The phase-by-phase checklist

Phase 0. Qualification - [ ] Intended purpose written, signed, dated - [ ] MDCG 2019-11 Rev.1 walked and cited - [ ] Qualification decision documented with rationale - [ ] If not a medical device, GDPR obligations still mapped

Phase 1. Classification - [ ] Rule 11 decision documented, citing Annex VIII - [ ] Borderline cases escalated to Notified Body or competent authority - [ ] Classification justification file created and version controlled

Phase 2. Conformity route - [ ] Route chosen under MDR Article 52 - [ ] Notified Body longlist built, outreach started - [ ] Technical file outline drafted - [ ] Realistic timeline accepted by leadership

Phase 3. QMS - [ ] EN ISO 13485:2016+A11:2021 procedures drafted - [ ] Design controls, risk management, CAPA in place - [ ] Records being generated by real workflow, not back-filled - [ ] Internal audit run and closed

Phase 4. Cybersecurity - [ ] Threat model in place - [ ] Security risk assessment aligned to EN ISO 14971:2019+A11:2021 - [ ] SBOM maintained - [ ] Vulnerability monitoring and disclosure process defined - [ ] Secure update mechanism implemented - [ ] Incident response plan drafted

Phase 5. Clinical evidence - [ ] Clinical evaluation plan under Annex XIV Part A - [ ] State of the art analysis - [ ] Literature search protocol - [ ] Gap analysis - [ ] Clinical investigation decision under Article 62, if needed, made early - [ ] PMCF plan scoped

Phase 6. GDPR - [ ] DPIA run - [ ] Lawful basis documented - [ ] Data flows mapped - [ ] Processor agreements signed - [ ] DPO appointed if required - [ ] Cross-reference to MDR file in place

Phase 7. Reimbursement - [ ] Target markets prioritised - [ ] Reimbursement hypothesis drafted - [ ] Decision to pursue DiGA or equivalent deferred until after CE marking - [ ] Evidence gap between MDR CE and reimbursement understood

The Subtract to Ship playbook for digital health

Felix frames digital health compliance in four rules.

Rule 1. Remove every feature that does not serve the intended purpose. Every extra feature drags the technical file, the risk file, the clinical evidence, and the cybersecurity surface. The device that ships first is the one with the smallest surface that passes the intended purpose.

Rule 2. Decide classification before coding the sensitive paths. Architecture built under the assumption of Class I looks nothing like architecture built for Class IIb. Changing classes late is expensive.

Rule 3. Write procedures that produce records automatically. A QMS that depends on manual upkeep fails the first time the team is under pressure. A QMS wired into the tooling survives.

Rule 4. Start clinical evidence when you start the CEP, not when you start the CER. The CEP is the plan. The CER is the report. Founders who wait until they need the CER to think about evidence are already late.

Reality Check

  1. Has someone in the organisation written and signed the qualification decision, or is it assumed?
  2. Is the classification justification specific to this device, or is it a template with the name changed?
  3. Has a Notified Body been contacted, or is the plan still to apply "later"?
  4. Does the QMS produce records from real workflow, or are procedures being reverse-engineered to match what happened?
  5. Is the cybersecurity plan in the architecture document, or in a separate file that engineering has not read?
  6. Is there a clinical evaluation plan under Annex XIV Part A, signed and dated, with a clear evidence strategy?
  7. Is the GDPR work owned by a named person, with a DPIA on file?
  8. Is reimbursement an aspiration, or a plan that sits behind the CE marking work?

Frequently Asked Questions

Is every digital health app a medical device? No. The intended purpose and the function determine qualification under MDR Article 2 and MDCG 2019-11 Rev.1. Wellness and lifestyle apps can stay out of scope, but the line is narrower than many founders believe.

Can a digital health app be Class I under MDR? Rarely. Rule 11 pushes most diagnosis and therapy support software into Class IIa or higher. Class I digital health usually signals a qualification or classification question worth a second review.

Does a lean QMS really pass audits? Yes, if the procedures produce records and the records match reality. Tibor has audited ten-person teams that passed cleanly because the evidence was consistent and traceable.

How much clinical evidence does a digital health SaMD need? It depends on risk class, novelty, and the state of the art. Low-risk, well-precedented functionality can sometimes rely on literature and performance testing. Novel or higher-risk functionality typically needs prospective data. The CEP is where this is decided.

Does GDPR delay CE marking? Not usually, if it is run in parallel from the start. It delays launch when it is discovered late.

Should a founder pursue DiGA before CE marking? No. DiGA requires an existing CE mark. The DiGA evidence work starts after CE, not before.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 2, Article 10, Article 52, Article 61, Article 62, Annex I §17, Annex VIII Rule 11, Annex XIV.
  2. MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745, October 2019, Rev.1 June 2025.
  3. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices, December 2019, Rev.1 July 2020.
  4. EN ISO 13485:2016+A11:2021, Medical devices, Quality management systems.
  5. EN 62304:2006+A1:2015, Medical device software, Software lifecycle processes.
  6. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1.
  7. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.