The FDA analysis of 3140 medical device recalls
conducted between 1992 and 1998 reveals
that 79% of the software-related recalls were
caused by software defects introduced when
changes were made to the software after its
initial production and distribution. The primary
cause of the medical devices’ critical
condition can be isolated to a single variable,
repeatability. An engineering process with a
lack of repeatability is no more predictive of
results (and success) than an ill-conceived scientific
experiment.
When medical device and pharmaceutical companies
consider the burden imposed on them
by the FDA (as compelled by the US Congress)
and international standards organizations, they
are given pause to perhaps reconsider the potential
benefits of introducing products in the
inherently risky and increasingly regulated
health sector of the economy. In recent years
there has been an avalanche of new guidance
on best practices compiled into standards such
as IEC 62304 and certification mandates from
the FDA. LDRA medical industry customers
complain that 80 percent of their software development
budget goes into documentation
and testing. This is after having automated the
architectural modeling and coding of their
software. The first step in better understanding
the dimensions of the challenges facing suppliers
to the medical industry is to examine
the totality of the associated development and
maintenance processes. These terms can refer
to the entire left side of the product life cycle
equation or to some specific task such as
coding. A big difference! This terminology
may also be very misleading if one considers
the full type and range of activities that are actually
performed in the course of a product
life cycle.
For example, in figure 1, these processes are
shown to be interrelated if not wholly integrated
and certainly not distinct activity silos.
Moreover, a lot more seems to be going on
than just what is connoted by the terms development
and maintenance. In what is called
the Product Realization Process by the 11th
Conference of the Global Harmonization Task
Force (GHTF), December, 2007, a full requirements
engineering (RE) process is indicated.
Being a medical product RE process, this not
only includes the formation, specification and
validation of requirements, it also implicitly
entails risk management (RM). Key elements
of risk management include: risk analysis (including
hazard identification), risk evaluation,
risk control, residual risk control, and postmarket
information.
In order to make this process work, risk management
and its related requirements should
be based on the actual events and prevent
them from recurring. To do this, accuracy in
reporting, consistency in analysis and the
ability to reestablish the context in which the
software was originally produced are essential.
These are the characteristics of a repeatable
process. The RM activity in the context of a
product lifecycle is effectively escalated into a
system engineering process. The GHTF proclaimed
that: as software can be an integral
part of a medical device, software risk management
should not be isolated from that of
hardware and from overall medical device risk
management. This leads into what I call the
Toyoto syndrome, in which both the hardware
and software perform to specification, but
somehow on the fuzzy edge of the system integration,
system behavior can go askew. Complex
embedded systems are vulnerable to such
anomalies that can only be properly evaluated,
remediated and prevented from recurring in
the context of a highly repeatable process.
A colleague of mine from many years ago provided
comic relief by proclaiming: in the course
of every project, it seems, the time comes
when you have to shoot the engineer and ship
the radio. Underlying his caustic wit was the
sense that complex embedded products, especially
with the increasing levels of software integration
they manifested, were being fully realized
during interminable periods of very
costly system testing and schedule delays. Some
how it was being left to the wizardry of a few
key people to get the product right and that
the process that went in to producing the
product was history. Moreover, once the radio
was shipped, the project then transitioned into
maintenance mode and the product was left
to a team without a usable, repeatable process.
A very important pronouncement of IEC
62304 is that the maintenance process is the
mirror image of development process. With
the exception of specific process management
tasks, the symmetry is readily apparent in the
respective IEC 62304 development and maintenance
process models depicted in figures 2
and 3. The organizing and controlling function
of each activity depicted in these process models
is a corresponding set of objectives. An objective
states what the activities are supposed
to accomplish. For example, the activity 5.2,
software requirements analysis, is predicated
on an objective such as, Develop High Level
Software requirements from allocated System
requirements. The resulting activity produces
an asset, the specification of a high level software
requirement. This asset must next be validated
based on a set of Objectives such as:
Software high-level requirements comply with
system requirements, are accurate and consistent,
are compatible with target computer, are
verifiable, conform to standards, and are traceable
to system requirements.
No comments:
Post a Comment