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

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

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…

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

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

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” …

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.

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…

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

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

Current State of MD Interoperability?

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

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

MD Interoperability Landscape

Understanding Interoperability

HL7’s Model of Interoperability

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

Turnitsa’s Model - Annotated None Technical Syntactic Semantic Pragmatic Dynamic Stand-alone RS232, Ethernet, , Zigbee, BT, USB, TCP/IP… HL7, IEEE 11073, Continua… Snomed, IHE-PCD RTM, IEEE , 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

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

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.

ISO/IEEE Point of Care Medical Device Communication

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

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

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

Series structure Data & Information Definitions xxxx Application Profiles xxxx Transport & Physical Layers xxxx Internetworking Support xxxx Related – some shared concepts xxxx Application Gateways xxxx

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

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

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

Domain Information Model

xxxx 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!)

xxxx 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

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

TR: Guidelines … RF wireless Use case topological overview

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

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

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

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

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

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

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 Nomenclature and DIM

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

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

Connectathon

HIMSS 2010 PCD – HIMSS 2011

Continua Health Alliance

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

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

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  = Pulse Oximeter  = Pulse / Heart Rate  = Blood Pressure  = Thermometer  = Weighing Scale  = Glucose  = Cardiovascular Fitness Monitor  = Strength Fitness Equipment  = Independent Living Activity  = Medication Monitor  = Base Framework Protocol Thermometer

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

Other MD Interoperability “Players”

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

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

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

Why am I here? Do existing Standards meet the needs of evolving 802 wireless standards? –New Use Cases to consider? Should IEEE 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?

Contact Thank you for your attention. Ken Fuchs Mindray North America Mahwah, NJ