Medi SPICE and the Development of a Process Reference Model for

Inclusion in IEC 62304

Valentine Casey and Fergal McCaffery

Dundalk Institute of Technology, Dublin Rd, Dundalk, Co. Louth, Ireland

Keywords: Medical Device Software, Software Development, Software Process Assessment, Software Process

Improvement, Medi SPICE, IEC 62304, ISO/IEC 15504-5, ISO 14971, ISO 13485, ISO/IEC 15504-2.

Abstract: The demand for medical device software continues to grow and there is an associated increase in its

importance and complexity. This paper discusses medical device software process assessment and

improvement. It outlines Medi SPICE, a software process assessment and improvement model which is

being developed to meet the specific safety-critical and regulatory requirements of the medical device

domain. It also details the development of a subset of the Medi SPICE process reference model for inclusion

in the next release of the IEC 62304 standard: Medical device software - Software life cycle processes. IEC

62304 is a key standard for medical device software development and is approved by many national

regulatory bodies including the Food and Drug Administration in the United States and the European Union.

This paper also outlines 3 lightweight software process assessment methods which have been developed in

tandem with Medi SPICE. Finally the timeline for the release of the full Medi SPICE model is provided.

1 INTRODUCTION

Today Information Technology (IT) increasingly

performs an essential role in the provision of

healthcare services (Abraham et al., 2011). This is

particularly reflected in the importance that IT now

plays in medical diagnoses and treatment (Hanna et

al., 2011). To facilitate this development the level of

software functionality in medical devices and the

complexity of that software has substantially

increased (Rakitin, 2006). The importance that

software now plays in medical devices has been

acknowledged by the European Union (EU). This is

demonstrated in the latest amendment to the Medical

Device Directive (MDD) 2007/47/EC (European

Council, 2007), which now recognizes that

standalone software can be classified as an active

medical device in its own right. Likewise in the

United States (US) the Food and Drug

Administration (FDA) have recently provided

guidance in relation to medical device data systems

(US FDA, 2011a) and draft guidance in relation to

mobile applications for medical use (US FDA,

2011b).

While the importance that medical device

software plays is now recognized, it is also realized

that it can be difficult to both successfully develop

and achieve regulatory approval for its placement on

the market (Mc Caffery et al., 2010a). This is due to

the safety-critical nature of medical device software

which must be developed to comply with numerous

specific regulations and international standards.

These are dictated by the regulatory requirements of

the geographical location where the medical device

is to be marketed (Burton et al., 2006).

Although guidance is available from regulatory

bodies in terms of what software activities must be

performed, no specific methods for performing these

activities are provided. As a result, medical device

software development organizations have been

compliance centric in their approach. This has

therefore resulted in very limited adoption of

software process improvement in the medical device

domain (Denger et al., 2007). Until relatively

recently, this was not such an important issue due to

the limited proportion of software in medical

devices. This is no longer the case and there is now a

particular requirement for highly effective and

efficient software development processes to be in

place. These processes need to be defined in a

regulatory compliant manner and then adopted to

produce the required deliverables in order to achieve

approval from the relevant body (Mc Caffery et al.,

2010a).

237

Casey V. and Mc Caffery F..

Medi SPICE and the Development of a Process Reference Model for Inclusion in IEC 62304.

DOI: 10.5220/0004082102370246

In Proceedings of the 7th International Conference on Software Paradigm Trends (ICSOFT-2012), pages 237-246

ISBN: 978-989-8565-19-8

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

To address the requirement to identify, assess,

and assist with the implementation of these

processes Medi SPICE is currently under

development. The objective of Medi SPICE is to

provide a software process assessment and

improvement model that meets the specific

requirements of the medical device industry (Mc

Caffery and Dorling, 2010). The development of

Medi SPICE is being undertaken by the Regulated

Software Research Group (RSRG) at Dundalk

Institute of Technology (DkIT) in association with

the SPICE User Group, international standards

bodies and representatives from the medical device

software industry. This collaborative process is a

key aspect of the development of Medi SPICE.

While a Medi SPICE assessment can be used to

evaluate and initiate software process improvement,

it may also be used for supplier selection. In this

context, the results from an assessment may be used

as criteria for selecting a supplier, when an

organization wishes to outsource or offshore part or

all of its medical device software development (Mc

Caffery and Dorling, 2009). This is important, as

today software has truly become a globally sourced

commodity (Casey, 2010). As a result the level of

globally distributed software medical device

development continues to increase (Sudershana et

al., 2007) (Klein et al., 2010). Given the mission

critical nature of medical device software and the

need for regulatory compliance, supplier selection is

a key activity for medical device organizations and

Medi SPICE can be utilized to help address this

need.

The rest of this paper is structured as follows: In

section 2, we discuss the regulatory requirements for

medical device software development. In particular

we focus on IEC 62304:2006 (IEC 62304:2006,

2006) and the important role it plays. We also

consider the requirements for the next release of the

IEC 62304 standard. In section 3, we provide an

overview of Medi SPICE which includes its

development, structure and processes. In section 4,

we outline the development of the IEC 62304 Medi

SPICE Process Reference Model (PRM). This is

based on the structure of ISO/IEC 12207:2008

(ISO/IEC 12207:2008, 2008) and is a subset of the

Medi SPICE PRM. It is planned that this PRM will

be included in the appendix of the next release of the

IEC 62304 standard. In section 5, we discuss the

lightweight process assessment methods we have

developed in tandem with Medi SPICE. We also

briefly outline our findings from undertaking a

lightweight Medi SPICE-Adept assessment in

Ireland and Australia. Finally in sections 6, we

provide our conclusions and future work including

the timeline for the release of the full Medi SPICE

process assessment and improvement model.

2 MEDICAL DEVICE SOFTWARE

REGULATION

Regulations, international standards, technical

reports and guidance documents play a key role in

medical device software development. As stated this

is due to the safety-critical nature of medical device

software and the need for organizations developing

such software to minimize the risk of failure and the

prevention of harm to patients, clinicians and third

parties. To address this, governments have defined

regulatory requirements and established auditing

bodies to ensure that only safe medical devices are

placed on the market (Burton, 2009).

The FDA is responsible for medical device

regulation and approval in the US. To provide

assistance in achieving regulatory approval, the FDA

have published a number of guidance documents

which outline essential activities to be performed

during software validation (US FDA Center for

Devices and Radiological Health, 2002), pre-market

submission (US FDA Center for Devices and

Radiological Health, 2005) and when using off-the-

shelf software in a medical device (US FDA Center

for Devices and Radiological Health, 1999).

Although the FDA guidance documents provide

general information on which software activities

should be performed, they do not provide specific

details on how they should be undertaken.

In the EU the CE mark is required to market a

medical device. The requirements for the

achievement of the CE mark are outlined in the

Medical Device Directive (MDD) 1993/42/EE

(European Council, 1993) and its latest amendment

MDD 2007/47/EC (European Council, 2007), the

Active Implantable Medical Device Directive

(AIMDD) 90/385/EEC (European Council, 1990)

and the In-Vitro Diagnostic Directive (IVDD)

98/79/EC (European Council, 1998). The applicable

directive(s) depend on the type of medical device

being developed.

While these directives must be adhered to, they

provide very limited information regarding the

specific requirements for medical device software

development. This is exemplified by the latest

amendment MDD 2007/47/EC which states: “For

devices which incorporate software or which are

medical software in themselves, the software must be

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

238

validated according to the state of the art taking into

account the principles of development lifecycle, risk

management, validation and verification”. The term

“state of the art” is not defined and as a result many

organizations developing medical device software

for sale in the EU rely on the regulatory guidance

documents provided by the FDA (Mc Caffery et al.,

2010a).

In order to market a medical device in China,

approval must be obtained from the State Food and

Drug Administration (SFDA). In Australia, approval

and registration is provided by the Therapeutic

Goods Administration (TGA) and in Canada, by

Health Canada. Auditing bodies performing similar

roles exist in other countries including Brazil, Japan,

India, South Korea, Singapore, Mexico and New

Zealand.

To achieve compliance with national and

regional regulatory requirements, conformance with

a number of international standards and technical

reports are recommended by auditing bodies, these

include: IEC 62304:2006 (IEC 62304:2006, 2006),

ISO 14971:2007 (ISO 14971:2007, 2007), ISO

13485:2003 (ISO 13485:2003, 2003), EN 60601-

4:2000 (BS EN 60601-1-4:2000, 2000), IEC/TR

80002-1:2009 (IEC/TR 80002-1:2009, 2009) , IEC

62366:2007 (IEC 62366:2007, 2007), IEC/TR

61508:2005 (IEC/TR 61508:2005, 2005), and IEC

60812:2006 (IEC 60812:2006, 2006). A number of

these standards are harmonized with the European

MDD and approved by the FDA. These include ISO

14971:2007, ISO 13485:2003, and IEC 62304:2006.

2.1 Risk Management

To determine the level of regulatory compliance that

is required for medical devices, auditing bodies have

adopted predefined classification schemes based on

hazard/risk posed by the medical device. The FDA

has 3 levels of concern and in the EU the MDD has

4 classes based on perceived potential hazard,

ranging from low risk to high risk. Medical devices

are evaluated against the relevant scheme and

classified. The manufacturer of the device is then

required to establish design controls in line with the

medical device’s classification level. The higher the

classification of the device, the more stringent the

design controls and constraints that must be

complied with (Mc Caffery et al., 2010a).

ISO 14971:2007 Medical Devices - Application

of risk management to medical devices is the de

facto standard for medical device risk management

(Burton, 2009). The FDA recognizes ISO

14971:2007 as an approved standard and considers

compliance with it acceptable for meeting the risk

management requirements for medical device

premarket submissions. The FDA also provide their

regulators with training in the standard as part of

their software risk management training (Mc Caffery

et al., 2010a). The EU also consider ISO 14971:2007

as a harmonized standard and conformance with the

standard is acceptable for meeting the risk

management requirements of the MDD (Harvey,

2003). In Canada, ISO 14971:2007 is a recognized

standard by Health Canada. In both Japan and

Australia, it has also become the industry standard

for managing medical device risk.

While ISO 14971:2007 is the standard that

medical device software organizations must conform

to, it was developed to address the requirements of

developing a medical device as a whole. Until

relatively recently medical devices were mostly

hardware with only a small level of software

content. As a result there is a lack of specific

information as to how ISO 14971:2007 should be

applied for medical device software development.

To address this a technical information report

IEC/TR 80002-1:2009 was released to provide

specific guidance on how ISO 14971:2007 should be

applied when developing medical device software

(Vogel, 2010).

2.2 Quality Management System

A key requirement for medical device development

is that a quality management system is in place. The

FDA define a quality system as “the organizational

structure, responsibilities, procedures, processes,

and resources for implementing quality

management” (US FDA, Revised April 1, 2011). By

ensuring conformance to the requirements of a

quality management system, medical device

organizations have the structure and support in place

to facilitate a controlled development environment.

With the objective of providing greater reliability,

safety, and the effectiveness of the devices they

produce (Mc Caffery et al., 2010a). Conformance

with the requirements of 21 CFR Part 820 Quality

System Regulations (US FDA, Revised April 1,

2011) is central to achieving FDA approval in the

US. ISO 13485:2003 Medical device - Quality

management systems- Requirements for regulatory

purpose is the international standard used for and

audited against for medical device development.

This standard is harmonized with the European

MDD and recognized by the FDA.

Medi SPICE and the Development of a Process Reference Model for Inclusion in IEC 62304

239

2.3 Medical Device Software Life Cycle

Processes

As software components were added to medical

devices, manufacturers had to consider how software

could be developed to ensure that it minimized risk

and the possibility of failure. The medical device

industry took the decision to recognize ISO/IEC

12207:1995 Information Technology - Software life

Cycle Processes (ISO/IEC 12207:1995, 1995) (a

general software engineering life cycle processes

standard) to address this situation. Subsequently, the

Association for the Advancement of Medical

Instrumentation (AAMI) software committee

reviewed ISO/IEC 12207:1995 and identified a

number of shortcomings due to the fact that it was a

generic standard.

As a result a decision was taken to create a new

standard which was domain specific to medical

device software development. When developing this

standard the AAMI did not discard the work done

with ISO/IEC 12207:1995 and used it as the

foundation for AAMI SW68:2001 (ANSI/AAMI

SW68:2001, 2001). In 2006, a new standard IEC

62304:2006 Medical device software - Software life

cycle processes, was released which was based on

the AAMI SW68:2001 standard.

IEC 62304:2006 is approved by the FDA and is

harmonized with the European MDD. It provides

coverage of the key medical device software

development processes. Software developed using

the IEC 62304:2006 standard is based on the

assumption that it is developed and maintained in

accordance with a quality management standard

(e.g. ISO 13485:2003), and the risk management

standard ISO/IEC 14971:2007. Both ISO

13485:2003 and ISO/IEC 14971:2007 are

considered to be aligned standards with IEC

62304:2006 and their relationship is documented in

(IEC 62304:2006, 2006).

IEC 62304:2006 is software specific in focus and

does not address system level processes which

include Requirements Elicitation and Validation.

These are addressed by its aligned standards and

ISO/IEC 15288: 2002 (ISO/IEC 15288:2002, 2002).

ISO/IEC 12207:1995 AMD 1:2002 (ISO/IEC

12207:1995/Amd.1, 2002) and AMD 2:2004

(ISO/IEC 12207:1995/Amd.2, 2004). These are the

foundations on which IEC 62304:2006 was

developed and their relationship is documented in

Annex C of the IEC 62304:2006 standard.

2.4 The Release of ISO/IEC 12207:2008

ISO/IEC 12207:1995 AMD 1 and AMD 2 was

recognized as comprehensive in its approach to

general software development and a number of

standards in addition to IEC 62304:2006 were

derived from it. These include ISO 15504-2:2003

(ISO/IEC 15504-2:2003, 2003), ISO/IEC 15504-

5:2006 (ISO/IEC 15504-5:2006, 2006) and ISO/IEC

90003:2004 (ISO/IEC 90003:2004, 2004). The

importance the standard plays is reflected in the fact

ISO/IEC 15504-2:2003 and the ISO/IEC 15504-

5:2006 PRM are derived directly from ISO/IEC

12207:1995 AMD 1 and AMD 2.

An extensive revision of the ISO/IEC 12207

standard took place. This was undertaken in parallel

with the revision of ISO/IEC 15288:2002. This

resulted in the release in 2008 of ISO/IEC

12207:2008 Systems and software engineering -

Software life cycle processes. The focus of the new

standard is no longer just the software engineering

life cycle processes; it now addresses the system

engineering processes as well. The structure of the

standard has been amended to reflect this change.

As a result, standards which are derived from

ISO/IEC 12207:1995 AMD 1 and AMD 2 are being

updated to conform to the new structure of ISO/IEC

12207:2008. These include the next release of

ISO/IEC 15504-5 and IEC 62304 which are

currently under review. Medi SPICE will also

conform to the new structure of ISO/IEC

12207:2008.

3 MEDI SPICE

As outlined in section 1, Medi SPICE is a software

process assessment and improvement model which

is being developed to meet the specific requirements

of the medical device industry (Mc Caffery et al.,

2010b). The results of a Medi SPICE assessment

may be used to indicate the state of a medical device

suppliers software practices in relation to the

regulatory requirements of the industry, and identify

areas for process improvement (Mc Caffery and

Dorling, 2010). The results of an assessment may

also be used as criteria for supplier selection (Mc

Caffery and Dorling, 2009). The overall objective of

Medi SPICE is to provide a conformity assessment

scheme to support first, second or third party

assessment results that may be recognized by the

regulatory bodies.

Medi SPICE is based upon ISO/IEC 15504-5 and

provides coverage of the medical device regulations,

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

240

and standards. These include the FDA regulations

and guidelines, the European MDD and the

associated approved and harmonized standards and

technical reports (Mc Caffery et al., 2010a). Medi

SPICE contains a PRM and a Process Assessment

Model (PAM)

The development of Medi SPICE commenced in

2008 with an extensive literature review and a

number of preliminary studies. This phase of the

research culminated in the identification of the

context and strategy for the development of Medi

SPICE. This aspect of the research has been

published in Medi SPICE: An Overview (Mc

Caffery and Dorling, 2009), Medi SPICE

Development (Mc Caffery and Dorling, 2010) and

Software Process Improvement in the Medical

Device Industry (Mc Caffery et al., 2010a). In 2010

work commenced on the development of a

preliminary PRM and PAM (Mc Caffery et al.,

2010b). The preliminary PRM & PAM contained 11

processes:

 Software Requirements Elicitation

 System Architectural design

 System Requirements Analysis

 Software Requirements Analysis

 Software Construction

 Software Integration

 Software Testing

 Configuration Management

 Change Request Management

 Software Verification

 Software Validation

These processes were based on the structure of

ISO/IEC 15504-5:2006 and ISO/IEC 12207:1995

AMD 1 and AMD 2. They were developed to meet

the specific requirements of the relevant medical

device regulations, standards and guidance

documents. In addition, they also conformed to the

requirements of ISO/IEC 15504-2:2003 for a PRM

and PAM. On completion, these processes were

released for review by the ISO/IEC 15504

community and representatives from the medical

device software industry. These processes have been

subsequently updated and amended to bring them in

line with ISO/IEC 12207:2008 and the latest version

of ISO/IEC 15504-5 (currently under ballot). In

addition the number of processes has been increased.

3.1 The Medi Spice Process Reference

Model (PRM)

The Medi SPICE PRM contains the set of medical

device software lifecycle processes that are

fundamental to the development of good quality

medical device systems. The PRM outlines the

purpose of each process and the outcomes that must

be accomplished to achieve that purpose.

The Medi SPICE PRM contains 2 sets of life

cycle processes. These are the Systems Life Cycle

Processes and the Software Life Cycle Processes.

These consist of 42 processes and 15 subprocesses

which are structured as follows:

The System Life Cycle Processes (contains)

 3 Agreement Processes and 7 Subprocesses;

 6 Organizational Project - Enabling Processes

and 6 Subprocesses;

 7 Project Processes;

 10 Technical Processes and 2 Subprocesses.

The Software Life Cycle Processes (contains)

 6 Software Implementation Processes;

 9 Software Support Processes which includes a

medical device specific process Hazard

Mitigation;

 1 Supplementary Process

3.2 The Medi SPICE Process

Assessment Model (PAM)

The Medi SPICE PAM is related to the Medi SPICE

PRM and forms the basis for collecting evidence and

the rating of process capability. To achieve this it

provides a two-dimensional view of process

capability. In one dimension, it describes a set of

process specific practices that allow the achievement

of the process outcomes defined in the PRM; this is

termed the process dimension.

In the other dimension, the PAM describes

capabilities that relate to the process capability

levels and process attributes, this is termed the

capability dimension. Indicators for process

capability are generic practices that are applicable to

any process and associated with process attributes,

generic work products and generic resources that can

be observed when a particular process attribute is

achieved (ISO/IEC 15504-2:2003, 2003). In line

with ISO/IEC 15504 the Medi SPICE process

capability is defined over 6 levels:

Level 0 Incomplete;

 Level 1 Performed;

 Level 2 Managed;

 Level 3 Established;

 Level 4 Predictable;

 Level 5 Optimizing.

Medi SPICE and the Development of a Process Reference Model for Inclusion in IEC 62304

241

The Medi SPICE PRM and PAM are being released

in stages and each stage is extensively reviewed

prior to release.

3.3 The Medi SPICE and IEC

62304:2006

Given the importance of IEC 62304:2006 to medical

device software development, conformance to this

standard plays a key role in the development of

Medi SPICE along with its aligned standards. As

discussed in section 2, IEC 62304:2006 is currently

being revised. As part of this revision, it is being

aligned with ISO 12207:2008; it therefore requires

that IEC 62304 should contain a PRM. As stated it is

proposed the IEC 62304 revision will contain a

subset of the Medi SPICE PRM (the Medi SPICE

processes that will be included in the revision of IEC

62304). This will enable the relevant IEC 62304

processes to be comparable with those of ISO

12207:2008. It will also provide IEC 62304 with a

PRM that may be used as the foundation for a

process assessment model specifically for

compliance with this standard.

4 DEVELOPMENT OF THE IEC

62304 MEDI SPICE PRM

The first step in the development of the IEC 62304

Medi SPICE PRM was the identification of the

ISO/IEC 12207:2008 processes which were directly

relevant to IEC 62304:2006. This was facilitated by

the fact that IEC 62304:2006 documents its

relationship to ISO/IEC 12207:1995 AMD 1 and

AMD 2 at the process, activity and task level in

Table C.5 of the standard.

Utilizing this information all the relevant IEC

62304:2006 processes, activities and tasks were

identified and mapped against ISO/IEC 12207:2008.

To achieve this a document was produced based on

Table C.5 in the IEC 62304:2006 standard, but it

was extended to include full details of the ISO/IEC

12207:1995 AMD 1 and AMD 2 tasks upon which

the IEC 62304:2006 activities and tasks were based.

In Table C.5 (within IEC 62304:2006) these tasks

were only referenced. Analyzing this information

and comparing it against ISO/IEC 12207:2008

allowed a direct mapping to be made between the

processes and activities. The tasks were also

analyzed in detail and any differences highlighted

and evaluated.

Due to the restructuring that took place in

ISO/IEC 12207:2008 and the changes required to

facilitate this, the names and locations of a number

of processes, activities and tasks changed from the

previous release of the standard. While at the task

level only cosmetic adjustments had been made i.e.

the use of the term “implementer” instead of

“developer” and the addition of brief notes to a

limited number of tasks. The only relevant task

omitted from ISO/IEC 12207:2008 which had been

in ISO/IEC 12207:1995 AMD 1 and AMD 2 and

referenced by IEC 62304:2006 was 6.4.2.2 Process

Verification. This task had been used as the basis for

the Verify Integration Tests Procedures task in IEC

62304:2006. While this task is absent from ISO/IEC

12207:2008 this is a requirement of IEC 62304:2006

and it was therefore retained in the Medi SPICE

PRM.

Having identified the relevant ISO/IEC

12207:2008 processes these were compared with the

Medi SPICE PRM processes and the next release of

ISO/IEC 15504-5. This resulted in the selection of

13 processes for inclusion in the IEC 62304 Medi

SPICE PRM. This included an extra process Hazard

Mitigation which is not an ISO/IEC 12207:2008

process as it is medical device software specific.

The processes which were identified as suitable

for inclusion in the IEC 62304 PRM are as follows:

 Software Implementation

 Software Operation

 Software Maintenance

 Software Requirements Analysis

 Software Architectural Design

 Software Detailed Design

 Software Construction

 Software Integration

 Software Qualification Testing

 Software Configuration Management

 Software Problem Resolution

 Hazard Mitigation

 Software Change Request Management

The relationship between these processes and IEC

62304:2006 are detailed in figure 1.

The set of processes were then reviewed by both

members of the IEC SC62A JWG3 Standards

Working Group (the IEC 62304 development team)

and the ISO/IEC 15504 community. Having agreed

the processes, development of the IEC 62304 Medi

SPICE PRM commenced. Each process was

developed in line with the requirements of a PRM as

defined in ISO/IEC 15504-2:2003 (ISO/IEC 15504-

2:2003, 2003). This included assigning a process ID,

a process name and defining a process purpose.

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

242

Figure 1: The IEC 62304 Medi SPICE PRM processes for

inclusion in the IEC 62304 PRM and their relationship to

IEC 62304:2006.

Based on the process purpose outcomes were

identified. The objective of each outcome was to

contribute to the achievement of the process

purpose. While the purpose and outcomes addressed

the requirements of medical device software

development and IEC 62304:2006 they were also

inclusive of the requirements of the aligned, medical

device standards and regulations. These included the

FDA regulations and guidance documents, the

requirements of the European MDD, ISO

14971:2007, ISO 13485:2003 and IEC/TR 80002-

1:2009. The PRM recorded the source of each

outcome and where relevant each outcome received

an IEC 62304 safety classification. Once the IEC

62304 Medi SPICE PRM was complete it was sent

for review and evaluation by the ISO/IEC 15504

community and the IEC SC62A JWG3 Standards

Working Group. Based on the successful completion

of these reviews and receipt of approval from the

Standards Working Group it is now planned to

include the IEC 62304 Medi SPICE PRM in the

Appendix of the forthcoming release of IEC 62304.

5 THE DEVELOPMENT OF

LIGHTWEIGHT ASSESSMENT

METHODS

An important part of this ongoing research has been

the development of 3 lightweight medical device

software process centric assessment methods. The

first was Med-Adept (Mc Caffery and Casey, 2010)

which is a lightweight assessment method that

provides a means of assessing the software

engineering capability of processes in relation to

medical device software development. The goal of a

Med-Adept assessment is to provide organizations

who may be considering developing medical device

software with an understanding of what they would

need to have in place before embarking on such a

strategy. To date a total of 8 Med-Adept assessments

have taken place.

Traceability plays a key role in the development

of regulatory compliant medical device software

(Mc Caffery and Casey, 2011). Med–Trace was

developed as an assessment method specifically to

assist companies to adhere to the traceability aspects

of the medical device software standards (Casey and

Mc Caffery, 2011). The objective of Med-Trace is to

enable software development organizations to gain

an appreciation of fundamental traceability best

practices, based on the software engineering

traceability literature, software engineering process

models, and the medical device software guidelines

and standards. To achieve this, Med-Trace may be

used to diagnose an organization’s weaknesses and

strengths with relation to their medical device

software development traceability practices. Med-

Trace assessments have taken place in 4 companies

and another 1 is currently in the planning stage.

The third lightweight assessment method is Medi

SPICE-Adept (Mc Caffery et al., 2011). This

method was initially based on the assessment of the

11 processes which made up the preliminary Medi

SPICE PRM and PAM. While these were the initial

processes selected for Medi SPICE-Adept. These

have been updated and will be expanded to provide

coverage of all the Medi SPICE processes and

Medi SPICE and the Development of a Process Reference Model for Inclusion in IEC 62304

243

subprocesses.

Medi SPICE-Adept provides organizations with

a lightweight assessment of each of the processes

they select with the Medi SPICE Model. This covers

conformance to the specific requirements of the

medical device regulations, standards, and guidance

documents. It also provides a method for carrying

out an assessment, against the requirements for best

software engineering practice for each process. That

said, it is a lightweight method and the objective of

undertaking a Medi SPICE-Adept assessment, is not

to receive formal certification or a capability rating.

Rather it is to identify an organization’s strengths

and weaknesses and to initiate and facilitate process

improvement.

5.1 Implementation of Medi SPICE-

Adept

The first Medi SPICE-Adept assessment took place

in an Irish based medical device company Western

Medical (a pseudonym). The company selected 10

processes and these were assessed over a two day

period. Based on the results of the assessment, a

findings report was prepared and presented. Process

improvement objectives and a process improvement

plan were collaboratively defined and developed

with the company, based on the findings report. The

improvement plan is currently being implemented

and when this is complete the processes will be

reassessed. A final detailed report will then be

prepared and an updated improvement plan will also

be provided.

The findings report and improvement plan were

very positively received by Western Medical as was

the whole assessment procedure. A Medi SPICE-

Adept assessment has also recently been

successfully implemented in Australia by colleagues

in Griffith University. The Australian assessment

provided similar positive feedback. Given the level

of demand the RSRG will continue to carry out

additional Medi SPICE-Adept assessments both in

Ireland and in collaboration with international

colleagues.

5.2 The Rationale for Developing

Lightweight Assessment Methods

There was a specific demand in the industry for the

development of each of these lightweight assessment

methods and their introduction has been welcomed.

While this was the case, the purpose of their

development was not solely to address these

requirements. The implementation of each of these

methods has allowed key aspects of Medi SPICE to

be tested and refined in an industrial setting. It has

also provided relevant feedback which has been

documented and incorporated into subsequent

iterations of the Medi SPICE model. This is seen as

a key element in the development of Medi SPICE.

This was also the rationale for the development of

the lightweight assessment methods in tandem with

the development of Medi SPICE.

6 CONCLUSIONS

It was decided in 2011 that Medi SPICE would

conform to the structure of ISO/IEC 12207:2008 and

the latest version of ISO/IEC 15504-5 (currently

under ballot). As outlined in section 3 the structure

and processes which make up the current version of

the Medi SPICE PRM were selected and agreed.

Work on the detailed development of the PRM

commenced.

Following the invitation to add a subset of the

Medi SPICE PRM to the next release of the IEC

62304 standard, work commenced on the production

of the IEC 62304 Medi SPICE PRM. As outlined in

Section 4 this work is now complete. The

development of the remaining Medi SPICE PRM

and PAM processes is currently under way. The full

Medi SPICE PRM is scheduled for release in

September 2012. This will be followed by the

release of the Medi SPICE PAM by the end of

December 2012. This will see the release of the full

Medi SPICE process assessment and improvement

model by January 2013. At that stage additonal

research will be undertaken on its implementation

and to facilitate continued improvement.

ACKNOWLEDGEMENTS

This research is supported by the Science

Foundation Ireland (SFI) Stokes Lectureship

Programme, grant number 07/SK/I1299, the SFI

Principal Investigator Programme, grant number

08/IN.1/I2030 (the funding of this project was

awarded by Science Foundation Ireland under a co-

funding initiative by the Irish Government and

European Regional Development Fund), and

supported in part by Lero - the Irish Software

Engineering Research Centre (http://www.lero.ie)

grant 10/CE/I1855.

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

244

REFERENCES

Abraham, C., Nishiharas, E. & Akiyama, M. (2011)

Transforming healthcare with information technology

in Japan: A review of policy, people, and progress.

International Journal of Medical Informatics, 80, 157-

170.

ANSI/AAMI SW68:2001 (2001) Medical device software

- Software life cycle processes. Arlington, AMMI.

BS EN 60601-1-4:2000 (2000) Medical Electrical

Equipment, Part 1 - General requirements for safety.

London, BSI.

Burton, J. (2009) The Medical Device Industry:

Development in Software Risk Management,

Newcastle upon Tyne, Cambridge Scholars

Publishing.

Burton, J., Mc Caffery, F. & Richardson, I. (2006) A risk

management capability model for use in medical

device companies. International Workshop on

Software quality (WoSQ '06). Shanghai, China, ACM.

Casey, V. (2010) Virtual Software Team Project

Management. Journal of the Brazilian Computer

Society, 16, 83 – 96.

Casey, V. & Mc Caffery, F. (2011) Med-Trace:

Traceability Assessment Method for Medical Device

Software Development. IN 2011 (Ed.) European

Systems and Software Process Improvement and

Innovation Conference. Roskilde University,

Denmark.

Denger, C., Feldmann, R., Host, M., Lindholm, C. &

Shull, F. (2007) A Snapshot of the State of Practice in

Software Development for Medical Devices. First

International Symposium on Empirical Software

Engineering and Measurement. Madrid, Spain.

European Council (1990) Council Directive 90/385/EEC

On the approximation of the laws of the Members

States relating to active implantable medical devices.

Luxembourg, Official Journal of The European

Communities].

European Council (1993) Council Directive 93/42/EEC

Concerning Medical Devices. Luxembourg, Official

Journal of The European Communities.

European Council (1998) Council Directive 98/79/EC On

in vitro diagnostic medical devices. Official Journal of

The European Communities, Luxembourg.

European Council (2007) Council Directive 2007/47/EC

(Amendment). Luxembourg, Official Journal of The

European Union.

Hanna, S., Rolf, R., Molina-Markham, A., Poosankam, P.,

Fu, K. & Song, D. (2011) Take two software updates

and see me in the morning: the case for software

security evaluations of medical devices. The 2nd

USENIX conference on Health security and privacy.

San Francisco, CA, USA.

Harvey, R. (2003) Do We Need Medical Device Risk

Management Certification? Medical Device &

Diagnostic Industry, 25, 44 49.

IEC 60812:2006 (2006) Analysis technique for system

reliability - Procedure for failure modes and effects

analysis (FMEA). Second ed. Geneva, Switzerland,

IEC.

IEC 62304:2006 (2006) Medical device software—

Software life cycle processes. Geneva, Switzerland,

IEC.

IEC 62366:2007 (2007) Medical devices - Application of

usability engineering to medical devices. Geneva,

Switzerland, IEC.

IEC/TR 61508:2005 (2005) Functional safety of

electrical/electronic/ programmable electronic safety

related systems. London, BSI.

IEC/TR 80002-1:2009 (2009) Medical device software

Part 1: Guidance on the application of ISO 14971 to

medical device software. London, BSI.

ISO 13485:2003 (2003) Medical devices — Quality

management systems — Requirements for regulatory

purposes. Second ed. Geneva, Switzerland, ISO.

ISO 14971:2007 (2007) Medical Devices — Application

of risk management to medical devices. Second ed.

Geneva, ISO.

ISO/IEC 12207:1995 (1995) Information Technology —

Software life Cycle Processes. Geneva, Switzerland,

ISO.

ISO/IEC 12207:1995/AMD.1 (2002) Information

Technology — Software life Cycle Processes

Amendment 1. Geneva, Switzerland, ISO.

ISO/IEC 12207:1995/AMD.2 (2004) Information

Technology — Software life Cycle Processes

Amendment 2. Geneva, Switzerland, ISO.

ISO/IEC 12207:2008 (2008) Systems and software

engineering - Software life cycle processes. Geneva,

Switzerland, ISO.

ISO/IEC 15288:2002 (2002) Systems Engineering —

System life cycle processes. Geneva, Switzerland,

ISO.

ISO/IEC 15504-2:2003 (2003) Software engineering -

Process assessment - Part 2: Performing an

assessment. Geneva, Switzerland, ISO.

ISO/IEC 15504-5:2006 (2006) Information technology -

Process Assessment - Part 5: An Exemplar Process

Assessment Model. Geneva, Switzerland, ISO.

ISO/IEC 90003:2004 (2004) Software engineering --

Guidelines for the application of ISO 9001:2000 to

computer software. Geneva, Switzerland, ISO.

Klein, H., Rausch, A., Kunzle, M. & Fischer, E. (2010)

Application of Collaborative Scenarios in a Process-

Based Industrial Environment. 36th EUROMICRO

Conference on Software Engineering and Advanced

Applications (SEAA). Lille, France.

Mc Caffery, F., Burton, J., Casey, V. & Dorling, A.

(2010a) Software Process Improvement in the Medical

Device Industry. IN LAPLANTE, P. (Ed.)

Encyclopedia of Software Engineering. New York,

CRC Press Francis Taylor Group.

Mc Caffery, F. & Casey, V. (2010) Med-Adept: A

Lightweight Assessment Method for the Irish Medical

Device Software Industry. European Systems &

Software Process Improvement and Innovation

Conference, (EuroSPI). Grenoble, France.

Medi SPICE and the Development of a Process Reference Model for Inclusion in IEC 62304

245

Mc Caffery, F. & Casey, V. (2011) Med-Trace. 11th

International SPICE Conference on Process

Improvement and Capability dEtermination. Dublin

City University, Ireland.

Mc Caffery, F., Casey, V. & Mc Hugh, M. (2011) How

Can Software SMEs become Medical Device Software

SMEs. IN O'CONNOR, R. V., PRIES-HEJE, J. & R.,

M. (Eds.) European Systems & Software Process

Improvement and Innovation Conference, (EuroSPI).

Copenhagen, CCIS.

Mc Caffery, F. & Dorling, A. (2009) Medi SPICE: An

Overview. International Conference on Software

Process Improvement and Capability Determinations

(SPICE). Turku, Finland.

Mc Caffery, F. & Dorling, A. (2010) Medi SPICE

Development. Software Process Maintenance and

Evolution: Improvement and Practice Journal, 22, 255

– 268.

Mc Caffery, F., Dorling, A. & Casey, V. (2010b) Medi

SPICE: An Update. International Conference on

Software Process Improvement and Capability

Determinations (SPICE). Pisa, Italy, Edizioni ETS.

Rakitin, R. (2006) Coping with defective software in

medical devices. Computer, 39, 40 - 45.

Sudershana, S., Villca-Roque, A. & Baldanza, J. (2007)

Successful Collaborative Software Projects for

Medical Devices in an FDA Regulated Environment:

Myth or Reality. International Converence on Global

Software Engineering. Brazil.

US FDA (2011a) 21 CFR Part 880 Medical Devices;

Medical Device Data Systems Final Rule. Federal

US FDA (2011b) Draft Guidance for Industry and Food

and Drug Administration Staff Mobile Medical

Applications, July 21.

http://www.fda.gov/downloads/MedicalDevices/Devic

eRegulationandGuidance/GuidanceDocuments/UCM2

63366.pdf, Accessed 20th February 2012.

US FDA (Revised April 1, 2011) 21 CFR Part 820 Quality

System Regulations. Code of Federal Regulations,

Title 21, 8.

US FDA Center For Devices And Radiological Health

(1999) Off-The-Shelf Software Use in Medical

Devices; Guidance for Industry, medical device

Reviewers and Compliance. Rockville, CDRH.

US FDA Center For Devices And Radiological Health

(2002) General Principles of Software Validation;

Final Guidance for Industry and FDA Staff. Rockville,

CDRH.

US FDA Center For Devices And Radiological Health

(2005) Guidance for the Content of Premarket

Submissions for Software Contained in Medical

Devices. Rockville, CDRH.

Vogel, D. A. (2010) Medical Device Software

Verification, Validation and Compliance, Norwood

MA, Artech House.

ICSOFT 2012 - 7th International Conference on Software Paradigm Trends

246