Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Harnessing Data Distribution Service (DDS) in Next Generation Healthcare Systems


Published on

The Medical Device "Plug-and-Play" (MD PnP) initiative a key healthcare interoperability program that is using the Object Managment Group's Data Distribution Service (DDS) standard in the reference implementation for their Integrated Clinical Environment (ICE).

Medical devices are essential for the practice of modern medicine. Some medical devices utilize open networking standards for communication to provide data for electronic health records. However unlike the interoperable "plug-and-play" environment of modern computers and consumer electronics, most acute care medical devices are not designed to interoperate. Medical devices typically utilize proprietary protocols for system integration. These approaches do not provide the comprehensive integration capabilities necessary for safe, cross-manufacturer medical device integration for data communication and medical device control for the card of a single patient.

The Medical Device “Plug-and Play” (MD PnP) Interoperability Program promotes innovation in patient safety and clinical care by leading the adoption of patient-centric integration of medical devices and IT systems in clinical environments.

MD PnP’s OpenICE is an initiative to create a community implementation of the ASTM F-2761 standard for the Integrated Clinical Environment (ICE). It is defining the conditions under which interoperability can enable device integration to create new medical device systems with greater safety and performance capabilities than any individual device. The initiative encompasses not only software implementation of those functionalities described in the standard but also an architecture for a wider clinical ecosystem that incorporates seamless connectivity to increase patient safety. OpenICE seeks to provide a framework for the inclusion of healthcare devices and systems into the broader Internet of Things and Industrial Internet efforts.

This presentation will detail how DDS is being used within OpenICE to enable the integration of devices and the sharing of real-time patient data between devices and other clinical information systems.

Published in: Software
  • Be the first to comment

Harnessing Data Distribution Service (DDS) in Next Generation Healthcare Systems

  1. 1. Harnessing DDS in Next Generation Healthcare Systems Webcast November 19, 2014
  2. 2. Webcast Presenters Julian M. Goldman - Director, MD PnP Program / Director, CIMIT Interoperability Program / Medical Director, Partners HealthCare Biomedical Engineering Julian M. Goldman, MD is an anesthesiologist at the Massachusetts General Hospital, Medical Director of Biomedical Engineering for Partners HealthCare, and the Director/PI of the Program on Medical Device Interoperability - a multi-institutional federally funded program founded in 2004 to advance medical device interoperability to improve patient safety and HIT innovation. Dr. Goldman completed his residency and medical informatics fellowship at the University of Colorado, and served as a Visiting Scholar in the FDA Medical Device Fellowship Program as well as an executive of a pulse oximetry company. His awards include the AAMI Foundation/Institute for Technology in Health Care Clinical Application Award and the International Council on Systems Engineering Pioneer Award. E-card:
  3. 3. David Arney - Lead Engineer, MD PnP Program David Arney is the Lead Engineer for the Medical Device Plug and Play Program. He has been working on applying formal methods to medical device software since 2001 and was a scholar in residence at the FDA's Center for Devices and Radiological Health in the Office of Science and Engineering Laboratories. He was involved in writing the ASTM 2761-09 ICE standard for interoperable medical devices. He started at the MD PnP program in September of 2010, and is currently writing his dissertation for a PhD in computer science under Professor Insup Lee at the University of Pennsylvania. Jeff Plourde - Applications Developer, MD PnP Program Jeff Plourde is an Application Developer for the MD PnP program. Previously he worked in the hedge fund industry. As a portfolio manager Jeff built and analyzed statistical trading models using high-throughput backtesting techniques and deployed those models with his own high frequency trading algorithms. He holds a BS in Computer Science and a BS in Biology from Rensselaer Polytechnic Institute. Jeff began working with the MD PnP program in May 2012. Jeffrey Peterson - Clinical Engineer, MD PnP Program Jeffrey Peterson is currently a Clinical Engineer for the MD PnP program. Previously, he worked as a Clinical Engineer at UMass Memorial Medical Center in Worcester, MA. His projects were focused on healthcare technology management, clinical alarm management and distribution and medical device integration. He holds an MS Biomedical and Clinical Engineering and a BS in Biomedical Engineering, both from the University of Connecticut. Jeff completed his Master’s thesis on clinical alarm management during his time at UMass. Webcast Presenters
  4. 4. Angelo Corsaro – CTO, PrismTech Angelo Corsaro, Ph.D. is Chief Technology Officer (CTO) at PrismTech where he directs the technology strategy, planning, evolution, and evangelism. Angelo leads the strategic standardization at the Object Management Group (OMG), where he co-chairs the Data Distribution Service (DDS) Special Interest Group and serves on the Architecture Board. Angelo is a widely known and cited expert in the field of real-time and distributed systems, middleware, and software patterns, has authored several international standards and enjoys over 10+ years of experience in technology management and design of high performance mission- and business-critical distributed systems. Angelo received a Ph.D. and a M.S. in Computer Science from the Washington University in St. Louis, and a Laurea Magna cum Laude in Computer Engineering from the University of Catania, Italy. Webcast Presenters
  5. 5. Angelo  Corsaro,  PhD   Chief  Technology  Officer DDS Overview
  6. 6. CopyrightPrismTech,2014 DDS is an Object Management Group (OMG) Standard for efficient, secure and interoperable, platform- and programming- language independent data sharing DDS standardises: - Programming API - Interoperable wire-protocol - Extensible Type System - Data Modeling - Security Framework - Remote Procedure Call The DDS Standard
  7. 7. CopyrightPrismTech,2014 DDS provides a Global Data Space abstraction that allows applications to autonomously, anonymously, securely and efficiently share data DDS’ Global Data Space is fully distributed (decentralised), highly efficient and scalable Data Distribution Service (DDS) DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS
  8. 8. CopyrightPrismTech,2014 DataWriters and DataReaders are automatically and dynamically matched by the DDS Discovery A rich set of QoS allows to control existential, temporal, and spatial properties of data Data Distribution Service (DDS) DDS Global Data Space ... Data Writer Data Writer Data Writer Data Reader Data Reader Data Reader Data Reader Data Writer TopicA QoS TopicB QoS TopicC QoS TopicD QoS
  9. 9. CopyrightPrismTech,2014 Elegant and High Level Data Sharing Abstraction Polyglot and platform independent • Java, Scala, C, C++, C#, JavaScript, CoffeeScript etc. • Android, Windows, Linux, VxWorks, etc. Peer-to-Peer by nature, Brokered when useful Key Highlights
  10. 10. CopyrightPrismTech,2014 Content and Temporal Filtering (both sender and receiver filtering supported) Queries 20+ QoS to control existential, temporal, and spatial properties of data Key Highlights
  11. 11. DDS in Action
  12. 12. CopyrightPrismTech,2014 Sample Oximeter Data Model module  dds  {          module  demo  {        /**              The  Oximetry  Parameters  are  split  into  two  topics                        to  take  into  account  the  different  update  rates.                            Since  the  pleth  parameter  is  updated  with  a  ~10ms                        period,  it  is  sent  on  its  own  topic  to  avoid  sending                        over  and  over  data  that  changes  every  second.        **/        struct  Oximetry  {            string  deviceId;            long  deviceType;            long  spO2;            long  bpm;            long  rr;        };                #pragma  keylist  Oximetry  deviceId        /**          *  High  frequency  pleth  data  used  for  graphing                    *  and  analysis.          */        struct  Pleth  {            string  deviceId;            float  pleth;        };                #pragma  keylist  Pleth  deviceId              /**                *  Topic  used  to  advertise  the  presence  of  a  device.                */            struct  DeviceInfo  {                  string  deviceId;                  string  description;                };                #pragma  keylist  DeviceInfo  deviceId                };   };  
  13. 13. CopyrightPrismTech,2014 Producing Oximetry  DomainParticipant  dp(0);      Topic<Oximetry>  topic(dp,  “TOximetry”);      Publisher  pub(dp);      DataWriter<Oximetry>  dw(pub,  topic);      while  (true)  {          Oximetry  o  =  getOximetry();          dw  <<  o;  //  -­‐or-­‐  dw.write(o)          sleep(1);      }         C++ CoffeScript rt  =  new  dds.Runtime()   rt.onconnect  =  ()  -­‐>      topic  =  new  Topic(0,  “TOximetry”,                                          “dds::demo::Oximetry”)    rt.registerTopic(topic)    dw  =  new  DataWriter(rt,  topic)    writeOximetry  =  ()  -­‐>     o  =  getOximetry()   dw.write(o)    setInterval(writeOximetry,  1000)  
  14. 14. CopyrightPrismTech,2014 C++ CoffeScript Consuming Oximetry    DomainParticipant  dp(0);      Topic<Oximetry>  topic(dp,  “TOximetry”);      Subscriber  sub(dp);      DataReader<Oximetry>  dr(pub,  topic);      LambdaDataReaderListener<Oximetry>  listener;      listener.data_available  =            [](DataReader<Oximetry>&  dr)  {                auto  samples  =;              showOximetry(samples);          };          dr.listener(&listener,                                StatusMask::data_available());             rt  =  new  dds.Runtime()   rt.onconnect  =  ()  -­‐>      topic  =  new  Topic(0,  “TOximetry”,                                          “dds::demo::Oximetry”)    rt.registerTopic(topic)    dr  =  new  DataReader(rt,  topic)    dr.addListener((o)  -­‐>  showOximetry(o))  
  15. 15. Integrating the Clinical Environment: Implications for healthcare quality, safety, and innovation Julian M. Goldman, MD Director, Program on Interoperability, Mass General Hospital Medical Director, Partners HealthCare Biomedical Engineering Anesthesiologist, MGH/Harvard Medical School Contact information: Prismtech Webinar Nov 19, 2014
  16. 16. • 1999 IOM published “To Err Is Human” up to 98,000 people a year die because of mistakes in hospitals. • 2010 the Office of Inspector General for Health and Human Services said that bad hospital care contributed to the deaths of 180,000 patients in Medicare alone in a given year. • 2013 Journal of Patient Safety: between 210,000 and 440,000 patients each year who go to the hospital for care suffer some type of preventable harm that contributes to their death. • “That would make medical errors the third-leading cause of death in America, behind heart disease, which is the first, and cancer, which is second. “ 1999 2013
  17. 17. Devices, processes, non-integrated system  errors Home ventilator
  18. 18. OR scene – patient’s life saved: Clinicians need timely, accurate data to reduce error, treatment delays, injuries and deaths. Is that how we practice today? Where are innovative solutions?
  19. 19. Proposal: Can an Integrated Clinical Environment (ICE) add “error resistance” to healthcare delivery?
  20. 20. Apps for smart alarms; med safety; equipment management What if… Asking a lot of the platform “Medical IoT” (Internet of Things)
  21. 21. Pulse Oximeters measure oxygen saturation – displayed as SpO2 % Julian M. Goldman, MD / MGH Pulse Oximeter oxygen saturation is 84% on instrument display and in EHR EMR Medical Devices generate “First Mile” of data (from patient) Blood Pressure Bluetooth pulse oximeter
  22. 22. Example - Infusion technology: 1. Decision support? 2. Prevent contra-indicated infusion? 3. “Artificial pancreas” Capabilities? (closed loop) 4. Consolidate all data for adverse event analysis? 5. Check device status, software version? Recall? 6. Adjust settings remotely? Medical Devices are also the “Last Mile” (data back to devices) These infusion pumps are for use on ONE patient
  23. 23. Patient-Controlled Analgesia (PCA) system safety concerns PCA Pump (With patient button) Nurse callPatient • Patients can call to request more pain medication, but, cannot call for help when over-medicated. • Over-medication can cause respiratory and cardiac arrest • Comprehensive monitoring is not typically used due to high false and nuisance alarm rate • “Safe PCA System” prototype uses information from medical monitors, EMR, and IV pump to prevent overdose
  24. 24. Patient Controlled Analgesia (PCA) PCA Pump (With patient button) Nurse callPatient 1. Up to 6,875 serious preventable PCA-related adverse events are estimated to occur annually. NO official figures. NO reporting 2. PCA can be fixed! Digital platform of interoperable devices + apps -> safer medication administration • Why is data fusion and decision support so challenging to implement? Typical Patient Controlled Analgesia System
  25. 25. Oxygen Level Low WHY???? Pulse Oximeter Data example JM Goldman MD / MGH
  26. 26. Not reall low oxygen “Bad” data BP cuff - Pulse Oximeter Interaction JM Goldman MD / MGH Baseline Cuff inflates – loss of finger signal Blood returns to finger
  27. 27. Monitor Displays Low Oxygen Level (SpO2) Alarm Event “84%” at 2:07 No evidence of 84% SpO2 in EHR (Blue ticks representing SpO2 values Don’t change) We must have a system perspective Sampling error for transient events Julian M. Goldman, MD / MGH
  28. 28. Sources of variation in EHR documentation due to Data Sampling Patient’s “actual” SpO2 minimum = 70% 60 Seconds Example of possible EHR sample points for 1-minute recording Based on this example, EHR May record SpO2 as: 98% 92% 80% 75% Etc.
  29. 29. Cardio-Pulmonary Bypass (Heart-lung machine) Normal routine: Switch from anesthesia machine ventilator to cardiopulmonary bypass machine, and back to ventilator (after bypass) or
  30. 30. Failure to Ventilate after Bypass • Adverse Anesthetic Outcomes Arising from Gas Delivery Equipment: A Closed Claims Analysis. • Anesthesiology. 87(4):741-748, October 1997 • “… In the second case, the anesthesiologist forgot to resume ventilation after separation from cardiopulmonary bypass. The delayed detection of apnea was attributed to the fact that the audible alarms for the pulse oximeter and capnograph had been disabled during bypass and had not been reactivated. Both patients sustained permanent brain damage.” Almost every surgical team has experienced this error! 17 years
  31. 31. Cardio-Pulmonary Bypass Smart system would provide warning if ventilator off and bypass pump flow = 0. No App for that and
  32. 32. Ebola
  33. 33. In Hospital XWe need to move personnel away from patient area
  34. 34. Remote data display, remote device control, apps, and complete data collection to monitor individual and population health 1 provider in room
  35. 35. Medical Device “Plug-and-Play” Interoperability Program (MD PnP) Founded in 2004, the MD PnP research program is a multi-institutional community with Lab based at Massachusetts General Hospital (MGH), with grant support from NIH/NIBIB, NSF, DoD/TATRC, and NIST Mission: lead the adoption of open standards and technologies for medical device interoperability to improve patient safety
  36. 36. Goals of the MD PnP Program 1. Lead the adoption of open standards and related technology to support medical device interoperability and system solutions 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
  37. 37. MD PnP Lab at MGH/PHS • Vender-neutral sandbox for experimenting with device interoperability solutions (standards technologies, products) • Contains devices – production and research • Supports diverse collaborators
  38. 38. Safety Culture Based on Reason, Managing the Risks of Organisational Accidents, 1977
  39. 39. What success will look like … • DATA: Widespread availability of complete clinical and medical device performance data for … • Real Time Safety: Close the loop on clinical care, workflow, and implement “error resistant” systems • Unleash innovation in patient care, patient safety, and healthcare efficiency to save hundreds of thousands of lives and billions of $. • A “systems engineering” platform is widely available for research, development, and deployment.
  40. 40. Dr. Julian M. Goldman, M.D. – Principle Investigator Jeffrey Plourde – Lead Developer Jeffrey Peterson – Clinical Engineer David Arney – Lead Engineer MD PnP Interoperability Program Massachusetts General Hospital Harvard Medical School Harnessing DDS in Next Generation Healthcare Systems 19 Nov 2014 1
  41. 41. Integrated Clinical Environment ASTM-F2761-09 ICE  Multi-manager (apps)  Data Logger  Functional architecture  No technical specification (yet)  Device adapter  Replaced by native speakers 19 Nov 2014 2
  42. 42. OpenICE Prototype in the Lab ASTM-F2761-09 ICE 19 Nov 2014 3 Middleware (DDS)
  43. 43. OpenICE Prototype  Realization of the ICE functional architecture  Fully open source  Initially targeted at clinical research community. 19 Nov 2014 4
  44. 44. OpenICE On The Web  MD PnP Program   SourceForge    19 Nov 2014 5
  45. 45. 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 6 19 Nov 2014
  46. 46. 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 Memory Medical Device Supervisor Application Memory Memory Messages Messages 7 19 Nov 2014
  47. 47. Message Oriented Middleware  Innumerable examples: JMS, MQ Series, TIBCO Rendezvous  Devise messages to ensure consistent information throughout system nodes.  Not a natural analog to non-distributed parallel systems; source of error. Memory Medical Device Supervisor Application Memory Memory Messages Messages 8 19 Nov 2014
  48. 48. 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 9 19 Nov 2014
  49. 49. Quality of Service Policies  Reliability  Configurable to seek acknowledgment of emitted data automatically.  Liveliness  Automatic detection of defunct remote data emitters.  Destination Order  Guarantees ordering of data  Any single policy would require a great deal of implementation upon a Message Oriented Substrate. 10 19 Nov 2014
  50. 50. DDS & MDPnP  OMG Standard  An open, vibrant standard with associated community  Supports multiple languages C, C++, Java, etc.  Vendor Neutral  Declarative Non-Functional Characteristics  Quality of Service Policies  Interoperability  Uses familiar data access paradigms 11 19 Nov 2014
  51. 51. ICE Device Adapter Web Server ( ICE Supervisor Data Logger Device Device ICE Device Adapter DDS Participant Web OpenICE Prototype 12 DDS Websocket Proprietary OpenICE Data Model 19 Nov 2014
  52. 52. DDS Websocket Proprietary Ivy Vital-Guard 450C Dräger Evita XL Beaglebone Black Network Web Browser Server OpenICE Supervisor OpenICE Prototype 13 19 Nov 2014
  53. 53. Current Deployment Equipment OpenICE Prototype  Standard 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 19 Nov 2014 14
  54. 54. Device Functionality Problems  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.) 15 19 Nov 2014
  55. 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)  Analysis of adverse events involving patients (clinical) 19 Nov 2014 16
  56. 56. PCA Safety Demo  Open sourced  Download from  Closed loop control of PCA pump  Can use devices or simulators 17 19 Nov 2014
  57. 57. PCA Safety Demo 18 19 Nov 2014
  58. 58. Thank You Learn more:   – membership signup for news 19 Nov 2014 19
  59. 59. Angelo  Corsaro,  PhD   Chief  Technology  Officer VORTEX Overview and Healthcare Applications
  60. 60. CopyrightPrismTech,2014 VORTEX is a ubiquitous data sharing platform for the Internet of Things providing scalable end-to-end seamless, efficient, secure and timely data sharing for IoT supporting device, edge, gateways and cloud VORTEX platform coverage, performance and scalability make it the only viable choice from consumer to demanding business critical, industrial, real time, IoT applications VORTEX simplifies IT/OT integration, and is the only platform that holistically addresses IT and OT requirements Introducing Vortex Sensors/ Things/ Devices Connectivity/ Transport Edge Management/ Telemetry Application Platform Enterprise Systems Ubiquitous Data Sharing peer-to-peer, device-to-cloud, cloud-to-cloud
  61. 61. CopyrightPrismTech,2014 Specialised device implementations optimally addressing requirements of OT and IT platforms VORTEX can readily deal with data ingestion seamlessly integrating with other protocols, e.g. MQTT, CoAP, etc. VORTEX leverages the DDS standard for interoperability and uniquely extends it with support for Internet Scale systems, mobility and Web 2.0 applications The VORTEX Platform Device Tools Integration Vortex Cloud MaaS
  62. 62. CopyrightPrismTech,2014 VORTEX Architecture IP UDP TCP DTLS TLS WebSocket DDSI Wire Protocol VORTEX Café VORTEX Cloud VORTEX Web VORTEX Gateway VORTEX Lite VORTEX OpenSplice MQTT AMQP XMPP HTTP HBase DMBS TCP/IP, UDP/IP … VORTEX Café DDS API DDS Security
  63. 63. Use Cases
  64. 64. CopyrightPrismTech,2014 E-Health Use Case Hospital A Private Cloud Analytics Big  Data  Store Hospital B
  65. 65. Further information – MD PnP ▶ OpenICE ▶ ▶ For further information please contacct ▶ Andrea Lenco – ▶ )
  66. 66. Further information - PrismTech ▶ For further information please contact us directly ▶ angelo ▶ (on-demand live demo available) ▶ Or via social media