A ROADMAP TO IMPLEMENT A QUALITY MANAGEMENT

SYSTEM

Derek Flood, Fergal Mc Caffery, Valentine Casey

Dundalk Institute of Technology, Dublin Rd, Dundalk, Ireland
{derek.flood,fergal.mccaffery,val.casey}@dkit.ie

Keywords: Medical Devices, Software Process Improvement, Roadmaps, Quality Management System.

Abstract: In recent years the proportion and complexity of software in medical devices has increased considerably.
This has presented an opportunity for software development organisations to expand into the medical device
domain. Due to the high level of risk associated with medical devices, strict regulations must be adhered to
in order to market such products. One key aspect of these regulations is the necessity to have in place a
Quality Management System to help ensure an organisations’ ability to consistently meet customer and
regulatory requirements. This paper presents a roadmap which can be used to assist organisations, wishing
to develop medical device software to implement a Quality Management System.

1. INTRODUCTION bodies instead provide guidance documents

outlining what activities should be performed
Advancements in technology have allowed medical (McCaffery et al., 2010).
practitioners to provide a higher level of care to To help address this shortfall this paper details a
patients and offer a wider range of treatment options. software development process roadmap which can
However, when technology is used there is a risk to be used to guide organisations through the
the patient if that device should fail. To offset these implementation of a Quality Management System
risks organisations must comply with the regulatory (QMS) which is compliant with the ISO 13485 (ISO,
requirements of the country where the device is to be 2003) standard. The roadmap presented here has
sold (Burton et al., 2006). been developed using the specific practices defined
Software is becoming a more pivotal component in the Medi SPICE process assessment model, which
of medical devices due to its flexibility and its is designed to assess an organisations ability to
ability to allow complex changes to be made, develop medical device software.
without the need for hardware changes (Lee et al., This paper is structured as follows. Section 2
2006), resulting in increased medical device introduces the Medi SPICE (McCaffery et al., 2010)
software complexity (Rakitin, 2006). In addition framework. Section 3 Introduces ISO 13485 and
software can now in its own right also be considered details a roadmap for implementing a QMS, while
a medical device (Mc Hugh et al., 2011). Therefore Section 4 outlines how the roadmap will be
software development organisations are subjected to validated. Section 5 details some of the limitations
the same regulatory requirements as other medical of the roadmap and how these will be addressed in
device organisations. the future. Conclusions are provided in Section 6.
Software organisations now have an opportunity
to expand into the medical domain. These
organisations however must develop more stringent 2. MEDI SPICE
processes in order to meet regulatory compliance. A
significant difficulty for such organisations is that As regulatory bodies only detail what activities must
there is no prescribed method for performing be performed, medical device organizations have
regulatory compliant software development been compliance centric in their approach to
activities (McCaffery et al., 2010). Regulatory software development. As a result there has been
very limited adoption of software process outcomes and purpose defined in the PRM; this is
improvement within the medical device domain termed the process dimension. In the second
(Denger et al., 2007). dimension, the PAM describes capabilities that
Existing generic Software Process Improvement relate to the process capability levels and process
(SPI) models, such as the Capability Maturity Model attributes, this is termed the capability dimension.
Integration (CMMI®) (CMMI Product Team, 2006)
and ISO 15504-5:2012 (ISO/IEC 15504-5:2012,
2012) (SPICE), do not provide sufficient coverage to
achieve medical device regulatory compliance
3. QMS ROADMAP
(McCaffery and Dorling, 2010). To address this
issue a medical device specific SPI framework, titled The ISO 13485 – Medical devices - Quality
Medi SPICE, has been developed. management systems – Requirements for regulatory
The objective of undertaking a Medi SPICE purposes, is an international standard defining the
assessment is to determine the state of a medical requirements for the implementation of a QMS to be
device organisation’s software processes and used for the development of medical devices. The
practices. This is in relation to the regulatory standard not only covers software but also
requirements of the industry and best practice with incorporates hardware and related activities such as
the goal of identifying areas for undertaking production and servicing.
process improvement (McCaffery and Dorling, The main focus of the QMS is to help insure that
2010). It can also be used as part of the supplier high quality processes are implemented and
selection process when an organisation wishes to monitored. The standard places a strong emphasis on
outsource or offshore part or all of their medical ensuring the organisation is committed to the quality
device software development to a third party or of their products, through effective process
remote division (Casey, 2010). management and a commitment to quality from all
Medi SPICE is based upon the latest version of levels of the organisation from top management
ISO/IEC 15504-5:2012 and ISO/IEC 12207:2008 down.
(ISO/IEC, 2008). It is being developed in line with To assist organisations to implement a QMS, a
the requirements of ISO/IEC 15504-2:2003 roadmap has been developed. The roadmap is
(ISO/IEC, 2003) and contains a Process Reference divided into three phases. The first phase is project
Model (PRM) and Process Assessment Model planning and should occur at the start of a medical
(PAM). It also incorporates the requirements of the device software development project.
relevant medical device regulations, standards, The second phase is the system development
technical reports and guidance documents. phase. During this phase the product is built using
The Medi SPICE PRM consists of 44 processes the system development lifecycle.
and 15 subprocesses which are fundamental to the The final phase is on-going and irregular
development of regulatory compliant medical device activities. The phase contains a number of practices
software. Each process has a clearly defined purpose that should be performed during the development of
and outcomes that must be accomplished to achieve the product however; they do not fall under
that purpose. individual stages of the software development
Medi SPICE also contains a PAM which is lifecycle. As these do not follow a strict sequence
related to the PRM and forms the basis for collecting they are not included as numbered steps.
evidence that may be used to provide a rating of Table 1 outlines the steps included within each
process capability. This is achieved by the provision phase of the roadmap. The planning phase contains 6
of a two-dimensional view of process capability. In steps, the systems development phase contains 16
one dimension, it describes a set of process specific steps and the on-going and event driven phase
practices that allow the achievement of the process contains 9 steps.
 Table 1: Steps in the QMS roadmap
On-going and Irregular
Planning Phase Systems Development Phase
Activities Phase
Appoint a quality manager Gather customer requirements Risk analysis
Define quality objectives Assign resources Document management
Establish product scope Analyse system requirements Software configuration management
Establish SDLC Design the system architecture Quality assurance
High level planning Software development Validation and verification
Low level planning Software requirements analysis Software review and audit
Software architectural design Problem resolution
Detail the software design Change request management
Software construction Acquisition
Software integration
Software qualification testing
Software installation
System integration
System qualification testing
Delivery
Customer support

3.1 Project Planning Phase Step 5: High Level Planning. The next step is to
define the high level processes necessary for the
The first section of the roadmap should be development of the product. For example,
performed prior to the development of the medical development of a document management strategy.
device. During this phase the organisation will Step 6: Low-level planning. While high-level
establish the product scope and the procedures to be processes define the overall strategy to be employed,
used during the development of the medical device. the low-level processes are focused on particular
Step 1: Appoint a quality manager. The first areas or provide more detailed instructions to meet
step in implementing a QMS is to assign a member the overall strategy.
of the management team responsibility for
overseeing and reporting on the QMS, and 3.2 System Development Phase
promoting the awareness of regulatory and customer
requirements throughout the organisation. After the planning phase has been completed, the
Step 2: Define quality objectives and policy. organisation will begin to develop the medical
The quality objectives and policy outline the device. These steps follow the order of the software
organisations commitment to quality and guide the development lifecycle and can be implemented in
processes used to ensure product quality. At this the presented order.
stage the organisation’s quality manual Step 7: Gather Customer requirements. The
incorporating the scope of the QMS, and details and first step of this phase is to determine the customer
justification for any exclusion and/or non- requirements for the project. As part of this stage,
application, is established. risk analysis should be performed and documented.
Step 3: Establish the product scope. This step Step 8: Assign resources. When the customer
involves the definition of the customer requirements requirements have been defined and understood top
and an internal analysis of the organisations ability management should ensure that adequate resources,
to meet these. In addition to this a communications in terms of personnel and infrastructure, are in place
interface should be established to ensure effective and documented.
communication between the customer and the Step 9: Analyse System requirements. In this
organisation. step, non-functional requirements, potential risks
Step 4: Establish the Software Development and performance expectations are identified. The
Lifecycle (SDLC) for the project. During this step process, and consistency with customer
the organisation should define the software requirements, should be documented and
development lifecycle that should be used during the maintained.
development of the product. This should include all Step 10: Design the system architecture. If
processes necessary for the QMS and the sequence external software components are to be used an
and interaction between these processes. appropriate acquisition strategy should be in place.
The system architecture design should be consistent the process used should be documented. Traceability
with the system requirements and the process used should be ensured.
should be adequately documented. Step 20: System Qualification Testing. As part
Step 11: Software development. The software of the system qualification testing phase, a QMS
implementation process to be used during the project should ensure that the system tests can be traced
should be documented and maintained. If any back to system requirements. The process used
deviation from this process is encountered the should be documented and maintained.
relevant documentation should be updated. Step 21: Delivery. The QMS requires that the
Step 12: Software Requirements analysis. The organisation should ensure that delivery conditions,
requirements of the software component of a in accordance with the supply agreement, are met.
medical device are analysed in the context of the Step 22: Customer Support. The QMS should
complete system and its operating environment. ensure that the organisation monitors the operational
Traceability and adequate testing should be ensured. use and ensure that adequate support is available to
Risk control measures should be implemented and the customer. The organisation should also collect
any modifications to the system requirements should and retain customer satisfaction data relating to both
be documented. the product and the customer service.
Step 13: Software Architectural design. As
part of the QMS, it is necessary to ensure that the 3.3 On-Going and Irregular
architectural design is consistent with the system and Activities Phase
software requirements.
Step 14: Detail the software design. A detailed During the development process a number of
software design document should be produced. This activities are performed at regular intervals or when
shall be consistent with the system architecture. The specific events occur. The schedule for these
process used should be adequately documented. activities should be defined during the planning
Step 15: Software construction. The software phase; however, the execution of these activities can
units defined in the software design document occur at any time.
should be constructed. Detailed documentation, Risk Analysis. At all stages of the product
including traceability, should be maintained as development, the organisation should ensure that
required by the configuration management strategy. adequate risk management activities are performed.
Step 16: Software integration. The software The level of risk analysis is dependent upon the class
units should be integrated into the complete software of device that is being developed.
system. The integrated system should be tested Document management. Throughout the entire
independently from the testing of individual development process a consistent document
components. The results from this testing, as well as management process should be in place. Each
the strategy for integration and testing should be document should be checked before distribution,
documented and maintained. ensuring they are available where needed.
Step 17: Software Qualification Testing. In Software configuration management. During
this step the integrated software system is tested. the lifetime of the project, configuration items
User documentation should be updated as necessary. should be maintained and accessible at the point of
A fundamental component of this stage is to ensure use. The QMS should ensure that each configuration
that a regression test strategy is developed and item is uniquely identified and that a description of
carried out. All processes used and results obtained each item is maintained.
should be documented and maintained. Quality assurance. The QMS dictates that
Step 18: Software Installation. Documented regular assessments should be performed in terms of
procedures, including verification and acceptance both the processes used during the development of
criteria, should be established as part of the QMS. the product and the product itself. Through
This documentation should be made available to processes assessment activities the organisation
other agents who have been authorised by the should perform process improvement activities when
customer to perform installation activities. possible.
Step 19: System Integration. The next step is to The organisation should also periodically assess
integrate the software with the overall system. Each the achievement of the quality objectives and
component of the system should be independently monitor the performance of the QMS. When a
verified to ensure that they meet the system deviation from the quality objective is found, the
requirements. The results of such verification and organisation should strive to take action as quickly
as possible to ensure that the quality of the product configuration items should be updated if impacted
is not negatively affected. by the change.
Part of the assessment and improvement Acquisition. In the event the organisation shall
initiatives should be commitment from all relevant incorporate external software units in the product,
departments within the organisation. This will the organisation should ensure that an appropriate
ensure assessment activities will not interfere with acquisition process is followed. This process should
the main functions of the organisational units under encompass a process for supplier tendering and
assessment. The results of the assessment and any selection, acquisition of the product, acceptance
process improvement activities that will take place criteria and testing and a means for managing
should be communicated to all stakeholders. changes and resolving issues with the supplier.
Validation and Verification. At regular
intervals the organisation should perform validation
and verification activities to ensure that the product 4. VALIDATION
is correct and meets project requirements and quality
standards. The results of these activities should be
Two aspects, order and completeness, of the
recorded and any problems identified should be
roadmap presented above will be validated. Order
entered into a software problem resolution process. refers to the placement of the practices in each step.
The results of such activities should be It will be necessary to ensure that all practices that
communicated to all relevant stakeholders.
are depended upon are in place before an
Software review and audit. At regular intervals
organisation tries to implement any new practices.
the organisation shall prepare and conduct a
The completeness of the roadmap refers to its ability
software review and audit. If a product is found to be
to cover the requirements of the ISO 13485 standard.
non-conforming then the organisation should take The order of the implementation steps will be
appropriate action either by removing the non- validated using the Medi SPICE dependency graphs
conformities or by authorising its release under
(Flood et al., 2012). The practices in each step will
concession. If the product is released under
be validated to ensure that all dependant practices of
concession, the organisation should ensure that it
each step are performed in the same or preceding
still meets all regulatory requirements. The nature of
steps. If a practice is found to be performed in the
the non-conformity and the identity of the person(s) same step of the roadmap the organisation will be
authorising the concession should be documented. alerted and instructed to perform this practice before
Problem Resolution. The organisation should
any dependant ones.
ensure that any problem identified is recorded and
In order to validate the completeness of the
the root cause of the problem is diagnosed. The
roadmap a number of qualified ISO 13485 assessors
organisation should have procedures in place to alert
will be asked to review it. A semi-structured
users of the problem pending a fix or a change. A interview will then be conducted with the assessor.
solution for the problem should then be found and
implemented while tracking the status of the issue
until it is resolved. If no action is taken as a result of
a problem being identified, the organisation should 5. LIMITATIONS AND FUTURE
justify and record why no action has been taken. The WORK
organisation shall maintain records of all customer
complaints. The roadmap presented here is based on ISO 13485.
Change request management. A documented In the US the FDA produce a similar regulation,
procedure should be in place to address change FDA Regulation 21 CFR 820 (FDA, 2007), for
requests. This procedure should ensure that an audit organisations wishing to distribute medical devices
trail is in place enabling traceability. Prior to the within the US. Although both documents provide
implementation the organisation should assess the similar guidance additional practices may be
impact of the change request on both the existing required for medical device organisations wishing to
system and other change requests. Additionally the operate within the US. However, it should be noted
risks associated with the change request should be that the FDA are currently implementing a pilot
analysed. programme to accept a QMS that is compliant with
Upon implementation of the change request, the ISO 13485.
organisation should perform all necessary The next step of this work will be to perform a
verification and validation activities. All similar analysis of the FDA Regulation 21 CFR 820.
The relevant best practices will be identified and any REFERENCES
additional requirements identified will be
incorporated into the existing roadmap to produce a Burton, J., McCaffery, F., and Richardson, I., A risk
roadmap for organisations wishing to distribute management capability model for use in medical
medical devices in Europe and the US. device companies. in International Workshop on
The roadmap presented above allows an Software quality (WoSQ '06). 2006. Shanghai, China:
organisation to create a QMS, assuming they have ACM.
no existing processes in place. In the case of Casey, V. (2010) Virtual Software Team Project
software development organisations wishing to enter Management. Journal of the Brazilian Computer
Society, 16, 83 – 96.
the medical device domain, some existing processes
CMMI Product Team (2006) Capability Maturity Model®
may be in place and the roadmap will need to be Integration for Development Version 1.2. Software
tailored for these organisations. Engineering Institute, Pittsburch PA.
In addition to this there are some steps that may Denger, C., Feldmann, R., Host, M., Lindholm, C. &
not need to be performed, depending on the Shull, F. (2007) A Snapshot of the State of Practice in
circumstances of the organisation or product. Software Development for Medical Devices. First
To address these issues an assessment method International Symposium on Empirical Software
that can be used to determine the organisations Engineering and Measurement. Madrid, Spain.
existing processes and their specific requirements FDA 2007. Title 21--Food and Drugs Chapter I --Food
and Drug Administration Department of Health and
will be developed.
Human Services subchapter h--Medical Devices part
820 Quality System Regulation. U.S. Department of
Health and Human Services.
6. CONCLUSIONS Flood D., Mc Caffery, F., Casey, V., (2012)
“Understanding the Relationships Within the Medi
SPICE Framework”, The Seventh International
This paper presents a software process roadmap for
Conference on Software Engineering Advances
the implementation of a QMS for organisations (ICSEA 2012)
operating within the medical device domain. In ISO 13485:2003 (2003) Medical devices — Quality
order for medical device products to be sold, they management systems — Requirements for regulatory
must be approved by the relevant regulatory body purposes. Second ed. Geneva, Switzerland, ISO.
within the region the device is to be sold, such as the ISO/IEC 12207:2008 (2008) Systems and software
FDA in the US. The regulations set forth by these engineering - Software life cycle processes. Geneva,
organisations require that a QMS is in place during Switzerland, ISO.
the development and distribution of medical devices. ISO/IEC 15504-2 (2003) - Software engineering —
Process assessment — Part 2: Performing an
To assist organisations wishing to develop
assessment. 2003: Geneva, Switzerland.
medical devices, this paper details a software ISO/IEC 15504-5:2012 (2012) Information technology -
process roadmap for implementing a QMS. This Process Assessment - Part 5: An Exemplar Process
roadmap is based on the ISO 13485, an International Assessment Model. Geneva, Switzerland, ISO.
standard detailing the requirements of a QMS for Lee, I., Pappas, G., Cleaveland, R., Hatcliff, J., Krogh, B.,
organisations in the medical device domain, and the Lee, P. , Rubin, H. , and Sha, L., High-Confidence
base practices defined in the Medi-SPICE PAM. Medical Device Software And Systems. Computer,
2006. 39(4): p. 33 - 38.
McCaffery, F., Dorling, A. and Casey, V., (2010) Medi
SPICE: An Update. in International Conference on
ACKNOWLEDGEMENTS Software Process Improvement and Capability
Determinations (SPICE). 2010. Pisa, Italy: Edizioni
This research is supported by the Science ETS.
Foundation Ireland (SFI) Stokes Lectureship McCaffery, F. & Dorling, A. (2010) Medi SPICE
Programme, grant number 07/SK/I1299, the SFI Development. Software Process Maintenance and
Principal Investigator Programme, grant number Evolution: Improvement and Practice Journal, 22, 255
– 268.
08/IN.1/I2030 (the funding of this project was
Mc Hugh, M., McCaffery, F. & Casey, V. 2011.
awarded by Science Foundation Ireland under a co-
Standalone Software as an Active Medical Device In:
funding initiative by the Irish Government and O'CONNOR ET AL (ed.) The 11th International
European Regional Development Fund), and SPICE Conference Process Improvement and
supported in part by Lero - the Irish Software Capability dEtermination. Dublin: Springer.
Engineering Research Centre (http://www.lero.ie) Rakitin, R., Coping with defective software in medical
grant 10/CE/I1855 devices. Computer, 2006. 39 (4): p. 40 - 45.