X. Medical Device Software Traceability Fergal Mc Caffery*, Valentine Casey*, M S Sivakumar*, Gerry Coleman*, Peter Donnelly*, John Burton 1 *Regulated Software Research Group, Lero, Dundalk Institute of Technology, Ireland 1 Vitalograph Ireland Ltd. Ireland Abstract Software traceability is central to medical device software develop- ment and essential for regulatory approval. In order to comply with the regulatory requirements of the medical device industry it is essential to have clear linkages and traceability from requirements - including risks - through the different stages of the software development and maintenance lifecycles. The regulatory bodies request that medical device software development organizations clearly demon- strate how they follow a software development lifecycle without mandating a par- ticular lifecycle. However, due to the traceability requirements of the industry most medical device companies adopt the V-model. Within this chapter we will discuss the importance of traceability to medical device software development, the current state of practice within the industry in relation to traceability and how we feel that traceability could be improved within the industry. The chapter also de- scribes the development and implementation of a medical device traceability soft- ware process assessment method (Med-Trace) in two medical device software de- velopment organizations. We include these two case studies as one involved a medical device SME based in Ireland and the other a medical device SME based in the UK as we want to illustrate that Med-Trace can be applied within different countries. Keywords: Medical device standards, Medical device software traceability, Medi- cal device software process assessment and improvement X.1 Introduction Software is becoming an increasingly important component of medical devices, as it enables often complex functional changes to be implemented without having to change the hardware [1]. With increasing demands for greater functionally within medical devices, the complexity of medical device software development also in- creases [2]. This therefore places increased demands for appropriate traceability and risk management processes and tools.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
X. Medical Device Software Traceability
Fergal Mc Caffery*, Valentine Casey*, M S Sivakumar*, Gerry Coleman*,
Peter Donnelly*, John Burton1
*Regulated Software Research Group, Lero, Dundalk Institute of Technology, Ireland 1Vitalograph Ireland Ltd. Ireland
Abstract Software traceability is central to medical device software develop-
ment and essential for regulatory approval. In order to comply with the regulatory
requirements of the medical device industry it is essential to have clear linkages
and traceability from requirements - including risks - through the different stages
of the software development and maintenance lifecycles. The regulatory bodies
request that medical device software development organizations clearly demon-
strate how they follow a software development lifecycle without mandating a par-
ticular lifecycle. However, due to the traceability requirements of the industry
most medical device companies adopt the V-model. Within this chapter we will
discuss the importance of traceability to medical device software development, the
current state of practice within the industry in relation to traceability and how we
feel that traceability could be improved within the industry. The chapter also de-
scribes the development and implementation of a medical device traceability soft-
ware process assessment method (Med-Trace) in two medical device software de-
velopment organizations. We include these two case studies as one involved a
medical device SME based in Ireland and the other a medical device SME based
in the UK as we want to illustrate that Med-Trace can be applied within different
countries.
Keywords: Medical device standards, Medical device software traceability, Medi-
cal device software process assessment and improvement
X.1 Introduction
Software is becoming an increasingly important component of medical devices, as
it enables often complex functional changes to be implemented without having to
change the hardware [1]. With increasing demands for greater functionally within
medical devices, the complexity of medical device software development also in-
creases [2]. This therefore places increased demands for appropriate traceability
and risk management processes and tools.
2
Due to the safety-critical nature of medical device software it is important that
highly effective software development practices are in place within medical device
companies. Medical device companies must comply with the regulatory require-
ments of the countries in which they wish to sell their devices [3]. To tackle these
issues, governments have put in place regulatory bodies whose role is to define
regulatory systems for medical devices and to ensure that only safe medical devic-
es are placed on the market [4]. Although guidance exists from regulatory bodies
on what software activities must be performed, no specific method for performing
these activities is outlined or enforced [5].
To this end, in the USA, the Food and Drug Administration (FDA) Center for
Devices and Radiological Health (CDRH) has published guidance papers which
include risk-based activities to be performed during software validation [6], pre-
market submission [7] and when using off-the-shelf software in a medical device
[8]. Although the CDRH guidance documents provide information on which
software activities should be performed, they do not enforce any specific method
for performing these activities. The obvious implication of this is that medical de-
vice manufacturers could fail to comply with the expected requirements.
Therefore, within the medical device industry a decision was made to recognize
ISO/IEC 12207:1995 [9] (a general software engineering lifecycle process stand-
ard) as being suitable for general medical device software development. Howev-
er, the Association for the Advancement of Medical Instrumentation (AAMI)
software committee carefully reviewed ISO/IEC 12207:1995 and decided that, due
to a number of shortfalls, it was necessary to create a new standard specifically for
medical device software development. The AAMI used ISO/IEC 12207:1995 as
the foundation for their new standard “AAMI SW68, Medical device software –
Software lifecycle processes” [12]. In 2006, a new standard AAMI/IEC 62304
[10] was released that was based on the AAMI SW68 standard.
In 1993, the Council of the European Communities published the Council Di-
rective 93/42/EEC (1993) [11], the “Medical Device Directive” (MDD), on medi-
cal devices. The MDD is intended to ensure the safety of medical devices placed
on the market in the European Union, and has the backing of national legislation
in member states. Amendments to this directive occurred via Directives
2000/70/EC (2000) [12], 2001/104/EC (2001) [13], 2003/32/EC (2003) [14], and
2007/47/EC (2007) [15].
Whenever we mention medical device guidelines within this chapter we refer
to the following medical device standards and guidelines: IEC 62304, FDA, the
MDD, ISO 14971 [16], EN 60601-4 [17], TIR 32 [18], IEC 80002-1[19], IEC
62366 [20], GAMP 5 [21], IEC/TR 61508 [22], ISO 13485[23] and IEC 60812
[24].
In this context, we embarked on a study of Software Traceability, which is crit-
ical to the requirements and safety aspects of software for medical devices. Within
this chapter we include the following sections:
2. Requirements for traceability in the context of software development
for medical devices;
3. The development of an software traceability process assessment meth-
od (Med-Trace) for determining the capability of a medical device soft-
3
ware development organization to perform regulatory compliant and ef-
fective traceability;
4. Implementation of Med-Trace within two medical device software de-
velopment organizations;
5. How each of the two assessed organizations plan to improve traceabil-
ity;
6. Challenges the medical device software industry is facing in terms of
implementing traceability;
7. Foundation for further research in this area and how Med-Trace may
be rolled out to assist organizations.
X.2 Requirements for medical device software traceability
In order to understand the requirements for traceability in the context of medical
device software development we conducted a literature review of generic practices
for software traceability and in particular a review of the medical device standards
requirements for traceability.
X.2.1 Traceability Literature Review
The literature review was undertaken in three stages and focused on:
Generic software development and traceability;
Safety-critical software development and traceability;
Medical device software traceability requirements.
X.2.2 Traceability for Generic Software Development
“Requirements traceability refers to the ability to describe and follow the life of a
requirement in both a forwards and backwards direction - i.e. from its origins,
through its development and specification, to its subsequent deployment and use,
and through periods of on-going refinement and iteration in any of these phases”
[25]. An important focus of requirements traceability is identifying how high level
requirements are transformed into low level requirements and how these are sub-
sequently implemented in the software product. Initially requirements traceability was utilized as an aid in tracing requirements
from customer/stakeholder needs to implementation and final verification before
delivering the product to the customer. The role traceability plays has expanded
and it has become an important tool in the software development activities of pro-
ject management, change management, and defect management [26]. This is par-
4
ticularly relevant as software development is increasingly globally distributed
across multiple teams and sites [27], [28]. It is therefore essential to have an ef-
fective traceability process in place as it provides an essential support for develop-
ing high quality software systems [29].
When considering generic software development, two of the most popular
process assessment and improvement frameworks are the Capability Maturity
Model® Integration (CMMI
®) [30] and ISO/IEC 15504-5:2006 [31], [32]. Both
recognize the importance traceability plays and incorporate it in their respective
models. Each model was reviewed in detail with regard to the requirement for ef-
fective traceability and how this was addressed.
X.2.3 Traceability for Safety-Critical Development
Software products are increasingly being deployed in complex, potentially dan-
gerous products such as military systems, cars, aircrafts and medical devices.
Software products for these areas can be critical because failure can result in loss
of life, significant environmental damage, or major financial loss [33].
Traceability is especially vital for critical systems which must satisfy a range of
functional and non-functional requirements, including safety, reliability and avail-
ability [34].
Within the safety-critical software arena, different standards/certifications are
available for different industries. These include DO-178B [35] for the Aerospace
industry, with Automotive SPICE [36] and ISO 26262 [37] being required in the
Automotive industry. IEC 60880 [38] describes the European standards for certi-
fication of nuclear power generating software and IEC/TR 61508 [22] describes a
general-purpose hierarchy of safety-critical development methodologies that have
been applied to a variety of domains ranging from medical instrumentation to
electronic switching of passenger railways. Requirements traceability is an impor-
tant clause in all the above mentioned standards/certifications.
In addition to the software development lifecycle, a software safety lifecycle
has also to be implemented for safety-critical systems. It is crucial to maintain
traceability between the software safety requirements, the decisions taken during
design, and their actual implementation in the code. This is a complex task and
needs to be performed whilst the system is being developed and not after the de-
velopment has finished [39].
X.2.4 Medical Device Software Traceability Requirements
A detailed review was undertaken of the medical device guidelines with regard to
traceability. A key point to emerge from this study is that while requirements
5
traceability is essentially part of risk management, hazard traceability is of equal
importance in medical device software development. The most relevant findings
regarding traceability are presented here in summary.
X.2.4.1 ANSI/AAMI/IEC 62304:2006
In 2006, ANSI/AAMI/IEC 62304:2006 (Medical Device Software – Software Life
Cycle Processes) was released. Traceability plays a key role in this standard and
is defined as the “Degree to which a relationship can be established between two
or more products of the development process” [10]. It is specifically addressed in
the following sections of the standard: Section 5.1 states that “the manufacturer
shall establish a software development plan for the development activity”. This
plan shall address "Traceability between system requirements, software require-
ments, software system test, and risk control measures implemented in the soft-
ware". Section 5.2 specifies that “the manufacturer shall verify and document that
the software requirements are traceable to the system requirements or other
source.” Section 5.7 states that “the manufacturers shall verify that the software
system test procedures trace to the software requirements”. In section 7.3 Verifica-
tion of Risk Control Measures the standard specifies that “the Manufacturer shall
document traceability of software hazards as appropriate: From the hazardous
situation to the software item. From the software item to the specific software
cause. From the software cause to the risk control measure and from the risk con-
trol measure to the verification of the risk control measure”
As part of the Configuration Management Process in section 8 the standard
specifies that “the manufacturer shall create an audit trail whereby each change
request, problem reports and approval of change request can be traced.
Traceability is also addressed in B.6 Software Maintenance Process which
states “It is especially important to verify through trace or regression analysis that
the risk control measures built into the device are not adversely changed or modi-
fied by the software change that is being implemented as part of the software
maintenance activity”.
X.2.4.2 Medical Device Directive and Amendments
The European Medical Device Directive (MDD) [14] mentions traceability twice,
but only in relation to the calibration of test equipment: In 2007, Directive
2007/47/EC added the following amendment to section 8 of the MDD: “For de-
vices which incorporate software or which are medical software in themselves, the
software must be validated according to the state of the art taking into account the
principles of the development lifecycle, risk management, validation and verifica-
tion”[15]. It is in this context that effective software requirements and risk man-
agement traceability are essential to achieve state of the art validation.
6
X.2.4.3 General Principles of Software Validation
The US FDA CDRH General Principles of Software Validation; Final Guidance
for Industry and FDA Staff document [6] provides guidance on validation and
traceability in medical device software development. The scope of the document
outlines that traceability is an important activity that provides support to achieve a
final conclusion that software is validated. Under section 3.1.2 it states: “the vali-
dation of software typically includes evidence that all software requirements have
been implemented correctly and completely and are traceable to system require-
ments”. In section 3.2 it specifies that “software validation includes confirmation
of conformance to all software specifications and confirmation that all software
requirements are traceable to the system specifications”. The document goes on to
outline in section 5 that traceability is key across almost all of the software devel-
opment processes and especially in relation to the requirements, design, construc-
tion and test processes.
X.2.4.3 Premarket Submissions for Software Contained in Medical Devices
The FDA CDRH document Guidance for the Content of Premarket Submissions
for Software Contained in Medical Devices [7] provides information to industry
regarding the documentation to include in premarket submissions for software de-
vices, including standalone software applications and hardware-based devices that
incorporate software. In this document traceability analysis is defined as linking
together the product design requirements, design specifications, and testing re-
quirements. It also provides a means of tying together identified hazards with the
implementation and testing of the mitigations. It also states that traceability analy-
sis should be included as part of the premarket submission for Moderate and Ma-
jor level of concern medical devices.
X.2.4.4 Off-The-Shelf Software Use in Medical Devices
The FDA CDRH Guidance for Industry, FDA Reviewers and Compliance on Off-
The-Shelf Software Use in Medical Devices [8] document was developed to ad-
dress the many questions asked by medical device manufacturers regarding what
they need to provide in a pre-market submission to the FDA when they adopt Off-
The-Shelf (OTS) software. With regard to traceability it states: “The introduction
of new or modified OTS components to a product baseline may impact the safety
of the product. Therefore a safety impact assessment of the medical device must
be performed and the associated hazards documented in a Failure Modes and Ef-
fects Analysis (FMEA) table. Each hazard’s consequence should be provided and
expressed qualitatively; e.g., major, moderate, or minor. Traceability between
these identified hazards, their design requirements, and test reports must be pro-
vided”.
7
X.2.4.5 ISO 14971:2007
ISO 14971:2007 (Medical devices - Application of risk management to medical
devices) [16] is the de-facto standard on risk management for medical devices.
The FDA recognize the standard [6] and agree compliance with it as acceptable
for pre-market submissions in the US [7]. In the EU, conformance with the stan-
dard is also acceptable for meeting the requirements of the medical device direc-
tives. In section A.2.3.5 the standard defines the risk management file as: “Where
the manufacturer can locate or find the locations of all the records and other
documents applicable to risk management. This facilitates the risk management
process and enables more efficient auditing to the standard. Traceability is neces-
sary to demonstrate that the risk management process has been applied to each
identified hazard.”
X.2.4.6 IEC/TR 80002-1:2009
IEC/TR 80002-1:2009 (Medical Device Software – Part 1: Guidance on the ap-
plication of ISO 14971 to medical device software) [19]. Though this technical re-
port does not add to, or otherwise change, the requirements of ISO 14971:2007, it
does provide direction on how the standard can be implemented specifically for
medical device software. The technical report states: “The software process should
set up a system that makes traceability possible, starting from the software-related
hazards and the software risk control measures and tracing their implementation to
the corresponding safety-related software requirements and the software items that
satisfy those requirements. All of these should be traceable to their verification”.
X.2.4.7 ISO 13485:2003
ISO 13485:2003 (Medical devices - Quality management systems – Requirement
for regulatory purposes). The standard specifies requirements for a quality man-
agement system that can be used by an organization for the design and develop-
ment, production, installation and servicing of medical devices, and the design,
development, and provision of related services [23]. With reference to traceabil-
ity, the standard states in section 7.5.3.2.1: “The organization shall establish
documented procedures for traceability. Such procedures shall define the extent of
product traceability and the records required”. It goes on in section 7.5.3.2.2 with
reference to “Particular requirements for active implantable medical devices and
implantable medical devices” to state: “In defining the records required for trace-
ability, the organization shall include records of all components, materials and
work environment conditions, if these could cause the medical device not to sat-
isfy its specified requirements. The organization shall require that its agents or dis-
tributors maintain records of the distribution of medical devices to allow traceabil-
8
ity and that such records are available for inspection. Records of the name and ad-
dress of the shipping package consignee shall be maintained.”
X.2.2.8 Traceability for Medical Device software development
Software development for medical devices can be a difficult and complex endeav-
our compared to other domains. Safety is a key area which must be successfully
addressed given the potential for harm that defective medical device software can
cause. An analysis of medical device recalls by the FDA in 1996 [40] found that
software was increasingly responsible for product recalls: In 1996, 10% of product
recalls were caused by software-related issues. The standards and guidelines cre-
ated to overcome this have already been discussed, but problems still persist. In
the period the 1st November 2009 to 1
st November 2010 the FDA recorded 78
medical device recalls and state software as the cause [41].
Our literature review highlighted there was a limited amount of published ma-
terial regarding implementation challenges and advances in the field of traceability
in medical device software. This was in contrast to other sectors in the same con-
text e.g., automotive and aerospace software development. Another important as-
pect to emerge from our literature review was that while there is a requirement to
address traceability, and undertake traceability analysis, there is limited guidance
available to help implement traceability effectively in organizations. This finding
is in line with a review of guidance for all aspects of medical device software de-
velopment which took place in 2009 [42].
X.3 Development of the Med-Trace Assessment Method
One of the main aims of the Regulated Software Research Group in Dundalk Insti-
tute of Technology is to support the growth of a medical device software devel-
opment industry within Ireland. Therefore, as traceability is central to the devel-
opment of regulatory compliant software development we decided to develop an
assessment method specifically to assist companies to adhere to the traceability
aspects of the medical device software standards.
The Adept method [43] was previously developed to provide a lightweight as-
sessment of software processes from CMMI® and ISO/IEC 15504-5 and was not
domain specific. The Adept method provides an organization with a choice of 12
process areas that may be assessed using Adept. However, based upon previous
research four of these process areas are considered to be important to the success
of any software development company and these processes are therefore manda-