Risk is a fairly well-known term in the medical device industry; it is defined and measured by the combination of the probability of the occurrence of harm and the severity of that harm to the patient, operator, or others situated with the device. Therefore, the higher the probability of harm occurring and the more severe the consequences, the higher the risk will be. To mitigate or reduce risk, device manufacturers need to put in place controls to minimise the probability of the occurrence of harm and also limit its consequences. This sounds simple. In reality, the effectiveness of controlling risk is also a function of cost, which device manufacturers must consider in their efforts to successfully compete in the market.
The LDRA tool suite is the premier choice for building quality into the software used in medical devices. Many medical devices have achieved their software quality objectives with the aid of the LDRA tool suite.
Whenever a medical device is developed that includes software as a design component, the safety of patients and practitioners are factors in the development of the system. To this end, the U.S. Department of Health and Human Services Food and Drug Administration (FDA) has established various procedures to certify that the medical devices meet their safety critical objectives.
Medical devices are regulated by the FDA's Center for Devices and Radiological Health (CDRH), who must approve a medical device prior to its distribution and usage. The whole device must be submitted for approval, and in addition the software must be validated per the guidelines in the publication General Principles of Software Validation; Final Guidance for Industry and FDA Staff (January 11, 2002).(FDA Guidelines). The scope of these guidelines is somewhat broader than the strictest definition of validation, and includes all of the aspects of good software engineering, including planning, verification, testing, traceability and configuration management.
Medical devices are assigned a classification as a Class I, II or III device, dependent on the risk that the device poses to the patient and/or user. Class I includes devices with the lowest risk and Class III includes those with the greatest risk. Regulatory control increases from Class I to Class III. The device classification regulation defines the regulatory requirements for a general device type.
The FDA Guidelines document is fundamentally a process document; defining the key elements required for the development of software for medical devices, including safety critical software. The LDRA tool suite is the most complete software validation solution for the development of medical device software, supporting the entire FDA Guidelines process from requirements through to deployment, helping to eliminate or reduce labour intensive and error prone elements of the process:
1. Requirements Traceability - The FDA Guidelines advocate a requirements driven process, whereby all components of the deployed software are traceable to the original high level requirements, resulting in 100% Requirements Test Coverage and a requirements traceability matrix. TBreq is the only Requirements Traceability solution supporting the tracing of requirements throughout the entire development process. Using TBreq, requirements are traced from system level through to individual software components, including tracing the verification artifacts such as test cases and structural coverage analysis data that were generated to validate test completion and completeness. TBreq then provides the Requirements-Based Test Coverage Analysis required by the FDA Guidelines and automatically generates a requirements traceability matrix.
2. Code Inspections - Recognised by the FDA Guidelines as a very effective means to detect errors before the execution of code, the use of static analysis is advocated for code inspections and for enforcing adherence to a coding standard. The LDRA Testbed product static analysis capabilities can be used to identify latent defects in code, and to enforce coding standards compliance. In addition, it can also be used to create a custom coding standard, for which the multiple built-in coding standards can be used as a reference.
3. Software Testing - Testing as early in the development lifecycle as feasibly possible is advocated by the FDA Guidelines, starting with rigorous unit testing. The TBrun product excels when it comes to this arena, enabling the generation of requirements driven tests, and their maintenance for regression test purposes. In addition, the TBeXtreme product provides automated test case generation that helps minimise developers overhead when maximizing the code covered by unit testing. This helps to improve code quality while alleviating the onerous nature and inherent inaccuracies prevalent in a manual unit testing process.
4. Structural Coverage Analysis - System tests must be created against the system level requirements, and then the FDA Guidelines states that coverage analysis can be used to assess the test effectiveness and to ensure that 100% of the software code structure is exercised. The coverage analysis level required for a system should be commensurate with the level of risk posed by the software. The LDRA Testbed product saves endless hours of using a highlighter pen to identify tested and untested code by providing automated coverage analysis measurement for the coverage metrics advocated by the FDA Guidelines.
5. Object Code Coverage - For the most safety critical software, analysis at the high level language may not be enough. It is also necessary to guarantee that 100% of the object code produced by the compiler is also exercised. The LDRA Testbed Object Box coverage module enables the automated measurement of object code coverage, helping to ensure that all of the compiler generated code is exercised.
6. Tool Qualification - Before submitting Structural Coverage Analysis results from a tool to be as system validation data, it is often prudent to adopt a tool qualification process that verifies that the tool provides confidence at least equivalent to that of the process(es) eliminated. LDRA provides a Tool Qualification Support Package that includes documentation and test procedures required to ensure that LDRA Testbed can be qualified in a customers environment.
7. Secure Code - With the increase in the number of networked medical devices, the FDA is ramping up their awareness of the need for CyberSecurity, including releasing a reminder in November 2009 that it CyberSecurity is a shared responsibility between medical device manufacturers and medical device user facilities. The LDRA Testbed coding standards capability provides the ability to assess code against the CERT-C secure coding standard, ensuring that deployed medical devices meets the highest secure standards.