Written by Todd Brian, Validated Software.
In Part 1 of this series, we looked at off-the-shelf software, and the costs of saftey-critical products.
In Part 2, we examined the processes for developing and validating safety-critical products.
In Part 3, we outlined the regulatory environment for medical devices.
In this final part, we'll describe the various medical device standards. This part is largely reference material to support the first three parts.
IEC 62304 Medical Device Software - Software Life-Cycle Processes was created by a joint working group of the ISO and IEC team members, and released in 2006. As of March 2010, it is mandatory for medical products carrying the CE mark and sold in the EU. With recognition by the FDA as a consensus standard, IEC 62304 is the de facto standard for manufacturers selling to the international market.
IEC 62304 recognizes that the software life cycle involves not just development, but that software is also released and used in the field. It requires up front planning and addresses real-life product issues such as software maintenance, problem resolution, and change management. IEC 62304 makes the assumption that the software life cycle exists within a quality and risk management system. With regard to the risk management process, ISO 14971 is assumed and is a normative standard. ISO 14971 is dominant in the risk management category, while ISO 13485 is the quality management system of choice.
IEC 62304 defines the software lifecycle as a framework of essential processes, including:
- Software development process
- Software maintenance process
- Software hazard management process
- Software configuration management process
- Software problem resolution process
- Risk management process - ISO 14971
- Quality management system (Suggested ISO 13485)
IEC 62304 divides each process into a set of activities, and each set is subdivided into a set of tasks. In addition to identifying the set of processes, activities and tasks that are necessary and sufficient to undertake the project, IEC 62304 also provides a scale, which manufacturers are to use to evaluate the hazard associated with the software as implemented within the device.
Similar to the “Level of Concern” used by the FDA, these software safety classes are assigned based on severity as follows:
- Class A: No injury or damage to health is possible
- Class B: Non-serious injury is possible
- Class C: Death or serious injury is possible
Once the Class of the software is established, IEC 62304 provides a list of the processes, activities and tasks that must be performed in order to develop software that will meet the needs of the application. See the section Software Safety Classes below for a sample of the direction provided by the standard. As expected, Process 5, Activity 5.1 requires that the planning task is performed for all classes of software. But for activity 5.1.5, “Software development standards, methods and tools planning” this level of planning is only required for Class C.
|Clauses and Sub-clauses||Class A||Class B||Class C|
|4.0 General Requirements|
|Clause 4 All Requirements||X||X||X|
|5.0 Software Development Process|
|5.1 Software development Planning (activity)||X||X||X|
|5.1.1 Software Development Plan (task)||X||X||X|
|5.1.2 Keep Software Development plan ...||X||X||X|
|5.1.3 Software Development plan reference ...||X||X||X|
|5.1.4 Software Development standards, ...||X|
|5.1.5 Software integration and ...||X||X|
|Clause 8 All requirements||X||X||X|
|Clause 9 All requirements||X||X||X|
Software Safety Classes
IEC is not perfect and there is room for improvement. Observations consistently find that IEC 62304 is easier to understand and has less ambiguity, it is provided as a single document and incorporates mechanisms for handling off the shelf software as an integral part of the process, and it provides a process for partitioning software into separate classes to reduce validation costs without sacrificing the integrity of the device.
The latest release, formally known as ISO 14971:2007 “Medical Devices -- Risk Management -- Application of Risk Management to Medical Devices,” is recognized by the FDA and specified by the EU's Medical Device Directive (MDD) and is the normative risk management process used by IEC 62304. Unless otherwise stated, the assumption is that manufacturers use ISO 14971 as their defined and documented process that satisfies risk analysis, evaluation, and control. Similar to IEC 62304, ISO 14971 applies to the device life cycle, not just development. It is best treated as an absolute requirement.
ISO 13485 “Medical devices -- Quality management systems -- Requirements for regulatory purposes,” is seen as required infrastructure for medical device manufacturers. While other standards such as ISO 9001 are also acceptable, ISO 13495 is tailored to meet the specific regulatory and quality requirements of broad needs of the medical device industry and certain sectors such as implantable devices, and sterile medical devices. It is best treated as an absolute requirement.
Medical Software in the Future
The working group tasked with predicting the future had a much easier job than either the FDA or the industry as a whole will in the years to come. While the medical industry is not missing ethics, it is optimistic rather than pragmatic. That optimism is exhibited by the “Tell me it is Safe” FDA process compared with a "Prove it" process used in avionics.
While the institutional goals of the FDA are worthy, it is clear that the process to approve device for market represents a clash of two cultures. What other organization in the world drives a safety critical process by detailing the documents that must be submitted rather than the steps needed to ensure that the device is safe?
Why is that important? It is not the paperwork that is critical. The paperwork is a by-product of doing the right thing at the right time. If documentation alone drives the process, safety will never truly catch up.
The convergence of technologies similar to in cell phones and other consumer electronics such as wireless connectivity, 2D and 3D graphics, multimedia, etc will increase convenience, expand capabilities, and drive portability. Many of these technologies will in turn drive the need for even more software such as security and privacy software that is needed because of the wireless and other connectivity. All of this will result in device software code bases that will grow by a magnitude or more, and for many companies most of this software will have to come from outside.
The problem for manufacturers will not be the availability of software, but the availability of software that is qualified or able to be qualified for use in medical devices. Companies such as Micriµm, and Validated Software provide software and the evidence of compliance with both FDA and IEC 62304 standards.
Common Safety-Critical Development Standards
Globally, there are many regional and industry-specific standards. Two robust standards specifically involved in software development are IEC 61508 and DO-178B. Given that standards apply to not only software, but all aspect of design, each industry and its related equipment poses dramatically different hazards. Therefore the methods used to evaluate and mitigate these hazards promote the use of diverse standards governing device creation. Specific standards that address not only the medical industry are:
- IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems. IEC-61508-3 specifically addresses software.
- UK Defense Standard 00-56 Issue 2, Safety Management Requirements for Defense Systems
- US Requirements and Technical Concepts for Aviation (RTCA)DO-178B Software Considerations in Airborne Systems and EquipmentCertification
- US RTCADO-278B Guidelines for Communications, Navigation, Surveillance, and Air Traffic Management (CNS/ATM) Systems Software Integrity Assurance
- US RTCADO-254 North American Avionics Hardware
- EUROCAEED-12B European Airborne Flight Safety Systems. Technically equivalent to DO- 178B
- IEC 62304 - Medical Device Software - Software Life Cycle Processes
- IEC 61513, Nuclear power plants - Instrumentation and control for systems important to safety General requirements for systems, based on EN 61508
- IEC 61511 Functional safety - safety instrumented systems for the process industry sector
- IEC 62061, Safety of machinery - Functional safety of safety- related electrical, electronic and programmable electronic control systems, based on EN 61508
- EN 50128, Railway applications - Communications, signaling and processing systems. Software for railway control and protection systems
- EN 50129, Railway Industry Specific
- NASA Safety Critical Guidelines
Standards Bodies and Worldwide Standards Organizations
- American National Standards Institute (ANSI)
- American Society for Testing and Materials (ASTM)
- Association for the Advancement of Medical Instrumentation (AAMI)
- Australian Therapeutic Goods Administration
- British Standards Institution (BSI)
- Canadian Standards Association (CSA)
- European Committee for Electrotechnical Standardization (CENLELEC)
- European Committee for Standardization (CEN)
- European Telecommunications Standards Institute (ETSI)
- Finnish Standards Association
- French Association for Standardization (AFNOR)
- German Standards Institute (DIN)
- Global Harmonization Task Force (GHTF)
- IEEE-SA Standards Association (IEEE-SA)
- International Electrotechnical Commission (IEC)
- International Standards Organization (ISO)
- Medicines and Healthcare Products Regulatory Agency (UK)
- National Institute for Standards and Technology (NIST)
- Radio Technical Commission for Aeronautics (RTCA)
- Standards Association of Australia
- Standards Council Canada (SCC)
- Swedish Standards Institute (SIS)
- Swiss Association for Standardization (SNV)