Jeffrey Peterson Clinical Engineer MD PnP Interoperability Program @ MGH
Open Source
Interoperability
Problems, Prototypes,
and Potential
11/6/14
Agenda
1 Problems
2 Prototypes
3 Potential
PCA Safety
¡ Patient Controlled Analgesia
¡ Patient presses pain button to receive intravenous
pain medication
¡ Comprehensive monitoring generally not used
¡ Sometimes SpO2 required
¡ Over medication can kill
11/6/14
5
11/6/14
7
11/6/14
9
Adverse Event Affects
PCA Safety
¡ 0.19% - 11.5%
¡ Respiratory depression associated with PCA use (Hagle, 2004; Cashman, 2004)
¡ 65-677 patients annually
¡ Mortality from IV-PCA programming errors (Vicente, 2003)
¡ 56,000 patients
¡ Adverse events including injury and death from smart PCAs between 2005
and 2009 (FDA, Center for Devices, 2010) ¡ 1,072-6,875 patients annually (up to 18/day)
¡ Adverse events from PCA usage extrapolated from 82 annual events in FDA
MAUDE (Hankin, 2005)
The Cost of Error
PCA Safety
¡ Costs specifically associated with IV PCA–related errors (Meissner, 2009)
¡ $388 million for medication-related errors (MED MARX data)
¡ $12 million for device-related errors (MAUDE data)
¡ Average cost per error event $733 in the MEDMARX dataset and $552 in the MAUDE dataset
¡ Harmful IV PCA errors were 120 to 250 times more costly than non-harmful
errors
¡ 407 IV PCA–related errors annually
¡ 17 device-related errors per 10,000 people within the United States
11
Single Device
Alarm Fatigue
1 Noisy ECG signal induces a HR
reading of 0 and an Asystole
alarm is announced
2 Arterial IBP waveform indicates
the heart is still pumping
3 Staff slowly loses trust in the
Asystole alarms and response time slowly increases
Multiple Device
Alarm Fatigue
1 Alarm: Respiration Rate Low
¡ Source: Transthoracic
impedance from monitor
2 Patient is intubated and
ventilated
¡ Respiratory rate is controlled
3 Is more data better?
¡ More alarms certainly are
not
11/6/14
13
Impact
Alarm Fatigue
¡ Is there a technology answer to alarm fatigue?
¡ Workflow and process improvements can only improve
the current state so far
¡ 85% to 99% of alarms are not actionable (AAMI 2011)
14
Not Actionable
Possibly Not Actionable Actionable
Integration Hazards
¡ Near miss event in OR – how do we review?
¡ Minimum HR? No BP data? Reverse P waves?
11/6/14
15
Black Box Data Archive
Integration Hazards
¡ What happened?¡ Clinically, what happened to the patient?
¡ What did the devices record? Did they malfunction?
¡ Staff holds grand rounds to review the case and to
determine if the treatment of the patient’s un-anticipated deterioration was appropriate
¡ Time sync data importance to data collection
Time Synchronization
Integration Hazards
11/6/14
17
Device Type
Count StdDev Offset Average Offset Maximum Offset
Medical Devices (Excl. Workstations & Wall
Clocks) 1324 1:32:34 0:33:26 16:42:10
All devices 1732 1:22:12 0:25:58 16:42:10
Networked Devices that
Auto-Sync 291 0:02:16 0:00:53 0:31:16 Stand-alone Devices 950 1:46:38 0:46:06 16:42:10 Hospital A 52 0:31:11 0:30:25 1:52:00 Hospital B 495 1:41:23 0:32:55 16:42:10 Hospital C 468 0:47:12 0:17:10 13:39:28 Hospital D 717 1:27:24 0:26:35 13:18:47
ECRI’s Top 10 Health Technology Hazards
Breadth of Problems
2014
1. Alarm hazards
2. Infusion pump medication errors
3. CT radiation exposures in pediatric patients
4. Data integrity failures in EHRs and other health IT
systems
5. Occupational radiation hazards in hybrid ORs 6. Inadequate reprocessing of endoscopes and
surgical instruments
7. Neglecting change management for networked
devices and systems
8. Risks to pediatric patients from “adult” technologies
9. Robotic surgery complications due to insufficient training
10. Retained devices and unretrieved fragments
2013
1. Alarm hazards
2. Medication administration errors using infusion
pumps
3. Unnecessary exposures and radiation burns from diagnostic radiology procedures
4. Patient/data mismatches in EHRs and other health
IT systems
5. Interoperability failures with medical devices and
health IT systems 6. Air embolism hazards
7. Inattention to the needs of pediatric patients when using “adult” technologies
8. Inadequate reprocessing of endoscopic devices and surgical instruments
9. Caregiver distractions from smartphones and other mobile devices
10. Surgical fires
What is the Solution?
¡ There is no single solution, but we as an industry can
do better
¡ We can build a better foundation to build the next
generation of devices on
¡ Provide apps and devices alike with the contextual
and state information needed to make better decisions/algorithms
19
Functional Data Sharing
¡ What if the PCA pump knew the vitals of thepatient?
¡ What if different devices/monitors/applications
could act on each others alarms and data?
¡ What if there was a seamless, reliable and
comprehensive archive of medical device data for a patient’s entire duration of stay?
But we have interoperability
already, right?
Standards-Based ¡ Heath Level 7 ¡ HL7 FHIR ¡ ISO/IEEE 11073 ¡ Continua 11073-20601 PHD ¡ IHE PCD-01 Proprietary ¡ GE Unity ID ¡ Philips Intellibridge/Vuelink ¡ Dräger Medibus ¡ Dongles: NantHealth, Capsule21
11/6/14Health Level 7
¡ Messaging protocol for event notification
¡ Point to point communication
¡ “Exchange, integration, sharing, and retrieval of electronic
health information”
¡ Massive scope WRT content areas
¡ The Wiki currently has 7,396 pages
¡ Ex: ADT feed – Message indicates a patient has been admitted (does not indicate the location of every patient to every interested party)
HL7 FHIR
¡ FHIR - Fast Healthcare Interoperability Resources ¡ Based on HL7 except modular and extensible
¡ XML representation of information model
¡ Uses existing web standards for fast implementation
¡ XML, REST, JSON, HTTP, OAuth
¡ Quickly gaining adoption
11/6/14
23
ISO/IEEE 11073
¡ Specified a domain information model,
nomenclature, application profiles, transportation profile (specifies OSI Layers 5-7)
¡ Defines manager to agent communication ¡ Never achieved wide-spread adoption
¡ Too complex?
Continua 11073-20601 PHD
¡ Intended use is for communication betweenperson home health devices and healthcare application or EMR
¡ Organized into Agent-Transport-Manager
¡ Doesn’t define agent-agent interactions
¡ Focus on small, limited functionality devices
11/6/14
25
IHE PCD-01
¡ Intended use: put data into EMR
¡ Message based observational reporting
¡ “Transaction used to communicate Patient Care
Device Data between Device Observation Reporter and Device Observation Consumer actors”
¡ Uses HL7 V2.6 Chapter 7
¡ Uses an information model and a nomenclature from the IEEE 11073
Proprietary Interoperability
¡ In general: methodologies for getting data into apatient monitoring network and subsequently into the EMR
¡ Third party devices are a data source, never a sink ¡ There are often licensing fees, NDAs, and other
legal or financial roadblocks slowing adopters
11/6/14
27
So what is missing?
¡ We have standards for integration, not necessarily
interoperability
¡ We do not have the tools needed to develop
solutions
Problem Statement
¡ There is currently no publically available tooling to
develop a device or application that can leverage massive amounts of state and transactional real
time data originating from medical devices and applications without the limitations of peer to peer transactional messaging
29
MD PnP @MGH
¡ Medical Device Plug and Play Interoperability Lab ¡ Mass General Hospital – Department of Anesthesia
11/6/14
31
MD PnP Team
11/6/14
32
Dr. Julian Goldman
Director, PI Dave Arney Lead Engineer
Jeff Plourde
Lead Developer Andrea Lenco Research and Grants
Jeff Peterson
Clinical Engineer Diana Lu Program Manager
Rick Schrenker
Senior Biomedical Engineer Katharine Koury Clinical Research Coordinator
Diego Alonso
Application Developer Ken Auerbach Database Engineer
Dylan Bagshaw
MD PnP Key Milestones
¡ 2004 – Program Kickoff¡ 2005 – Lab Opens
¡ 2008 – MD FIRE Procurement Guide Published ¡ 2009 – ICE Standard Published
¡ 2009 – NIH $10M Funding
¡ 2012 – OpenICE Prototype Begins
33
MD PnP Collaborations
What is our goal?
¡ Increase patient safety and outcomes by
developing the tools needed to build a more intelligent and open medical device ecosystem
¡ ICE - Integrated Clinical Environment
¡ Device interface specification
¡ Reference prototype implementation
¡ Core functionality - security, patient ID management,
device inventory, etc.
11/6/14
35
OpenICE Project
MD PnP Objective
Integrated Clinical Environment Prototype Reference ImplementationRequirements and Technical Specifications
Standards Based Regulatory Pathway
Integrated Clinical Environment
ASTM-F2761-09 ICE
¡ Multi-manager (apps)
¡ Data Logger
¡ Functional architecture
¡ No technical specification (yet)
¡ Device adapter
¡ Replaced by native speakers
11/6/14
37
OpenICE Prototype in the Lab
ASTM-F2761-09 ICE
38
Middleware (DDS)
What is a parallel system?
¡ Multiple processors run multiple software programs
concurrently within the same computer
¡ There is shared “memory” that all processors can
access
Memory
Email Web Browser Word Processor
What is a distributed system?
¡ A collection of networked computers coordinatingtheir actions by passing messages
¡ Each computer has isolated memory
¡ No one computer can know at any instant the true
contents of all isolated computer memories
Memory
Medical Device Supervisor Application
Memory Memory
Messages Messages
What is Data Distribution
Service?
¡ An abstraction layer (API) that simplifies distributed
system development by providing all computers with a reproduction of shared memory
Memory
DDS DDS DDS
Memory Memory
Messages Messages
Medical Device Supervisor Application
Memory
ICE Device Adapter OpenICE Data Model Web Server (socket.io) openice.info ICE Supervisor Data Logger (MongoDB) Device Device ICE Device Adapter DDS Participant Web
OpenICE Prototype
42
DDS Websocket ProprietaryDDS Websocket Proprietary Ivy Vital-Guard 450C Dräger Evita XL Beaglebone Black Network Web Browser Server OpenICE Supervisor
OpenICE Prototype
43
Current Deployment Equipment
OpenICE Prototype
¡ Single subnet Ethernet
¡ Zero configuration required
¡ WiFi 802.11n enabled
¡ Hardware
¡ Standard PCs (Mac, Windows, Linux) running
Supervisor
¡ BeagleBones running “device adapter” software
¡ Standard Intel server running Ubuntu
¡ These are not the only possibilities for
deployment
Data Model API
OpenICE Prototype
¡ www.openice.info/diagnostics.html
11/6/14
45
Device Functionality
Many Problems to Solve
¡ Medical devices today were not designed with ICE
functionality in mind
¡ Time of data export is varied (PB840)
¡ Alarm data export behavior differs (Ivy alarm silence)
¡ Waveform export is highly varied (Philips batching)
¡ Nomenclature is not standardized (NIST, 11073, etc.)
Regulatory
Many Problems to Solve
¡ FDA WG – Component based regulatoryenvironment is the agreed upon pathway
¡ Pre-submission for devices based on ICE
¡ ASTM-F2761 (ICE) was recognized by FDA as part of
a list of interoperability standards
(Disclaimer: I do not speak on behalf of the FDA)
47
Adoption
Many Problems to Solve
¡ Preliminary research ICE implementations at MGH ¡ Small companies
¡ DocBox, Moberg
¡ MD FIRE – Signed by VA, Kaiser, Hopkins, Partners ¡ NIST Demonstrated ICE-based data logger
PCA Safety Demo
¡ Open sourced¡ Download from mdpnp.sourceforge.net
¡ Closed loop control of PCA pump ¡ Can use devices or simulators
Web Demo
https://openice.info/demo.html
11/6/14
55
Data Logger - Clinical Black Box
¡ Record device data in an open, standardized, and time-synchronized manner
¡ The log will include:
¡ Commands, Button presses, Location, Status
¡ Physiologic and technical alarms
¡ Physiologic vital sign data from patients
¡ Device connections and disconnections from ICE
¡ Data Log supports Analysis and Playback for two complementary purposes:
¡ Analysis of device interactions (debugging, root cause analysis)
What can ICE do for us?
¡ Enables the community!
¡ Provides interoperability for novel applications
¡ Cost savings/workflow improvement for CE/IT
¡ Streamlined HIT installations and lower Integration costs
¡ Remove dependencies on underlying infrastructure
¡ (Possible) Streamlined Regulatory Pathway
¡ Lower activation energy for development and deployment
11/6/14
57
MD FIRE
What can I do today?
¡ MD FIRE - Medical Device Free Interoperability
Requirements for the Enterprise – mdpnp.org
¡ Procurement and adoption of open, documented,
interoperable interfaces
¡ Comprised of a white paper, sample RFP and
contracting language
¡ Signed by VA, Kaiser, Hopkins, Partners
Someone else’s problem…
What can I do today?
¡ Facilitate physician innovation (drive user needs)
¡ Advanced critical care informatics
¡ Support evolving and innovative clinical care models
¡ Participate in the standards process
¡ Hospitals are out represented by ~10:1 to OEMs
59
Future of Clinical Engineering
¡ Shift towards IT is an opportunity¡ Medical devices are quickly becoming the most
essential inputs into the HIT ecosystem
¡ Point of care validation of components/apps will
be a new focus area
¡ Similar to the requirement for electrical safety testing
¡ Management and configuration (e.g. pump drug
libraries)
Future of Clinical Engineering
¡ CEs are uniquely positioned to enable, support,and develop the future of medical technology
¡ Data driven medicine
¡ Clinical decision support systems
¡ Hospital designed algorithms (hospital as a
manufacturer)
11/6/14
61
Future of Clinical Engineering
¡ Clinicians/nurses who innovate can improveoutcomes, reduce costs, generate publications, generate IP, create opportunities for revenue generation
¡ Innovation almost always requires new data collection
or connectivity – CEs are the gatekeepers to this innovation
¡ These activities are fundamentally enabled by CE
Thank You
Learn more:¡ OpenICE.info
¡ mdpnp.org – membership signup for news
11/6/14
63
