This article focuses on one of the cornerstones of the application of IEC 62304—the software architecture and how developing an architecture strategy early can support more effective deployment of development resources, ultimately leading to safer products, faster development cycles, and an overall reduction in product realization costs.
Today’s medical device manufacturers continue to face a multitude of competitive and environmental challenges—commoditization of their devices, need for higher levels of data integration and interoperability, cost containment, and changes in reimbursement, to name a few. Further compounding the issue, device manufacturers are making due with smaller development teams, faster development cycles, and demands for safer, more reliable products.
In order to stay competitive, device manufacturers must focus their limited design and development resources where they will be most effective. To address this issue, risk-based product development is gaining tremendous traction. Established in 2006 and adopted by the FDA as a consensus standard in 2008, IEC 62304 is rapidly becoming the de facto standard for many device manufacturers to govern their software development process.
Fundamentally, IEC 62304 provides a framework that supports a risk-based approach to software development, allows for segregation of software elements based on their established risk levels, and focuses risk management activities where they are most impactful.
IEC 62304 Safety Classification Determines Process Requirements
At its core, IEC 62304 requires software developers to perform, in compliance with ISO 14971, a risk assessment of the key functionality provided by the software. Based on this assessment, software developers can then classify software components as well as the software as a whole, based on the level of hazard presented to the patient and/or the device’s users, per the following:
- 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
IEC 62304 utilizes the results of the safety classification to specify the degree of development process rigor that must be applied during the software realization process. Furthermore, IEC 62304 encourages, through the architecture, segregation of software components based on their risk classification. The segregation is used to focus development rigor and effort where it will have the most impact. Through the architectural process, product teams have the opportunity to balance product complexity, development cost, and product safety as they make segregation decisions.
To completely understand the tradeoffs that can be made as part of the architectural segregation process, the “cost” of safety classification must be understood. The table shows the different process requirements imposed by IEC 62304 based on safety classification.
Software components that are safety class C require the most rigorous process. To appreciate the cost of that rigor, the additional process requirements (verses safety class B) need to be understood:
- Tool development and qualification planning
- Definition and enforcement of the standards and methods used during development
- The identification of the architectural mechanism that segregates class C software from software of a lesser safety class for the purposes of risk control
- Detailed software design of each class C software unit
- Detailed design for interfaces used by class C software
- Detailed design verification for compliance with the software architecture
- Detailed software unit testing including (where appropriate):
- Proper event sequence
- Data and control flow
- Planned resource allocation
- Proper fault handling
- Initialization of variables
- Memory managements and memory overflows
- Boundary conditions
In contrast, safety class A software only requires a minimal process focused on requirements and their verification.
The Power of Architecture Strategy and Segregation
As previously established, the true business value of IEC 62304 starts with the risk assessment process and culminates in the key architectural decisions made during the formulation of the architecture. The architectural strategy is the first set of activities associated ultimately with the development of the system and software architecture.
The goal of the architecture strategy is to holistically and systematically understand the critical drivers that define the success of the product and to use those drivers to assess and converge on the key architectural decisions that must be made to ensure the product’s success.
The output of the architectural strategy is a set of guiding principles for the system including:
- Principles of Organization—How the system is to be functionally and physically organized
- Principles of Operation—How the system components work together to meet the functional requirements
- Principles of Variation—What points of variation the system must support when released
- Principles of Evolution—What elements the system must encompass to support long-term growth
A key driver for the strategy process is the system and functional risk-based classification performed in compliance with IEC 62304. This classification is critical as the basis for the decision-making process for how the software is organized and functional elements segregated. It is the segregation of components by safety classification that allows the application of different degrees of process rigor to be applied. Key to the segregation strategy is the approach taken to achieve it. Common approaches include:
- Separation of software on different processors
- Use of an RTOS that supports virtualization and isolation of components
- Separate, independently operating applications
For the segregation to be effective, developers must demonstrate that the system components are clearly isolated, independent, and do not share common resources with lower classification elements.
The process of segregation is a complex one that balances design complexity with process rigor within the framework of the manufacturers’ development resources and time constraints. Appropriately balanced, segregation can provide a tangible business benefit and allow for product development costs to be lowered, schedules accelerated, and product safety increased.
Adoption of IEC 62304 by medical device developers can provide a significant marketplace differentiator as well as a framework for effectively applying development resources while minimizing realization costs and product risks. While IEC 62304 defines a more explicit set of software development process requirements over previous medical device process standards and guidance, it also provides an approach for safety segregation of architectural components that ensures the appropriate application of process rigor.
The benefit of IEC 62304 is anchored in the initial architectural strategy and early identification of product risks and the architectural segregation of system components based on those risks. This process allows for software classified, for example, as safety class C to clearly segregate the components of the system that are truly class C from those that are not. Instead of developers applying safety class C rigor to the entire system, they can focus their attention on the system elements that present the most product risk.
The application of risk segregation comes at a cost. It requires careful analysis and assessment at the architectural level early in the development process. Design complexity and potentially increased product cost must be weighed against overall development cost and schedule improvement. For most organizations, risk-based segregation provides tangible business and product benefits. Most organizations that embrace an IEC 62304 approach see reduced product realization costs, a shorter development schedule, and ultimately, faster time to revenue recognition.
For more information, visit www.foliage.com.