Medical Device Interoperability and Relevant Standards Efforts IEEE

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

Overview – Medical Device Requirements – What is Interoperability? – MD Interoperability Players • ISO/IEEE 11073 • 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 Data Processing System / PDMS Patient Monitor Syringe Pumps and Infusors Respirator Additional Pump Additional Monitor – but changing periodically, and evolving over time

Point-of-care Variable configuration, e. g. intensive care Data Processing System / PDMS Patient Monitor Many Syringe Pumps and Infusors Respirator - 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, i. Sirona, Cerner, etc. ) providing device integration middleware and services. – Patient monitoring vendors have created interoperable systems incorporating many 3 rd 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: – – – HL 7 IEEE 11073 -10101, 10 xxx, etc. IEEE 11073 -20601, 40 xxx, etc. ASTM F 2761 (ICE) DICOM ISO TC 215, CEN TC 251, IEC, etc. • So, what is the problem? – Standards are just a starting point.

MD Interoperability Landscape

Understanding Interoperability

HL 7’s Model of Interoperability

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

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

Level 4 Pragmatic Level 3 Semantic Level 2 Syntactic Level 1 Technical Level 0 None Integratable Interfaceable Increasing Capability for Interoperation Dynamic A s s o c i a ti o n A u th e n ti c a ti o n Authorization Di sco very S a fe ty S e c u r i ty Interoperable Level 5 C e r ti fi c a ti o n Interoperability Eco-System

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 a number of organizations that are working towards this in the medical device space.

ISO/IEEE 11073 Point of Care Medical Device Communication

IEEE 11073 - Charter Point-of-care Medical Device communication: v v 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 v v 11073 is a comprehensive system of point-of -care medical device communication standards 11073 device types range from real-timeoperating medical equipment to point-ofcare test 11073 supports wired, wireless IR and wireless RF network technologies 11073 provides plug-and-play, internetworking and application gateway capabilities

11073 - Architecture Requirements: v v v 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 11073. 1 xxxx Data & Information Definitions 11073. 2 xxxx Application Profiles 11073. 3 xxxx Transport & Physical Layers 11073. 5 xxxx Internetworking Support 11073. 6 xxxx Application Gateways 11073. 9 xxxx Related – some shared concepts

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

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

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

Domain Information Model

11073 -2 xxxx content Application profile standards. . . v v v 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-andplay interoperability!)

11073 -2 xxxx content Application profile standards. . . v v v 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

11073 -3 xxxx content Lower Layer Profiles: Point-to-Point transport standards… v v Ir. DA-Based Cable Connected (11073. 30200) Ir. DA-Based Infrared Wireless (11073. 30300) At various time also considered… v v RF Wireless – high emphasis on Qo. S! IP-Based (Ethernet)

TR: Guidelines … RF wireless Use case topological overview

TR: Guidelines … RF wireless Possible difficulties to be overcome… v v v 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 ECG Device POCT Device MDC Devices Ventilator IV Pump 1073 Cabled 1. Acute Care POCT Device POCT 1 Monitor IEEE 1073 & Ir. DA AP DMI EDI D POC Data Mgr. 5. POC Dev w/ EDI HIS IR o POCt Device ECG Cart Other Dev. Pocket PC POCT 1 IR 2. General Clinic CIS o Ir. DA AP Palm PDA 3. Remote Device using Modem 4. POC Dev w/ DMI POCt Device modem Other Dev. modem POCT Device modem Other Dev. modem Analog Phone Line modem Terminal Server

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 Base Standards from SDOs Profile Development IETF IHTSDO CPs e. Health Projects

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

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 HL 7 and IEEE 11073 Nomenclature and DIM

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

IHE PCD Profiles CPOE/ Pharmacy System Physiologic Monitoring System Ventilation/ Anesthesia System ACM, DEC, WCM Barcode Medication Administration System PIV Infusion Pump ACM, DEC Home Based System Current PCD Future Non- PCD ACM, DEC, WCM, ADQ, PCIM EMR/EHR Clinical Decision Support System ACM, DEC, WCM, ADQ IDCO CIS ACM, DEC, WCM, ADQ, PCIM Other Devices ACM, MEM Implantable Device Equipment Management System 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

Connectathon

PCD – HIMSSPCD 2011 @ HIMSS 2010

Continua Health Alliance

“…to establish an ecosystem 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

Based on Connectivity Standards Thermometer Pulse Oximeter Pulse / Blood Pressure Weight Scale Glucose Meter § 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 PC Personal Health System Cell Phone § 11073 -20601 = Base Framework Protocol Cardiovascular and Strength Fitness Monitor Set Top Box Independent Living Activity Medication Monitor Personal Health Device Class Specification Medical Device Profile Specification Aggregator

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

Other MD Interoperability “Players”

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

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 HL 7 • HL 7 continues to support changes to existing standards which are required to support evolving needs.

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

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?

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