The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of healthcare products, has published detailed guidance dedicated to software validation. The document covers the most important aspects related to the general principles of software validation and also describes typical tasks supporting validation.
Table of Contents
It is important to mention that guidance documents issued by the FDA are non-binding in their legal nature and should be treated accordingly. In particular, they are intended to provide additional clarifications concerning applicable regulatory requirements, as well as recommendations to be taken into consideration by medical device manufacturers and other parties involved to achieve and sustain compliance thereto. Furthermore, the authority states that an alternative approach could be applied, provided such an approach complies with existing legislation and has been agreed with the authority in advance.
The present article describes the aspects related to specific tasks supporting software validations and related activities.
Design
As explained by the FDA, in the design process, the software requirements specification is translated into a logical and physical representation of the software to be implemented. The concept of software design specification stands for a description of a way the final product should operate when used for its intended purpose, including the details on its functionality and the particular way it should be implemented. As further explained in the guidance, the information contained in the design specification should be provided in two ways simultaneously: as a brief overview, and also in detail. The description contained in the software design specification should be sufficient for a developer to be able to follow it when creating the product without the need to make additional decisions on a case-by-case basis.
The authority additionally emphasizes the importance of considering human factors since numerous adverse events are resulting from inappropriate use of medical devices due to their complexity or unusual way of using them prescribed by manufacturers. Hence, the aspects associated with human factors should be taken into consideration at all the steps of the software design and development process to ensure the safety and effectiveness of the product when used for its intended purpose.
According to the guidance, the software design specification should include:
- Software requirements specification, including predetermined criteria for acceptance of the software;
- Software risk analysis;
- Development procedures and coding guidelines (or other programming procedures);
- System documentation (e.g., a narrative or a context diagram) that describes the context of the system in which the program is intended to function, including the relationship of hardware, software, and the physical environment;
- Hardware to be used;
- Parameters to be measured or recorded;
- Logical structure (including control logic) and logical processing steps (e.g., algorithms);
- Data structures and data flow diagrams;
- Definitions of variables (control and data) and description of where they are used;
- Error, alarm, and warning messages;
- Supporting software (e.g., operating systems, drivers, other application software);
- Communication links (links among internal modules of the software, links with the supporting software, links with the hardware, and links with the user);
- Security measures (both physical and logical security); and
- Any additional constraints not identified in the above elements.
The actual implementation of all the elements the software will contain should be based on the respective written procedure to be duly developed and implemented by the manufacturer. The authority also recommends indicating that some of the elements listed hereinabove are not applicable.
The software design process itself comprises numerous activities to be undertaken. For instance, the main purpose of a software design evaluation is to ensure the design is feasible and consistent. Another important aspect relates to the software architecture – it should be developed in a way ensuring that all necessary changes could be implemented without the need for significant efforts to be paid, should such changes be reasonably necessary at later stages. The medical device manufacturer (software developer) should also undertake the appropriate risk analysis to evaluate existing risks and hazards associated with the use of the software for its intended purpose, and also to evaluate new risks arising due to changes to the design.
The authority acknowledges that the software development process usually includes several iterations. Hence, version control is important to ensure traceability.
Hence, the typical tasks in the sphere of design include:
- Updated Software Risk Analysis,
- Traceability Analysis – Design Specification to Software Requirements (and vice versa),
- Software Design Evaluation,
- Design Communication Link Analysis,
- Module Test Plan Generation,
- Integration Test Plan Generation,
- Test Design Generation (module, integration, system, and acceptance).
Class I Software Medical Devices
Class I is the lowest class under the applicable classification system and applies to the devices with the lowest risk associated thereto. Hence, the applicable regulatory controls are quite low as well. In the case of software-based medical devices, this class applies for the devices that are:
- Intended to monitor the state or progression of a disease;
- Providing information that does not indicate if an individual may be in danger;
- Associated with a low public health risk.
Class IIa Software Medical Devices
This category applies to medical devices associated with medium risk. An example provided by the TGA describes diabetes diagnosis software that is intended to be used by a healthcare professional. Thus, such a product is a Class IIa medical device as the device provides information to a relevant health professional to inform the diagnosis of a serious disease. This category also covers risk prediction software, as well as the tools that record data from a patient monitor or images directly from an MRI scanner (provided that such software does not impact the operations of a scanner itself).
Class IIb Software Medical Devices
This category applies to medical devices associated with medium-high risk. For instance, such classification should be applied to a product that is intended to analyze a cardiac MRI in order to provide information used in making diagnoses of related diseases. As in the previous example, the software is intended to provide information to healthcare professionals only. As described in the guidance, Class IIb applies to medical software that is intended by the manufacturer (the software developer) to provide information to a relevant health professional to inform the diagnosis of a serious disease. Other examples of Class IIb products include tools intended to be used to diagnose an acute arterial occlusion due to the severity of potential consequences of this disease if the necessary treatment is not applied. This category also covers software products that are intended to provide recommendations for treatment or intervention on the basis of input data (e.g., a coronary angiogram). As in the previous cases, such software should be used only by healthcare professionals. Consequently, a Class IIb software-based medical device is the one that is intended to:
- Recommend a treatment or intervention to a relevant health professional for the purposes of making a decision about the treatment or intervention; and
- Be used in cases when the absence of a treatment or a treatment itself could result in severe health deterioration or other adverse consequences.
The same classification applies to wearable devices intended to collect and analyze data for screening for serious heart diseases, as well as questionnaire apps intended to analyze the information provided by a patient and provide a diagnostic output.
Coding or Construction
Another important aspect addressed in the guidance relates to coding or construction. In general, a new software product could be created in two ways:
- Coding, which stands for the implementation of a design specification as source code, provided the product is created from a scratch; and
- Construction, which is a process of creating a new product by assembling the elements that already exist.
The particular approach to be used should be determined based on the intended purpose of the future product, availability of resources, and functionality needed.
Coding itself, and additional processes associated thereto should be conducted under the respective written procedures to be developed and implemented by medical device manufacturers (software developers) engaged in the creation of such products.
When describing the processes associated with coding and construction, the guidance addresses the most important aspects associated thereto, such as debugging the code, compilation, source code evaluation, as well as documenting these processes. The guidance also pays special attention to a source code traceability analysis to be performed to ensure that software design specification has been duly implemented, and all the elements could be traced back to source code.
The typical tasks related to coding or construction include the following ones:
- Traceability Analysis,
- Source Code to Design Specification (and vice versa),
- Test Cases to Source Code and Design Specification,
- Source Code and Source Code Documentation Evaluation,
- Source Code Interface Analysis,
- Test Procedure and Test Case Generation (module, integration, system, and acceptance).
In summary, the present FDA guidance highlights the most important aspects associated with the particular actions to be undertaken by medical device manufacturers (software developers) concerning software design and coding processes. The document describes in detail the typical tasks associated with each of the aforementioned processes and outlines the key points to be taken into consideration.
Sources:
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
