Open Source Interoperability

Transcription

1 Open Source Interoperability Problems, Prototypes, and Potential Jeffrey Peterson Clinical Engineer MD PnP Interoperability MGH

2 2 Agenda 1 Problems 2 Prototypes 3 Potential

3 Problems

4 4 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

5 5

6 6

7 7

8 8

9 9

10 Adverse Event Affects 10 PCA Safety 0.19% % Respiratory depression associated with PCA use (Hagle, 2004; Cashman, 2004) 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)

11 The Cost of Error 11 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

12 Single Device Alarm Fatigue 12 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

13 Multiple Device 13 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

14 Impact Alarm Fatigue 14 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) Not Actionable Possibly Not Actionable Actionable

15 15 Integration Hazards Near miss event in OR how do we review? Minimum HR? No BP data? Reverse P waves?

16 Black Box Data Archive Integration Hazards 16 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 unanticipated deterioration was appropriate Time sync data importance to data collection

17 Time Synchronization Integration Hazards 17 Device Type Count StdDev Offset Average Offset Maximum Offset Medical Devices (Excl. Workstations & Wall Clocks) :32:34 0:33:26 16:42:10 All devices :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 Draft unpublished data

18 ECRI s Top 10 Health Technology Hazards Breadth of Problems Alarm hazards 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 1. Alarm hazards 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

19 19 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

20 20 Functional Data Sharing What if the PCA pump knew the vitals of the patient? 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?

21 But we have interoperability already, right? 21 Standards-Based Heath Level 7 HL7 FHIR ISO/IEEE Continua PHD IHE PCD-01 GE Unity ID Proprietary Philips Intellibridge/Vuelink Dräger Medibus Dongles: NantHealth, Capsule

22 22 Health 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)

23 23 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

24 24 ISO/IEEE 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?

25 25 Continua PHD Intended use is for communication between person 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

26 26 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

27 27 Proprietary Interoperability In general: methodologies for getting data into a patient 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

28 28 So what is missing? We have standards for integration, not necessarily interoperability We do not have the tools needed to develop solutions

29 29 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

30 Prototype

31 31 MD Medical Device Plug and Play Interoperability Lab Mass General Hospital Department of Anesthesia

32 32 MD PnP Team Dr. Julian Goldman Director, PI Jeff Plourde Lead Developer Jeff Peterson Clinical Engineer Rick Schrenker Senior Biomedical Engineer Diego Alonso Application Developer Dylan Bagshaw Co-op Intern Dave Arney Lead Engineer Andrea Lenco Research and Grants Diana Lu Program Manager Katharine Koury Clinical Research Coordinator Ken Auerbach Database Engineer Harshal Sawant Biomedical Engineer

33 33 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

34 34 MD PnP Collaborations

35 35 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.

36 OpenICE Project MD PnP Objective 36 Requirements and Technical Specifications Prototype Reference Implementation Standards Based Regulatory Pathway Integrated Clinical Environment

37 Integrated Clinical Environment ASTM-F ICE 37 Multi-manager (apps) Data Logger Functional architecture No technical specification (yet) Device adapter Replaced by native speakers

38 OpenICE Prototype in the Lab ASTM-F ICE 38 Middleware (DDS)

39 39 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 Web Browser Word Processor Memory

40 40 What is a distributed system? A collection of networked computers coordinating their 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 Messages Messages Medical Device Supervisor Application Memory Memory Memory

41 What is Data Distribution Service? 41 An abstraction layer (API) that simplifies distributed system development by providing all computers with a reproduction of shared memory Medical Device Supervisor Application DDS DDS DDS Messages Memory Messages Memory Memory Memory

42 OpenICE Prototype Web openice.info 42 Device Device ICE Supervisor ICE Device Adapter DDS Participant DDS Websocket Proprietary ICE Device Adapter OpenICE Data Model Web Server (socket.io) Data Logger (MongoDB)

43 43 OpenICE Prototype Ivy Vital-Guard 450C Dräger Evita XL OpenICE Supervisor Web Browser Beaglebone Black Server DDS Websocket Proprietary Network

44 Current Deployment Equipment 44 OpenICE Prototype Single subnet Ethernet Zero configuration required WiFi n 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

45 Data Model API OpenICE Prototype 45

46 Device Functionality Many Problems to Solve 46 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.)

47 Regulatory 47 Many Problems to Solve FDA WG Component based regulatory environment 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)

48 Adoption Many Problems to Solve 48 Preliminary research ICE implementations at MGH Small companies DocBox, Moberg MD FIRE Signed by VA, Kaiser, Hopkins, Partners NIST Demonstrated ICE-based data logger

49 Potential

50 50 PCA Safety Demo Open sourced Download from mdpnp.sourceforge.net Closed loop control of PCA pump Can use devices or simulators

51 51

52 52

53 53

54 54

55 55 Web Demo

56 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) Analysis of adverse events involving patients (clinical)

57 57 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

58 MD FIRE What can I do today? 58 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

59 Someone else s problem What can I do today? 59 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

60 60 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)

61 61 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)

62 62 Future of Clinical Engineering Clinicians/nurses who innovate can improve outcomes, 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

63 63 Thank You Learn more: OpenICE.info mdpnp.org membership signup for news