Medical Device Interoperability: the Medical Device Plug and Play Program

Transcription

1 C I M I T Medical Development Group Medical Software SIG 12 October 2011 Waltham, MA Medical Device Interoperability: the Medical Device Plug and Play Program David Arney Systems Engineer, CIMIT/MGH Program on Medical Device Plug-and-Play Interoperability (MD PnP)

2 Outline MD PnP Team Who we are / What we're doing Quantum& SHARP Specific Challenges Time Data Collection MD PnP Lab Use cases Demo and reference implementation Open source medical devices

3 Medical Device Plug and Play Massachusetts General Hospital and the CIMIT, with Army/TATRC, initiated the MD PnP program in 2004 to lead the adoption of open standards and technologies for medical device interoperability to improve patient safety. Support/collaboration: DoD, NSF, NIST, FDA, AHRQ, NIH, VAH MD PnP Community diverse, interdisciplinary, multi-institutional Lab located in Cambridge, Mass Goals: 1. Lead the adoption of open standards and related technology to support medical device interoperability and app deployment 2. Define a regulatory pathway in partnership with the FDA and other regulators 3. Elicit clinical requirements for the proposed interoperable solutions 4. Use our vendor-neutral laboratory to: evaluate interoperability standards and solutions serve as a community resource 5. Investigate safety of proposed engineering solutions

4 ORHigh-acuity clinical care environments are complex How do we prevent errors and Injuries? Too easy to make mistakes Hard to leverage technology to prevent errors and improve efficiency Clinical practice moves faster than documentation

5 Devices, processes, non-integrated system -> errors

6 MD PnP Collaborators WHO WE ARE A geographically-dispersed diverse group of stakeholders who want to improve patient safety and healthcare efficiency through innovations enabled by medical device interoperability:

7 What could we accomplish in healthcare with open, interoperable platforms? Innovation Rich contextual data (for clinical decision support) Means for rapid prototyping of new sensors and algorithms Facilitate validation for regulatory clearance Swap devices as needed to optimize selection And what we have seen in other domains Crowd-sourcing of Apps : If device platform is standardized, apps can be developed by global expert community

8 What is the value of interoperability? Interoperability is means to an end Lowers the barrier to leveraging a heterogeneousecosystem of devices to integrate the clinical environment & innovate Computer + peripherals (e.g. network printers) have latent features INTENDED by manufacturer to be available to ecosystem Democratizing apps smartphone as example: identify products via barcode with camera, send to Amazon via Wi-Fi or Cellular radio, display in phone browser via HTTP

9

10 MD PnP NIH Quantum Grant Development of a Prototype Healthcare Intranet for Improved Health Outcomes Translation: The creation of an eco-system for interoperability of medical device and CISs in high-acuity environments to support innovation in patient safety and healthcare quality Award: 5 Years: $10M Collaborating Organizations: CIMIT/Massachusetts General Hospital (Julian Goldman P.I.) Anakena Solutions, California (Michael Robkin) DocBox Inc, Waltham, MA (Tracy Rausch) Penn (Insup Lee) Kansas State University (J. Hatcliff) Moberg Research, Ambler, PA (Dick Moberg) University of Illinois at Urbana-Champaign (Lui Sha) Tim Gee - Medical Device integration consultant FDA CDRH/OSEL/DESE VA OHI/Office of JIV An HHS ONC Health IT SHARP affiliated program

11

12 HealthCare Intranet To enable interoperable, reliable, private, secure, affordable, integration of medical devices and clinical information systems/ehrs to deliver innovative medical device apps to improve the safety, quality, efficacy, and efficiency of healthcare delivery.

13 Summary of Quantum Scenarios 1. PCA Safety Interlock, example of componentlevel medical device interoperability 2. ICU preparedness, example of in-hospital patient transfer and rich clinical context 3. Tele-health (TH) devices in hospital, example of transferring care from home to hospital and use of TH devices for high-acuity care 4. FDA regulatory staged implementation of framework for levels of interoperability and associated levels of hazards and their mitigation

14 MD PnP Challenges Will address two specific, motivating challenges: Time and Clock Errors Data Logging There are many others Standards development and Gap Analysis Regulatory pathway Adoption pathway (aka business case) Legacy systems

15 Time & Clock Errors Much data is entered manually Retrospective documentation is a problem Reported times in the records may come from Clock on the wall A Device Clinician s wristwatch Device adapter Device gateway EMR Thus, even something as simple as the start time of surgery or the time an infusion was started may be different in the nursing record versus the device clock time versus the anesthesia record.

16 MetaVision EMR screen EMR time-stamp error ACT Machine 10:54 ACT appeared to have been checked 22 minutes after heparin administration (was actually 30 min). Could -> overdose. Cause ACT device time incorrect (note - device does not use NTP) 8 minutes 11:02 Data protocol converter ACT Machine

17 Clock Times Preliminary data (MGH, July 2011) 337 devices from 40 ORs and nearby storage/staging areas Networked physiologic monitors: 3-10 min errors (max one hour) Infusion pumps: 1-3 Hour errors (max 3.5 hours) MetaVision EMR: (hosted on PCs) some had 2-3 min errors Wall clocks: 5-10 min errors Ultrasound machines: 2-12 min error (max 3 hours) Propaq transport monitors: 7-30 min typical (max 90) SEDLine: 2-50 min (max 5 months) Reference Date=07/11/11 ReferenceTime= 08:07:24

18 Data Logger The purpose of the data logger is to record low-level device datain an open, standardized, and time-synchronized manner. The log includes: commands Button presses location device connections and disconnections physiologic and technical alarms physiologic data from patients information about the status of devices Data Log supports Analysis and Playback for two complementary purposes: Analysis of device interactions (debugging) Analysis of adverse events involving patients (clinical)

19 Adverse Event Definition and Example AE Definitions usually focus on causality (root cause analysis) of events that directly harm patients. We re also interested in device device interactions that may lead to patient harm as well as near misses. Current Device Interface Problems that lead to unintended interactions: Proprietary Interfaces Mismatched Terminology Lack of structured data Odd connectors & pinouts Adapters Galore Interfaces don t match specs

20 Ventilator Example NOTE: Not the current production firmware version!

21 Device Log Example AlarisMedley Pump Soft Buttons Playback requires reconstructing device state Playback FSM Pump UI

22 Data Logger in ICE Architecture Caregiver Clinical Application Script (CAS) implements a workflow. External Networks ethernet UI Clinical Application Script Interpreter CAS 1 CAS 2 Network Controller CAN Supervisor Data Logger wifi Adapter Adapter Adapter Device 1 Device 2 Device 3 CAS includes: Executable Program Device Requirements Safety Properties Supervisor is the physical box with the caregiver UI. CAS Interpreter runs on the Supervisor. Supervisor may be a separate box or be hosted on a device like a ventilator or patient monitor. Devices transmit a Device Model that describes their capabilities when they connect to the network. Patient

23 Patient Safety Implications Medical device design process starts with intended use and hazard analysis Hazard analysis is based on designer s imagination and AE reports Adverse Events are underreported, near misses are barely reported Better logging and analysis of AEscan help drive safer medical devices

24 MD PnP Lab Open House 9/7/11 MD PnP Lab, CIMIT, 65 Landsdowne St., Cambridge, MA

25 Interoperability Prototyping Platform MD MP3

26 Hardware Platform for ICE Device Interface Custom FPGA Adapter BeagleBoard Custom made $1200 each Custom codebase Hard Real-time networking Ethernet and Serial interfaces No NTP support Limited processor power Limited Storage Off the shelf $150 each Runs Linux, Windows, or RTOS General-purpose networking Supports wireless (WiFi, BT, etc.) NTP Large storage (up to 64GB)

27 Mapping from ASTM ICE Standard to MD MP3 Caregiver Supervisor External Network Network Controller Data Logger Adapter PulseOx Adapter Pump Adapter PulseOx Patient

28 Mapping from ICE to MD MP3 Caregiver Supervisor External Network Network Controller Data Logger Adapter PulseOx Adapter Pump Adapter PulseOx Patient

29 Reference Implementation and Open Source Medical Software Our code will be released as open source What can we do to make it easy for you to use? Licensing: GPL, LGPL, Mozilla, etc. Reference Implementation & Library Test suites & harness (to a standard or coverage criteria?) Coding to a standard? (ANSI C, MISRA C) Documentation Support Community Bug Tracking, etc.

30 Integration of the clinical environment is required to: Acquire healthcare data comprehensively Support distributed healthcare workers in managing high-acuity patients Add error-resistance to patient care Enable compliance with data security, integrity, and privacy requirements Manage the connected devices Enable Appsfor high-acuity healthcare These needs are present across continuum of high-acuity healthcare: hospital, home, transport, etc.

31 MD PnP Program website

32 Scenario #4 -Levels of Interoperability 1. Virtual Display: Pulse Oximeter, ETCO 2 (end-tidal CO 2 ),and BIS (depth of anesthesia monitor) data are remotely displayed to monitor a patient during colonoscopy. Monitoring devices are exchanged to demonstrate interoperability. 2. Derived Alarms: SpO 2 from pulse oximeter, and ETCO 2 and BIS signals are combined to create smart alarms (to detect medication-induced respiratory depression during procedure) 3. Virtual front panel: manually control multi-parameter monitor and IV infusion pump through single integrated control panel to assist with patient management from outside of procedure room 4. Autonomous control: use SpO 2, ETCO 2, BIS data for: Safety interlock e.g. Stop IV propofolpump if respor BP low, or Physiologic Closed Loop Control -Titrate infusion rate of IV propofolpump to target BIS value And, create smart alarm and activate innovative alarm signal

33 Capabilities to consider 1. Collect data consider accuracy, bandwidth, and completeness requirements 2. Decision support consider quality, timeliness, and all of above 3. Tight integration/control examples: -trigger NIBP cycle when PR changes 20% - Stop opioid infusion if respiratory deterioration 4. Safety/Performance/Security considerations system properties that depend on needs NOT bottom up based on communication standards (Wi-Fi, HL7, etc.) need system architecture