Medical Device Software Process Improvement
A Perspective from a Medical Device Company
Marie Travers and Ita Richardson
Lero - the Irish Software Engineering Research Centre, University of Limerick, Limerick, Ireland
Keywords: Software Development Process, Medical Device, Regulated Environment, Process Improvement, Change
Management.
Abstract: When manufacturing medical devices there are many constraints that have to be taken into account such as
safety, compliance with regulations and traceability. To do this, well-defined processes are used. With this
in mind we examine how process improvement is implemented in a medical device company while
managing the resultant change. The case study presented in this paper investigates the use of Kotter’s
Change Model to support the implementation of process improvement in a medical device company. The
results of the case study demonstrate that Kotter’s change model was an appropriate model to use. The sense
of urgency Kotter stipulates was inherent in the company. The team was aware that change was needed. A
flaw in Kotter’s approach is that there is no recommendation for a pilot project. Having a pilot project
worked well for this company as it helped to eliminate stress and anxiety. A further case study is planned in
the company to observe how the process is working after implementation of the full project.
1 INTRODUCTION
In the healthcare industry, medical devices are
manufactured to aid patients. To safeguard patient
safety and minimize risk such devices are regulated.
The regulatory body in the USA is the Food and
Drug Administration (FDA) whereas in Europe the
regulatory body is the European Commission (EC)
using the Medical Devices Directive (MDD) (EU
Council 1993), (EU Commission 2007). Regulators
can also approve standards such as the International
Organization for Standardization (ISO) standards.
Recently the MDD (2012) amended its definition
of a medical device to include software. Therefore,
software can, in certain cases, be classed as a
standalone medical device. In addition, medical
device software embedded within a medical device
or used in the manufacturing of a device is also
subject to regulation.
In our research, we are interested in how MD
companies cope with change of processes.
Therefore, this paper documents a single case study
where the company changed their documentation
process from being document-centric to being
artefact-centric. It was important for this company
to undergo change in a controlled manner, which
would not affect their regulatory status. We studied
the software development process of a medical
device company to see how they developed and
implemented the software documentation process.
2 SOFTWARE FOR THE
MEDICAL DEVICE INDUSTRY
The medical device industry faces persistent
challenges, including competitors, government
regulations, and productivity and quality issues. To
remain competitive, they must reduce costs,
streamline Research and Development, increase
accountability, incorporate traceability and
accelerate time to market.
Standards and guidelines have been developed to
aid in achieving the safest possible product. For
example in America the U.S. code of federal
regulations title 21 part 820 governs the quality
system regulations.
The international standard (ANSI/AAMI/IEC
2006) governs Medical Device (MD) software
development life cycle (SDLC) processes. A set of
processes, activities, and tasks that are needed within
a MD SDLC process are defined by The
International Electrotechnical Commission (IEC)
62304 (Cawley et al 2011). However, these authors
462
Travers M. and Richardson I..
Medical Device Software Process Improvement - A Perspective from a Medical Device Company.
DOI: 10.5220/0005223904620469
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2015), pages 462-469
ISBN: 978-989-758-068-0
Copyright
c
 2015 SCITEPRESS (Science and Technology Publications, Lda.)

also point out that reading the standards can lead to
incorrectly thinking that a waterfall-type software
development methodology is the best methodology
to use. They suggest that companies should ensure
knowledge of Annex B of the IEC 62304 standard.
Individual MD companies can decide which
methodology to use.
2.1 Literature Review and Related
Work
McCaffery et al (2012) point out that with regulatory
compliance in mind, MD companies usually use a
SDLC such as the V-model. Agreeing with this,
Cawley et al (2011) also state that more emphasis is
being put on how to improve SDLC processes such
as by using a more iterative development
methodology (Spence, J.W. 2005; AAMI 2012).
Having studied the use of SDLCs in MD companies
another issue that arises is that there does not seem
to be a method for quantifying just how much
process is enough (Cawley et al 2011). To ascertain
where too much rigour is being applied and possibly
reducing the amount of work required, Cawley et al
(2011) recommend carrying out a process review.
Companies attempting to improve their products
also have to change their development processes to
ensure high quality products (Hayes and Richardson
2008). Companies implementing process change can
benefit from using a change management model but
published models usually relate to organization
change as opposed to process changes (Hayes and
Richardson 2008).
Introducing change must be a formalised planned
process. Even though it is sometimes considered that
having a process can be an overhead, change
management techniques have shown that when
change is planned it is more likely to be successful
(Forte 1997). Most planning models assume that
changes in organisations are planned changes
(Hayes and Richardson 2008). The models stipulate
that, for successful change, certain sequential steps
need be executed. Kotter’s model is one such change
management model. The steps described by Kotter
(2005) are:
 Establish a Sense of Urgency
 Form a Powerful Guiding Coalition
 Create a Vision
 Communicate the Vision
 Empower Others to Act on the Vision
 Plan for and Create Short-Term Wins
 Consolidate Improvements and Produce Still
More Change
 Institutionalise new approaches
Focusing on the implementation of process
improvement in a medical device company, this
paper investigates the hypothesis that “Eight Steps to
Transforming your Organisation” (Kotter 2005) is a
suitable framework for such a change.
The literature review revealed there is no model
available to provide software development teams’
guidance on end-to-end software development that
conforms to regulatory requirements. Burton (2008)
proposes an alternative process improvement model
and he states that even though there are standards
and guidelines it not possible to guarantee complete
regulatory compliance and existing process
improvement models are not broad enough.
2.2 The Company
MedIn (an alias) is a medical device company with
branches located in Ireland and abroad. Within the
particular plant we investigated, Research and
Development is performed along with the
manufacturing of commercial MDs. The MDs
contain embedded software. When developing a
product, MedIn always start with identifying the
intended use, as this will establish the device class,
which in turn identifies what regulations and
standards must be complied with. Their risk analysis
process can help determine the class of device.
Currently, each of these product development
processes are documented and reviewed at every
phase in a document-centric approach. The
company decided to move to an artefact-centric
approach for managing their product development
processes. To facilitate this, MedIn have chosen a
software product from a leading software provider.
This software provider offers artefact-centric
product development solutions.
For MedIn this software provider had the main
advantage of:
 Provision for regulatory compliance such as
electronic signatures and adherence to FDA
standard 21 CFR part 11
In addition, artefact-centric approaches aid:
 Time-to-market
 The software can provide better visibility into
the progress of product development, and
reduce the work needed to maintain
traceability and respond to change.
MedIn are applying software process improve-
ment in a safety critical environment while
minimizing risk and adhering to regulations. Figure
1 shows the applicable regulations for MedIn’s core
product. The primary or core regulations are:
MedicalDeviceSoftwareProcessImprovement-APerspectivefromaMedicalDeviceCompany
463

Figure 1: Regulations applicable to MedIn.
 IEC 62304 Software Development Lifecycle
 FDA guidance on Off The Shelf (OTS)
software
Next the risk management regulation applicable
is ISO 14971. The guidance document on how to
apply ISO 14971 is found in 80002-1. Finally the
following regulations influence the product, namely:
 GAMP 5 V model
 ISO 13485 Quality Management System
(QMS) for use in Europe
 FDA 21 CFR 820 Quality Management
System (QMS) for use in USA
 MDDS (Medical Device Data Systems)
 Usability standards
 If a networked device then
o FDA Cyber Security Guidance
o IEC 80001-1
 If device used in clinical trials then
o Digital Signatures 21 CFR part 11
MedIn purchased an artefact-centric software
package from a leading software provider. Training
on the application of the software was given by the
chosen software provider to key personnel identified
within MedIn such as the quality team and the
software development team. A small sample project
was chosen to demonstrate and test the use of this
new approach. When complete the plan is to test and
use this new approach with a live project.
MedIn plan in the future to further improve their
process by moving from the current SDLC process
of a V-model to an agile software development
process. To implement this they have identified that
this might have to be achieved with smaller
deliveries, which is in fact smaller V-model
deliveries.
3 RESEARCH APPROACH
After completing a literature review of software
development within healthcare, we were interested
in understanding how process improvement within
MD companies is carried out. Therefore our
research question was as follows:
How does a medical device company plan
(manage change) and implement process
improvements while also adhering to
regulations governing its medical device
products?
The approach taken was to commence a single
case study within a MD company. One of the
authors spent three months onsite and became
HEALTHINF2015-InternationalConferenceonHealthInformatics
464

immersed in one project. This project was set up to
support the company in moving from a document-
centric approach to more integrated, artefact-centric
approach for managing their product development
processes. The company viewed this proposed
process improvement as a change management
issue. They were particularly concerned with how to
manage this change effectively while also remaining
compliant to the relevant regulations?
In addition to being a participant-observer on the
project, the researcher held one-to-one interviews
with software development team members. The 7
interviewees were all experienced in product
development processes. They included software
developers, a quality engineer and regulatory
manager. The interviewees’ work experience
spanned 5 to 20 years.
As recommended by Miles and Huberman
(1994) triangulation (applying a combination of
research methods) was used to facilitate the
validation of information and to remove bias.
Artefacts were collected on site such as process and
procedure documents, policy documents,
presentations, organisational charts, relevant
standards and email correspondence. This provided
the authors with a rich collection of project data and
statistics. Participant observations, interview data,
and artefacts were analysed to understand the case
study. We reviewed the data within the structure of
Kotter’s Change model, which allowed us to
understand how change had been made within the
organization, whilst still maintaining the regulatory
requirements, which are so important from its sales’
perspective. This facilitated the gaining of a holistic
view of the working environment. We analysed the
data focusing on Kotter’s steps 1 to 6. Steps 7 and 8
are outside the scope of this paper.
4 RESEARCH FINDINGS
4.1 Software Process in MedIn
Regardless of any change to the documentation
process, it was important that the SDLC continued to
adhere to the relevant regulations. In MedIn,
processes are described and documented. These, in
turn, are mapped to a relevant standard. Standards
have accompanying guidance documents to aid
interpretation. Usually medical device software
developers develop software with a plan driven
sequential SDLC, such as the V-Model (McCaffery
et al 2012).
Within MedIn software to be produced can be
divided into one of three groups of software process:
 Development
 Maintenance
 Customization
For development in MedIn the V-model is used.
For class A devices developed in MedIn the V-
model used but Architecture Design, Unit test and
Code reviews are optional. MedIn do Verification
&Validation (V&V) but it is optional in the
regulations.
From our case study analysis, key factors were
identified which affect the SDLC process within
MedIn, namely safety, regulations, standards and
business focus.
To address these factors the following Quality
Processes are employed in the company:
 Quality Management
 Risk Management
 Change Management
 Configuration Management
 Software Safety Classification
 Traceability
It is the responsibility of the CTO to manage
SDLC processes – User Requirements, Verification
and Validation Planning, Specification Design,
Traceability, Pre-Production, Internal Validation,
Customer Acceptance and Production. In addition,
he has responsibility for the implementation of the
Quality Processes listed above.
4.1.1 Development Process
The current software development approach within
MedIn is the V-model. This is the standard V-model.
In the future MedIn plan to use the agile model for
software development. To incorporate the agile
model for development with medical devices it is
envisaged that there would be more frequent
releases. The releases will have less functionality.
MedIn plan to break the proposed release version
into multiple deliverables each containing a sub-set
of the overall functionality. The core principle here
is that the sub-sets shall be fully documented and
tested in their own right – so in theory could be
released individually. In practice though, they will
not release to customers until they have all
functionality for the full release ready. Agile will not
remove the need documentation, as this is necessary
for regulation compliance. Overall MedIn want to
become more iterative and get more feedback.
MedicalDeviceSoftwareProcessImprovement-APerspectivefromaMedicalDeviceCompany
465

Figure 2: Customization Process within MedIn.
4.1.2 Maintenance Process
The Maintenance process can be either a non-
conformance request or a modification
implementation. If a modification implementation
then it can take the form of a new feature or a
change request.
4.1.3 Customization Process
The customization process in MedIn differs from the
development process and is done in phases as shown
in Figure 2. MedIn find that these phases work more
efficiently for the specific needs of a customization
task.
4.2 Analysis of Change
Further to understanding the software development
process, we analysed the change, which the
company was undergoing with relation to its
documentation. We discuss our findings in terms of
each of Kotter’s (2005) steps.
4.2.1 Establish a Sense of Urgency
Having analysed the use of Kotter’s model during a
software process change project in a development
company, Hayes and Richardson (2008) agree that,
prior to any change, the need for such a change must
be communicated to everyone in the organisation.
They further state that management should be
behind the change and that the development team
must be motivated to realise the change. Lack of
urgency is a common reason why many
organisations fail when implementing a change
(Hayes and Richardson 2008).
MedIn are a medical device company that uses
processes to develop their medical devices while
also adhering to the relevant regulations governing
its medical device products. Prior to implementing
the new system, MedIn used a document-centric
approach for managing their product development
processes. This process was a manual paper based
approach where for regulatory compliance all
documents had be reviewed and manually signed by
the quality control department. The documents were
then stored and easily accessible to a regulatory
auditor for regulatory compliance. In MedIn as the
current process was no longer useful it was taking up
too much time for employees, adding unnecessary
complexity to projects and clouding visibility on
project status. Each document had to be individually
signed after each review by the software quality
team members. It was then stored in a suitable
location so that it was readily accessible for
regulators to inspect. This document-centric
approach involved members of staff having to
process and file each document. This had been
recognised by management and employees and was
the driving force behind the change that was being
undertaken.
Further disadvantages were:
 Using documents to manage the product
development process clouded visibility into
project status
 Design transfers between teams were
complicated by using documents
 Accountability was hindered
 Creating, managing, and reviewing
documents were the most time-consuming
tasks
Management and employees recognised that this
situation could not continue. It was cumbersome
and not cost-effective in a competitive market. In
summary, the sense of urgency came from
throughout the company.
Therefore, MedIn investigated moving away
from a document-centric approach to another
approach but they were restricted in that any new
approach had to be regulatory compliant. One
HEALTHINF2015-InternationalConferenceonHealthInformatics
466

method that offers regulatory compliance is an
artefact-centric approach. An artefact-centric
approach relies not on documents but on commercial
software to create, track, and trace individual
artefacts and work items. The advantages in moving
to an artefact-centric approach that MedIn had
identified were:
 Time-to-market
 The software can provide better visibility into
the progress of product development, and
reduce the work needed to maintain
traceability and respond to change
4.2.2 Form a Powerful Guiding Coalition
Kotter (2005) recommends gradually involving
different members of the organisation in the change
to form a project team. In the case of MedIn it began
with the Chief Technology Officer (CTO) of the
company getting support from other senior
management. The CTO reviewed and identifed a
suitable software product to facilitate the planned
change in process while still adhering to relevant
regulatory constraints. Key staff members were also
identified and chosen to be trained initially on how
this new process could work. Time was allocated
for the members to implement a pilot project with
the new process. The guiding coalition was driven
by the CTO. However, as other key staff members
were involved, there was an involvement from staff
throughout the company.
4.2.3 Create a Vision
For organisational change, Kotter also recommends
that a clear vision and plan for implementing change
is needed. To aid the management of regulatory
compliance MedIn decided to use a software
package to track product development artefacts,
verification and validation artefacts, internal
validated IT systems, and other activities.
Management within MedIn identified the need to
develop an implementation plan which stated the
objectives of the change. This was used as the basis
to identify the vision of the project. From this,
management were enabled to plan the training
needs, staff and the scope of the pilot project.
4.2.4 Communicate the Vision
Communication of the vision should come from
senior management. Once the implementation and
training plans were identified, management had a
vehicle by which they could carry out this
communication effectively. They were able to
discuss implementation with all employees who
subsequently undertook the relevant training.
Therefore, employees became aware of relevant
tasks to be completed in the project and of their roles
within the project. Kotter’s (2005) Step 4
recommends communication of the vision should
come from senior management. This was the case in
MedIn, as the project was driven by the CTO.
4.2.5 Empower Others to Act on the Vision
Obstacles, such as organisational structure should be
removed. At MedIn the project began with staff
training followed by a pilot implementation before a
planned rollout the new artefact-centric approach to
all projects. The importance of the vision was
evident to the team members as the actions that were
put in place such as the pilot project demonstrated
that, from a Senior Management point of view, this
was an important project which needed to be worked
on by everyone. The team members were keenly
aware that the existing process was very time
consuming and burdensome and that the proposed
vision was a more time efficient process.
4.2.6 Plan for and Create Short-term Wins
Change should have clear goals and objectives and
take place in small steps. Within MedIn, this was
done by allocating relevant team members to carry
out a pilot project. The pilot project which Kotter
does not mention actually worked well for MedIn. It
allowed the team members to become acquainted
and familiar with how the new process should work.
4.2.7 Kotter’s Steps 7 and 8
Kotter’s (2005) Step 7 Consolidate Improvements
and Produce More Change recommends that
management or change advocates should be become
more involved in the process thus ensuring
continuation of changes. Kotter’s (2005) step 8
Institutionalise New Approaches recommends that
for success change has to be implemented so that it
is now part of the organisation’s culture.
Currently these last two steps are out of the scope
of this case study as the process change is not yet
complete. A further visit is planned to MedIn to
observe how the process is working after
implementation of the change.
5 DISCUSSION
For this case study Kotter’s change model was
MedicalDeviceSoftwareProcessImprovement-APerspectivefromaMedicalDeviceCompany
467

appropriate. The sense of urgency Kotter stipulates
was inherent in the MedIn project. The team was
aware that change was needed. A flaw in Kotter’s
approach is that there is no recommendation for a
pilot project; this actually worked well for MedIn as
it helped to eliminate stress and anxiety. There were
specific aspects of the model that were overlooked
and there were elements that were necessary. For
instance Kotter’s (2005) step 5 Empower Others to
Act on the Vision was nessessary for team members
to have awareness of the importance of the vision.
The team members were given the time to carry out
a pilot project using the new artefact-centric
approach.
At the end of the 3-month case study the change
implemented thus far was working well and to an
organized plan going forward. A further case study
is planned to see if this move to this new approach is
working as planned.
6 CONCLUSIONS
We studied the SDLC within a MD company.
Cawley et al (2011) point out that many MD
companies are pre-occupied with complying with
regulations and that MD companies are looking at
how to manage process improvement while not
affecting regulatory compliance (Cawley et al 2011,
2013). This was found to be true in our case study
also. There does not seem to be a method for
quantifying just how much process is enough. This
is a significant challenge facing medical device
companies. They further recommend auditing
existing processes to review where improvements
could be made to maybe, for example, save time.
They also note that the challenge for researchers is
to develop architectures and methodologies that
facilitate advancements while being flexible to how
the regulators might respond.
The research presented in this paper documents a
single case study in MedIn. We have demonstrated
that process improvement when managed through
the use of a model will support the implantation of
change in an organisation. While Kotter’s change
model (2005) was a good basis, there were specific
aspects of the model that were overlooked and there
were elements that were necessary. Therefore a
more tailored and specific framework is required.
Due to regulation restrictions and business concerns
such as time to market, MD companies have to
implement change in an organised and planned
fashion.
7 FUTURE WORK
A futher case study is planned in the future within
MedIn, allowing us to study how process
improvement change has been managed in the
longer term. We recognise that doing a single case
study presents changes which are specific to one
company, but analysing these changes allows us to
recognise the difficulties faced by and strategies
used by MD companies when implementing change.
We have a starting point upon which to build our
research and to investigate change management
within the MD industry.
ACKNOWLEDGEMENTS
This research is partially supported by Science
Foundation Ireland (SFI) through Grant No.
03/CE2/I303.1 within Lero – The Irish Software
Engineering Research Centre (http://www.lero.ie).
REFERENCES
AAMI (2012) TIR45:2012 Guidance on the use of AGILE
practices in the development of medical device
software 2012, Association for the Advancement of
Medical Instrumentation.
ANSI/AAMI/IEC (2006) 62304:2006 Medical Device
Software-Software life cycle processes, 2006,
Association for the Advancement of Medical
Instrumentation. p. 67.
Burton, J., (2008) A Software Risk Management
Capability Model for Medical Device Software,
Unpublished thesis (PhD), University of Limerick.
Cawley, O., Wang, X., Richardson, I., (2013) Regulated
Software Development-An Onerous Transformation,
in Foundations of Health Information Engineering and
Systems: Springer, 72-86.
Cawley, O., Richardson, I., Wang, X., (2011) Medical
Device Software Development - A Perspective from a
Lean Manufacturing Plant, O’Connor, R. V., Rout, T.,
McCaffery, F., and Dorling, A., ‘Software Process
Improvement and Capability Determination’, Berlin,
Springer, 84 – 96.
EU, Council Directive (1993) 93/42/EEC of the European
Parliament and of the Council, Concerning Medical
Devices, E. Council, Editor 1993, Official Journal of
the European Union.
EU, Directive (2007) 2007/47/EC of the European
Parliament and of the Council, 2007, Official Journal
of the European Union.
FDA (2009) Code of Federal Regulations 21 CFR Part
820, U.F.a.D. Administration, Editor April 2009.
HEALTHINF2015-InternationalConferenceonHealthInformatics
468

Forte, G., (1997) Managing Change for Rapid
Development, IEEE Software 14(6), 114–123.
Hayes, S. & Richardson, I., (2008), Scrum Implementation
using Kotter’s Change Model, 9th International
Conference on Agile Processes and eXtreme
Programming in Software Engineering, Limerick,
Ireland, Lecture Notes in Business Information
Processing 2008, vol 9, Part 6, 10th-14th June, pp.
161-171.
Kotter, J., (2005) Leading Change: Why Transformation
Efforts Fail, Harvard Business School Press, Boston.
McCaffery, F., Casey, V., Sivakumar, M.S., Coleman, G.,
Donnelly, P., Burton, J., (2012) Medical Device
Software Traceability, Software and Systems
Traceability, Ed. Zisman A., Cleland-Huang J. and
Gotel, O., Springer Verlag Publishers, pp 321 – 340.
MEDDEV 2.1/6 (2012) Guidelines on the qualification
and classification of stand alone software used in
healthcare within the regulatory framework of medical
devices, European Commission.
Miles, M., Huberman, A. (1994) Qualitative Data
Analysis, 2nd edn. SAGE Publications, USA.
Spence, J.W. (2005) There has to be a better way!
[software development] in AGILE Conference, July
24 - July 29, 2005. Denver, CO, United states: Inst. of
Elec. and Elec. Eng. Computer Society, 272-278.
MedicalDeviceSoftwareProcessImprovement-APerspectivefromaMedicalDeviceCompany
469