Technical Documentation (TD)
This compliance category contains requirements concerning the technical documentation that must be recorded and published for FDA AI based SaMD.
According to the IMDRF/SaMD N23:
A systematic documentation of the SaMD and its supporting design and development, including a robust and documented configuration and change management process, is necessary to identify its constituent parts, to provide a history of changes made to it, and to enable recovery/recreation of past versions of the software, i.e., traceability of the SaMD.
Records are used to provide evidence of results achieved or activities performed as a part of the QMS or SaMD lifecycle processes as well as justifications for any QMS or SaMD lifecycle processes not performed. Records can be in paper or electronic form.
For SaMD lifecycle processes, document control and records management makes it easier for the users of those documents and records, both within and outside (outsourced contractors, customers, etc.) the organization, to share and collaborate in the many activities related to the SaMD lifecycle processes. Document control and records management also serves to help communicate and preserve the rationale for why certain decisions were made, such as those related to patient safety or risk management.
Records generated to demonstrate QMS conformity should be appropriately identified, stored, protected, and retained for an established period of time. The following activities are examples of ways to manage and maintain appropriate documentation in the QMS system:
Reviewing and approving documents before use;
Ensuring current versions of applicable documents are available at points of use to help
prevent the use of obsolete documents;
Retaining obsolete documentation for an established period;
Controlling documents against unauthorized or unintended changes; and
Maintaining and updating documents across all SaMD lifecycle processes.
Example: In the cases of Magna and Parva, it is important to manage and control documentation throughout the SaMD lifecycle processes. Documentation does not mean bureaucracy; rather, it is the foundation to drive traceability, repeatability, scalability, and reliability in SaMD projects. Magna uses established documentation processes and techniques that include the use of a commercially available requirements management tool throughout the SaMD lifecycle processes. Parva has re-purposed its source-code control software to enable the company to manage its documentation in a controlled way.
Furthermore, this compliance category covers in large part the following sections from IMDRF/SaMD:
7.3 -- Document Control and Records
8.1 -- Requirements Management
8.2 -- Design
8.3 -- Deployment
8.4 -- Verification and Validation
In part, this compliance category also covers the following guiding principles from FDA GMLP:
Principle 1. Multi-Disciplinary Expertise Is Leveraged Throughout the Total Product Life Cycle: In-depth understanding of a model’s intended integration into clinical workflow, and the desired benefits and associated patient risks, can help ensure that ML-enabled medical devices are safe and effective and address clinically meaningful needs over the lifecycle of the device.
Principle 2. Good Software Engineering and Security Practices Are Implemented: Model design is implemented with attention to the “fundamentals”: good software engineering practices, data quality assurance, data management, and robust cybersecurity practices. These practices include methodical risk management and design process that can appropriately capture and communicate design, implementation, and risk management decisions and rationale, as well as ensure data authenticity and integrity.
Principle 3. Clinical Study Participants and Data Sets Are Representative of the Intended Patient Population: Data collection protocols should ensure that the relevant characteristics of the intended patient population (for example, in terms of age, gender, sex, race, and ethnicity), use, and measurement inputs are sufficiently represented in a sample of adequate size in the clinical study and training and test datasets, so that results can be reasonably generalized to the population of interest. This is important to manage any bias, promote appropriate and generalizable performance across the intended patient population, assess usability, and identify circumstances where the model may underperform.
Principle 6. Model Design Is Tailored to the Available Data and Reflects the Intended Use of the Device: Model design is suited to the available data and supports the active mitigation of known risks, like overfitting, performance degradation, and security risks. The clinical benefits and risks related to the product are well understood, used to derive clinically meaningful performance goals for testing, and support that the product can safely and effectively achieve its intended use. Considerations include the impact of both global and local performance and uncertainty/variability in the device inputs, outputs, intended patient populations, and clinical use conditions.
Principle 10. Deployed Models Are Monitored for Performance and Re-training Risks Are Managed: Deployed models have the capability to be monitored in “real world” use with a focus on maintained or improved safety and performance. Additionally, when models are periodically or continually trained after deployment, there are appropriate controls in place to manage risks of overfitting, unintended bias, or degradation of the model (for example, dataset drift) that may impact the safety and performance of the model as it is used by the Human-AI team.
Below is the list of the controls that are part of this compliance category:
Last updated