MDR Annex II · Annex III · Rule 11 · IEC 62304
Medical device software technical documentation checklist
Check whether the dossier lets a reviewer move from the medical purpose to the released code, clinical evidence, risk controls and post-market obligations without losing the evidence chain.
Review 89 concrete checkpoints, record document references and gaps, and create a clean PDF or printed report. Your draft stays in this browser and is not sent to MDRC.
Start the checklist ↓89 checkpoints · 12 dossier sections
Project details
Define the software and dossier version under review
Only completed fields are carried into the issued report. The software product name is required.
Entries are stored in this browser only. They are not uploaded or submitted.
Dossier review
Review the complete software evidence chain
Use Completed, Open or Not applicable. Add a document reference, decision or short rationale only where it helps the review.
The legal manufacturer and the exact software product are identified
Record legal name, SRN where available, product name, modules, platforms, deployment models, current versions and whether the software is a device in its own right, part of a device or an accessory.
The intended purpose states the medical function without relying on vague technology language
Identify the medical purpose, target population, intended users, use environment, inputs, outputs, clinical decisions supported, limitations and contraindications. Claims in the website, app store, IFU and clinical evaluation must match.
Qualification as medical device software is documented for every medical function or module
Apply the MDR definition and MDCG 2019-11 Rev.1. Distinguish medical functions from storage, communication, workflow and general wellness functions and document dependencies between regulated and non-regulated modules.
MDR classification is justified using Rule 11 and any other applicable Annex VIII rules
Decision-support software is generally Class IIa, rising to IIb or III when a wrong decision could cause serious deterioration, surgical intervention, death or irreversible deterioration. Monitoring software is generally IIa and becomes IIb when it monitors vital parameters whose variation could create immediate danger. Other software may be Class I.
The conformity assessment route matches the software class and manufacturer status
Class I software may use self-declaration when no other feature requires a Notified Body. Classes IIa, IIb and III require an appropriately designated Notified Body and a documented assessment route.
The regulatory product boundary includes all safety-relevant dependencies
Identify operating systems, browsers, mobile devices, cloud services, databases, interfaces, hardware, networks and external services needed for the software to perform safely.
Basic UDI-DI, UDI-DI strategy and product identifiers are mapped to the covered configurations
Link the Basic UDI-DI, UDI-DI where assigned, trade names, catalogue identifiers, modules, platforms and versioning rules so the dossier and registrations identify the same product.
Claims and product presentation are supported by the approved scope and evidence
Prevent unsupported diagnostic, predictive, preventive or therapeutic claims and ensure demonstrations, screenshots, app-store text and sales material do not expand the intended purpose.
Previous generations and similar devices are identified with meaningful differences
Describe design lineage, earlier versions, comparable products, relevant market history and which earlier evidence is reused, including why it remains applicable.
A master index covers MDR Annex II and Annex III and names the current document version
For every required element, identify the controlled document, section, version, owner and approval status. Do not use broad folder references that force the reviewer to search.
The dossier has a unique identifier, approval record and complete revision history
Distinguish the approved submission set from drafts and obsolete evidence. Record what changed, why it changed and which linked evidence was reassessed.
The GSPR checklist assesses every applicable Annex I requirement at sub-requirement level
For each applicable requirement, state the conformity method and cite exact evidence. For each non-applicable requirement, give a product-specific reason.
The standards list identifies editions, amendments, harmonised status and any deviations
Explain which clauses were applied and how gaps or alternative methods provide an equivalent level of safety and performance.
Labels, electronic displays, IFU, user manuals and installation information are controlled
Keep product name, version, manufacturer, UDI, intended purpose, warnings, compatible environments, minimum requirements and support information consistent across every supplied format.
Warnings, limitations, residual risks and required user actions match the supporting evidence
Trace information-for-safety controls from the risk file to the exact screen, label or document location and verify that the intended user can act on them.
The declaration of conformity, certificates and registrations identify the same product scope
Cross-check legal manufacturer, authorised representative, product and versions, classification, conformity route, standards, Basic UDI-DI, certificate scope and EUDAMED or national registration data.
Translations and country-specific supplied information are version-synchronised
Retain translation verification and approval, distribution-country coverage and a method to prevent an obsolete language version remaining available after a safety or product change.
A software development and maintenance plan exists for the current release
Define lifecycle model, activities, deliverables, responsibilities, reviews, configuration controls, tools, verification, anomaly handling, release criteria and maintenance arrangements.
The IEC 62304 software safety class is documented and justified
Assign Class A, B or C according to the possible harm if the software contributes to a hazardous situation, considering external risk controls. This safety class is separate from and does not replace the MDR device class.
The lifecycle model preserves required evidence when agile methods are used
Sprints and user stories are acceptable only when approved requirements, risk links, reviews, tests, configuration baselines and release records remain complete and traceable.
Lifecycle activities are scaled by risk without omitting mandatory controls
Document which activities apply to each software item, why any activity is tailored and how higher-risk components receive stronger review, independence and verification.
Legacy or previously developed software has a documented gap assessment
Identify missing requirements, architecture, risk links, verification, anomaly and configuration records and define remediation or justified alternative evidence before relying on the software.
Problem-resolution and maintenance processes are planned before release
Define intake, triage, safety and security assessment, investigation, correction, regression testing, regulatory evaluation, customer communication and closure.
Lifecycle records identify the exact software, tools and environment used
Retain repositories, branches, commits, build tools, compiler or interpreter versions, dependencies, test environments and generated artefacts needed to reconstruct the released state.
System and software requirements are uniquely identified, testable and approved
Cover medical functions, performance, safety, security, usability, interfaces, data, alarms, installation, maintenance, regulatory constraints and foreseeable misuse with measurable acceptance criteria.
Each requirement has a controlled source and rationale
Trace requirements to user needs, intended purpose, GSPRs, risk controls, clinical evidence, usability findings, standards, interoperability specifications or post-market information.
The architecture identifies software items, interfaces and segregation
Show components, data stores, external services, trust boundaries, safety classes, responsibilities and how segregation or redundancy prevents one failure from defeating a risk control.
Data flows and external interfaces are specified end to end
Define data source, format, units, timing, validation, transformation, missing or stale data behavior, error handling, authentication and outputs for APIs, devices, EHRs and cloud services.
Clinical calculations, thresholds and alarms have approved specifications
Document formulas, units, rounding, reference ranges, timing, priority, latching, acknowledgement and safe behavior at boundary conditions, invalid input and communication loss.
Bidirectional traceability connects needs, requirements, risks, code and tests
A reviewer should be able to move from each medical claim and risk control to implemented software and objective verification, and from each released software item back to an approved requirement.
Requirement changes are reviewed before implementation
Assess affected architecture, hazards, clinical claims, usability, security, tests, UDI, technical documentation, registrations and already deployed versions before approval.
The software risk management file is linked to the device risk management process
Apply lifecycle risk management and connect software causes, sequences of events, hazardous situations, harms, controls, verification and production or post-production information.
Software-specific hazards and failure modes are systematically analysed
Consider wrong, delayed, missing or duplicated output; data corruption; incorrect units; alarm failure; automation bias; unintended access; unavailable service; interoperability failure; update failure and foreseeable misuse.
Cybersecurity risks are evaluated for their safety impact
Connect threat scenarios to patient or user harm. Security controls that reduce safety risk must appear in the risk file and receive the same implementation and verification discipline as other risk controls.
A usability engineering process covers safety-related user interactions
Identify users, environments, critical tasks, use scenarios and use-related hazards; perform formative evaluation and validate the final user interface with representative users and conditions.
Clinical evidence covers valid clinical association, technical performance and clinical performance
Use the MDCG 2020-1 structure where applicable. Show that the output is associated with the target condition, the software correctly processes inputs and the output achieves the intended clinical purpose in the target population.
Every medical performance claim has an acceptance criterion and supporting data
Define datasets, reference standard, endpoints, sample size, missing-data handling, subgroup analysis, uncertainty and confidence intervals for claims such as sensitivity, specificity, accuracy, prediction or treatment support.
Residual risks, limitations and user information are mutually consistent
Carry unresolved limitations, prerequisites, supported populations, compatible environments, required user review and fallback actions into the clinical evaluation, risk file, labelling and interface.
Coding, review and static-analysis rules are defined and applied
Use language- and risk-appropriate coding standards, peer review, secure coding, prohibited constructs, complexity thresholds and documented disposition of findings.
Unit, integration and system tests cover normal, boundary and failure behavior
Test calculations, states, interfaces, timing, concurrency, invalid input, communication loss, resource exhaustion, recovery and foreseeable misuse at the appropriate level.
Every implemented risk control has objective effectiveness evidence
Trace controls to tests with predefined acceptance criteria and verify that controls do not introduce new hazards or unacceptable side effects.
Test coverage is justified against requirements and risk rather than a single percentage
Review requirements coverage, risk-control coverage, code coverage where useful, interface combinations, data classes and unresolved gaps. A high line-coverage number alone does not demonstrate adequate testing.
Verification independence is proportionate to software safety risk
Define when reviewers or testers must be independent from implementation and prevent the same person from approving their own high-risk work without an effective independent check.
Known anomalies are documented and assessed before release
Record reproducibility, affected versions, safety and security impact, workaround, risk acceptability, planned correction and disclosure. Do not use a backlog label as a substitute for release assessment.
Validation uses the final or equivalent configuration in representative use conditions
Confirm intended users, workflows, hardware, operating systems, browsers, networks, data, interfaces, installation, cybersecurity controls and labelling before concluding that the product meets user needs and intended purpose.
A current SOUP and third-party component inventory exists
Record component name, supplier, exact version, function, licence, source, known anomalies, support status, safety or security relevance and the released products that use it.
Third-party components are evaluated before selection and update
Assess functionality, maturity, provenance, documentation, known vulnerabilities, maintenance, compatibility, licence obligations, replacement options and consequences of failure.
Vulnerability and end-of-support monitoring covers every relevant dependency
Use supplier notices, vulnerability databases and component inventories to identify affected versions, assess exploitability and safety impact, and trigger correction or documented acceptance.
External development and cloud-service agreements define measurable controls
Specify deliverables, change notification, incident reporting, uptime where safety-relevant, backup, data location, access control, audit rights, records, subcontracting, termination and continuity.
Training, validation and test datasets are governed where AI or statistical models are used
Document provenance, consent or lawful basis, inclusion and exclusion, labelling, reference standard, representativeness, quality checks, leakage prevention, versioning and separation of training, tuning and test sets.
Model performance is evaluated across clinically relevant subgroups and conditions
Predefine subgroup analyses, failure thresholds, uncertainty, bias controls, out-of-distribution behavior and human oversight. Aggregate performance must not hide unsafe subgroup performance.
Model, algorithm and third-party changes are versioned and treated as product changes
Control retraining, parameter changes, data updates, dependency upgrades and supplier releases through impact assessment, verification, clinical evaluation, regulatory review and deployment approval.
Configuration management uniquely identifies every released software item
Baseline source, requirements, architecture, dependencies, data or model, scripts, infrastructure configuration, labelling and test evidence under one controlled release identifier.
The build is automated or otherwise reproducible from an approved baseline
Control build instructions, tools, environment, dependencies, secrets, generated artefacts and checksums so an authorised person can reproduce and verify the release.
The released configuration record lists source, dependencies, data, model and infrastructure versions
Record source commit or tag, build tools, SOUP versions, configuration, model and dataset identifiers, deployment scripts, database schema, supported platforms and cryptographic hash where applicable.
Release criteria require complete evidence and formal authorisation
Confirm approved requirements, tests, risk controls, clinical and usability conclusions, anomaly assessment, cybersecurity review, technical documentation, labels, UDI and PRRC-related conformity checks.
Distribution prevents substitution or unauthorised modification
Use controlled repositories, signing, hashes, access control, app-store ownership, deployment logs and customer entitlement so the installed version can be authenticated.
Installation, update, migration, rollback and recovery are verified
Test supported upgrade paths, retained settings, database migration, interruption, failed update, rollback, compatibility and user instructions without assuming a clean installation.
Software versioning, UDI and supplied information remain aligned
Define major, minor, patch and build identifiers, explain which version is visible to users, assess when a new UDI-DI is required and keep the interface, IFU, declaration, certificate and registration data consistent.
A release evidence summary closes every requirement, risk control and unresolved anomaly
For the submitted version, identify final test reports, risk-control verification, usability and clinical conclusions, cybersecurity status, known anomalies, release approval and any justified open action.
A cybersecurity plan and threat model cover the complete product ecosystem
Identify assets, actors, attack surfaces, trust boundaries, credible threats, vulnerabilities, safety consequences, controls, verification, residual risk and post-market maintenance for the software and connected services.
Security requirements implement defence in depth and secure defaults
Address authentication, authorisation, least privilege, encryption, key management, integrity, session control, input validation, secrets, logging, update security, fail-safe behavior and recovery as applicable.
Security verification uses complementary methods
Combine code review, static and dynamic analysis, dependency scanning, configuration review, fuzzing or abuse testing, vulnerability scanning and penetration testing according to architecture and risk.
A software bill of materials supports vulnerability response
Maintain machine-readable or otherwise searchable component names, suppliers, versions and dependency relationships for each release and link findings to affected deployed versions.
A coordinated vulnerability disclosure and incident process is operational
Provide an intake route, acknowledgement, triage, safety and exploitability assessment, remediation targets, authority and customer communication, disclosure coordination and closure records.
Security updates are delivered through a controlled and verified mechanism
Define authenticity, integrity, compatibility, regression testing, urgency, deployment monitoring, rollback, user communication and support for users unable to update immediately.
Personal-data controls are distinguished from but coordinated with MDR safety controls
Where GDPR applies, document lawful basis, minimisation, purpose limitation, retention, data-subject handling, processors, transfers and breach processes without assuming that MDR conformity alone establishes data-protection compliance.
Supported hardware, operating systems, browsers and environments are controlled
Publish exact compatibility and minimum requirements, verify representative combinations and define monitoring, warning and response when a platform changes or reaches end of support.
Cloud responsibilities are divided explicitly between manufacturer and providers
Document who controls availability, security, patching, backup, monitoring, data location, incident response, subcontractors and evidence, while retaining manufacturer responsibility for device conformity.
Availability, latency, capacity and recovery targets reflect clinical risk
Define measurable limits, alarms, escalation and tested recovery objectives for services whose delay or loss could affect a medical decision or interrupt safe use.
Backup restoration and disaster recovery are tested
Verify backup integrity, restoration time, data consistency, configuration recovery, regional or supplier failure and continued complaint, vigilance and customer communication capability.
Operational logs and audit trails support safety investigation
Capture version, configuration, user or system action, input source, output, time synchronisation, errors and security events where necessary, with protected access and justified retention.
Interoperability and interface changes are detected and assessed
Monitor API, EHR, device, terminology, data-format and protocol changes; use contract or compatibility testing and prevent silent acceptance of incompatible or semantically changed data.
Customer configuration and remote service preserve the validated state
Define authorised settings, installation checks, remote-access controls, service records, customer responsibilities and when configuration requires additional validation or creates a product change.
The PMS plan names software-specific data sources, indicators and thresholds
Include complaints, support cases, incidents, version and exposure data, update success, uptime, errors, overrides, false results, literature, security findings, app-store feedback, PMCF and relevant competitor signals.
Exposure data allow rates to be calculated by version and use
Collect active installations or users, analyses, patients, sessions, clinical decisions or other justified denominators and distinguish current, superseded and unsupported versions.
Complaints, software problems and security reports enter one coordinated triage process
Prevent duplicate or fragmented assessment across helpdesk, engineering and regulatory teams and record awareness date, affected version, patient impact, reportability, investigation and closure.
Serious incidents, trend reports and FSCAs are decided and reported on time
Use documented MDR decision criteria, awareness dates, authority workflows and follow-up. A remote correction, configuration change or safety communication may be an FSCA even when no physical product is returned.
PMS and PMCF verify performance in real users, environments and subgroups
Define how post-market evidence confirms clinical performance, usability, interoperability and benefit-risk and detects dataset shift, new populations, automation bias or changed clinical practice.
The PMS report or PSUR updates the complete evidence system
Use the class-appropriate output and frequency and feed conclusions into risk management, clinical evaluation, PMCF, cybersecurity, requirements, CAPA, labelling and technical documentation.
Update support, end of life and supply-interruption communication are controlled
Define support periods, security maintenance, deprecation, customer migration, safe shutdown and Article 10a assessment where interruption or discontinuation could foreseeably cause serious harm.
Every change request states the problem, scope and affected released versions
Identify requested behavior, reason, urgency, dependencies, users, deployed population and whether the change corrects a defect, adds a claim, changes intended purpose or affects a risk control.
Change impact assessment covers the complete regulated evidence chain
Review classification, GSPRs, architecture, risk, usability, cybersecurity, clinical evidence, verification, validation, UDI, registrations, labelling, PMS and Notified Body notification before implementation.
Regression testing is selected from documented impact and risk
Test changed code and credible effects on interfaces, data, calculations, performance, security, installation and previously verified risk controls rather than repeating an arbitrary fixed suite.
Emergency patches retain approval, traceability and retrospective review
Define reduced but mandatory pre-release evidence, authorised risk acceptance, customer and authority communication, deployment monitoring and a deadline for full documentation and regression completion.
The technical-documentation revision record names every document affected by the change
Update the dossier index, device description, GSPR matrix, risk file, clinical evaluation, cybersecurity records, verification, supplied information, PMS documents and declarations as applicable.
Notified Body notification or approval requirements are assessed before deployment
Apply the certificate, QMS agreement and applicable change guidance. Record the decision and do not rely only on the engineering label assigned to the change.
A final submission review confirms completeness, consistency and readable evidence references
Check that approvals are present, links resolve, versions agree, confidential files are separated appropriately, requested formats are followed and no placeholder, draft or unresolved contradiction remains.
Open findings have owners, due dates, interim controls and a documented submission decision
Do not conceal incomplete evidence. State the gap, affected claims or risks, containment, completion plan and authorised rationale for submitting or withholding the dossier.
Clear the search or turn off the open-items filter.
Issue the review
Create a clean technical-documentation review report
The report excludes website navigation, guidance text, controls, empty project fields and empty comment boxes. In the print dialog, choose Save as PDF or select a printer.
Regulatory basis
Built around MDR Annexes II and III and software lifecycle evidence
The MDR is legally binding. Standards and MDCG guidance support implementation but do not replace product-specific legal, technical and clinical assessment. The exact evidence set must match the software, its class, claims, risks and deployment model.
Regulation (EU) 2017/745
Annexes I–III, Rule 11, clinical evaluation and post-market duties
MDCG 2019-11 Rev.1
Qualification and classification of medical device software
IEC 62304
Medical device software lifecycle processes
ISO 14971
Risk management throughout the medical-device lifecycle
MDCG 2019-16 Rev.1
Cybersecurity requirements and lifecycle controls
MDCG 2020-1
Clinical evaluation and performance evidence for medical device software
MDCG 2025-4
Safe making available of medical-device apps on online platforms
MDCG 2025-6
Interplay between the MDR, IVDR and Artificial Intelligence Act
