Compliance and Improvement in Medical Device Software
Regulatory compliance can be an opportunity to develop more robust processes. Dr Dave Jennings of Trosolwg Systems and Software discusses a software design process with built-in activities that monitor business risk and project progress.
Software is increasingly a part of medical devices. It provides the essential mechanism for control and data interpretation, and is used to an increasing extent due to the improvement in economics and performance of processors. The creation of software is in some senses straightforward. It leads to minimal problems in manufacture and it enables considerable complexity of function to be captured.
Software's apparent simplicity is seductive: from the early days of computers there were reliability problems of quality, which led to the "Software Crisis," which was identified in the late 1960s. It was recognised then that a disciplined approach to the design of software was necessary. This article looks at the current position with respect to medical devices and their need for verifiable designs that meet regulatory demand.
Regulatory and standards context
The purpose of regulation in the medical device industry is to ensure that products are delivered to known safety levels. Medical intervention is not without risk: products will inevitably expose patients to hazards by their very nature. However, medical device design should ensure that the presented risks are known and properly controlled. Unpredicted risks are not acceptable.
The difficulty in producing software is essentially due to the large input space of the system. Its reliability cannot be controlled simply by sample-based testing of the input space. It is, therefore, necessary to employ a well-disciplined development environment in the design of high-integrity software for medical device applications. The main standards that apply are ISO 13485,1
which defines the required quality control system, and ISO 14971,2
which defines how hazard analysis should be undertaken.
In addition to those standards, which are applied to any medical device, ISO EN 623043
was agreed in 2006 and is now a harmonised standard in the EU and the US. ISO EN 62304 defines a framework of requirements for software lifecycle processes. In defining the framework, the standard
- employs both ISO 13485 and ISO 14971 to specify requirements that apply to software development
- identifies activities that must be undertaken and documentation that must be produced in the course of software development
- defines the fundamentals that are required to be provided by change control systems, which must be used within the process
- states the minimum requirements that must be met (with certain variants identified according to the perceived hazards that could ensue).
The standard does not attempt to define a practical working implementation of a development lifecycle, which is ideally required to help ensure a product meets the needs of compliance with the published standards.
Software lifecycles - the essentials
The first lifecycle that is generally recognised to have been identified was described by Royce in 1970.4
Royce noted that Waterfall is "risky and invites failures, because it postpones testing until the end of the development." In other words, business risk increases through the project, because it provides no mechanism for evaluating the solution's viability as work progresses.
Remarkably, despite showing the Waterfall model in that paper as an example of a process that was deeply flawed, his seminar audience apparently went away and implemented it. Unfortunately, Waterfall-type lifecycles that model the software development process as a series of discrete events with a beginning, middle and end, have become commonplace. ISO EN 62304 notes that Waterfall would be a feasible implementation of the standard.
Alternative lifecycles should therefore be considered and careful selection made within a quality process to enable the development team to create a product that is demonstrably in compliance with the published standards.
Various forms of iterative lifecycle have been proposed since Boehm's landmark paper of 1988.5
Probably the most robust of these is the Unified Process (USDP) of Jacobson (1999), which is really an idealised framework.6
Jacobson identifies the primary features of the USDP:
- It is iterative and incremental, which means that the process is divided temporally into a sequence of sub-lifecycles, whose activities build on previous work. Each iteration is typically targeted to take six to eight weeks and to deliver some important element of design or functionality. The iteration is preceded by planning and followed by review to ensure that business risk is managed.
- The process is architecture-centric, which means that an early aim in development is to define a viable candidate system architecture that acts as a focus for design and development activities.
- The process is Use Case driven and should normally use the Unified Modelling Language (UML) to guide and communicate development activity.
Within any iteration, a suite of basic tasks should be performed, which may include requirements engineering, analysis, design, implementation and testing. The relative workloads applied between those activities in iterations changes through the set of iterations that make up the whole development.
Use Cases are employed as the optimal means for defining the functional characteristics of software systems. They are written as sequences of steps that the system is required to perform to implement a meaningful service on behalf of a user. This means that they can be written in terms readily understandable by the system's user, who is, by definition, a domain expert. Use Cases are not defined in arcane and obscure terms that only a requirements engineer can understand.
When Use Cases are used with UML-based modelling, their advantages over other specification techniques are highlighted. Their step-wise nature should be reflected in models created by the analyst, which explore the system'ss behaviour and provide the initial means for verifying that the requirements have been correctly captured. The first steps towards system verification may be taken in a modelled system long before significant amounts of code have been written.
Making Best Practice conform
The USDP effectively provides the basic framework for a software lifecycle. However, in terms of what is required for the development of medical device software it is insufficient. ISO EN 62304 identifies a number of activities that need to be added to enable compliance:
- Hazard analysis is required for all medical device software. From the starting point of requirements, it is essential that each requirement is evaluated for risk, and that any residual risk is mitigated and documented. Furthermore, risks should continue to be assessed through the course of design and implementation, and these in turn should be mitigated where necessary. The basic activity must be in compliance with ISO 14971 as supplemented by ISO EN 62304.
- Compliance with a quality process, which meets ‚€®ISO 13485, is required.
- Medical device designs, including their software elements must be verified and validated. ISO EN 62304 identifies verification as an activity that is within the standard life cycle, and validation as being outside of it. We would normally consider testing of design or implementation as being a special case of verification, in which test information is applied at specific samples through the system's input space. The samples should be identified in Test Cases that provide complete coverage of the set of system requirements.
- There must be clear policy and practice that lead to implementation of Change Control. It is normal for these practices in software development to be managed through the use of tools that integrate Change Management and Version Control. ISO EN 62304 requires that Change Requests be traceable to modifications in the system or its design artefacts. It, therefore, makes sense to follow best practice through the use of tools that ensure that change may only happen in response to managed requests, and that the changes made may be traced to their source stimuli.
- ISO EN 62304 highlights the need for robust tracing through requirements, test cases and risk control. It makes little business sense for this to be done other than by using tools built for the purpose. A word processor is inadequate for the job; maintaining the resulting cross-reference is extremely time-consuming and error prone. A requirements management tool can do the work effectively and highlight where the effects of changes are likely to be felt. A good requirements management tool will also have the ability to enable covering links to be built to system models.
- The process used and many of its activities must be documented in a Software Development Plan. This plan forms the core of the required documentation, which also encompasses policies for change and risk management, document control and the basic development activities.
- It is required that documented mechanisms are established for the maintenance of software so that maintenance activities are managed along similar lines to the overall development. The Maintenance Plan must document the process of response to any discovered failures, including how these are reported to interested parties.
Model driven development allows the creation of tracing at a fine level of granularity from Use Case elements to model elements. Although this is not specifically required by ISO EN 62304, it does add to the robustness of the design process. This tracing is nevertheless precisely in accord with the general principle of tracing all design inputs to design outputs, thereby ensuring that an implementation precisely matches its source requirements.
Figure 1: Temporal structure of lifecycle (copyright: Trosolwg)
The lifecycle structure shown
in Figure 1 shows how we have enhanced the USDP to comply
with ISO EN 62304. Iterations
are grouped in phases, which
provide a structured mechanism
for defining process milestones.
In this way major decisions
about commercial and resourcing strategies for the product under development may be reviewed
Compliance is an opportunity
Regulatory compliance should be considered an opportunity, not a burden. Software developed using a strong and automated process is more reliable and quicker to market.
Automation of quality related activities allows the development team to concentrate on what they are good at and decreases the time required for quality audit.
We have found that the USDP, when used as a foundation and appropriately enhanced, provides a firm basis for software development for medical devices. It has built-in activities that monitor business risk and project progress.
The USDP, as enhanced, offers the opportunity to create software using a high quality process tailored for compliance with standards. This lifecycle process thus helps reduce the probability of project failure and ensures that project delivery is managed on time and in budget.
1. ISO 13485:2003 Medical Devices, Quality management systems, Requirements for Regulatory Purposes.
2. ISO 14971:2009 Medical Devices, Application of Risk Management to Medical Devices.
3. ISO EN 62304:2006 Medical Device Software, Software Life Cycle Processes.
4. W. Royce "Managing the Development of Large Software Systems," Proc. Western Electric Show and Convention (IEEE WESTCON) August 1970, 1-9.
5. B.W. Boehm, "A Spiral Model of Software Development and Enhancements," Computer, 21, 5 (1988).
6. I. Jacobson, G. Booch, J. Rumbaugh, "The Unified Software Development Process," Addison-Wesley, ISBN 0201-57169-2 (1999).
Dr Dave Jennings
is Programme Director Design and Build at Cynllun Trosolwg Ltd, Trosolwg, Llansaint SA17 5HX, UK,
tel. +44 (0)1267 267 068,
If you found this article interesting please
Sign Up Now for your free subscription to