Académique Documents
Professionnel Documents
Culture Documents
Page 1 of 8
Home [1] -> Regulatory and Compliance [2] -> Simplifying IEC 62304 Compliance for
Developers
[3]
Medical devices have become increasingly sophisticated, often employing softwarecontrolled applications whose failure to function correctly could result in death or
serious injury to the patient treated by them. Despite this increased danger, medical
software standards continue to reflect only the rigour of low-risk applications.
Notably, many of the medical device faults stem from product upgrades. An analysis of
3140 medical device recalls conducted between 1992 and 1998 by US FDA, reveals
that 242 of them (7.7% of the total) are attributable to software failures. Of the software
recalls, 192 (or 79% of the total) were caused by software defects introduced after
software upgrades.
Reacting to an ongoing inability to manage product upgrades, US FDA recently took
punitive action against Baxter Healthcare and their infusion pumps forcing a recall. On
April 27, 2010 US FDA had warned users about faulty components in defibrillators
manufactured by Cardiac Science Corp. Unable to remedy the problems with software
patches, Cardiac Science was forced to replace 24,000 defibrillators. As a result,
Cardiac Sciences shares were hit and they reported a net loss of US$18.5 million.
They were eventually acquired by Opto Circuits.
These recalls have resulted in a change in focus by many medical device providers.
Many companies are now changing their approach to improve their software processes
as well as to adopt IEC 62304, a standard for design of medical products recently
endorsed by the European Union and the United States. IEC 62304 introduces a riskbased compliance structureClass A through C where the failure of Class C software
could result in death or serious injurythat ensures that medical applications comply
with the standards suitable for their risk assessment. This standard outlines
requirements for each stage of the development lifecycle and defines the minimum
activities and tasks to be performed to provide confidence that the software has been
http://www.emdt.co.uk/print/2706
13/04/2015
Page 2 of 8
developed in a manner that is likely to produce highly reliable and safe software
products.
As you can see in Figure 1, IEC 62304 focuses on the software development process,
defining the majority of the software development and verification activities. This
process includes activities such as software development planning, requirement
analysis, architectural design, software design, unit implementation and verification,
software integration and integration testing, system testing and finally software release.
http://www.emdt.co.uk/print/2706
13/04/2015
Page 3 of 8
Software development
plan
Class
A
Class
B
Subclauses
5.1.1, 5.1.2,
5.1.3, 5.1.6,
5.1.7, 5.1.8,
5.1.9
5.1.5, 5.1.10,
5.1.11
5.1.4
5.2.1, 5.2.2,
Software requirements 5.2.4, 5.2.5,
5.2.6
specification
5.2.3
Software architecture
5.3.1, 5.3.2,
5.3.3, 5.3.4,
5.3.6
X
X
5.3.5
Software detailed
design
5.4.1
5.4.2, 5.4.3,
5.4.4
5.5.1
Software unit
implementation and
verification
Class
C
X
X
5.5.2, 5.5.3,
5.5.5
5.5.4
Software integration
and integration testing
All
requirements
Software system
testing
All
requirements
5.8.4
Software release
Software maintenance
process
5.8.1, 5.8.2,
5.8.3, 5.8.5,
5.8.6, 5.8.7,
5.8.8
6.1, 6.2.1,
6.2.2, 6.2.4,
6.2.5
6.2.3
http://www.emdt.co.uk/print/2706
13/04/2015
Software risk
management process
Page 4 of 8
As you can see from the table, the device safety classification plays a major role in
determining the activities to be included for software development. A Class A device
requires minimal activities to accomplish the software design whereas Class C devices
require all activities to be carried out.
All medical device software must undergo requirement management and traceability
analysis throughout the software development lifecycle. An established verifiable
requirement is essential for defining what is to be built, determining that the medical
device software exhibits acceptable behaviour, and demonstrating that the completed
medical device software is ready for use.
IEC 63204 demands that all software requirements be identified in such a way as this
makes it possible to demonstrate traceability between the requirement and software
system testing. As well, this enables developers to trace the risk control measures to
the software requirements.
Why does requirements traceability matter?
Requirements traceability is widely accepted as a development best practice to ensure
that all requirements are implemented and that all development artefacts can be traced
back to one or more requirements.
The traditional view of software development shows each phase flowing into the next,
perhaps with feedback to earlier phases, and a surrounding framework of configuration
management and process. Traceability is assumed to be part of the relationships
between phases; however, the mechanism by which trace links are recorded is seldom
stated.
In reality, however, while each individual phase may be conducted efficiently thanks to
investment in up-to-date tool technology, these tools seldom contribute automatically to
any traceability between the development tiers. As a result, the links between them
become increasingly poorly maintained over the duration of projects. The net result is
absent or superficial cross checking between requirements and implementation and
consequent inadequacies in the resulting system.
To gain true automated traceability requires a Requirements Traceability Matrix (RTM)
since the RTM sits at the heart of every project and is a key deliverable within many
development standards.
http://www.emdt.co.uk/print/2706
13/04/2015
Page 5 of 8
Figure 3: RTM sits at the heart of the project defining and describing the
interaction between the design, code, test and verification stages of
development.
Figure 3 demonstrates how project managers can view and create project
requirements, and track them back to their original sources as enhancement requests.
Developers can review requirements (and use cases if present) while they are
designing software. Testers can get a jumpstart on testing activities by viewing project
requirements directly from their test management environment. Administrators can
include requirements when creating project baselines. Executives can receive
dashboard views of projects states, gaining at-a-glance information on progress.
http://www.emdt.co.uk/print/2706
13/04/2015
Page 6 of 8
IEC 62304 subclause 5.1.1 section C specifically calls for traceability to be established
between system requirements, software requirements, software system test and riskcontrol measures implemented in software. The RTM plays a major role here by linking
the various tiers of the software development life cycle. The RTM provides traceability
between high- and low-level requirements to the software architecture. It also helps
verify whether there is any deviation in the design from the requirement, including
those related to risk control per IEC 62304 subclause 5.3.6.
The RTM provides further traceability between the software architecture and software
detailed design, where the software architecture is refined into software units. The
RTM helps verify that software units dont contradict with the software architecture.
Coding starts during the unit implementation where each software unit is implemented
according to the design requirement. The RTM traces the units implemented with the
software units along with the various static verification activities carried out during code
verification and it also maps the verification plan with the dynamic analysis (done on
either host or target system) carried out during unit testing, integration and system
testing.
Using the RTM, project managers can estimate the impact of requirement changes
(impact analysis) and how it affects the system. We can see from the diagram that,
when RTM becomes the centre of the development process, it impacts on all stages of
design from high-level requirements through to target-based deployment.
Integrating requirements management with other tools saves time and avoids rework.
Requirements are integrated with defect tracking, visual development and testing tools
to jumpstart activities and provide each role on the team with a direct window into end
user needs.
IEC 62304 and Maintainability
The responsibility of the manufacturer doesnt end with the release of the software
product. IEC 62304 includes a focus on product maintenance as well.
Since many incidents in the medical device industry are related to service or
maintenance of medical device systems including inappropriate software updates and
upgrades, the software maintenance process is considered to be as important as the
software development process. The IEC 62304 standard hopes to curb the high
percentage of medical device software defects introduced after product release (i.e.,
during software maintenance).
A healthy software maintenance process is very similar to a solid software
development process, with the addition of problem and modification analysis and
modification implementation activities. The maintenance process requires that the
manufacturer monitor the feedback of the released product from both within the
organisation and from the user. This feedback must be documented and analysed to
determine whether a problem exists. When a problem is found, a problem report
should be created.
http://www.emdt.co.uk/print/2706
13/04/2015
Page 7 of 8
http://www.emdt.co.uk/print/2706
13/04/2015
Page 8 of 8
Author:
Anil Kumar is a Technical Consultant with LDRA in India, specialising in the
development, integration and certification of mission- and safety-critical systems. With
a solid background in development tools and real-time operating systems, Anil guides
organisations in selecting, integrating and supporting their real-time embedded
systems from development through to certification.
Related stories
Developing Medical Device Software to IEC 62304 [4]
Decoding MISRA C:2012 for Medtech Applications [5]
[1]
http://www.emdt.co.uk/print/2706
Regulatory and
13/04/2015