PROJECT:
PERIPHERAL
SAM CARELLO
CHRIS DAVIS
JEANA O’BRIEN
MICHAEL POSCH
“Project Peripheral” represents PVMC’s medical device data integration
initiative. This document describes the present state of the organization’s
biomedical device deployment, and defines the future state relative to the
design of the “Vision 2015” information architecture.
Potemkin
Village
Medical
Center
P
CONTENTS
Background ..................................................................................................................................... 2
Business Case.................................................................................................................................. 4
Stakeholders .................................................................................................................................... 6
Common Workflow Scenarios ........................................................................................................ 8
Use of Standards ............................................................................................................................. 9
Hardware or Physical Interface Standards .................................................................................. 9
Medical Device Interoperability Standards ............................................................................... 11
Composite Standards ................................................................................................................. 12
Information System Functional Requirements ............................................................................. 16
Diagram of the Information Architecture ..................................................................................... 19
Present State .............................................................................................................................. 19
Future State ............................................................................................................................... 20
Identification of the Origin of the Data Elements ......................................................................... 22
Patient Demographics ............................................................................................................... 22
Order Data ................................................................................................................................. 22
Physiological Device Data and Device onfiguration ................................................................ 23
Description of Data Flow .............................................................................................................. 24
Flow of Patient Demographics Data ......................................................................................... 24
Flow of Patient Monitoring Data .............................................................................................. 24
Flow of Ventilator Data............................................................................................................. 24
Flow of Infusion Pump Data ..................................................................................................... 25
Summary ....................................................................................................................................... 27
References ..................................................................................................................................... 28
1
BACKGROUND
Potemkin Village Medical Center (PVMC) has officially kicked-off “Vision 2015”; a strategic
campaign aimed at revolutionizing its health information systems. In four years, the hospital
hopes to transform the organization’s presently fragmented information architecture into one that
is fully integrated as well as standardized – both in terms of content and technical protocols. By
the end of the campaign, all documentation entered throughout the organization will be stored
electronically. Clinicians will have a single entry point where they will be able to access all
information pertinent to their patient's case. Data will be contained within a central data
repository where it can then be made universally available through the statewide Health
Information Exchange (HIE).
Over the next year, the hospital will be focusing on three major initiatives that will help create a
foundation for the planned future state of the information architecture:
1) Digitize: Move all paper documentation into one of the hospital’s online systems.
2) Standardize: Set up task force teams in each department to begin the process of
normalizing system content and moving it into standard nomenclatures.
Note: if there is a particular reason that any medical record data sets cannot be
converted into standard clinical terms, then the team should plan on developing a
mapping table that can be used to normalize the data at the interface level.
3) Share: Find areas where data is isolated from the rest of the organization and develop
methods of messaging the information into the hospital’s interface engine.
Note: IT professionals assigned these interface projects should pursue the adoption of the
HL7 version 2.6 or version 3 standard in any instance where it is available. In the
coming years, the hospital will be working to move all of its interfaces over to the latest
version of this messaging standard.
PVMC sees the electronic capture and exchange of medical device data as a critical element to
meeting the above objectives and realizing Vision 2015. The executive planning committee has
asked that a project team be put in place for the purpose of achieving hospital-wide device
integration. The project has been code-named, "Project: Peripheral". Phase 1 of the project will
include intensive care units only.
The intensive care units of PVMC consist of 72 total monitored beds located in three separate
geographic areas. Each unit has assigned multi-disciplinary staff consisting of nurses,
respiratory therapists, pharmacists, nursing assistants, nutritionists, physicians and chaplains.
The hospital maintains biomedical engineers on site who support devices in the intensive care
2
units and elsewhere. Their expertise includes troubleshooting for the intravenous pumps,
monitors, and ventilators planned for this project. The ICU physicians are intensivists employed
by the hospital whose primary focus is care of the ICU patients. The hospital has a full array of
surgical and medical sub-specialists who care for patients in the ICU on a consultative basis.
Patients are admitted to the intensive care units via one of three ways- admissions from the
Emergency Department, transfer of unstable patients from the hospital wards, and direct admit
patients transferred from other facilities. PVMC does not treat pediatric patients as there is a
dedicated Children’s Hospital next door. The hospital is Joint Commission accredited and has a
culture of safety with intent to follow JC standards as well as evidenced- based practice.
3
BUSINESS CASE
The executive sponsor of Project: Peripheral is the Chief Executive Officer, with additional
support from the Chief Medical Officer, Chief Medical Informatics Officer, Chief Nursing
Officer, and the Chief Information Officer. The goal of this project is to integrate digital cardiac
monitoring systems, ventilators, and infusion pumps in the intensive care units with the
electronic health record. This initiative supports all three strategic goals of Vision 2015: To
support the digital capturing and electronic transfer of data recorded by these three devices, to
standardize the collection of these data elements by electronic means, and to share this data with
all members of the health care team, not just ICU caregivers, via the interface into the electronic
health record.
Device integration is attractive to PVMC for a variety of reasons. According to the Institute of
Medicine, at least 1.5 million preventable adverse drug events (ADE) occur each year in the
United States (Institute, 2006). Although it is difficult to estimate the costs associated with
ADEs, one study found that $8,750 (in 2006 dollars) were added to a patient’s hospital bill for
each ADE that occurred during their hospital stay (Institute, 2006). Inappropriate use of IV
infusion pumps was found to be the second most common proximal cause, representing 13%, of
ADEs in all admissions to 11 medical and surgical units in two tertiary care centers over a span
of six months (Leape 1995). Another reason PVMC should be attracted to device integration is
that reducing the need for manual transcription of data both improves patient safety and saves a
substantial amount of time. Comparison of vital signs captured automatically through a data
management system versus manual transcription of vital signs into an electronic health record
demonstrates the automation to be more accurate than manual transcription reducing errors by
75%. Additionally, using automation reduced the time required for manual transcription of vital
signs by an average of 96 seconds per reading (Meccariello M 2010). Integration of ventilator
devices has been shown to save respiratory therapists up to 60 minutes per shift (Chan 2009).
Such improved efficiency also positively impacts physician, nursing, and ancillary staff
satisfaction (Chan 2009).
The greatest advantage of device integration in the ICU setting is to alleviate the need for manual
transcription of device settings and readings. This improves the accuracy of the data by
eliminating transcription error, allows nursing and ancillary resources to spend more time
focusing on patient care rather than recording monitor and device data, and makes this data
available to all users in near real time by eliminating the reliance on manual data entry at a time
convenient for the nursing and ancillary staff. Patient safety is improved with the removal of
manual data entry (Meccariello M 2010). Integration of infusion pumps not only improves
patient safety, but will also enhance accuracy of charges by more accurately and reliably
automating the capture of IV infusion start and stop times. Documenting IV infusion start and
4
stop times is a critical regulatory component for billing for these services according to Centers
for Medicare and Medicaid Services (CMS) guidelines. The integration of smart infusion
pumps and the ability to automate the programming of the smart pumps will further increase
patient safety by eliminating the manual calculations and programming involved in setting up
continuous intravenous infusions. Smart pump integration will also mitigate the risk of adverse
drug events that may be introduced by the manual administration of medications at the point of
care. Device integration will improve job satisfaction of nursing and ancillary staff by
automating the capture of monitor and device data, as well as improving patient satisfaction by
allowing for more time at the bedside by the clinical staff.
The scope of Project: Peripheral includes digital cardiac and vital sign monitors, ventilators, and
IV infusion pumps in the Intensive Care Unit settings. Other areas that have cardiac monitoring,
such as the Emergency Department and recovery areas of the Operating Room are not included
in the scope of this project. One-way communication to capture data from settings of IV
infusion pumps is in the project scope, but two-way communication and the configuration of
smart infusion pumps should also be taken into consideration for phase one. The capture and
storage of real time waveforms from cardiac monitors and ventilators is out of scope for the
project.
Measurements of successful implementation will be primarily monitoring patient and medical
staff satisfaction, including nursing, ancillary staff, and physicians, through standard surveys.
Additionally, the patient safety event reporting system will be monitored for both decrease in
manual transcription errors and for potential unanticipated errors due to the new device
integration process. The alternative workaround is continued manual data entry from ICU
monitors, ventilators and infusion pumps. This manual workflow increases the liability for the
organization should a transcription error occur and creates non-value added work for the staff.
5
STAKEHOLDERS
In addition to the stakeholders of the overall EHR project, Project Peripheral includes
stakeholders specific to the device integration project. The Vision 2015 high level process
owners also have responsibilities for the component projects. This “high power, high interest”
group consisting of the organization’s senior leadership includes the hospital Chief Executive
Officer, Board of Directors, Chief Financial Officer, Chief Medical Officer, Chief Information
Officer, Chief Medical Informatics Officer, and the Chief Nursing Officer. This group is
indirectly responsible for the safety and integrity of the system through the power of their
positions but primarily serve to assist with capital resources. They wield the power for
significant change and have the interests of the entire facility in mind. They are not directly
engaged with the project’s design and implementation but must be kept informed of significant
events, changes, or challenges which may impact resources, timelines, or outcomes. They
should be managed closely in terms of communication at appropriate intervals and through
predetermined means.
Stakeholders to keep satisfied due to their high power include the end-users, particularly the
physicians. This group is more intimately associated to the project, and also includes the ICU
nurses, respiratory therapists, ICU pharmacists, ICU unit clerks, specialist physicians, and others
whose daily workflow will be impacted by Project Peripheral. This group is expected to have a
fairly high degree of emotional interest in the project outcome even if they have less interest in
planning and design. The interest level may vary between these users. High user interest could
help to identify “super users” who can lend knowledge and influence to colleagues. These staff
should be sought as key resources regarding user input.
Overall, this group of stakeholders must give frequent feedback to the project team regarding
workflows, use cases, and “user-friendliness” of the system. Their involvement is important in
planning the project and also in testing and training. The ICU Quality Specialists and
Informatics/Data Metrics Analysts must be engaged with the team to determine important data
elements required for analytics and reporting. This information may be required for regulatory
and quality reporting as well as potential research.
Stakeholders with direct connection to Project Peripheral would also include the people or
groups responsible for design and implementation. This would include the project manager as
well as many others. The device integration project team should have overlap with the EHR
design/build team to ensure equal standards, data formats and other key information is kept insync. Others integral to the project include the Biomedical Engineers assigned to the ICU
devices, the hardware team regarding end-user devices, as well as system infrastructure team
working on connectivity, application management team, Help Desk support personnel and
6
training team. If the organization has an Office of Change Management and Workflow Analysis,
these staff should lend their expertise as part of project readiness.
Patients and family members are also key stakeholders. They do not have specific input or
power over the project but are likely to be quite interested. In the ICU environment, lives are
potentially at stake if a device malfunctions. This could result in caregivers not being aware of a
critical change in status, a medication error due to incorrect data entry of a patient weight
resulting in erroneous dose calculation from the infusion pump, or faulty ventilator readings. It
would be desirable to have a communications plan in place to keep patients and families
informed regarding key events such as project go-live and to lessen anxieties.
Other stakeholders providing input and value but with less direct connection to the actual project
include the marketing staff responsible for project communication to employees as well as
hospital patients and their families. The hospital may wish to advertise plans for Vision 2015 to
engage potential new patients through emphasis of the innovative technology allowing for safer
care delivery. Internal communications will allow all employees to be kept apprised of the
project status. This could provide benefits in employee recruitment and retention for tech savvy
employees, and perhaps give reassurance to others who may fear the changes. The Marketing
Web Team plays a role in helping develop internet based training tools and refresher guides to
assist in education of the staff regarding Project Peripheral. Other stakeholders include the
Environmental Services and Patient Transport Group. They will need to be informed and
educated regarding the transport of patients from the ICU who are on integrated devices, and in
regards to special handling of these devices and cables while cleaning.
7
COMMON WORKFLOW SCENARIOS
Diagram 1 – Common Workflow Scenarios
8
USE OF STANDARDS
Standards and working groups focusing on medical device interface standardization have been in
existence for years and have attempted to establish a common architectural, data application and
communication framework for device connectivity with computer-based information systems
and with each other. Barriers to the widespread adoption of interoperability have included the
absence of proven standards for data communication and control, and a lack of reliable and safe
system architectures. Moreover, there have been regulatory concerns, liability concerns, and a
scarcity of well-defined use cases.
From a standard-based interoperability stand-point a significant issue revolves around common
standards that are implemented consistently. Medical devices use either proprietary protocols or
standard-based protocols with local or manufacturer-specific extensions (i.e. proprietary
terminology). Even those vendors who use standards have a choice of standards and
terminology, thus providers have a complex task of integrating multiple vendors devices into
their enterprise. Consistent adoption of standards including terminology would remove some of
the barriers. Unlike information systems, medical devices often undergo a longer product
lifecycle, as they take longer to upgrade and modify not only because they are regulated products
but because they consist of both hardware and software. Therefore designing, developing, and
testing a new or revised medical device version requires more time than an information system.
HARDWARE OR PHYSICAL INTERFACE STANDARDS
The first set of interface standards are standards for connecting the device to a device data
intermediary, such as a PC, laptop or tablet computer. The serial - RS232 (25 or 9 pin), USB, and
IRDA standards have been the most common hardware interface used in collecting the device
data to the PC. These standards have greatly facilitated getting the device data to a PC that is
connected to the network. Most device manufacturers can collect the data from their devices on a
server or gateway. The device gateway can either store the data and or filter the data before
sending it along to the computerized medical record system using the HL7 standard. The devices
can either be polled by the gateway for the data or sent to the gateway at a specific frequency. A
common barrier is that some legacy devices can only send a subset of their data and some cannot
send any data. Most devices today are electronic and should all have the capability of outputting
data to another system, but some of the older devices do not even have RS232 ports, thus, there
is no way to collect their data (Zaleski 2009).
Below is the listing of potential wireless hardware interface standards that could be used to
eliminate the hard-wired data communication from the medical device to the PC in this project.
These technologies are known as Personal Area Network (PAN) technologies.
9
IEEE 802.15 - Bluetooth technology is a short-range communications technology that is simple,
secure, and everywhere. You can find it in billions of devices ranging from mobile phones and
computers to medical devices and home entertainment products. It is intended to replace the
cables connecting devices, while maintaining high levels of security. The Bluetooth SIG is an
industrial association for Bluetooth manufacturers, which has standardized the Bluetooth Health
Device Profile (HDP) for transmitting medical data using Bluetooth. The association works
closely with the IEEE 11073 protocol which standardizes the format for medical data. (Bluetooth
2011)
ZigBee is a specification for a suite of high level communication protocols using small, lowpower digital radios based on the IEEE 802.15.4-2003 standard for Low-Rate Wireless Personal
Area Networks (LR-WPANs), such as wireless light switches with lamps, electrical meters with
in-home-displays, consumer electronics equipment via short-range radio needing low rates of
data transfer. The technology defined by the ZigBee specification is intended to be simpler and
less expensive than other WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF)
applications that require a low data rate, long battery life, and secure networking.(Wikipedia
2011)
One change that is enabling more effective and widespread use of medical device data is the use
of Ethernet (IEEE 802.3) and/or wireless (IEE 802.11) interfaces. Connecting the devices
directly to an existing hospital or dedicated device network provides a great way to receive and
send data to medical devices. Both of these options fall in the category of local area networks
(LANs). The complexity here is in being able to associate a given device with a specific patient
so we know which patient to store the data to and then an easy way to disassociate the device
from the patient. This association is often done by the use of bar coding or radio-frequency
identification (RFID) technology and standards. The Ethernet standard is the hard-wired LAN
solution used when the device is dedicated in the patient’s room and the workflow does not call
for the medical devices to be mobile such as a patient monitor or an infusion pump dedicated to
an ICU room. But some devices, such as mechanical ventilators, must be mobile as they are
required for different patients on an as-needed basis or when a patient monitor or infusion pump
that must accompany a moving patient. For these mobile workflows, enabling the device to
communicate on the network over Wi-Fi is critical to its usability in the clinical environment.
Here are a set of wireless standards to be considered when connecting medical devices to the
network.
IEEE 802.11 is a set of standards for implementing wireless local area network (WLAN)
communication in the 2.4, 3.6 and 5 GHz frequency bands. They are created and maintained by
the IEEE LAN/MAN Standards Committee (IEEE 802).

802.11a - is an amendment to the IEEE 802.11 specification that added a higher data rate of
up to 54 Mbit/s using the 5 GHz band. It has seen widespread worldwide implementation,
particularly within the corporate workspace. Using the 5 GHz band gives 802.11a a
10



significant advantage, since the 2.4 GHz band is heavily used to the point of being crowded.
Degradation caused by such conflicts can cause frequent dropped connections and
degradation of service.
802.11b - is an amendment to the IEEE 802.11 specification that extended throughput up to
11 Mbit/s using the same 2.4 GHz band. This specification under the marketing name of WiFi has been implemented all over the world. 802.11b devices suffer interference from other
products operating in the 2.4 GHz band.
802.11g - is an amendment to the IEEE 802.11 specification that extended throughput to up
to 54 Mbit/s using the same 2.4 GHz band as 802.11b. This specification under the marketing
name of Wi-Fi has been implemented all over the world. 802.11g suffers from the same
interference as 802.11b in the already crowded 2.4 GHz range.
802.11n -is an amendment to the IEEE 802.11-2007 wireless networking standard to improve
network throughput over the two previous standards—802.11a and 802.11g—with a
significant increase in the maximum raw data rate from 54 Mbit/s to 600 Mbit/s with the use
of four spatial streams at a channel width of 40 MHz
MEDICAL DEVICE INTEROPERABILITY STANDARDS
The following is a list of interoperability standards relevant to PMVC project:
ISO IEEE 11073 - replaced IEEE 1073, initially called the Medical Information Bus, is now
called Point-of-care Medical Device Communication standard, and pertains to the
communication of patient data from medical devices (patient monitors, ventilators, and infusion
pumps).
Table 1 – Relevant IEEE 11073 Standards
Standard
Description
11073-10101
Standard describes common nomenclature, syntax and terminology for identifying finds and vitals
parameters. (11073-10101 2004)
11073-10201
Standard proposes a domain information model describing medical device data attributes and their
structure for communicating with external systems.(11073-10201 2004)
11073-20101
Standard proposes application-level communication profiles including medical device encoding
rules, allocation of object identifiers, time synchronization protocols, state transition, and some
sample code segments for implementing these.(11073-20101 2004)
11073-30200
Standard describes suggested connectivity for cable connected communication, including RS-232,
RJ45, and others.(11073-30200 2004)
11
Health Level Seven (HL7) - is the accepted messaging standard for communicating clinical data
and is the most widely implemented standard in healthcare information in the world. This is the
standard used to communicate between the device gateway and the Electronic Health Record
(EHR). This standard is used to provide for outbound transactions or results in the form of both
solicited or unsolicited observations and inbound transactions containing patient identifying
information know as ADT (admit, discharge and transfer) transactions. The HL7 Standard is
broadly divided into two categories – Version 2 (V2) and Version 3 (V3). The majority of HL7
messaging employs messages that use the 2.3 or 2.3.1 versions of the standard. Newer versions
of the standard, including V3, represent only a small portion of real-world usage in interfacing.
Composite medical device standards such as IHE PCD specifically selected HL7 v2.6 as the HL7
version used to send medical device data.
DICOM – Digital Imaging and Communication in Medicine – is a standard for the exchange
of computerized biomedical images and image-related information within and between
healthcare systems. For this project and the devices in scope (patient monitors, infusion pumps
and ventilators) there are no images needed to be transferred, therefore this standard is out-ofscope for this project.
COMPOSITE STANDARDS
These following standards or SDO’s assist in developing specific implementations of established
standards described above in order to achieve our integration goals and specific use cases.
IHE IT Infrastructure (ITI) - The IHE IT Infrastructure (ITI) domain addresses the
implementation of standards-based interoperability solutions to improve information sharing,
workflow and patient care. The following IHE ITI profiles will be used to exchange patient
demographic data from the hospital registration system to the medical devices and the medical
device gateways using the HL7 standard: (IHE 2010)


Patient Demographics Query [PDQ] lets applications query a central patient information
server and retrieve a patient’s demographic and visit information.
Patient Administration Management [PAM] establishes the continuity and integrity of
patient data in and across acute care settings, as well as among ambulatory caregivers.
IHE Patient Care Devices (PCD) - The “Integrating the Healthcare Enterprise” organization
(IHE) is an international voluntary collaboration of vendors, healthcare providers, regulatory
agencies, and independent experts working on improving medical data interoperability in a
number of subject areas (domains), such as radiology in healthcare. The IHE domain concerned
with electronic medical devices is the patient care devices domain (IHE PCD Domain). IHE does
not exist to create standards, but rather “integration profiles,” which show how to apply existing
standards from internationally recognized standards development organizations (SDOs) to
12
particular medical information exchange needs (IHE 2010) . IHE has drafted and codified a
patient care device technical framework to provide guidance in the application of existing
standards for medical device integration and interoperability (e.g.: HL7, IEEE 11073)
Table 2 – Overview of current IHE PCD activities
Activity
Description
IHE PCD DEC - Device
Enterprise
Communication
Sending device data to an enterprise system using HL7 v.2.6 (PCD-01 transactions),
specifying subset of device data to subscribe to (PCD-02).
The following standards are utilized by the IHE PCD DEC transactions.



IHE PCD PIV - Point-ofCare Infusion
Verification
Sending an infusion order to an infusion pump using HL7 v.2.6 for verification by a
clinician before initiation, to reduce risk of medication errors.
The following standards are utilized by the IHE PCD PIV and DEC transactions.




IHE PCD ACM - Alarm
Communications
Management
IHE PCD WCM Waveform
Communication
Management
IHE PCD RTM - Rosetta
Terminology
Management
HL7 - Health Level 7 Version 2.6 CH5 Query and CH7 Observation Reporting
ISO/IEEE 11073-10201 Domain Information Model
ISO/IEEE 11073-10101 Nomenclature
HL7 - Health Level 7 Version 2.6 CH4 Order Entry
HL7 - Health Level 7 Version 2.6 CH5 Query and CH7 Observation Reporting
ISO/IEEE 11073-10201 Domain Information Model
ISO/IEEE 11073-10101 Nomenclature
Sending details of a physiological or technical alarm from a patient care device to an
alarm management system and from there typically to a phone or other hand-held
device for notification of the event to appropriate persons.
Extending the DEC Profile to support the encoding of patient care device waveform
data (ECG, ventilator waveforms, etc.) in HL7 v.2.6 messages.
Specifying uniform terms and codes for clinical and technical observations from
devices, to reduce risk of mistaken or lost measurement identity, and also permissible
valid units of measure for observations. Conformance to RTM is required in all other
PCD Domain profiles to which it is applicable.
IHE PCD Rosetta Terminology Mapping (RTM)- The primary purpose of the Rosetta
Terminology Mapping (RTM) profile is to harmonize the use of existing ISO/IEEE 11073-10101
nomenclature terms by systems compliant with IHE PCD profiles. The RTM profile also
specifies the units-of-measure and enumerated values permitted for each numeric parameter to
facilitate safe and interoperable communication between devices and systems. The Rosetta Table
is designed to serve as a temporary repository that can be used to define new nomenclature terms
that are currently not present in the ISO/IEEE 11073-10101 nomenclature. RTM will also serve
as a framework for capturing new terms to support the IEEE 11073 ‘Personal Health Devices’
(PHD) initiative.
13
Continua- The Continua Health Alliance is a non-profit, open industry coalition of healthcare
and technology companies, patient organizations and associations that are joined to collaborate
and improve the quality of personal healthcare. Continua is not a standards setting body – rather
the Alliance selects existing commercially available standards, works within them by adding
definitions or refinements and finally tests and certifies interoperability of devices among
member companies. The Alliance then drafts guidelines on how to use those existing standards
to achieve true interoperability across many companies and many devices. Initial efforts are in
the home healthcare and sport device arenas, therefore out-of-scope for our project.
HITSP -Healthcare Information Technology Standards Panel (HITSP) selects standards and
profiles for uses in the United States, particularly related to government institutions and
activities. Like IHE, they are not a standards development organization, and are chartered not to
create standards but to select them and facilitate their use. In a great many cases, they adopt IHE
profiles for this purpose. As in the case of SDOs, there is close cooperation between HITSP
committees and IHE committees, helped by overlap in membership.
AAMI 80001-1 Managing Medical IT-Networks- 80001-1 specifies general requirements for
the application of risk management of IT-networks incorporating medical devices that achieve
essential properties such as safety, effectiveness, data and system security and interoperability. It
defines responsibilities for parties such as medical device manufacturers, non-medical device
manufacturers, the responsible organization, IT-network integrator, and potentially others,
engaged in installing, using, reconfiguring, maintaining and decommissioning IT-networks
incorporating medical devices. This Standard addresses risks related to patients, operators and/or
third parties.(AAMI 2010)
MD PnP - Medical Device "Plug-and-Play" Interoperability Program – is an interdisciplinary, multi-institutional medical device informatics research program. MD PnP is
pursuing open standards leading to seamless, universal connectivity among medical devices and
systems.(MDPnP 2011) MD PnP was initiated by Massachusetts General Hospital (MGH) and
the Center of Integration of Medicine & Innovation Technology (CIMIT) (CIMIT 2011). This is
an interdisciplinary program focusing on medical device interoperability to improve patient
safety and workflow-related efficiency.
14
Patient
Registration
HL7 (ADT)
IHE ITI
HL7 (ADT)
IHE ITI
HL7 v2.6
IHE PCD
IEEE 11073
Device Gateways
Electronic
Health
Records
Ethernet,
802.11 a/b/g/n
Ethernet,
802.11 a/b/g/n
Ethernet,
802.11 a/b/g/n
Bedside
Computer
Rs232, USB, IRDA,
Bluetooth, Zigbee
IEEE 11073
Patient Monitor
Rs232, USB, IRDA,
Bluetooth, Zigbee
IEEE 11073
Ventillator
Ethernet,
802.11 a/b/g/n
Rs232, USB, IRDA,
Bluetooth, Zigbee
IEEE 11073
Infusion Pump
Diagram 2: Medical Device and Data Exchange Standards
15
INFORMATION SYSTEM FUNCTIONAL REQUIREMENTS
The following functional and information system requirements required for the project are listed:
The system shall only be utilized in an ICU setting.
All patient demographic information shall come from the registration system.
The system shall provide updated patient demographic information to the medical device
The system shall provide for a mechanism to associate a particular medical device to a specific
patient.
The system shall link the ICU monitor, ventilator, or IV infusion pump attached to a patient bed
with the patient assigned to that bed in the EHR.
All system data sent through the interface shall be reviewed and verified by appropriate clinical
staff before being permanently filed into the EHR.
The system shall utilize defined standard ICU devices.
The system shall provide for the electronic transmission of infusion information from a barcodeenabled medication administration system (BCMA) to an infusion pump as part of the
medication administration process.
The system shall support the ―five rights‖ of medication administration electronically (right
patient, right route, right dose, right time, right drug)
The system shall provide the management of alarms and notifications
The system shall send the following data points from the ICU patient monitor through the
interface and file discretely into the EHR:
1. Temperature
2. Non-Invasive Blood Pressure Systolic
3. Non-Invasive Blood Pressure Diastolic
4. Non-Invasive Blood Pressure Mean
5. Invasive Blood Pressure Systolic
6. Invasive Blood Pressure Diastolic
7. Invasive Blood Pressure Mean
8. Monitored Heart Rate
9. Pulse Oximetry
10. Respirations
11. End Tidal CO2
12. Cardiac Output
16
13. Cardiac Index
14. Central Venous Pressure
15. Saturated Venous Oxygen
16. Pulmonary Artery Pressure Systolic
17. Pulmonary Artery Pressure Diastolic
18. Pulmonary Artery Pressure Mean
19. Pulmonary Capillary Wedge Pressure
20. Intracranial Pressure
21. Coronary Perfusion Pressure
22. Right Ventricular Stroke Work
23. Left Ventricular Stroke Work
24. Right Ventricular Stroke Work Index
25. Left Ventricular Stroke Work Index
26. Systemic Vascular Resistance
27. Systemic Vascular Resistance Index
28. Pulmonary Vascular Resistance
29. Pulmonary Vascular Resistance Index
30. Stroke Volume
31. Stroke Volume Index
The system shall send the following data points from the ventilator through the interface and file
discretely into the EHR:
1. Ventilator ID
2. Ventilator type
3. Humidifier temperature setting
4. Humidifier temperature actual
5. Ventilator mode
6. Waveform settings
7. Tidal volume set (Vt)
8. Minute ventilation (Ve)
9. Set rate
10. Patient rate
11. Sigh volume set (mL)
12. Sigh rate set
13. Trigger
14. Inspiration time
15. Expiration time
16. I:E ratio set
17. T High
18. T Low
17
19. P High
20. P Low
21. Inspiratory positive airway pressure (IPAP)
22. Expiratory positive airway pressure (EPAP)
23. Peak flow
24. Pressure control
25. Pressure support
26. Positive end-expiratory pressure (PEEP)
27. Continuous positive airway pressure (CPAP)
28. FiO2
29. Heliox Flow
30. Heliox Mixture
The system shall send the following data points from the IV infusion pump through the interface
and file discretely into the EHR:
1. Pump ID number
2. Pump mode (primary, intermittent, fluid, secondary, bolus)
3. Pump status (infusion start, infusion start at KVO rate, infusion complete, infusion
paused, infusion delayed, infusion stopped, device disconnect from Systems Manager,
device (re)connect to Systems Manager)
4. Volume to be infused
5. Volume remaining
6. Volume infused
7. Rate
8. Drug name
9. Drug concentration
10. Dose rate
11. Dose
12. Time stamp of event
18
DIAGRAM OF THE INFORMATION ARCHITECTURE
PRESENT STATE
The current PMVC architecture as it relates to biomedical devices consists of disparate standalone systems from a variety of vendors. The medical device systems require manual re-entry of
the patient demographics into each device or system and are not integrated within the larger
hospital enterprise. The data in these systems are contained within each system are do not allow
for the communication and interoperability of the physiological data into other systems like an
electronic health record (EHR). The diagram below depicts the current architecture.
Central
Monitoring
and
Surveillance
Information Systems
Patient Monitoring
Gateway
EHR
Patient
Monitors
PHR
CDSS
Clinical Decision Support
Systems
Ventilators
Infusion Pump
Gateway
Infusion
Pumps
Diagram 3 – Current Information Architecture
19
FUTURE STATE
The future architecture allows for the interoperability and the full exchange of information from
multiple systems from different vendors within the enterprise. The registration system is the
supplier of the patient demographics to all systems including the medical devices eliminating the
need to enter patient information at the device. The different device gateways provide for the
communication of the physiological data and alarms to the enterprise. This allows the device
data to be available for viewing in other systems like the EHR. This architecture also provides
the ability for the smart infusion pumps to communicate orders and data from the other ancillary
systems such as pharmacy, Point-of-Care Medication System (BPOC), and Electronic
Medication System (eMAR), allowing for the ability automate the clinical task of entering the
drug information into an infusion pump.
This interoperability of device data also provides the ability to use this data in other systems such
as clinical decision support system, data mining, and data warehouse.
This architecture also uses an interface engine as a traffic cop or message broker to all the
systems. For example, the interface engine receives patient information (ADT messages) from
the registration system then forwards them on to the different systems including the device
gateways. The interface engine would also receive the different HL7 result messages from the
device gateways and reformat them to a standard format. With this approach, conformance
happens in the Interface Engine, not in the individual device gateways.
The interface engine will also provide the following benefits.







Decrease integration costs by providing an alternative to customized point-to-point
interface application programming.
Improves data quality because of data mapping and consistent use of terms.
Allows our hospital to select the best system and medical devices for our needs
Preserves institutional investments in existing systems and medical devices
Simplifies the administration of healthcare data processing
Simplifies systems integration efforts
Shortens the time required for integration
20
Central
Monitoring
and
Surveillance
Workstations
PDA,
Smart
Phones
Decision Support /
Analytical Tools
Information Systems
Proprietary Device
Gateways
Interface Engine
Patient Monitoring
Gateway
HL7 / ADT
EHR
Patient
Monitors
Querry
Physiological
And
Operational
data
PHR
Report Writer
IHE PCD
Framwork
CDSS
Clinical Decision Support
Systems
Ventilator
Gateway
Ventilators
OLAP
MPI
Infusion Pump
Gateway
Data
Mining
Infusion
Pumps
Data
Warehouses
Data
Marts
Registration System
Pharamcy
BPOC
Electronic
Medication
Administration
(eMAR)
Diagram 4 – Future Information Architecture
21
IDENTIFICATION OF THE ORIGIN OF THE DATA ELEMENTS
Below are the sources and origins of the key data elements that are needed for this project.
PATIENT DEMOGRAPHICS
The patient demographics are provide by the patient at registration and entered in the hospital
registration system. The table shows the minimum data elements.
Patient Demographics
Patient ID
Account Number
Name
Date of Birth
Gender
SSN
Race
Address
Phone Numbers
Insurance Information
Location
Bed Number
Visit Number
Account status
Attending Physician
Referring Physician
Consulting Physician
ORDER DATA
Medication order details are needed in order to program the smart infusion pumps. This data is
entered by provider into EHR\CPOE system and travels from a Point-of-Care Medication System
(BPOC) or from the Pharmacy to a pump server.
Medication Orders
Name of the medication (generic and/or brand)
Dose of the medication
Dose Rate
Route of administration
Frequency [quantity }
Duration of therapy when appropriate
Volume to be infused
22
PHYSIOLOGICAL DEVICE DATA AND DEVICE ONFIGURATION
The physiologic device date will be provided by the individual devices attached to the patients.
The device configuration data elements, such as alarm limits, IV line information, ventilator and
monitoring parameters will be entered in the devices by the clinicians. In the case of the smart
infusion pumps these configurations will be provided by the order data. Here is a minimum list
of data elements provided by the three different types of devices.
Patient Monitoring Data
Ventilator Data
Infusion Pump Data
Temperature
Non-Invasive Blood Pressure
Systolic
Non-Invasive Blood Pressure
Diastolic
Ventilator ID
Pump ID number
Ventilator type
Pump mode
Humidifier temperature setting
Pump status
Non-Invasive Blood Pressure Mean
Humidifier temperature actual
Volume to be infused
Invasive Blood Pressure Systolic
Ventilator mode
Volume remaining
Invasive Blood Pressure Diastolic
Waveform settings
Volume infused
Invasive Blood Pressure Mean
Tidal volume set (Vt)
Rate
Monitored Heart Rate
Minute ventilation (Ve)
Drug name
Pulse Oximetry
Set rate
Drug concentration
Respirations
Patient rate
Dose rate
End Tidal CO2
Sigh volume set (mL)
Dose
Cardiac Output
Sigh rate set
Time stamp of event
Cardiac Index
Trigger
Central Venous Pressure
Inspiration time
Saturated Venous Oxygen
Expiration time
Pulmonary Artery Pressure Systolic
I:E ratio set
Pulmonary Artery Pressure Diastolic
T High
Pulmonary Artery Pressure Mean
Pulmonary Capillary Wedge
Pressure
T Low
Intracranial Pressure
P Low
Coronary Perfusion Pressure
Inspiratory positive airway pressure (IPAP)
Right Ventricular Stroke Work
Expiratory positive airway pressure (EPAP)
Left Ventricular Stroke Work
Peak flow
Right Ventricular Stroke Work Index
Pressure control
Left Ventricular Stroke Work Index
Pressure support
P High
Positive end-expiratory pressure (PEEP)
Continuous positive airway pressure
(CPAP)
FiO2
Heliox Flow
Heliox Mixture
23
DESCRIPTION OF DATA FLOW
The flow of data sets between systems for the integration of vital signs monitoring, ventilators,
and infusion pumps devices with the electronic health record is broken up into three distinct
flows and illustrated in Diagram 5. The diagram illustrates the data flow and information
exchanges between systems and also lists the IHE PCD transaction to be used.
FLOW OF PATIENT DEMOGRAPHICS DATA
The Patient Registration system will send ADT (admit, discharge, transfer) messages for new or
updated demographics and patient visit information. Generally, information will be entered into a
Patient Administration system and passed on to different medical device gateways, either in the
form of an unsolicited update or in response to a record-oriented query. The medical devices
will use barcode scanners to identify the patient by scanning the patient’s wristband and
validating the patient data with the device gateways and the ADT messages.
FLOW OF PATIENT MONITORING DATA
The first flow addresses the need for consistent communication of patient monitoring data to the
EHR that supports efficient patient care and better patient safety by reducing manual data entry
(e.g. patient demographics) and populating data from the patient monitoring devices into EHR
automatically. To automate the clinical task of entering patient vital signs and monitoring data
into our EHR, we need to send patient vital sign monitoring results from the patient monitoring
gateway to the EHR system. The diagram illustrates that vital signs that travel from a vital signs
monitor gateway to an EHR system use the IHE PCD-01 message or PCD-02 message if the data
needs to be filtered first. The exchange of wave form data from the monitoring gateway may be
implemented in the future, but out of scope for this initial project.
FLOW OF VENTILATOR DATA
The second flow addresses the need to send ventilator data to the EHR. This flow will be similar
to the patient monitoring flow, where the ventilator will receive ADT from the patient
registration data and send ventilator data to an EHR system using the IHE PCD-01 message. The
exchange of wave form data from the ventilator gateway may be implemented in the future, but
out of scope for this initial project.
24
FLOW OF INFUSION PUMP DATA
The last flow is to bring infusion pump data into the electronic medication administration
process. The workflow provides for the electronic transmission of infusion information from a
barcode-enabled medication administration system (BCMA) to an infusion pump as part of the
medication administration process. This reduces the need for manual programming of the pump,
and leverages the use of the pump’s onboard drug library to reduce medication errors. To
automate the clinical task of entering the drug information into an infusion pump, we need the
medication order details (drug, dose, volume, etc.) to be sent from our Bedside Point of Care
(BPOC) system to the infusion pump gateway that manages that pump. The diagram illustrates
that orders that travel from a Point-of-Care Medication System (BPOC) or from the Pharmacy
system to a pump gateway use an order request represented by IHE PCD-03 message. The
infusion pump gateway will also send pump alarms to a secondary alarm manager that will send
the alarm to a Smartphone, PDA, or pager. The exchange of alarm data will use the IHE ACM
profile and corresponding transactions.
The table below details the IHE profile and the transaction to be used to exchange the data and
referenced in the data flow diagram.
Table 3 – IHE Profiles and Transactions
Profile
IHE PCD DEC
IHE PCD PIV
IHE PCD ACM
ID
Transactions Title
PCD-01
Communicate PCD Data
PCD-02
PCD-02 - Specifying subset of device data to subscribe to
PCD-03
PCD-03 - Communicate Infusion Order
PCD-04
Report Alarm
PCD-05
Report Alarm Status
PCD-06
Disseminate Alarm
PCD-07
Report Disseminate Alarm Status
PCD-08
Subscribe to Alarm
25
Disseminate
Alarm
PCD-06
Report Alarm
PCD-04
SmartPhone
PDA
Pager
Secondary Alarm
Manager
Alarm Status
PCD-05
Central
Monitoring
and
Surveillance
Alarm Status
PCD-07
Monitoring
Data
Monitoring Results (PCD-01, PCD-02)
Monitoring Data
EHR
ADT
Orders
PCD-03
ngPatient Monitoring
o ri
nit
Gateway
Mo Data
ADT
Ventilator Data
PCD-01
Wearable
Monitor
Registration System
Orders
PCD-03
Orders
PCD-03
eMAR
Infusion Data
PCD-01
Pharamcy
BPOC
Ventilator
Gateway
ADT
Infusion Pump
Gateway
Disseminate
Alarm
PCD-06
Ventilators
SmartPhone
PDA
Pager
Report Alarm
PCD-04
Secondary Alarm
Manager
Alarm Status
PCD-07
Infusion
Pumps
Alarm Status
PCD-05
Diagram 5 - = Flow of data sets between systems
For easier illustration purposes, the flow of data sets and architecture illustrated above uses a
Point-to-Point interfacing approach where each medical device gateway receives ADT messages
directly from the patient registration system and sends HL7 result messages directly to the EHR.
In this approach each medical device vendor must make modifications to their gateways to
accept the ADT format supplied by the patient registration and conform to the IHE-PCD
specifications. This is in contrast to the architecture described previously which uses an interface
engine which would be the preferred approach.
26
Infusion Data
PCD-01
Patient
Monitors
SUMMARY
PVMC has embarked upon a significant endeavor regarding use of technology. The Project
Peripheral goal to connect ICU devices for electronic data feed into their hospital EHR is one
aspect. This paper outlines the business case to support the ICU device interoperability project
as well as assessments of workflow, present and future state designs, relevant data elements, and
architecture. Adequate project scope, design and implementation planning are essential to the
success. Engagement of the users to provide clinical input during the design phase will
strengthen likelihood of adoption and potentially avoid gaps in functionality or safety. Use of
medical and device integration standards, including use of vendors who follow recommended
standards, will facilitate integration of data into the EHR in a meaningful and useful way. Goals
for improvements in safety and efficiency of the staff will result in enhanced care delivery for
this population of critically ill patients.
27
REFERENCES
11073-10101 (2004). ISO/IEEE Health Informatics - Point-Of-Care Medical Device Communication - Part 10101:
Nomenclature. ISO/IEEE 11073-10101:2004(E): 0_1-492.
11073-10201 (2004). ISO/IEEE Health Informatics - Point-Of-Care Medical Device Communication - Part 10201:
Domain Information Model. ISO/IEEE 11073-10201:2004(E): 0_1-169.
11073-20101 (2004). IEEE Standard for Health Informatics - Point-Of-Care Medical Device Communication - Part
20101: Application Profile - Base Standard. ISO/IEEE 11073-20101:2004(E): 0_1-0_4.
11073-30200 (2004). IEEE Standard for Health Informatics - Point-Of-Care Medical Device Communication - Part
30200: Transport Profile - Cable Connected. ISO/IEEE 11073-30200:2004(E): 0_1-0_4.
AAMI (2010). "80001-1 Managing Medical IT-Networks ". from
http://www.aami.org/publications/standards/80001.html.
Bluetooth (2011). "Bluetooth Special Interest Group." from https://www.bluetooth.org/apps/content/.
Chan, L., Hailperin, M. (2009). "Developing a strategy for integrating medical device data with clinical information
systems (Powerpoint Slides). ." from http://www.dvhimss.org/pastprograms/pastprograms6.html
CIMIT (2011). "Center for Integration of Medicine & Innovative Technology."
IHE (2010). "IHE Patient Care Device Domain." from http://www.ihe.net/.
Leape, L. L., et al. (1995). "Systems analysis of adverse drug events." Journal of the American Medical Association:
274 (271), 235-243.
MDPnP (2011). "Medical Device "Plug-and-Play" Interoperability Program." from http://www.mdpnp.org.
Meccariello M, P. D., Quigley LG, Rock A, Qiu J. (2010). "Vital time savings: evaluating the use of an automated vital
signs documentation system on a medical/surgical unit." Journal of Healthcare Information Management:
24(24):46-51.
Wikipedia (2011). "ZigBee Standard." Retrieved 05/01/2011, 2011, from http://en.wikipedia.org/wiki/Zigbee.
Zaleski, J. (2009). "Integrating Device Data into Electronic Medical Record."
28