Ensuring Software Quality in Embedded Medical Devices
In medical devices, increasing complexity and market pressure bring additional risk and cost associated with defects. Attention to quality standards as well as the use of fundamental tools and practices can be applied to help meet these standards and mitigate the risk.
ELIJAH KERRY, NATIONAL INSTRUMENTS
Page 1 of 1
The term “medical device” is used to refer to any item that treats, diagnoses, prevents or monitors patients. This ranges from simple stethoscopes, to teleoperated surgical devices, to implantable defibrillators. As the complexity of these applications increases along with the power of embedded hardware, medical devices have come to increasingly rely on complex embedded software. The challenge of bringing these cutting-edge devices to market is compounded by the need to ensure patient safety and meet regulations set by agencies like the Food and Drug Administration (FDA).
Breaking Down Medical Device Standards
The FDA is responsible for administering Title 21 of the Code of Federal Regulations (CFR), which is intended to cover any and all products that could impact the welfare, health, or safety of people. Of the hundreds of parts within Title 21, there are a few in particular that engineers working on embedded medical devices should be aware of.
• Part 860: One of the fundamental questions that should be examined as early as possible is “will the FDA consider my application a medical device, and if so, what kind?” The answers to these questions can have a significant impact on the development process and the cost to certify and productize an FDA-approved application. There are three classifications of medical devices, ranging from non-threatening devices like dental floss (i.e., Class I), to non-invasive applications like CAT Scanners (i.e., Class II), to any application that is life-sustaining or invasive, such as an artificial heart (i.e., Class III).
• Part 820: This section defines the expectations the FDA has for the process under which a device is developed and manufactured. The software you write for an embedded device may not need to demonstrate compliance with this standard if it is to be classified as Class I under Part 860, but this can vary. For embedded engineers, this means that you not only have a development process, but that it’s documented and can be demonstrated to the FDA. This is similar in many regards to the popular ISO 9000 standard for a controlled process.
• Part 11: Any application that has access to or creates patient data needs to enforce very specific practices to ensure the accuracy and integrity of the information as well as observe privacy laws when appropriate. Unlike some of the other more vague standards, Part 11 is very specific when it comes to criteria such as passwords and authentication.
In addition to these standards, it’s important to consider whether you will need to submit a Pre-Market Notification (PMN) or file for Pre-Market Approval (PMA). The distinction between these comes down to whether or not a pre-existing or “substantially equivalent” product has already been released prior to May of 1976. Any and all Class III Devices have to submit a PMA so that the safety and effectiveness of the product may be evaluated by the FDA. An application for either standard has to include information demonstrating software development, verification and validation information.
Ultimately, it’s important to engage the FDA early in the process in order to confirm the regulations and requirements that apply to your device. However, meeting the regulations does not mean that any and all risks of failure or harm have been removed, as shown by the recent increases in medical device recalls. This further underscores the importance of abiding by best practices to ensure the quality and reliability of embedded software applications.
The use of the best practices serves to help identify, resolve and prevent defects in software as early in the lifecycle as possible. A medical device recall is the most costly and damaging result of a missed defect or problem, and can be devastating to the reputation of a company. However, an increasingly competitive market puts pressure on developers to meet hard deadlines at the expense of quality. This trend has been blamed by many for the recent spike in Class III Recalls, which represents the most serious recall category. As a result, officials at the FDA have indicated the possibility of modifying Part 820 to require stricter quality system regulations.
Best Practices for Ensuring Quality
Ensuring the quality and reliability of an embedded application requires a strong understanding and use of software engineering practices. Software engineering generally refers to a regimented and procedural methodology for designing, developing and testing applications. While multiple-process models for software engineering have emerged over the years, they almost all describe specific phases and criteria that must be met before moving on in the lifecycle process. Certain practices from within the software engineering process are recommended for engineers developing embedded medical devices.
First it is important to define a process. Ideally, all software vendors have a path that leads from the initial concept to a deployed application. However, in the medical field it’s not enough to trust that a process exists; the process needs to be documented. Additionally, it’s important to document how and when the process was followed with regards to a specific project or application. Ensuring this process is documented makes people more accountable for some of the less pleasant tasks like code reviews, documentation and unit testing. It also makes it possible to bring new engineers into an existing project, as their tasks and checklists are prescribed. Finally, it provides an audit trail for the FDA, which helps demonstrate that you’ve done your due diligence to ensure proper and safe operation. Failure to do so can not only open the doors for software bugs, it can lead to allegations of negligence.
Within the process, the use of a change management system is imperative. Developing any software without a change management system is like playing with fire—you are going to get burned. Change control systems are a critical component of any development process. As the name implies, they provide mechanisms for tracking and understanding when something in the application is modified, who modified it and the potential implications of the modification. One of the most fundamental components of a change control system is source-code control.
FPGAs, or Field Programmable Gate Arrays, represent one of the most important tools for embedded programmers working on safety-critical applications and should be used for critical components. FPGAs allow developers to define low-level, timing-accurate hardware behavior, which is paramount in control and safety applications. FPGAs also make it easy to execute timing-accurate operations in parallel, ensuring that nothing else can occur to interrupt a safety-critical operation. This complex hardware component can also shorten development time with the help of tools like LabVIEW, which makes it easy to rapidly iterate on different concepts in hardware instead of producing custom ASICs (Figures 1 and 2).
Don’t confuse prototypes with development. Keep them separate. New projects, especially at small start-ups, often ignore development process and structure in order to deliver a prototype that demonstrates a new proof-of-concept. For start-ups, this is often an important part of receiving additional funding. At established companies, this is often done to uncover potential patents or explore new research areas. However, one of the biggest follies to be avoided is to attempt to productize an application by simply polishing a prototype. Use the prototype to refine and define requirements as well as to estimate project timelines, but keep this separate from the development of the end-use application. Not doing so leads developers to skip over architectural and design considerations, which are mandated steps in any software engineering lifecycle.
Do use prototypes to derive specifications and requirements. In a perfect world all software projects would begin with complete requirements that represented the exact same vision for all stakeholders. However, the reality is different stakeholders have slightly different expectations for the final product during the early part of the lifecycle. Prototypes serve as a way to help align multiple parties with the expectations for the final product, which mitigates the need for last minute changes or feature-creep.
Manage and track requirements traceability. As we acknowledged earlier, requirements evolve and change throughout the development process. Understanding how these changes impact the entire application requires traceability from code to requirements. This can be achieved by requiring that developers enumerate requirements as they cover them in the implementation. For a project manager, tools like Telelogic DOORS and Requisite Pro are designed to manage and track the relationship between different requirements. They also integrate tightly with tools like National Instruments Requirements Gateway, Geensys’s Reqtify and LDRA’s TBreq to trace these specifications to the implementation automatically. Finally, these tools will also generate traceability matrices, which are expected as part of your documentation for the FDA.
In light of growing recalls and highly publicized defects in embedded devices, it’s impossible to ignore the need for a structured development approach that ensures safety and complies with regulatory standards. In addition, developers must satisfy these quality requirements while meeting increasingly shortened deadlines in order to remain competitive.
The good news is there are some fundamental software engineering practices that can be employed by companies of any scale for projects of any scope. The extent to which certain tools or processes are followed depends heavily on the criticality of the application, but their proper use can serve to improve the quality and reliability of all embedded applications.