Medical device validation using QPack
Medical device software validation
Developing medical device is a complex process that must be submitted to the strict regulations of the FDA. As a result of this complexity, routine end-product testing alone is often not sufficient to assure product quality. Some end-product tests have limited sensitivity, sometimes destructive testing is required to show that the process is adequate and in certain situations end-product testing does not reveal variations that may occur in the product which may impact safety and effectiveness.
The FDA believes through careful design and validation of both the process and process controls, a medical device manufacturer can establish a higher degree of confidence. Successfully validating a process will reduce the dependence upon intensive in-process and finished product testing. To learn more about the FDA software validation, you can review General Principles of Software Validation; Final Guidance for Industry and FDA Staff:
"Software validation is a critical tool used to assure the quality of device software and software automated operations. Software validation can increase the usability and reliability of the device, resulting in decreased failure rates, fewer recalls and corrective actions, less risk to patients and users, and reduced liability to device manufacturers. Software validation can also reduce long term costs by making it easier and less costly to reliably modify software and revalidate software changes. Software maintenance can represent a very large percentage of the total cost of software over its entire life cycle. An established comprehensive software validation process helps to reduce the long-term cost of software by reducing the cost of validation for each subsequent release of the software."
QPack validation module for medical device is designed to meet FDA's Quality System validation requirements such as those in regulatory affairs, quality assurance, process development or manufacturing.
QPack validation module provides tools for process validation that comply with FDA regulations.
As described in the General Principles of Software Validation; Final Guidance for Industry and FDA Staff, QPack supply the tools to comply with the guideline, described in the following section (chapter 4):
A documented software requirements specification provides a baseline for both validation and verification. The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).
Software quality assurance needs to focus on preventing the introduction of defects into the software development process and not on trying to "test quality into" the software code after it is written. Software testing is very limited in its ability to surface all latent defects in software code. For example, the complexity of most software prevents it from being exhaustively tested. Software testing is a necessary activity. However, in most cases software testing by itself is not sufficient to establish confidence that the software is fit for its intended use. In order to establish that confidence, software developers should use a mixture of methods and techniques to prevent software errors and to detect software errors that do occur. The "best mix" of methods depends on many factors including the development environment, application, size of project, language, and risk.
To build a case that the software is validated requires time and effort. Preparation for software validation should begin early, i.e., during design and development planning and design input. The final conclusion that the software is validated should be based on evidence collected from planned efforts conducted throughout the software lifecycle.
Software validation takes place within the environment of an established software life cycle. The software life cycle contains software engineering tasks and documentation necessary to support the software validation effort. In addition, the software life cycle contains specific verification and validation tasks that are appropriate for the intended use of the software. This guidance does not recommend any particular life cycle models - only that they should be selected and used for a software development project.
The software validation process is defined and controlled through the use of a plan. The software validation plan defines "what" is to be accomplished through the software validation effort. Software validation plans are a significant quality system tool. Software validation plans specify areas such as scope, approach, resources, schedules and the types and extent of activities, tasks, and work items.
The software validation process is executed through the use of procedures. These procedures establish "how" to conduct the software validation effort. The procedures should identify the specific actions or sequence of actions that must be taken to complete individual validation activities, tasks, and work items.
4.7. SOFTWARE VALIDATION AFTER A CHANGE
Due to the complexity of software, a seemingly small local change may have a significant global system impact. When any change (even a small change) is made to the software, the validation status of the software needs to be re-established. Whenever software is changed, a validation analysis should be conducted not just for validation of the individual change, but also to determine the extent and impact of that change on the entire software system. Based on this analysis, the software developer should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Design controls and appropriate regression testing provide the confidence that the software is validated after a software change.
Validation coverage should be based on the software's complexity and safety risk - not on firm size or resource constraints. The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use. For lower risk devices, only baseline validation activities may be conducted. As the risk increases additional validation activities should be added to cover the additional risk. Validation documentation should be sufficient to demonstrate that all software validation plans and procedures have been completed successfully.
Validation activities should be conducted using the basic quality assurance precept of "independence of review." Self-validation is extremely difficult. When possible, an independent evaluation is always better, especially for higher risk applications. Some firms contract out for a third-party independent verification and validation, but this solution may not always be feasible. Another approach is to assign internal staff members that are not involved in a particular design or its implementation, but who have sufficient knowledge to evaluate the project and conduct the verification and validation activities. Smaller firms may need to be creative in how tasks are organized and assigned in order to maintain internal independence of review.
4.10. FLEXIBILITY AND RESPONSIBILITY
Specific implementation of these software validation principles may be quite different from one application to another. The device manufacturer has flexibility in choosing how to apply these validation principles, but retains ultimate responsibility for demonstrating that the software has been validated.
Software is designed, developed, validated, and regulated in a wide spectrum of environments, and for a wide variety of devices with varying levels of risk. FDA regulated medical device applications include software that:
- Is a component, part, or accessory of a medical device;
- Is itself a medical device; or
- Is used in manufacturing, design and development, or other parts of the quality system.
In each environment, software components from many sources may be used to create the application (e.g., in-house developed software, off-the-shelf software, contract software, shareware). In addition, software components come in many different forms (e.g., application software, operating systems, compilers, debuggers, configuration management tools, and many more). The validation of software in these environments can be a complex undertaking; therefore, it is appropriate that all of these software validation principles be considered when designing the software validation process. The resultant software validation process should be commensurate with the safety risk associated with the system, device, or process.
Software validation activities and tasks may be dispersed, occurring at different locations and being conducted by different organizations. However, regardless of the distribution of tasks, contractual relations, source of components, or the development environment, the device manufacturer or specification developer retains ultimate responsibility for ensuring that the software is validated.
So, how does QPack supports these guidelines?
QPack supports any development lifecycle method, and supports all kinds of ALM activities such as requirements, development tasks, unit tests, QA activities and tasks, such as test cases, test scripts, defects and test execution sets. The system admin can define the relevant process and work procedure in the system to comply with organization working methodologies.
QPack manages the full software lifecycle process (ALM), thus allows QA team to start activities early in the process, right when requirements are defined. The work procedures are also defined early in the development phase, and control all development phases.
QPack requirements definition module provides a professional tool designed to gather requirements and trace them later on.
QPack provides a testing module that allows the QA team to implement testing methods and procedures in a controlled and structured way. The use of testing tool, that relates every test with the relevant requirement, assures product quality.
The reporting and analytic tools allow users to trace coverage of requirements by tests, and measure product quality in terms of tests, defects with low/high priority, active/completed tasks and more.
The internal discussion forum allows every member in the development process to remark and comment on each activity.