What belongs in the technical documentation of medical software?

The file must make the product reconstructable

Annex II of Regulation (EU) 2017/745 divides the technical documentation into six main areas. It requires product description and specification, manufacturer information, development and manufacturing details, proof of fundamental safety and performance requirements, benefit-risk analysis with risk management, as well as verification and validation. Annex III additionally requires technical documentation for post-market surveillance.

For medical software, neither a requirements specification nor a folder with test protocols is sufficient. The documents must form a consistent path from intended purpose and classification through risks and requirements to evidence.

Typical components for software

A robust documentation includes in particular:

• clear product and version description, variants, modules, accessories, and intended system environment,
• medical intended purpose, users, patient groups, indications, contraindications, and foreseeable misuse,
• classification justification according to MDR Annex VIII,
• software requirements, architecture, interfaces, data flows, and utilized third-party software,
• development and maintenance plan according to IEC 62304:2006+A1:2015,
• risk file according to ISO 14971:2019 linked to requirements and tests,
• usability file according to IEC 62366-1:2015+A1:2020,
• cybersecurity concept including threat model, secure configuration, update path, and relevant software components,
• test plans, results, and traceability for unit, integration, system, regression, and release tests,
• clinical evaluation plan and clinical evaluation report,
• labeling, user manual, and installation or operational requirements,
• PMS plan, if applicable PMCF documents and procedures for vigilance as well as safety corrections in the field.

MDR Annex II number 6.1(b) explicitly states for software the description of design and development as well as evidence of verification and validation in the finished product configuration. This includes summarized results of internal tests and examinations in simulated or actual use environments prior to final release.

A living, version-bound system

Documents must not contradict each other. For example, if an algorithm changes, the intended purpose, risk assessment, clinical evidence, cybersecurity, tests, UDI impact, and user information must be reviewed together. Baselines and configuration management must show which requirements, components, and evidence belong to a released version.

Annex II and III define the regulatory content, not a specific file format. An electronic document management system is suitable if approvals, versions, changes, and links remain traceable in a revision-proof manner. The scope and depth depend on the product, risk class, and intended purpose; a universal template folder does not replace this justification.