Vous êtes sur la page 1sur 8

Simplifying IEC 62304 Compliance for Developers

Page 1 of 8

Published on EMDT - European Medical Device Technology (http://www.emdt.co.uk)

Simplifying IEC 62304 Compliance for


Developers
Anil Kumar

Home [1] -> Regulatory and Compliance [2] -> Simplifying IEC 62304 Compliance for
Developers

Simplifying IEC 62304 Compliance for


Developers
Posted in Regulatory and Compliance [2] by Brian Buntz on January 18, 2011
Share

[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

Simplifying IEC 62304 Compliance for Developers

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.

Figure 1: The software development lifecycle includes software development, risk


management, configuration management and problem resolution processes. IEC 62304
outlines specific activites for each stage of the software development process.

The IEC 62304 software risk-management process is intended to provide additional


requirements for risk control for software, including software that has been identified
during the risk analysis as potentially contributing to a hazardous situation, or software
that is used to control medical device risk.
According to the standard, the manufacturer should identify the software items that
could contribute to a hazardous situation and their potential causes. These potential
causes should then be documented in the risk management file, which should contain
the sequence of events that were identified that could result in a hazardous situation.
For each potential documented cause, a risk control measure must be defined and
documented. IEC 62304 requires this risk control measure to then be implemented,
verified and documented. Traceability must be shown between the hazardous
situation, software items, software cause, risk control measures and verification of risk
control measures. In this way, risk management plays a major role in software
maintenance process.
Understandably, IEC 62304 begins with the software development planning of the
medical device. Here, required tasks directly relate to the safety classification of the

http://www.emdt.co.uk/print/2706

13/04/2015

Simplifying IEC 62304 Compliance for Developers

Page 3 of 8

device under development. Devices capable of delivering death or serious injury in


case of failure (Level C) undergo more rigorous compliance and are required to include
activities over and above those required for other levels.
Software
Documentation
Clause

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

Simplifying IEC 62304 Compliance for Developers

Software risk
management process

Page 4 of 8

7.1, 7.2, 7.3,


7.4.2, 7.4.3
7.4.1

Figure 2: IEC 62304 defines the processes and activities involved in


software development life cycle. This table summarises which software
safety classes are assigned to each requirement. A Class A device requires
minimal activities to accomplish the software design whereas the higher risk
Class C devices require all activities to be carried out.

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

Simplifying IEC 62304 Compliance for Developers

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

Simplifying IEC 62304 Compliance for Developers

Page 6 of 8

Figure 4: The requirements traceability matrix (RTM) plays a central role in a


development lifecycle model. Artefacts at all stages of development are linked
directly to requirements matrix and changes within each phase automatically
update the RTM so that overall development progress is evident from design
through coding and test.

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

Simplifying IEC 62304 Compliance for Developers

Page 7 of 8

According to IEC 62304 risk-management guidelines, problem reports are evaluated to


determine how the issue affects the safety of the released product and to decide
whether any upgrade or patch is required. The manufacturer also must verify that the
upgrade or patch does not cause a hazard or create a risk in the software that didnt
have any.
A good RTM with automated requirement traceability enables a manufacturer to adopt
the existing software development process to implement modifications. A thorough
regression analysis ensures that modifications have not introduces any new hazard
and adversely affected the risk control measure built into the existing device.
As part of the medical device, the software maintenance process needs to ensure that,
the safety-related problem reports are addressed and reported to appropriate
regulatory authority and affected users. The software products should be re-validated
and re-released after modification with formal controls that ensures the rectification of
the problem and the avoidance of further problems.
As per IEC 62304, risk management is an integral part of the entire software
development lifecycle for medical device. Because of the endemic problems with
software updates directly contributing to safety risk, most of the process and activities
involved in the standard speak about the risk management, right from software
development planning, requirement management, architectural design, coding and
verification through maintenance.
This standard requires the use of risk management process that is compliant with ISO
14971. Risk management as defined in ISO 14971 deals specifically with a framework
for effective management of the risk associated with the use of medical devices.
Conclusion:
The advent of IEC 62304 brings companies involved in systems and software
development for the medical industry into the same process as their counterparts in
industries such as aerospace and rail. All now face the efforts required to achieve
compliance with a demanding standard.
The need for such compliance has mandated business evolution in which processes
and project plans are documented, requirements captured, implementation and
verification carried out with respect to the requirements, and all artefacts fully controlled
in a configuration management system.
Adopting IEC 62304 as a process for medical device software development requires
conformance to the processes, activities and tasks defined by the standard. The device
safety classification assigned by the manufacturer plays a major role in determining the
effort required to develop the software. Fundamentally, IEC 62304 demands that
requirement traceability be met at all stages of the software development process, with
traceability to risk control measures as well.
Qualified, well-integrated tools ensure that developers can automate the process more
easily and efficiently. While this involves upfront costs and potential change of current
practises, compliance to IEC 62304 produces higher quality. A safe product avoids
expensive recalls and ensures that the same development process can underpin the
maintenance and upgrade process. The manufactures ROI comes quickly along with
improved credibility and reputation.

http://www.emdt.co.uk/print/2706

13/04/2015

Simplifying IEC 62304 Compliance for Developers

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]

Find more content on: Manufacturing [6]


Compliance [2]

http://www.emdt.co.uk/print/2706

Feature Article [7]

Regulatory and

13/04/2015

Vous aimerez peut-être aussi