Medical Device Software Standards

Transcription

1 Background Medical Device Software Standards By Peter Jordan, BA, C.Eng., MBCS Much medical device software is safety-related, and therefore needs to have high integrity (in other words its probability of failure has to be low.) There is a consensus that if you want to develop high-integrity software, you need a quality system. This is because software is a complex product that is easy to change and difficult to test, and the management system that handles these issues must include such quality system elements as: detailed traceable specifications, disciplined processes, planned verification and validation and a comprehensive configuration management and change control system. It is also agreed that software quality management systems need specific processes which are different from and additional to more general quality management systems such as that required by EN Historically, ISO Part 3: Guidelines for the application of ISO 9001:1994 to the development, supply, installation and maintenance of computer software states these additional processes very clearly, but is not mandatory. (This is now ISO ) In both Europe and the USA there is therefore a gap in both regulations and standards for Medical Devices. There is no comprehensive requirement specifically for software development methods. In Europe, IEC Medical electrical equipment - Part 1: General requirements for safety and essential performance, has specific requirements for software in section 14 Programmable Electrical Medical Systems (PEMS). This requires (at a fairly abstract level) some basic processes and documents, and includes an invocation of the risk management process of ISO Medical devices Application of risk management to medical devices In the US, there is an FDA regulation requiring Good Manufacturing Practice, with guidance on software development methods (strangely entitled Software Validation). This guidance is a de-facto regulation, since the guidance is used by both GMP inspectors and reviewers of regulatory submissions on new products, and, although the guidance is not law, it is difficult to argue with inspectors or reviewers. The guidance is quite burdensome, as it is quite prescriptive and generally departs from industry-standard practice and terminology. To address these problems in the USA, the Association for the Advancement of Medical Instrumentation (AAMI) wrote the standard ANSI/AAMI SW 68 Medical Device Software Software Lifecycles. This attempted a standard, acceptable to the FDA, which would make it easier for medical device manufacturers to choose software development processes. One of the key aims of SW 68 was to define processes that would deliver all the review documents required by the FDA. In the event, the FDA recognised SW 68 as meeting its requirements only for the FDA s low and medium Levels of Concern. This means that, for less safety-critical software, the manufacturer can claim compliance to the standard in its product approval submissions, instead of describing their quality system in detail. However, the highest level of concern (software whose failure could cause death) is not covered. Obviously, what would benefit manufacturers would be an international standard that: defines a minimal set of processes for inclusion in a software development lifecycle; allows processes to be chosen flexibly depending on the risk associated with software; permits partitioning of software into items with different risk levels; is harmonised by the EU; is accepted for all levels of concern by the FDA. Other influences Risk management ISO Medical devices Application of risk management to medical devices has introduced a rational approach to risk management based on a risk management lifecycle. The use of this lifecycle allows the manufacturer a very flexible approach to risk which ensures that every decision is made on the basis of actual risks rather than on rules of thumb. However, IEC (the master standard for safety of electrical

2 medical devices), although it invokes ISO 14971, still incorporates an older approach to risk management based on the rule that a single fault should not create a hazardous situation (with a number of exceptions and some very strange definitions). In the USA, the FDA does not accept that the probability of failure of software can be adequately predicted, so it requires in its guidance that software whose failure could lead to injury should be assumed to have 100% probability of failure. This allows ISO to be used, but cuts out all risk control measures which depend on high-integrity software. Why are medical devices different? We in the medical device sector must recognise that much of the safety community, especially those working on safe software, regard us as negligent compared with their normal practices. They often ask what is different about a medical device that justifies manufacturers not using normal safety processes? Many experts are so puzzled that they propose their own answers. A popular one is in your industry [medical devices] you only kill one patient at time. I believe that better answers include: Medical devices are often used where higher risks can be accepted because the risk of not treating a patient is high and the cost of a safer device is grossly disproportionate. Often the high risk is inherent in the purpose of the medical device. Most safety engineering, by contrast, aims to achieve very low risk levels. Medical devices are normally designed and manufactured by one organisation and used by another. Holistic risk management from design workshop to bedside is therefore impractical. By contrast, in industries such as chemical manufacturing, the whole process is managed by a single authority, from initial concept to retirement through operation of the plant to decommissioning. Many software safety experts think that the medical device sector should recognise IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems. This claims to be a standard for standards. Any industry sector writing a standard for software safety should in principle adopt its principles. However, application of IEC is difficult in the medical device sector because it tends to assume holistic risk management and it is best at addressing very low levels of risk. Although we in the medical device sector have succeeded in turning away IEC in favour of the simpler (but still rigorous) ISO 14971, we cannot make a reasonable case against using a software quality management system. For most of us, our public position of the safety of our product is (in the words of the Ronseal advert) it does exactly what it says on the tin. A software quality management system is needed if we expect to be believed when we claim that our software does exactly what it says on the tin. IEC Since 2002, a joint working group of ISO and IEC has been working on an international version of SW68. IEC Medical device software Software life-cycle processes aims to achieve both recognition by the FDA and harmonisation by the EU. The standard is currently in preparation as a Committee Draft for Voting. For the manufacturer who chooses to use IEC 62304, there will be 2 top-level activities: classifying software into 3 safety classes implementing a software lifecycle containing all the required processes according to the safety class of the software. I would expect that reputable manufacturers of medical device software are already doing risk management (including software risk management) and already have a software development lifecycle. They should therefore have few problems adopting IEC Working with safety classes IEC defines 3 safety classes: Class A: No injury is possible

3 Class B: Non-serious injury is possible Class C: Death or serious injury is possible These correspond to the FDA s safety levels of concern. However, note that: the FDA s levels of concern only apply to whole software systems, whereas IEC allows software to be partitioned into items with different safety classes; the FDA s levels of concern are used to decide which documents to submit to the FDA for review, whereas IEC s safety classes are used to decide which processes to use; IEC requires the manufacturer to use risk management before mitigating risks to determine the safety class of the software. The software must be assumed at this point to have a 100% probability of failure. An architecture is required which describes the device in enough detail to permit reasoning about risk. The architecture may be changed to minimise the software safety classes, for example by using a hardware protective device to prevent harm when software fails, or by reducing the complexity of the software. After the safety class of all software items in the device has been determined, the appropriate processes are incorporated into the software development lifecycle. The standard is based on the belief that the adoption of these processes has an effect on the integrity of the software. In other words, the software has a less than 100% probability of failure as a result of the application of the processes. Software development lifecycles IEC covers both software development and software maintenance. It requires software processes, and these include the production of documented outputs. The standard does not require a particular lifecycle. Iteration is permitted and in some cases recommended. The sequence and order of events is prescribed only to the extent necessary to perform tasks in a logical order. However, note that manufacturers are required to document the lifecycle used, either in a permanent process description or in a plan for a specific project. Iteration is explicitly permitted, limited only by the need to keep all documentation in a coherent state (i.e. if a document is changed, its parents and children must be changed as necessary to reflect the change). The main required processes are shown in Fig. 1: Customer Needs Activities outside the scope of this standard Customer Needs Satisfied System Development Activities (including Risk Management) 7 Software Risk Management 5.1 Development Planning 5.2 Requirements Analysis 5.3 Architectural 5.4 Detailed 5.5 Coding and Testing 5.6 Integration and Testing 5.7 System Testing 5.8 Release 8 Software Configuration Management 9 Software Problem Resolution Figure 1 Overview of software development processes and activities. Box numbers correspond to clauses of IEC

4 The processes consist of the main sequence of processes (clauses 5.1 to 5.8), and the supporting processes (clauses 7, 8 and 9). The supporting processes are performed continuously or as required during the whole lifecycle. Note that Software Problem Resolution is visible outside the manufacturer s organisation and includes post-market surveillance, and notification of problems to users and regulators. Software Configuration management is visible only inside the organisation and includes change control. The software maintenance process follows a similar pattern, shown in Fig. 2. Maintenance Request Activities outside the scope of this standard Request Satisfied System Maintenance Activities (including Risk Management) 7 Software Risk Management 6.1 Establish software maintenance plan 6.2 Problem and Modification Analysis 5.3 Architectural 5.4 Detailed 5.5 Coding and Testing 5.6 Integration and Testing 5.7 System Testing 5.8 Release 6.3 Modification Implementation 8 Software Configuration Management 9 Software Problem Resolution Figure 2 Overview of software maintenance processes and activities The standard permits simplified development processes to be used during software maintenance, subject to problem and modification analysis that identifies and addresses all the implications of any changes, and a rerelease of modified software. Problems with IEC Waterfall or iteration? The standard is arranged in a sequence that recognises the dependencies between processes, so its style appears to be waterfall-ish (see for example fig. 1). In spite of plenty of guidance material that says that the intention is not to impose waterfall development, many readers continue to worry about this. Safety is a property of the system IEC does not address the system level. This creates difficulties with determining the boundaries of the scope. For example, it is obviously desirable for software engineers to participate in the design of the system architecture, since it is that which identifies safety-critical components in an overall design and generates the requirement for high-integrity software. It is also absolutely necessary for change control and problem resolution to be system-wide so that the system design can change in response to necessary software change. The authors have adopted the policy that IEC requires an interface with the system-level processes, but does not describe those processes. This does result in clear, simple wording.

5 Restricted risk management IEC must (if is to succeed) be accepted by the FDA. The working group includes FDA representatives, who started from 2 firm beliefs: Assessment of software-related risk must assume 100% failure of software. Assessment of software risk must assume that software cannot be partitioned into items of different risk. They have moved a long way, to the benefit of all medical device manufacturers marketing in the US. They have accepted that arguments can be put (in the risk management process) for partitioning, and that prescribed development processes can reduce the software failure rate below 100%. However, to satisfy the FDA, IEC still requires the initial choice of software processes on the assumption of 100% software failure rates. This invokes the statement in ISO that any unknown risks should be assumed to be 100% probable. Lack of techniques and methods IEC does not specify any techniques or methods to achieve high-integrity software. A majority of the working group think that this would be a step too far, so it is the policy of the working group only to require processes and process elements including activities, tasks and outputs. This is the biggest area of disagreement between the working group and the IEC enthusiasts. IEC does recommend techniques and methods for each Software Integrity Level. Critics of IEC have pointed out that the correlation between methods and safety integrity is a matter of belief and is largely unproven by any evidence. Unfortunately the same can be said of the correlation between processes and safety integrity which is an underlying belief in IEC In fact the only statement that most people would accept is If you don t define and enforce software development processes you will probably get faulty software. Missing processes for Class A IEC defines safety class A as No injury is possible. This leads to some requirements that are normally expected in any software development lifecycle but are not required for class A. This has led to some misunderstanding. The standard does not intend to un-recommend such processes, merely to say that if the software can t hurt anyone, then it is a purely commercial decision whether to follow sensible practice. The standard is not concerned with faults that annoy the customer, only with those that injure patients or users. However, the process steps that lead to the safety classification are mandatory for all classes of software. This is to ensure that the classification is rigorous. Conclusions IEC 62304, if accepted, requires what reputable medical device manufacturers are already doing. I would therefore expect them to welcome it. It would remove the obligation to describe their processes in detail in regulatory submissions to the FDA. With all its limitations, I would commend IEC to you and to National Standardisation Bodies. There are still medical device manufacturers whose software development processes are quite rudimentary, and this threatens the lives of patients. IEC would prevent this and provide a more level playing field for all medical device manufacturers. There appears to be no appetite among either medical device manufacturers or regulators for a more extensive standard prescribing methods and techniques. Holding out for more at this stage would ensure that we get nothing. IEC also takes a big step towards simpler and more uniform expectations on both sides of the Atlantic.