2.5 Other Relevant Interoperability Standards
2.5.2 Medical Device Coordination Framework
The Medical Device Coordination Framework is designed to be an open platform for med- ical device integration. It is architected around a messaging-oriented-middleware, using Java Messaging Service (JMS) to implement a publish-subscribe framework. Programing in MDCF is model-based, with an abstract system design being used to automatically generate a set of channel descriptions.
The MDCF developers identified these requirements for middleware [45]:
• Flexible, dynamic information flow (frequently needing privacy)
• Heterogeneous systems, mechanisms, and needs
• Many listeners and many sources
• Time-critical, scalable performance
On top of JMS, MDCF adds a device connection manager, maintenance console, mon- itoring console, clinician console, and a scenario manager.
The device connection manager “verifies that the connecting device is in a database of approved devices and associated drivers (which provide API descriptions for interacting with each device”.
The scenario manager “manages the life-cycle of scenario script executions including acquisition of devices needed in the script, creation of components and JMS channels to realize inter-component communication, and tear-down of components and channels after script execution.”
Figure 1. Integrated Clinical Environment (ICE) / MDCF Architecture
“smart alarm” that provides more sophisticated analysis
and decision logic based on physiological parameters from
multiple devices, monitoring trends / history, or comparison
and correlation with data patterns from a broader population
indicating problematic physiological conditions.
Clinical decision support:
An app may pull information
from devices, patient electronic medical records, drug in-
teraction databases, and previous clinical studies to support
clinician decision making, diagnoses, or guidance / sugges-
tions for treatment.
Safety interlocks:
An app may control one or more devices
so as to implement system safety invariants that lock out
potentially unsafe individual device behaviors or interactions
between devices.
Workflow automation:
Many clinical procedures follow
protocols or recommended steps that involve interacting with
a collection of devices. An app may be used to partially
automate workflow steps by automatically activating / deac-
tivating devices, setting device parameters based on either
a patient’s medical record or on guidelines for a particular
type of procedure.
Closed-loop control:
An app may use information collected
from sensing devices and possibly a patient’s medical record
to control actuators on devices providing treatment or col-
lecting diagnostic information from patients.
III. MAP A
RCHITECTUREWhile there may be multiple suitable architectures for
MAPs, one architecture that is gaining traction in the regula-
tory domain is ASTM standard F2761-09 for the Integrated
Clinical Environment (ICE) [1]. ASTM F2761-09 is an
initial standard in an anticipated family of standards that
will flesh out detailed requirements and interfaces for ICE
components. ASTM F2761-09 itself is a short standard that
presents the high-level ICE architecture (corresponding to
the components in dashed lines in Figure 1) and gives a brief
description of each architecture component. Nevertheless,
the ICE architecture has become the basis for US Food
and Drug Administration (FDA) sponsored workshops and
working groups that are developing a regulatory pathway for
MAPs. Our research group has been extensively involved in
these activities, and is attempting to make a contribution
by developing an open-source MAP implementation that
conform to ICE – the Medical Device Coordination Frame-
work (MDCF) – developed jointly with researchers at the
University of Pennsylvania and reported on in previous work
[2], [3], [?]) and by developing sample artifacts and mock
regulatory submission documents for ICE components.
In the ICE architecture, the Network Controller provides
the MAP communication infrastructure to which medical
devices and other hospital information systems are at-
tached, the the Supervisor provides an execution platform
for apps. The Network Controller provides high-assurance
network communication capabilities that establish virtual
“information pipes” between devices and apps running in
the Supervisor. It exposes the ICE Interfaces of attached
devices to Supervisor apps, and is agnostic to the intended
use of the clinical apps that it supports. In the MDCF
implementation of ICE (corresponding to the components
in solid lines in Figure 1), a Device Manager component of
the Network Controller maintains a registery of all medical
devices that are currently connected with the MDCF. The
Device Manager implements the server side of the MDCF
device connection protocol (medical devices implement the
client side) and tracks the connectivity of those devices
(notifying the appropriate apps if a device goes offline un-
expectedly). The Device Manager serves another important
role: it validates the trustworthiness of any connecting device
by applying a key exchange protocol to determine if the
connecting device has a valid digital certificate to indicate
that has been previously certified to conform to its interface
and has received regulatory approval.
In the MDCF, the Supervisor can be thought of as a virtual
machine that hosts
Supervisor Apps. We are currently work-
ing on ensuring that it provides separation/isolation-kernel-
like [4] data partitioning (information cannot inadvertently
leak between apps, and apps cannot inadvertently interfere
with one another) and time partitioning (real-time scheduling
guarantees that the computations in one app cannot cause the
performance of another to degrade or fail). Each app declares
device typesindicating the types/capabilities of devices upon
which it depends. When a clinician initiates the app launch
process, the Supervisor queries the Network Controller to
2
Figure 2.7: MDCF ICE actions, and PCA-by-proxy.
Programming errors may be caused by confusing drug names, e.g., hydromorphone and morphine or morphine and meperidine [12], by making a mistake in dose or drug concentration calcula- tions [23, 12] or entering the wrong values for bolus dose size, infusion rate, or lockout interval. A common source of error is en- tering a value that is off by a power of 10 or using the wrong units. For example, entering 5 mL / minute instead of 5 mG / minute or programming a pump with a drug concentration of 1 mG/mL when it is actually 10 mG/mL [12]. [23] discusses a number of cases where patients were fatally overdosed because of an improperly programmed drug concentration.
When someone other than the patient presses the button to re- quest a bolus dose, it is called PCA-by-proxy. Normally if the patient is oversedated they are unable to press the button to get another bolus dose. If someone else presses the button, this safe- guard is bypassed and an overdose may occur. In 2004 the Joint Commission made PCA-by-proxy their 33rd sentinel-event. Sen- tinel events are occurrences that must be reported and investigated to their root cause or the facility risks losing their accreditation [7]. Healthcare facilities that have completed staff education programs and incorporated a warning about PCA-by-proxy into their patient education have seen lower overall rates of oversedation [8].
An analysis of reports to the MAUDE database maintained by the FDA’s Center for Devices and Radiological Health (CDRH) from 1984 to 1989 found that 67% of problems associated with PCA pumps were caused by operator error [4]. This early study took place before the 1990 change in Federal Reporting Guidelines that requires reporting of incidents involving ’device malfunctions and serious injuries or deaths’ to the FDA. A later study [11] found that nearly 80% of the 2009 reported incidents in 2002 and 2003 were blamed on device malfunctions and that nearly 65% of these suspected device malfunctions were confirmed by the device man- ufacturers. The human factors of pump interface design are an im- portant means of reducing use errors [17, 18]. Respiratory depres- sion associated with PCA varies between 0.3% and 6% depending on the patient population and how respiratory depression is defined [22]. Most cases of respiratory depression do not lead to permanent harm to the patient, but these still represent serious incidents with the potential to harm or kill patients.
While this data shows that serious accidents occur with IV PCA, adequate pain control provides benefits including improved patient satisfaction, lower rates of complication, reduced length of hospital stays, and lower rates of litigation [12]. Some biomedical engineers take the attitude that the only safe medical device is one that’s never taken out of the box, but discontinuing use of PCA pumps is simply not an option. While providing inadequate levels of medication would indeed reduce the chance of overdose, pain management is an essential part of the care of these patients.
As noted earlier, patients receiving PCA therapy are usually also connected to a patient monitor that records their vital signs. These monitors typically measure heart rate, blood pressure, respiratory rate, and oxygen saturation (SpO2). The monitor has simple alarms which sound when the vital signs go outside of some preset limits. If the patient receives an overdose, their vital signs will eventually go outside of the limits and the alarms will sound, summoning a caregiver to the bedside.
However, by the time their vital signs drop far enough to cause the alarm to sound, damage may have already been done. Care- givers are desensitized by frequent false positive alarms, and they may not respond as quickly as would be optimal. Furthermore, the
!"#$%&'( )%$*+,-./,0 )-.% 1/2+./, 1345&67-*.%,$ !"#$%&'()*+,-.* 1345&67-*.%, 8%9-:0&;2.%,<-:%$ =)>?@A@B&%.:C 1345&D2-E#%7&3-.-&3+$*#-0 1345&>%,F+:%$&G&3-.-&,/".+29 !46&:#/$%7&#//*&:/2.,/# ://,7+2-.+/2&$*%:+<+:-.+/2 H%0 8%9-:0&=)>?@A@B %.:C 1345&F+-&I4!G;! !46&I,+99%, '*+-.%&;J J+,."-#&!46&4/KK-27 4L-22%#
Figure 2: PCA pump coordinating with other discrete devices to provide closed-loop physiologic control and increase patient safety via the Medical Device Coordination Framework.
bedside.
3.3 Improving Patient Outcomes via Device Coordination
An automatic system that could detect oversedation and the onset of respiratory depression and discontinue the flow of pain killer on that event could add an additional safeguard to the system and would help to protect the many patients who are not adequately pro- tected by existing systems and procedures. Figure 2 illustrates such a closed loop control system in which a ’supervisor’ system contin- ually analyzes the patient’s physiologic data and then disables the PCA pump if the patient vitals indicate respiratory depression.
Previous work by the UPenn authors implemented a prototype of closed-loop physiologic PCA control [1] as an example of how an instance of a MDPnP system might be built. The previous proto- type focused on investigating specialized time triggered communi- cations platform for inter-device communications. In that work, de- vices and logic were hard-wired in a single monolithic module. In contrast, our current work investigates software engineering tech- niques such as middleware, component models, and a model-based programming with a completely new infrastructure, and studies the advantages that can be achieved via a component-based ap- proach for rapid devopment of coordination applications. Such technologies (e.g. Medically Oriented Middleware) are similiar at a low level to what is currently provided by companies like Cerner, Philipps, GE, and CareFX. While the middleware we describe has additional features designed to manage explicit coordination activ- ities, we expect that the similiarities could accelerate the adoption of interoperating medical device systems by healthcare providers. In particular, to the best of our knowledge, none of the commercial frameworks above supports a device coordination framework (do- ing so in a commercial release would run afoul of the FDA), and we believe that our model-based programming environment for coor- dination applications can provide inspiration to existing work that meshes well with underlying middleware already in use.
4 Medically Oriented Middlware
To quickly implement a prototype closed-loop PCA pump con- trol system, we used our Medical Device Coordination Framework (MDCF) first reported on in[14]. The MDCF is a software infras- tructure which includes a Medically Oriented Middleware (MOM) runtime component and associated development tools that enable
Figure 2.8: MDCF PCA
Programming is done in Cadena, using a component interface editor and a system scenario editor. Experiments were done with three types of messages: event notification, HL7, and DICOM. Experiments with varying numbers of data producers and consumers found that latencies we “within allowable bounds”. Persistent messaging was turned off due to unacceptable delays in the message database.
MDCF demonstrates the usefulness of middleware in medical device interoperability. illustrates role of tool support for model-based programming code generation conceptual framework
MDCF has also led to related work on separation architectures for combining high and low criticality devices, including internet of things devices [19], and virtual integration of devices [49].