FDA Compliance and Medical Device Development
Manufacturers of medical devices distributed in the U.S. must comply with regulations set out by the FDA's Center for Devices and Radiological Health (CDRH). They must establish and follow quality systems to help ensure that their products consistently meet applicable requirements and specifications.
The FDA’s Design Control Guidance for Medical Device Manufacturers is intended to assist manufacturers in understanding the intent of the regulation.
And, the FDA document may be applied to the design of all kinds of medical devices and any associated manufacturing processes, so it describes high-level principles, but it does not prescribe specific tools and techniques to be used for medical device software development.
Applying the FDA’s Design Control Guidance to Software Development
The Guidance document presents a simplified model for a product development process. The model is generic and covers the whole system design – including hardware and software components. Let’s examine how it can be applied to the design of the software components of a medical device:
Design Input for Medical Device Development
For software development, the Design Input is a collection of software requirements.
“Development of a solid foundation of requirements is the single most important design control activity.”
The document provides helpful guidance on mapping high-level user concepts to requirements, breaking down the requirements into different categories (functional, performance, interface), and determining the appropriate level of detail.
“It is almost inevitable that verification activities will uncover discrepancies which result in changes to the design input requirements.”
This means the change control process for software requirements must be carefully managed. Maintaining traceability between requirements and their associated test cases is essential to help check that all requirements have been properly tested, and to make sure that requirements are correctly updated when testing uncovers a need to change them.
A purpose-built requirements management tool such as Helix ALM can help you achieve these things by making it easy to organize requirements according to different categories, define them in a hierarchical structure and, importantly, maintain relationships between them when things change.
Furthermore, requirements stored in a centralized repository can be accessed by all project stakeholders while maintaining an auditable change history, supporting an approval workflow and ensuring that any change conflicts are managed. It should be noted that Helix ALM is ideal for managing all your system requirements — hardware as well as software.
Design Output for Medical Device Development
Design output is “the result of a design effort at each design phase”. Design output could be a diagram, a flow chart, or a design specification. Software source code is one example of design output.
“Design output should be expressed in terms that allow adequate assessment of conformance to design input requirements and should identify the characteristics of the design that are crucial to the safety and proper functioning of the device.”
In order to assess conformance to its requirements, software source code needs to be written clearly so that it is easy to understand how it achieves the requirements. Also, in order to help ensure the safe and proper functioning of the device, the code cannot exhibit any undefined behavior and every effort must be taken to remove bugs.
Design Review for Medical Device Development
This section of the Guidance stresses the importance of formal, documented reviews to find and address problems at the earliest possible opportunity. The results of any design reviews must be documented, and feedback must be provided to the designers so that existing or emerging problems can be fixed.
If we apply this principle to a typical software project with multiple developers working on the codebase, a centralized repository that can hold all outstanding issues and review comments becomes an essential tool. Furthermore, if static analysis is incorporated into a centralized Continuous Integration (CI) build process, developers can be automatically notified of issues found as soon as they are detected, and their resolution status can be tracked.
What's more, reports that show the level of compliance to the coding standard and/or the status of other outstanding code defects can be generated easily and used as evidence in formal design reviews.
Design Verification for Medical Device Development
“Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.”
For software components, verification includes static analysis, unit tests, integration/system tests
The output from a static analyzer can be used as evidence that your coding standard requirements have been met – and it can report on justifications when it has been necessary to deviate from the standard
Managing the dynamic relationships between requirements and test cases, and providing an at-a-glance view of test coverage is best achieved using a test case management tool.
So, selecting the right tools for your software project will make it much easier to follow the FDA Design Control Guidelines
Helix ALM makes it easy to manage and track requirements, tests, and issues — all in one spot. And, the ALM tool automatically creates traceability across each of these items. That helps development teams to prove compliance faster, so they can get their device to market on time.
Perforce static analyzers enable software development teams to easily comply with industry standards as well as find defects earlier in development — when they’re easier (and less expensive) to fix. Our products support C, C++, C# and Java, which are essential to medical device development.
Relationship to Key International Standards for Medical Device Development
The Importance of IEC 62304 for FDA Compliance
The most relevant and essential international standard for medical device software is IEC 62304 - “medical device software — software lifecycle process”. It applies to the development and maintenance of medical device software.
In the EU, it satisfies key software-related requirements in the EU Medical Device Regulation. And, in the U.S., the FDA accepts demonstration of compliance to the standard as evidence that regulatory processes have been fulfilled.
Many companies in the medical device industry have adopted the MISRA coding standard for developing their embedded software in C or C++. This helps them to meet the software acceptance criteria defined in section 5.5.4 of the standard.