Integrating requirements traceability with legacy and third-party software is a key to device success.
Editor’s note: This is a two-part article. Part 1 focused on the software development.
IEC 62304 focuses on the software development process, defining the majority of the software development and verification activities. This standard outlines requirements at each stage of the development lifecycle and defines the minimum activities and tasks to be performed to provide confidence that the software has been developed in a manner that’s likely to produce highly reliable and safe software products.
Similar to other industry-specific safety standards, requirement management is fundamental for all medical-device software development. An established, verifiable requirement is essential for defining what is to be built, determining that the medical device software exhibits acceptable behaviour, and demonstrating that the completed device software is ready for use. Medical devices often implement third-party software to gain specific capabilities such as Internet connectivity, USB communication, or file management without requiring the application developers to create the software needed to provide such functionality from scratch.
The use of software of unknown pedigree (SOUP) items therefore saves a considerable amount of time in the software development process. While IEC 62304 doesn’t discourage using SOUP items, the standard provides a process for ensuring that additional risk isn’t added to the system because of their use.
Since the medical device manufacturer identifies the SOUP items used in the system, detailed requirements of these items are defined, including the functional, performance, and safety requirements necessary for the safe operation of the device. The SOUP item delivered by the third-party must then be verified to meet these requirements. However, under IEC 62304, subjecting the SOUP item for functional test alone isn’t sufficient. A detailed structural coverage of the SOUP items is also mandated by IEC 62304 to determine that there are no unexercised paths with its functionality intact. A SOUP item must also be verified to satisfy the safety requirements and to confirm that it doesn’t cause a hazard or create a risk within a system.
This is where requirement traceability helps as it ensures that all requirements are implemented and the code is verified, and that all SOUP artifacts can be traced back to one or more requirements. Requirement traceability also helps to trace the defects identified during verification and tracks software modifications or patches inserted to address these defects.
The Requirement Traceability Matrix (RTM)—a widely accepted practice to manage and trace requirements—plays a vital role in managing the software requirements as well as the SOUP items to be used in the system. The RTM helps to establish traceability between the high-level requirements pertaining to SOUP items with the architectural design. In the RTM, the manufacturer specifies:
In most cases, the SOUP items are delivered in source, but without design documents, which makes them difficult to analyse. The use of modern test tools may help this process by providing visualization of the legacy code design as illustrated (see Figure 1).
Figure 1. The static call graph and flow graph represent the structure and the logic of the code in graphical form.
The system visualization facilities provided by modern test tools are extremely powerful, whether applied to statement blocks, procedures (or classes), applications, and/or the system as a whole. Static call graphs provide a hierarchical illustration of the application and system entities, and static flow graphs show the control flow across program blocks. Color-coded diagrams provide considerable benefit in understanding the structure of SOUP items. Such call and flow graphs are just part of the benefit of the comprehensive analysis of all parameters and data objects used in the code.
Requirement management and traceability have already proven their advantage in software development lifecycle to ensure that all requirements are implemented and that all development artifacts can be traced back to one or more requirements. Similarly, requirement management and traceability ensure that SOUP items are added and implemented based on system requirements.
Figure 2. The requirements traceability matrix (RTM) plays a central role in a development lifecycle model even when SOUP items are part of the system. Artefacts at all stages are linked directly to requirements matrix and changes within each phase automatically update the RTM.
The RTM provides traceability between the architectural design and the SOUP items. Since these items are delivered in source code, it becomes the manufacturers’ responsibility to verify the code and ensure that compliance to a specific coding standard is met.
It’s generally the case that SOUP items are developed under production pressure, not to adhere to more demanding standards. While this means that code can be written to a specific schedule, it adds stress to the requirement of rigorous verification and risk analysis of the SOUP items for the system integrator since verifying the legacy code to comply with a coding standard is time consuming. Because of this, developers typically address a subset of the coding standard initially, then gradually adopt additional rules. Note that test tools applied to the code only identify the violation and latent errors present in the legacy code; they can’t correct the code. Instead, they enable the code correction to follow coding standards as efficiently as possible.
IEC 62304 expects the manufacturer to evaluate the anomaly lists published by the SOUP item’s supplier to determine if any of the known anomalies could result in a sequence of events that could result in a hazardous situation. The RTM helps to ensure that the dynamic analysis (including system, integration, and unit testing) are performed to verify the functional and structural coverage of the SOUP items. It also helps to ensure the system functions per the design, even with the introduction of the SOUP items.
SOUP items are integrated with other software units and verified to make sure that the system functionality isn’t hampered with this additional software. According to IEC 62304, verifying the SOUP items is to be carried out based on the integration plan made during the software planning.
Although system-wide functional testing provides the functional overview of the SOUP items, this won’t test all code paths. It does, however, provide a logical place to start deeper code analysis. Test tools identify the exercised parts of the software and highlight the areas still requiring attention. These areas are then sent for unit test to ensure that each unit functions correctly in isolation. Test tools identify the unexercised code paths and makes sure they aren’t carried forward into the field and hence help to avoid unexpected product behaviour.
Running functional tests and structural coverage analysis during integration ensures that all code paths are exercised and the interfaces between multiple units are verified. The RTM provides traceability between these tests and various other analysis performed on SOUP items against the test plan established earlier. This plan contains test cases to be carried out and their expected results based on the system requirement. Using the RTM, project managers can estimate the impact of SOUP items to be incorporated and how they might affect the system’s safety.
Many incidents in the medical device industry are related to service or maintenance of medical device systems, including inappropriate software updates and upgrades. SOUP items play a key role here since these items are delivered by different vendors and need to be verified. The software maintenance process is considered as important as the software development process. The IEC 62304 standard hopes to curb the high percentage of medical device software defects introduced after a product is released (i.e., during software maintenance).
The maintenance process requires that the manufacturer monitor the feedback of the released product from both within the organization and from the user. This feedback must be documented and analyzed to determine whether a problem exists. When a problem is found, a report is created and analysed to determine whether SOUP items contributed to the problem. If a SOUP item is identified as contributing to a problem, the issue has to be conveyed to the respective vendor to address the problem with upgrades or patches.
IEC 62304 requires the manufacturer to establish procedures to evaluate and implement upgrades, bug-fix patches, and obsolescence of SOUP items. Each upgrade, fix, and patch must be analysed and verified to determine whether additional potential causes are introduced by these upgrades, contributing to a hazardous situation. As always, it’s necessary to determine whether additional software risk control measures are required.
During maintenance, the manufacturer is required to analyse changes to the SOUP items to determine whether the software modification could interfere with the existing risk control measures. The manufacturer must establish a scheme for the unique identification of configuration items and their versions. For each SOUP configuration item being used, the manufacturer must document the title, SOUP maker name, and unique SOUP designator. This identifies the specific software configuration items and the versions included in the software.
Use of SOUP is unavoidable since medical devices have become increasingly complex. To meet time to market, manufacturers need to take advantage of system functionality that’s readily available and not unique to the application. Using such modules lets the manufacturer focus on core device functionality and increases the likelihood of meeting the delivery schedule and avoiding budget overruns. This efficiency, however, comes at a price as third-party vendors may not follow any specific software-development process and/or standard.
Adopting IEC 62304 as a process for medical device software development and following the guidelines for incorporating SOUP items helps verify the functionality and structural coverage of the code and ensures that the risk of adding and using SOUP items is minimized. Such a process establishes quality practises that safeguard the medical device and forces SOUP items to meet the software requirements and provide complete traceability at the various stages of the software development lifecycle. Use of qualified and well integrated tools ensures that the developers can automate the necessary processes more easily and efficiently.
By adopting the quality software processes of IEC 62304, companies are better able to develop a safe product, avoid expensive recalls, and ensure that the same development process underpins the maintenance and upgrade process. The manufacturer’s ROI is achieved rapidly along with improved credibility and reputation.
Companies adopting the IEC 62304 process increase their ability to develop medical software safely and to produce high-quality devices for the medical community who can then use them to diagnose with ease and accuracy to the obvious benefit of their patients.Anil Kumar is a technical consultant with LDRA in India, specialising in the development, integration and certification of mission- and safety-critical systems. With a solid background in development tools and real-time operating systems, Anil guides organizations in selecting, integrating and supporting their real-time embedded systems from development through to certification. Mark Pitchford has over 25 years’ experience in software development for engineering applications, the majority of which have involved the extension of existing code bases. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. For the past 10 years, he has specialised in software test and works throughout Europe and beyond as a Field Applications Engineer with LDRA.