![](bg3.png)
untenable as the race to meet growing needs reliant
on complexity and connectivity progresses. We
submit there is a double-edged ‘Red Queen’s race’
in that near continual evolution of not only
proprietary instrument capability, but also its
integration with mainstream technology will be
important to remain competitive.
3.4 The Virtual Programmer Future
Design of next generation instruments should follow
a direction consistent with the industry trends
described previously. Some distance down this road
we submit there may be a `virtual programmer’ that,
unlike IMD instruments today, relies almost entirely
on shared, general-purpose, existing infrastructure
such as clinician’s PCs and a more virtual,
distributed network of functionality. The
programmer, in the form of hardware, operating
systems, and other components provided by IMD
manufacturers disappears – to be replaced by a
changing, mainstream, connected pool of resources
largely owned and maintained by others.
Commenting on this idea one of Medtronic’s
regulatory experts noted that this would be a
“revolutionary change rather than an evolutionary
one” and could not be achieved overnight (Peterson,
2007). To this end, a first step might be to transition
to the mainstream, buy and operate on a commercial
off the shelf (COTS) platform, and separate from
that any domain specific components which must
remain proprietary. The IMD manufacturer would
still control (in a regulatory and legal sense) the
programmer, as has traditionally been the case. The
second step would then be to transition to the use of
general purpose, clinician owned and maintained
PCs, operating systems and technologies in place of
all but the essential proprietary components. To our
knowledge no such clinician PC based instrument
system exists today despite the potential hardware
and support cost savings.
4 SHIFTING CONCERNS
As a result of our work towards a virtual
programmer, we have begun to see what we believe
are key challenges in security, obsolescence, and
development which are and will be echoed across
the industry. With simple, isolated instruments there
is a low attack surface or room for misuse to
motivate complicated security concerns. As trends
continue toward complex, connected, mainstream
components outside the control of the instrument
manufacturer, associated migration and development
costs beget significant additional concern.
4.1 Security
With instruments, there is the potential for some
severe types of harm including discomfort, death,
and exposure of protected health information (PHI).
Complex, mainstream, connected, general purpose
computing is notorious for having a high rate of
breach due to a number of different vectors which
are not of significant concern for traditional
instruments. Windows operating systems (e.g. in the
PainDoc™ programmer) are infamous for having
their “survival time” measured in minutes when
exposed to the Internet (SANS™, 2007). This
combination begets a potential for high severity and
high frequency security challenges. Also, in a
connected, virtual programming environment, one
can imagine new and frightening scenarios. One
might no longer have to get within a few feet of each
implant to program it or interrupt service to it and
anyone with internet access could potentially access
or affect a tremendous volume of PHI, patients,
IMDs and instruments in patients’ homes and
clinics. Instruments could become a risk to their host
clinical environments and they could be severed
from their increasingly important information
ecology or inadvertently open a backdoor for
hospital infrastructure to be compromised.
Though scenarios involving malicious attack
against patients (e.g. Vice President Cheney via his
ICD), addictive self medication, or even attempts to
manipulate the stock of a public instrument
manufacturer are regularly raised, perhaps the
greatest risk lies in less specifically targeted security
scenarios in which needed therapy is unavailable or
delayed. In many cases instruments are essential to
the therapy of patients to the extent that if
programming is unavailable when changes are
required or an IMD state is unknown there may be
significant patient harm. The ability to program
could be lost or interrupted by something as minor
as the instrument software not having sufficient
resources to operate (e.g. because malcode or user
software has used up RAM).
4.2 Obsolescence and Development
Recently companies like St. Jude, and Medtronic
(e.g. 2010 programmer) have begun basing their
instruments on COTS platforms available from
companies like Microsoft, Intel, HP and others from
the broader computing market. With these
mainstream components come mainstream
BIODEVICES 2008 - International Conference on Biomedical Electronics and Devices
158