The medical device industry is undergoing a profound transformation as it tries to cope with two conflicting requirements: 1) increasing the pace of innovation and commercialization of more modern and interconnected devices, while 2) maintaining a high level of safety and security.
Building a medical device today is increasingly becoming a system integrator activity, where reuse of pre-existing and/or third party components allows meeting stringent and aggressive project plans.
This article explores the benefits of leveraging third party software units (to start using IEC 62304 terminology) while meeting medical devices software safety and security requirements as defined in the IEC 62304 standard, with a particular focus on identifying which phases of a medical device software lifecycle would be more impacted and might require hopefully positive adjustments and changes.
What is IEC 62304
IEC 62304 is the “standard providing a framework of life cycle processes with activities and tasks necessary for the safe design and maintenance of medical device software.”
click for larger image
Figure 1: Relationship of key medical device standards to IEC 62304 (Source: IEC 62304)
The Food and Drugs Administration (FDA) recognizes IEC 62304 as a Consensus Standard while the European Medicines Agency (EMA) identifies IEC 62304 as a “harmonized” standard within its latest Medical Device Directive. This means that, although compliance to the standard is not mandatory, IEC 62304 is widely regarded as the benchmark to comply with regulatory requirements in both markets.
IEC 62304 can be considered one of the legs of a three-legged stool upon which sits safe, secure, correct, and complete software for medical devices. The other two legs of such stool are a quality management system and a risk management system, defined by ISO 13485 and IEC 14971 standards respectively.
Overview of IEC 62304 Software lifecycle processes and activities
IEC 62304 software lifecycle process begins with customer needs that drive system wide requirements. From system wide requirements software requirements are then derived, but before doing so the role of software as potential hazard has to be identified, and its impact and harm have to be assessed. Assessing the effects on the patient resulting from possible failures and malfunctions leads to classifying the software in three possible safety categories: Class A, Class B and Class C (Class A (no risk), Class B (low to moderate potential harm), and Class C (risk of serious injury or death)).
The software safety class dictates which processes, activities and tasks shall be carried out in order to comply with the standard. For the purpose of this article we won’t be distinguishing between safety classes. We will take a broad look at the entire IEC 62304 software development processes instead.
click for larger image
Figure 2: Overview of software development processes and activities (Source: IEC 62304)
Software of Unknown Provenance (SOUP)
IEC 62304 defines “software that is already developed and generally available” as Software of Unknown Provenance, or SOUP. The standard does not stop at the definition though, it also identifies those steps in the development process where one needs to pay particular attention to SOUP and it describes additional activities and tasks that might need to be carried out in order to guarantee proper operating conditions and thus proper functioning of such software.
Off The Shelf (OTS) software
IEC 62304 defines Off-the-Shelf (OTS) software as that particular type of SOUP “that has not been developed for the purpose of being incorporated into the medical device”. The standard makes a distinction between OTS and other SOUP “software previously developed for which adequate records of the development processes are not available”.
Why is the difference between OTS and other types of SOUP relevant? Under the strong assumption that OTS software has been developed by a commercial supplier that has followed a development processes and produced relevant documentation that describes OTS system requirements, APIs, performance, etc., it is evident that 1) the time necessary to integrate OTS software, 2) the risks associated to its usage, and 3) the average time to resolution of a problem are all more favorable for OTS software than for other types of SOUP.
In general terms, one might conclude that the cost of ownership of OTS software sits with the supplier, while the cost of owning other types of SOUP (including freely available, non-commercial open source software) sits entirely with the medical device manufacturer.
IEC 62304 Conformant OTS
Among SOUP software a special mention goes to Conformant OTS. A Conformant OTS is software that has been developed according to and thus is conformant to IEC 62304 standard. If we take an operating system, for instance, and in particular VxWorks Cert (where Cert stands for “Certifiable”, as opposed to a general purpose version of VxWorks), the advantages of using a Conformant OTS would be that of 1) dealing with a much smaller code base and reduced number of APIs/ functionalities 2) that have been developed following IEC 62304 software lifecycle processes and 3) come with documentation and certification evidence that can be reused by the medical device manufacturers.
click for larger image
Figure 3: VxWorks Certifiable API subset (Source: Wind River)
OTS software and IEC 62304 software lifecycle processes
As previously mentioned, IEC 62304 explicitly calls out SOUP in several sections of the standard describing additional activities that might need to be carried out in order to fully benefit from using SOUP while mitigating the possible risks of doing so.
Software development planning
If the medical device manufacturer is planning to use SOUP to implement some of medical software functionalities (i.e. the operating system), it is important to include in the software development plan a description of which software items will be SOUP, how the integration will be carried out and how the necessary testing of SOUP will be performed during integration.
When using a certified OTS, it is assumed that all necessary verification steps have been performed. This aspect needs to be documented as part of the software verification planning. In the case of other types of SOUP some additional verification might be required and thus would need to be planned.
It is also important to assess and plan for risk management associated with SOUP – this is where considerations such as SOUP software code base size, OTS vs. certified OTS, Service Level Agreements with the SOUP suppliers would be accounted for in documenting what the plan should be.
Using OTS software certainly comes with the benefit of having supporting documentation that is available to the manufacturer for inclusion in the documentation planning, whilst other types of SOUP might require such documentation to be developed from scratch. Regardless, SOUP related documents that will be produced have to be properly listed.
click for larger image
Figure 4: VxWorks Cert Documentation Evidence Package (Source: Wind River)
Finally, the manufacturer needs to plan how to put software items as well as other tools, compilers, build systems, configuration settings, etc., under configuration management. This is where having a clear understanding of how SOUP software is architected, which folders are relevant to producing a successful compilation, which build scripts and configuration parameters are necessary, would give a development edge and certainly save time.
Software requirement analysis
By now the manufacturer has decided whether or not to use SOUP to implement some of the medical device functionalities. Let’s assume, for instance, that a Class C device operating system will be an OTS. The manufacturer will have to include all requirements that such OTS will satisfy, including the lists of APIs that will be used to implement functional requirements, expected performance of APIs (i.e. timing requirements), programming code requirements, I/Os, data format, alarms, warning, and fault detection, etc.
The standard explicitly calls out for regulatory requirements to be listed, i.e. one might require the OTS operating system to be a conformant OTS in order to decrease risks and leverage available certification evidence and documentation.
Regarding risks, the manufacture needs to include risk control measures among the list of software requirements: when using SOUP, one might want to think how to control the risk of the SOUP not operating as expected, as well as how to intercept failures and errors and misbehaviors. This is where a conformant OTS would provide an advantage since risk control measures would potentially already be built into the operating system for example, well documented, audited and certified.
Software architectural design
At this stage of the lifecycle process, IEC 62304 requires to turn software requirements into a high level architectural design. SOUP software items will be identified as separate functional blocks, and for each of the SOUP item “the manufacturer shall specify both functional and performance requirements that are necessary for its intended use”.The manufacturer would have to specify also hardware and software requirements that are necessary to support proper operation of SOUP items and, finally, introduce verification steps that would ensure the medical device architecture supports, once again, proper operation of SOUP items.
Software detailed design & unit implementation and verification
In these two phases of the lifecycle process, the manufacturer will rely on SOUP to have already been designed, implemented and verified. It is at this stage that most of device manufacturers expect to save development and verification costs by using SOUP. It goes without saying though that some SOUP might not even have a detailed design, nor come with evidence of verification.
This is particularly true for pre-existing SOUP and open source software. Yet open source software is being widely adopted in the medical device industry!
As usual, it goes back to RISK management and risk control measures. Lack of detailed design or verification evidence would require handling SOUP with more care, accounting for higher chances of failures and errors and ultimately verifying if the risk of using SOUP to implement some portions of the system is acceptable.
At the time of writing, it is becoming common practice to leverage OTS open source for Class A and Class B software items, while using a Conformant OTS for Class C.
Software integration, integration testing & SYSTEM testing
At this stage, integrating and running SOUP pre-existing test cases would be extremely helpful. It is common practice for OTS software suppliers to provide a set of test cases and test scripts that the medical device manufacturer can include in their testing framework. The same is true for most open source SOUP packages, or at least those that are largely used and deployed such as the Linux kernel, toolchain, system libraries, etc.
The standard here points out that integration and system testing is an iterative process that needs to run after every change, both during development and maintenance. It is worth spending time in investigating availability and format of SOUP pre-existing test cases and capturing as requirement those test case formats that would make for an easy integration into the medical software test case framework. Some also specify test case performance requirements, such as execution time, since in a software world that is moving toward agile and DevOps, changes and subsequent testing are continuous activities that consume most of the time and effort of the development lifecycle.
In this paragraph, the IEC 62304 standards focuses on three main aspects: 1) meeting gating criteria before the medical device software can be released (i.e. verification is complete, residual anomalies have been vetted and evaluated against risks criteria), 2) versioning and archiving and 3) ensuring repeatability of the release, that is, being able at any point in time to be able to rebuild the exact same release that is made of potentially many software items. Most of the times, and certainly this is true for OTS software, SOUP components have already in place a versioning scheme that the manufacturer needs to adopt and align too.
Prerogatives of OTS software are, instead, a predictable release schedule with consistent versioning numbers, repeatability of build and documented release gating criteria. At Wind River, we can reproduce and deliver to customers versions of our operating systems that go back to the days the company was founded. When open source software is used, it is important that, when not using OTS open source (i.e. Wind River Linux), an open source project is evaluated for its community of adopters, release criteria, predictability of release schedule as well as availability of old releases.
Software configuration management process
Paragraph 8 of the IEC 62304 standard comes after maintenance and risk management processes. In particular, paragraph 8.1.2 calls out for documenting each of SOUP software 1) title, 2) manufacturer, 3) unique SOUP designator (i.e. a release number, release date, a patch or update number, etc.). Again, this is where OTS software comes in very handy, as the manufacturer would rely on release naming conventions that the OTS supplier has already established.
Software risk management process
When using SOUP and in particular OTS software, the manufacturer can and should minimize risks by simply reviewing the list of published anomalies to determine whether or not such known problems could lead to a hazardous situation. From a practical point of view, this is where having clear and documented release naming conventions as well as release gating criteria can result in saving quite a significant amount of time. Most, if not all, OTS software has a Release Note associated to each major (upgrade) or minor (update) release. Such Release Note describes not only the release number and date, but also the list of changes with possible impacts and the list of known anomalies that have been fixed or are still open. Finally, nowadays such list is updated dynamically almost daily, especially when security vulnerabilities are considered.
Manufacturers should make a habit of reviewing periodic security bulletins or querying the list of known security vulnerabilities that an OTS supplier publishes. See for example the Wind River Common Vulnerabilities and Exposures (CVE) database.
Software maintenance and problem resolution processes
Lastly, the standard requires establishing a software maintenance plan as well as a problem resolution process. This process would allow a manufacturer to receive, document, evaluate, resolve and track the feedback (including problems) arising after the release of the medical device software. IEC 62304 describes an iterative process that is comprised of the following:
- Establishing a maintenance plan with procedures to evaluate and implement upgrades, bug fixes, patches and possible obsolescence of SOUP. The more the predictability of upgrades release cadence, planned obsolescence, the lower the risk.
- Being ready to process and analyze feedback when problems arise. Especially when SOUP is used, being able to inform relevant parties, such as an OTS supplier, of a new problem and being able to count on agreed Service Level Agreements when expecting a fix are both valuable assets that reduce risk and lead to shorter time to resolution
- Spin a new release that incorporates the changes, and in case of SOUP/OTS, possibly a new patch, or update. Sometimes in the case of non-commercial open source software a fix might require to having to release an upgraded software item, with impacts on regression and the entire architecture. Upgrading a Linux kernel is definitely not the desired plan of action to cope with bugs or security vulnerabilities.
The IEC 62304 standard acknowledges that leveraging SOUP for developing some functionalities of a medical device is good business practice, as it can reduce time to market and increase speed of innovation. The standard goes to the extent of identifying which steps of the software lifecycle process might benefit from using SOUP, which activities need to be carried out to ensure proper operation of third party software. As we have seen, such SOUP related activities and the associated costs/risks give a clear indication whether or not SOUP or OTS or even IEC 62304 Conformant OTS is the right choice for a given use case. Which to select is ultimately the choice of the medical device manufacturer, whose goal should be that of maximizing leverage of third party software while reducing associated risks and unknowns.
Davide Ricci is Director of EMEA medical business at Wind River. He has a strong technical and business background built in over 10+ years of experience in open source software for devices and the IoT industry. His expertise spans from IoT devices and edge computing to open-source standards and ecosystems, from cloud data aggregation to device fleet management, lifecycle strategy and security. He holds a Master of Science in Computer Engineering, with specialization in Artificial Intelligence and Robotics di Milano, from the Politecnico of Milano.
The post Meeting medical device standards with off-the-shelf software appeared first on Embedded.com.