What the documentation of medical device software has to show
A software device's documentation runs from the declaration of conformity and the technical documentation its risk class requires to the clinical evidence that the software's output means what it is claimed to mean, and a health app has data protection to meet as well.
What the risk class sets
The extent of the activities required for regulatory compliance depends on the software's risk class, which is attributed under the classification rules and dictates the requirements for certification. Under the EU Medical Device Regulation (MDR), these requirements include a declaration of conformity to the general safety and performance requirements (GSPR), technical documentation, verification, validation, pre-clinical and clinical evaluation, usability, risk management, vigilance reporting, data integrity, information security and, where the conformity assessment route requires it, the involvement of a notified body. Software the MDR defines as a device may be placed on the EU market only once it has been shown to meet the GSPR and it carries the CE mark.
For software in any risk class above class I, a notified body must be involved in conformity assessment. For classes IIa, IIb and III, several conformity routes involving assessment by a notified body are open, depending on the manufacturer's decision.
When the software is designed to drive or influence another medical device, the compliance requirements are assessed within the intended purpose of the driven device, not of the software.
The regulations and standards that apply
The regulations and standards that apply to software as a medical device in the EU and the US are these:
| EU (European Commission) | US (FDA) | |
|---|---|---|
| Regulations | EU MDR 2017/745; Regulation (EU) 2016/679 (GDPR) | 21 CFR |
| Standards cited | ISO 13485; IEC 62304; IEC 60601; IEC 82304-1 | AAMI TIR 45:2012; GAMP 5 (software validation) |
| Definitions | EU MDR 2017/745 | IMDRF/SaMD WG/N10:2013 |
| Risk classification | I, Im, IIa, IIb, III | I, II, III; IMDRF/SaMD WG/N12:2014 |
| Product approval | Im, IIa, IIb, III: EC certificate under the MDR issued by an EU notified body | II, III: FDA approval through premarket approval (PMA) or 510(k) |
| Certificate validity | At most 5 years | – |
| Quality management system and standards | ISO 13485; ISO 14971; IEC 62304 | 21 CFR 820 (Quality System Regulation); 21 CFR 810 and 830; 21 CFR 803; 21 CFR 806 |
| Clinical evaluation | ISO 14155 (clinical investigations) | Investigational device exemption (IDE) and institutional review board (IRB): 21 CFR Parts 812, 50, 56, 54 and 820; IMDRF/SaMD WG/N41:2017 |
| Data protection | Regulation (EU) 2016/679 (GDPR) | HIPAA; Federal Trade Commission Health Breach Notification Rule |
The applicable regulations, guidance and standards are subject to change, and current information should always be checked.
Software requirements and the quality management system
Paragraph 17.1 of the GSPR introduces a new requirement that software ensure repeatability, reliability and performance in line with its intended use, and eliminate or reduce as far as possible the risks in the case of a single fault condition. It is coupled with the requirements already defined in the Medical Device Directive: development and manufacture according to the state of the art, taking account of the principles of the development lifecycle, risk management including information security, and verification and validation. A quality management system generally addresses these requirements, so implementing a suitable one is a prerequisite for compliance with the MDR. International standards such as ISO 13485, ISO 14971 and IEC 62304 should be considered in establishing it. Manufacturers need to follow relevant standards such as IEC 62304, which sets out a best-practice framework for software development, including cybersecurity management and the corresponding documentation based on the software safety classification.
Clinical evidence
Software as a medical device can best be described as software that uses an algorithm, whether logic, a set of rules or a model, that operates on data input, that is digitised content, to produce an output intended for the medical purposes its manufacturer defines. The risks and benefits of its output relate largely to the risk that the output is inaccurate or incorrect, which may affect a patient's clinical management.
Pre-clinical and clinical data under the MDR
MDR Annex II sets out the requirements for pre-clinical and clinical data for devices, including software. Documents giving the tests, the generated data and the conclusions that demonstrate the software's pre-clinical safety are required. The software verification and validation should describe the software's design and development process, provide evidence of its validation, and include testing performed both in-house and in a simulated or actual user environment before final release.
MDCG 2020-1, the guidance on the clinical evaluation of medical device software, sets out the definitions of clinical benefit and clinical evidence for such software. This guidance recommends specific sections for that evaluation, built around technical performance, clinical performance and valid clinical association, and it gives examples and recommendations for how the evidence behind each can be shown, what to put in the clinical evaluation report for software, and how to establish the relationship to the state of the art. One practitioner finds this guidance very helpful for its hands-on examples, and recommends it over the MDCG guidance on classification, finding that it reads much better.
The IMDRF's clinical evaluation
IMDRF/SaMD WG/N41FINAL:2017, the IMDRF's guidance on the clinical evaluation of software as a medical device, sets out how developers and manufacturers should evaluate software from a clinical standpoint to establish:
- that there is a valid clinical association between the software's output and the targeted clinical condition, including a pathological process or state
- that the software provides the expected technical and clinical data
A valid clinical association indicates the level of clinical acceptance, and how much meaning and confidence can be assigned to the clinical significance of the output in the intended healthcare situation and the clinical condition or physiological state.
Analytical validation measures the software's ability to generate the intended technical output from the input data accurately, reliably and precisely. It confirms, with objective evidence, that the software was correctly constructed, correctly and reliably processing input data and generating output data with the appropriate level of accuracy, repeatability and reproducibility, and it demonstrates that the software meets its specifications and that those specifications conform to user needs and intended uses. The manufacturer generally evaluates and determines it during the verification and validation phase of the software development lifecycle, using a quality management system.
The manufacturer uses a definition statement for the software, as defined in the IMDRF's N12 guidance, to identify its intended medical purpose (treat, diagnose, drive clinical management or inform clinical management), to state the healthcare situation or condition it is intended for (critical, serious or non-serious), and to describe its core functionality. Clinical validation, the third requirement, measures the software's ability to yield a clinically meaningful output associated with the target use of that output in the target healthcare situation or condition identified in the software's definition statement. "Clinically meaningful" refers to the positive impact of the software on the health of an individual or population, to be specified as meaningful, measurable, patient-relevant clinical outcomes, including outcomes related to the software's function such as diagnosis, treatment, prediction of risk or prediction of treatment response, or as a positive impact on individual or public health. Clinical validation can also be viewed as the relationship between the verification and validation results of the software's algorithm and the clinical conditions of interest. The manufacturer evaluates and determines clinical validity during development, before the software is distributed for use, and after distribution, while it is in use.
Clinical validation is a necessary component of the clinical evaluation of all software as a medical device. It can be demonstrated by any one of these:
- referencing existing data from studies conducted for the same intended use
- referencing existing data from studies for a different intended use, where extrapolation of such data can be justified
- generating new clinical data for a specific intended use
The rigour needed to meet these clinical evaluation requirements is outlined in IMDRF/SaMD WG/N12FINAL:2014, and it rests on the state of the healthcare situation or condition and on the significance of the information the software provides to the healthcare decision.
Post-market clinical data
IEC 62304 focuses on risk management over the product's lifecycle, and it is closely intertwined with clinical evidence in the form of the data on the application's safety and performance accumulated through post-market monitoring. The lifecycle requirements of IEC 62304 highlight the importance of continuous monitoring, hazard identification and corrective action as a source of clinically relevant evidence, which intersects with the post-market follow-up requirements in MDR Annex III. IEC 62304 recognises that hardware platforms evolve and that the software is refined to maintain and improve both its performance and the clinically meaningful measures it produces. By recording, assessing and integrating data from clinical use into the software's algorithms, post-market clinical data become part of a total product lifecycle approach that the FDA and the IMDRF both advocate.
Data protection
For a mobile health app, compliance with the General Data Protection Regulation (GDPR) is highly relevant alongside compliance with the MDR, and it will remain an important consideration in future software development. The GDPR applies to companies anywhere in the world that process the personal data of people living in the EU, and to EU-based companies that process personal data, whoever the data belong to. Anonymisation where possible, or pseudonymisation, of patient data, with satisfactory encryption, must be considered for MDR activities such as post-market surveillance, the manipulation, transfer, storage and deletion of clinical data, safety and performance requirements, and the transparency and traceability of devices. The GDPR's data-protection requirements are much stricter than those in the MDR or in the software regulations of the US and the IMDRF countries, which focus primarily on cybersecurity protection.
The medical writer's part
Medical writers will play an important role in supporting the preparation of the regulatory documentation that certification under the MDR requires. Presenting the clinical evidence is an important part of a medical writer's role in supporting conformity assessments. It includes demonstrating a scientifically robust clinical association, validating the software's ability to generate a clinically meaningful output measure, and verifying critically that this output is accurate, reliable and reproducible. A medical writer can support the required documentation in particular by assessing the clinical evidence and the verification and validation of the software with a clinical association. For a mobile health app, data sources include descriptions on mobile marketplaces, in some cases with specific guidelines for medical apps on privacy, claims, data and methodology. In one practitioner's experience, teams look to medical writers for guidance and hands-on examples of clinical evaluation protocols.
It is not unusual for manufacturers to create the software before having any documentation of its development, and to try to avoid regulatory processes for it. Developers of medical applications sometimes have little or no formal medical training and do not involve physicians in the process, and they may sometimes even forget the medical purpose while defining their device's intended purpose. Such communication gaps may be an opportunity for medical writers to apply their skills to provide documentation and clarity in the regulatory processes for the software.