1. Medical Device Interoperability and Relevant Standards Efforts IEEE 802.15.4j Meeting July 18, 2012 Ken Fuchs Mindray North America Secretary IEEE 11073 Co-Chair IHE PCD Domain

2. Overview –Medical Device Requirements –What is Interoperability? –MD Interoperability Players ISO/IEEE 11073 IHE PCD Continua Other Interoperability “Players” –Discussion

3. Point-of-Care: The Need Clinicians are starting to assemble MDs at the patient bedside. These devices need to talk to each other as well as to local data aggregators. Aggregators need to get the data to the EMR/EHR…

4. Point-of-care Fixed configuration, e.g. anesthesia – but changing periodically, and evolving over time Patient Monitor Respirator Syringe Pumps and Infusors Additional Pump Additional Monitor Data Processing System / PDMS

5. Point-of-care Variable configuration, e.g. intensive care Patient Monitor Respirator Many Syringe Pumps and Infusors Data Processing System / PDMS - changing frequently and within minutes

6. Easy to Use and Safe These systems need to operate safely under all conditions yet be easy to assemble. In the future many of these devices will be wireless. –Only covers Layer 1… Usable solutions will require a complete “stack” –For Medical Devices Layer 7 is the “Wild West” …

7. What is Interoperability? IEEE defines Interoperability as: –the ability of two or more systems or components to exchange information and to use the information that has been exchanged AAMI has recently offered a Medical Device focused definition… –the ability of medical devices, clinical systems, or their components to communicate in order to safely fulfill an intended purpose. Includes concepts of safety and intended purpose Not very specific as to the amount of “glue” required to get these systems to talk to each other.

8. Do we have MD Interoperability? While most acute care devices are built around proprietary interfaces… –Most, if not all, EMRs can connect to devices –We have a growing contingent of vendors (Capsule, Nuvon, iSirona, Cerner, etc.) providing device integration middleware and services. –Patient monitoring vendors have created interoperable systems incorporating many 3rd party devices. –Clinicians have developed many demonstrations and applications showing device interoperability. Maybe we already have Interoperability…

9. Do We Have MD Interoperability? Probably not … –Each new device integration is a custom effort requiring months of nursing/engineering skills It can cost between $6,750 and $10,000 per bed to integrate the devices, including ventilators, in a typical ICU (Moorman, 2010) –Clinicians desiring to use a new device must wait for their application vendor to develop a new driver (which may never happen) –The complexity of device interfacing may be hindering research which could lead to improved patient care –Purchasing decisions are driven by whether an interface to specific devices exists

10. Do We Have MD Interoperability? More issues with our current reality… –Safety issues can arise due to the sizable SW effort and on-site customization required to integrate devices –Costs to the Providers for system integration services are very high –Not all required data to accomplish a Use Case may be available –There can be finger pointing when trying to resolve problems –Too much complexity in maintaining each link in the communication chain –As device or system software is updated solutions break

11. Current State of MD Interoperability?

12. Is this the best we can do? When we say systems are Interoperable, does that mean that as long as there is some way of getting “stuff” from one system to another, we are happy? –BASIC Interoperability Or, do we expect that we only need to point these systems at each other and stand back, satisfied that the job is done? –SEAMLESS Interoperability Clearly we should be focused on achieving SEAMLESS Interoperability… –Sometimes referred to as Plug and Play Interoperability

13. Are Standards the Solution? We have many Lower Layer Standards And we have many Upper Layer standards: –HL7 –IEEE 11073-10101, 10xxx, etc. –IEEE 11073-20601, 40xxx, etc. –ASTM F2761 (ICE) –DICOM –ISO TC215, CEN TC251, IEC, etc. So, what is the problem? –Standards are just a starting point.

14. MD Interoperability Landscape

15. Understanding Interoperability

16. HL7’s Model of Interoperability

17. Turnitsa’s Model None Technical Syntactic Semantic Pragmatic Dynamic Stand-alone Common Physical and Transport Layers Common Format Meaning understood Context understood Dynamic Context understood Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Increasing Capability for Interoperation Interfaceable Integratable Interoperable Definition

18. Turnitsa’s Model - Annotated None Technical Syntactic Semantic Pragmatic Dynamic Stand-alone RS232, Ethernet, 802.11, Zigbee, BT, USB, TCP/IP… HL7, IEEE 11073, Continua… Snomed, IHE-PCD RTM, IEEE 11073-10101, LOINC… IHE PCD / Continua Use Case based Profiles… Resource and Load Management Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Increasing Capability for Interoperation Interfaceable Integratable Interoperable Example

19. Interoperability Eco-System None Technical Syntactic Semantic Pragmatic Dynamic Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Increasing Capability for Interoperation AssociationAuthenticationAuthorizationDiscoverySafetySecurity Certification Interfaceable Integratable Interoperable

20. MD Interoperability Eco-System Device Interoperability based on Framework(s) of Open Standards Profiles of Standards Conformance Testing Certification Testing Regulatory Pathways etc. –Incentives that drive all parties to comply with these Framework(s) There are a number of organizations that are working towards this in the medical device space.

21. ISO/IEEE 11073 Point of Care Medical Device Communication

22. IEEE 11073 - Charter Point-of-care Medical Device communication:  Provide real-time plug-and-play interoperability for patient-connected medical devices  Facilitate the efficient exchange of vital signs and medical device data, acquired at the point-of-care, in all health care environments … Leveraging off-the-shelf technologies, scaling across a wide range of system complexities, and supporting commercially viable implementations.

23. Overview  11073 is a comprehensive system of point- of-care medical device communication standards  11073 device types range from real-time- operating medical equipment to point-of- care test  11073 supports wired, wireless IR and wireless RF network technologies  11073 provides plug-and-play, internetworking and application gateway capabilities

24. 11073 - Architecture Requirements:  True interoperability across all 7-layers from the ‘connector’ to the end application  Mechanisms to support the strong quality of service (safety) requirements placed on regulated medical devices  Maintainability as communications technology and applications change

25. Series structure Data & Information Definitions 11073.1xxxx Application Profiles11073.2xxxx Transport & Physical Layers 11073.3xxxx Internetworking Support 11073.5xxxx Related – some shared concepts 11073.9xxxx Application Gateways 11073.6xxxx

26. 11073-1xxxx content Semantics needed to communicate a device’s structure, application data, status and control information. Three main components:  Nomenclature: 11073.10101  Domain Information Model (DIM): 11073.10201  Device Specialisations: 11073.103xx

27. 11073-10101 Nomenclature Nomenclature: A set of numeric codes that identify every item that is communicated between systems.

28. 11073-10201 Information Model Domain Information Model: An object oriented data model that specifies objects, attributes, attribute groups, event reports, and services that may be used to communicate device data and to control / configure the reporting of information...  Medical Devices and Functionalities  Measured Data and Settings  Alert Information  Remote Control  Patient Information  Communication

29. Domain Information Model

30. 11073-2xxxx content Application profile standards...  Provide specific sets of capabilities tailored for a class of communication needs / architectures  Limit the options that are available  Remaining options must be discovered and in some cases negotiated when a connection is made (enabling plug-and- play interoperability!)

31. 11073-2xxxx content Application profile standards...  Define a generic (non-device specific) set of data and services needed to initiate, configure, and maintain communication: Connect / Disconnect, Create / Delete, Get / Set, Event Report, Invoke, etc.  Specify the use of Standard Service Elements: ACSE, ROSE, CMISE, ASN.1, MDER (based on BER+), etc.  Provide optional packages, e.g for remote control

32. 11073-3xxxx content Lower Layer Profiles: Point-to-Point transport standards… Point-to-Point transport standards…  IrDA-Based Cable Connected (11073.30200)  IrDA-Based Infrared Wireless (11073.30300) At various time also considered… At various time also considered…  RF Wireless – high emphasis on QoS!  IP-Based (Ethernet)

33. TR: Guidelines … RF wireless Use case topological overview

34. TR: Guidelines … RF wireless Possible difficulties to be overcome…  High importance of data communicated  ‘Unknown’ communication capacity available  Security implications for different types of medical information remain difficult to determine – and standardise

35. POC Devices co-existence POC Dev w/ DMI 4. Monitor IEEE 1073 & IrDA AP ECG Device POCT Device MDC Devices Ventilator IV Pump POCT Device 1073 Cabled 1. Acute Care POCT1 IR POCt Device ECG Cart Other Dev. Pocket PC Palm PDA POCT1 IR 2. General Clinic IrDA AP POCt Device Other Dev. POCT Device Other Dev. 3. Remote Device using Modem Terminal Server modem Analog Phone Line modem POC Dev w/ EDI 5. DMI POC Data Mgr. HIS CIS EDI D o o

36. 11073’s Evolution A history of collaborative and complementary efforts: Arrows indicate effective transfer of development and/or maintenance responsibility.

37. IHE PCD Domain (Integrating the Healthcare Enterprise - Patient Care Device)

38. From Base Standards to Profile Standards Profile Development Base Standards from SDOs eHealth Projects IHTSDO IETF CPs

39. Contributing & Participating Vendors Regional Deployment IHE Europe IHE North America France USA Canada IHE Asia-Oceania Japan KoreaTaiwan Netherlands Spain Sweden UK Italy Germany Norway China Austria Global Development Radiology Cardiology IT Infrastructure Patient Care Coordination Patient Care Device Laboratory Pathology Eye CareRadiation Oncology Public Health, Quality and Research Pharmacy ACC ACCE ACEP JAHIS JIRA JRS METI-MLHW MEDIS-DC JAMI RSNA SFR SFIL SIRM BIR EuroRec COCIR EAR-ECR DRG ESC Professional Societies / Sponsors ACP ACOGH IMSS IHE Organizational Structure IHE International Board

40. Role of IHE PCD IHE PCD was formed in 2005 to address issues related to integration of Point-of-Care medical devices: –With each other –With enterprise systems IHE PCD wants to “raise the bar” from the current state of integration projects to out of the box, open, interoperable solutions. PCD Profiles tend to use HL7 and IEEE 11073 Nomenclature and DIM

41. Trial Trial IHE Profiles Drafted & Revised 6-13 mos. ImplementationPosted Install Interoperable products in Clinical Settings worldwide IHE Improves, Safety, Quality and Efficiency in Clinical Settings. 14-18 mos. Profile Selection by Committees 1-5 mos. Publish in IHE’s Product Registry Test at IHE Connectathons Published For Public Comment IHE Technical Framework Developed IHE Development Process Demonstrate at a IHE Call for Proposals Opens

42. CPOE/ Pharmacy System Future PCD Current PCD Infusion Pump Barcode Medication Administration System Other Devices Equipment Management System Future Non- PCD Clinical Decision Support System Implantable Device IDCO ACM, DEC, WCM, ADQ, PCIM ACM, MEM ACM: Alarm Communication Management ADQ: Asychronous Device Query DEC: Device Enterprise Communication IDCO: Implantable Device – Cardiac – Observation MEM: Medical Equipment Management PCIM: Point-of-Care Identity Management PIV: Point-of-Care Infusion Verification WCM: Waveform Content Module Home Based System Ventilation/ Anesthesia System EMR/EHR CIS Physiologic Monitoring System DEC ACM, DEC ACM, DEC, WCM PIV ACM, DEC, WCM, ADQ, PCIM ACM, DEC, WCM, ADQ IHE PCD Profiles

43. Connectathon

44. PCD @ HIMSS 2010 PCD – HIMSS 2011

45. Continua Health Alliance

46. “…to establish an eco- system of interoperable personal health systems that empower people & organizations to better manage their health and wellness”

47. Continua Process Includes: –Standards Development –Profiles Development –“Plugfests” –Public Demonstrations –Certification Program

48. PC Personal Health System Cell Phone Set Top Box Aggregator Based on Connectivity Standards Weight Scale Pulse Oximeter Independent Living Activity Cardiovascular and Strength Fitness Monitor Medication Monitor Glucose Meter Pulse / Blood Pressure Medical Device Profile Specification Personal Health Device Class Specification  11073-10404 = Pulse Oximeter  11073-10406 = Pulse / Heart Rate  11073-10407 = Blood Pressure  11073-10408 = Thermometer  11073-10415 = Weighing Scale  11073-10417 = Glucose  11073-10441 = Cardiovascular Fitness Monitor  11073-10442 = Strength Fitness Equipment  11073-10471 = Independent Living Activity  11073-10472 = Medication Monitor  11073-20601 = Base Framework Protocol Thermometer

49. Public Interoperability Demos Weighing Scale Wireless Pulse Oximeter Blood Pressure Monitor Device Interface XHR Interface EHR Heart Failure & COPD EHR PHR Telehealth Service Obesity & Diabetes

50. Other MD Interoperability “Players”

51. MDPnP Medical Device “Plug and Play” Interoperability Program (MDPnP) –Group that developed the ICE Standard which was published as ASTM 2761 –Program has obtained various grants to develop and demonstrate interoperable solutions –MDPnP is also working with the FDA on developing a regulatory pathway for interoperable medical devices

52. IEEE IEEE 11073 WG continues to develop many base semantic and syntactic standards which are used by other organizations. –Key contributions are the Nomenclature and Standards support for Continua HL7 continues to support changes to existing standards which are required to support evolving needs. HL7

53. FDA FDA is involved in “encouraging” medical device interoperability –Instigated the MDICC (Medical Device Interoperability Coordination Council) Engaging all relevant SDOs AAMI established the Healthcare IT Interoperability (HITI) workgroup. AAMI

55. Why am I here? Do existing 11073 Standards meet the needs of evolving 802 wireless standards? –New Use Cases to consider? Should IEEE 11073 coordinate more closely with 802.x WGs? –How do we make sure there is enough bandwidth for devices to accomplish their task? –How do we make sure all devices connected around a critically ill patient safely interoperate? Proper semantics, syntax, etc. –How do we easily and unambiguously associate a device with a specific patient? –How to report physical layer status to clinicians? What do they need to know?

56. Contact Thank you for your attention. Ken Fuchs Mindray North America Mahwah, NJ ken.fuchs@ieee.org k.fuchs@mindray.com