Ken Fuchs, Sr. Principal Architect Mindray North America Co-Chair: IHE-PCD Planning Committee Medical Devices – From Standards to Interoperability ACCE Clinical Engineering Symposium AAMI 2011

Monitoring Imaging Peri-operative MindrayMindray HQ – Shenzhen, China – Largest Chinese medical device manufacturer – Listed on NYSE – $740 M in revenue – 20 years old US HQ – Mahwah, NJ – Former Datascope HQ

The Situation… The nation is moving quickly toward widespread (universal?) adoption of EHR/EMR based medical records. In this environment it is natural for clinicians to demand the automatic acquisition of data from bedside medical devices. Today device interfacing continues to require considerable time, effort and resources… – Quality and reliability is sub-optimal There must be a better way!!

The Situation… When I was (much) younger I believed that developing the appropriate Standards was all that was needed. Develop the Standards and They will come !!! Develop the Standards and They will come !!!

Are Standards Enough?

Some History… So we built the Standards!! – In the US we had the IEEE 1073 (now 11073) Working Group developing POC Medical Device Communication Standards… – In Europe we had CEN TC251 also working on POC Medical Device Communication Standards… Surprisingly these 2 groups actually talked to each other and shared some members!!!

Some History… From this collaboration we ended up with: – CEN TC251 focused on Nomenclature and generated a Standard that eventually became ISO/IEEE – IEEE focused on the Domain Information ( ) Model and many other aspects of the Device Communication problem. By the early 2000’s (after 10++ years…) we had a set of Standards that could be used for real implementations.

Some History… So, what happened? – Almost nothing… – A few brave companies created some products that supposedly* complied with the Standard… Philips Alaris Draeger – Very little “consumer” demand – No guarantee of Interoperability *Not meant to be negative, there was just no independent way of testing compliance…

Some History… Why? – The world had moved over those 15 years. – HL7 became the de-facto approach for EMR connectivity. Each Device Vendor had an HL7 Gateway – Vendors found that the Standards were quite complicated. – Vendors could not guarantee that 2 IEEE compliant devices would talk to each other out of the box. Standards are Necessary but not Sufficient !! Standards are Necessary but not Sufficient !!

Plenty of Examples… Standards are Necessary but not Sufficient… – IR Remote Controls All vendors use the same IR Standard, but there is no interoperability – Wi-Fi Before the Wi-Fi Alliance was created, most b implementations would not interoperate – USB Did not work well until Microsoft “took control” and started to manage the Drivers necessary to make it work. Etc.

Other Efforts… Integrated Clinical Environment (ICE) – Proposes a Framework for a Clinical Workstation using Plug and Play devices focused on Safety Continua – Focused on Personal Healthcare Devices – They have an ecosystem of Standards (via IEEE 11073), Plug-Fests and paths to Certification Prototype Regulatory Submission WG – How would a vendor submit an “Interoperable Device” to the FDA?

How do we get to “Interoperability”?

So, What is Interoperability? We use the term a lot… How would we define it? Some Examples: – “Interoperability means the ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of healthcare for individuals and communities.” [HIMSS] – “Interoperability is the ability of different information technology information systems to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged.” [NAHIT]

Interoperability - A Definition From the AAMI HITI Working Group: – “Interoperability is the ability of two or more medical devices or clinical systems designed to communicate with one another to safely fulfill an intended purpose.” What this does not cover is the effort required to make the systems achieve interoperability. – We want to move from “Plug and Pray” to “Plug and Play” This introduces the concept of “Levels of Interoperability”.

Levels of Interoperability From Simulation Technology None Technical Syntactic Semantic Pragmatic Dynamic Conceptual Stand-alone Common Physical and Transport Layers Common Format Meaning understood Context understood Dynamic Context understood Assumptions & Constraints understood Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Integratability Interoperability Composability Increasing Capability for Interoperation Turnitsa, C.D. (2005) “Extending the Levels of Conceptual Interoperability Model (LCIM).” Proceedings IEEE Fall Simulation Interoperability Workshop, IEEE CS Press

Levels of Interoperability Examples None Technical Syntactic Semantic Pragmatic Dynamic Conceptual Stand-alone RS232, Ethernet, WiFi, USB, TCP/IP, … HL7, IEEE 11073, Continua, … Snomed, IHE-PCD RTM, IEEE Nomeclature, … IHE PCD/Continua Use Case based Profiles, … Resource and Load Management Model Based Interoperability Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Integratability Interoperability Composability Increasing Capability for Interoperation Turnitsa, C.D. (2005) “Extending the Levels of Conceptual Interoperability Model (LCIM).” Proceedings IEEE Fall Simulation Interoperability Workshop, IEEE CS Press

Levels of Interoperability AAMI (proposed) … None Technical Syntactic Semantic Pragmatic Dynamic Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Integratability Interoperability AssociationAuthenticationAuthorizationDiscovery Fault Tolerance Security Certification Increasing Capability for Interoperation Safety

IHE PCD and Interoperability

Role of IHE PCD IHE PCD was formed 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 achieve out of the box interoperable solutions.

The Patient Care Device Domain is concerned with use cases in which at least one actor is a patient-centric point-of-care medical device. The PCD coordinates with other IHE clinical specialty based domains such as medical imaging and lab to ensure consistency of medical device integration solutions across all IHE technical frameworks. NOTE: NOTE: Formed in 2005 & sponsored by HIMSS & ACCE IHE PCD Charter

All implementation detail! Profiles Simplify Development

Document Use Case Requirements Identify available standards ( e.g. HL7, DICOM, IEEE, IETF) Develop technical specifications Testing at Connectathons IHE Demonstrations Products with IHE Improved safety, quality & efficiency! Easy to integrate products IHE Profile Development Process Start Here!!

Current Profiles: Current Profiles:  Rosetta Terminology Management (RTM)  Enterprise sharing of Patient Care Data (DEC)  PCD Alarm Communication Management (ACM)  Point-of-care Infusion Verification (PIV) Implantable Device – Cardiac Observation (IDCO) Waveform Common Module (WCM) Work in Process: Work in Process:  Medical Device Data Query (MDQ)  Point-of-Care Identity Management (PCIM)  Medical Equipment Management (MEM) + Location Services + Cyber Security Management IHE PCD - Profiles

IHE PCD Overview

Connectathon – in the dungeon…

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 ACM, MEM ACM, DEC, WCM ACM: Alarm Communication Management DEC: Device Enterprise Communication IDCO: Implantable Device – Cardiac – Observation MEM: Medical Equipment Management PIV: Point-of-Care Infusion Verification WCM: Waveform Communication Management Home Based System Ventilation/ Anesthesia System EMR/EHR CIS Physiologic Monitoring System DEC ACM, DEC ACM, DEC, WCM AAMI Demo PIV AAMI Demonstration

HIMSS 2010 PCD – HIMSS 2011

Let’s Go Shopping !!

The Business Case Enables you to efficiently manage the array of integrated information systems necessary to support effective healthcare The alternative – Building site-specific interfaces More expensive Requires maintaining these custom interfaces for the life of the system involved. Integration via IHE is less costly at the start and makes future acquisitions easier to plan and execute IHE Profiles give clear definitions of how the pieces fit together IHE Profiles come with initial unit testing done

Leveraging IHE for Purchasing Ask for IHE-PCD by Name!! – How do you get IHE Integration Profiles? Specify IHE capabilities as requirements State in the RFP which IHE Actors and Integration Profiles you want. – What do IHE Integration Profiles cost? Nothing in most cases Any cost should be a fraction of the overall

We are Seeing Green Shoots!! Vendors are starting to release IHE compliant product… – ~20 devices/systems announced so far – We expect ~30 devices by end of ’11 Typically a search of Integration Statements on the IHE web site will give you a list… – – Some vendors are having internal issues getting the appropriate web sites set up.

We are Seeing Green Shoots!!

What Can You Do? Plan, Evaluate, Purchase IHE Conforming Devices In continuing discussions with vendors – at all levels – Push IHE Interoperability Refer to lower deployment, maintenance costs – Encourage vendors’ active IHE participation Lower development, installation, support costs – Refer to profiles Leverage public and objective commitments In RFPs – Refer to profiles, Conformance Statements – Use Conformance Statements to “nail down” vendor’s representations – Adopt very specific language

SummarySummary Due to the complexity of real-world devices, Standards are only a starting point. Achieving true “plug and play” Interoperability is still a goal and not a reality. Supporting and Specifying IHE-PCD compliant products is a step in the right direction!

Questions??? IHE-PCD Update Sunday 8:30 AM Find out more at