IHE PATIENT CARE DEVICES DOMAIN The Time for Interoperability is NOW!

1. IHE PATIENT CARE DEVICES DOMAINThe Time for Interoperability is NOW!

2. Why Are We Here? • Reasons for interoperability • Barriers to adoption • Momentum moving us forward • How IHE is breaking down these barriers • Status of IHE-PCD work • Future directions of IHE-PCD work

3. Are These Devices ReallyAvailable? • 19 products from 15 vendors are available for you to purchase today • Device Enterprise Communication (DEC) • Point of Care Infusion Verification (PIV) • Alarm Communication Management (ACM) • Implantable Devices Cardiac Observation (IDCO) • Search for IHE-PCD Compliant Devices and Systems • http://product-registry.ihe.net/

4. Key Benefits of Point of Care Medical Device Interoperability • More accurate data (10 to 20% errors introduced with data transcription) • Improved patient safety and care outcomes • Improved discharge decisions • Improved Case Management, Infection Prevention and QA • More “real time” data available to MD, clinicians and care managers • More clinically sound diagnosis and orders • Earlier initiative of appropriate interventions and therapies • Prevention of undetected patient deterioration (“failure to rescue”) • More “proactive” patient management (LOS,  reimbursement) • Better outcomes • Increased MD productivity and satisfaction • Increased Nursing productivity and satisfaction • 1 to 1.5 hrs day savings per RN or CAN • Outcomes data warehousing

5. Barriers: Market Forces • Healthcare organization financialpriorities • Where is the ROI for medical device interoperability? • Each solution must be justified financially • Reimbursement drivers • Are you willing to pay more for standards? • Would anyone buy an ultrasound without “DICOM” • Vendors marketing one-size-fits-all • Do they really make financial sense? • Don’t listen to these marketing or sales guys • Talk to people who have actually implemented • “Sure, we can interface these widgets to your EMR”

6. Safely, Effectively • Rigorous validation, verification, and testing of medical devices is required • This slows development to market timelines • We’re creating complex systems of systems requiring analysis

7. Complex Problems • Most healthcare organizations do not have the staff to understand requirements of medical device interoperability • Sure it “interfaces” does to your EMR but what does that mean? • We need to simplify the integration requirements • Vendor salespeople wouldn’t be able to blow as much smoke • Imaging devices as an example

8. Cultural • Clinical Engineering and Information Systems have traditionally worked in silo’s • Clinical Systems Engineer • A Hybrid employee • Trend is partnering CE with IT • Neither one can do this alone • AAMI-ACCE-HIMSS CE-IT Community

9. IHE PCD: Simplify Specs! Photo courtesy Jack Harrington

10. IHE • International organization of manufacturers, standards organizations, and users • IHE is not a standard, IHE is a user of standards • Identify and constrain standards to make them more user friendly and truly interoperable • Saying it’s a compliant IHE Image Acquisition Actor means a lot more than saying its “DICOM” • Claiming a Central Station is a Device Observation Reporter (DOR) means more than saying its HL7 • Standards are broadly based while IHE drills down to specify the parts of standards that are normally ambiguous • Example: A medical device claiming to be a DOR must use HL7 v2.6 and must structure their HL7 messages in a way clearly defined by IHE, using message contents and semantics that is also clearly defined by IHE • Vendors test their connectivity at annual connectathons

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

12. IHE Technical Frameworks • Profiles • Describe clinical information management use cases and specify how to use existing standards (HL7, DICOM, IEEE 11073, etc,...) to address them. • Actors • A system or application responsible for certain information or tasks. Each Actor supports a specific set of IHE transactions to communicate with other Actors. • Transactions • An exchange of information between Actors. For each transaction a Technical Framework describes how to use an established standard (such as HL7, DICOM or W3C) to exchange information.

13. IHE Profile Actor Transaction

14. Alarm Communication Management Profile • Clinical Objective: • Improve clinical efficiency by using technology to deliver the right alarms, with the right priority, to the right individuals via devices with the right content, and through configuration escalating communication of alarms to devices associated with other individuals • Technical Objective: • Provide uniform way of representing common alarm conditions to facilitate interoperability of systems from different vendors

15. Alarm Reporter (AR) Alarm Manager (AM) Alarm Communicator (AC) Alarm Source Alarm Aggregator Alarm Receiver Alarm Coordinator Alarm Disseminator Alarm Communication Alarm Endpoint Alarm Reporter . . . . . . Alarm Cache Alarm Archiver (AA) Communication detailed in this profile Communication not detailed in this profile Communication of alarm information from patient care devices to an alarm manager system communicating with secondary means of notification to caregivers. Typical secondary notification means would be annunciators, pagers, and smart phones.

16. Use Cases • Case A1: Location Sourced alarm (i.e. nurse call type alarms) • Case A2: Identified Patient Source (i.e. physiological type alarms) • Case A3: Same as A1/A2 with Escalation and Cancel at Alarm Reporter (AR) • Case A4: Same as A1/A2 with Escalation and Cancel at Communication Endpoint • Case A5: Same as A1/A2 with Escalation and Cancel at Alarm Manager (AM) • Case A6: Alarm with no destination other than logging by the Alarm Manager (AM) actor

17. Case A1: Location Sourced Patient wants a pillow Patient pulls nurse call Nurse call system lights the room’s dome light and light at central station. Nurse call system, operating as an Alarm Reporter (AR) actor sends Report Alarm [PCD-04] to Alarm Manager (AM) indicating nurse call alarm. The Alarm Manager (AM) logs receipt of the alarm. The Alarm Manager (AM) identifies the appropriate nurse based upon configured nurse to patient assignments, identifies the appropriate Alarm Communicator (AC) actor and destination communication device based upon nurse to device configuration in Alarm Manager (AM), sends Disseminate Alarm [PCD-06] to nurse’s communication device. The Alarm Manager (AM) logs the dissemination to the Alarm Communicator (AC). The nurse receives the alarm on their assigned device. The information minimally includes the patient location (room number). The nurse goes to the room, determines the needs of the patient, and provides the patient with a pillow. The nurse then resets the nurse call pull. The nurse call system turns off the room’s dome light and the light at the central station. The nurse call system, operating as an Alarm Reporter (AR) actor sends Report Alarm [PCD-04] to Alarm Manager (AM) indicating reset of the nurse call alarm. The Alarm Manager (AM) receives the alarm turns off any configured alarm escalation and logs the alarm. AR -> AM AM -> AC AC -> Nurse AR -> AM

18. Alarm Communicator -Vocera -Cisco Wireless IP Phone -Cell Phone-Pager Alarm Manager -”Smart” alarm systems -Alarm aggregators Alarm Reporter -Nurse Call -Medical Devices -Physio Monitors -Pumps -Apnea -Bedboard System

19. Leveraging IHE for purchasing • 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

20. Why Specify IHE • Specifying integration requirements for the system you are purchasing is a simple matter of selecting which IHE Integration Profiles and which IHE Actors you want supported • When you tell a vendor you want a certain IHE actor they immediately know your interface specifications instead of requiring an extensive interface technical assessment • Users can concentrate on the clinical requirements of their equipment – not how it is going to interface to other systems • Removes custom interfaces as obstacles for future upgrades and additions

21. The business case for implementing IHE Profiles • 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

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

23. Sample language • “The device shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Reporter (DOR) Actor.” • “The pump shall support the IHE Point-of-Care Infusion Verification (PIV) Integration Profile as the Infusion Order Consumer (IOC) Actor.” • “The device shall support the IHE Alarm Communication Management (ACM) Integration Profile as the Alarm Reporter (AR) Actor.” • The alarm aggregator shall support the IHE Alarm Communication Management (ACM) Integration Profile as the Alarm Manager (AM) actor

24. PCD User Handbook 2011 Edition • Overview of IHE-PCD • Value Propositions for medical device interoperability • Advice on how to specify IHE in technology assessment • Tools to find IHE-PCD compliant products • Guidance on installation testing to confirm that IHE capabilities are functioning properly • Issues to consider when installing and configuring IHE-compliant system • Identifying and addressing potential problems in order to maximize your benefit despite existing “legacy” systems • To be posted for comment shortly, meanwhile the draft is here • wiki.ihe.net/index.php?title=PCD_User_Handbook • 2011 Changes include • Appendix H Mapping Clinical Requirements to Purchasing Requirements • Consolidation of the 2 major sections into 1 section • Incorporation of public comments from 2010 edition

25. Smartphone Order AC Pager Annunciator PCD-03 Communication Device Point-of-care Medication Pharmacy HIS eMAR IOP PDS DOC IOP Disseminate Alarm PCD-06 Alarm Status PCD-07 Infusion Documentation Order Order PCD-03 PCD-03 ITI-030 PCD-01 Patient Id Pump Server IOC PDC DOR AR AM Report Alarm PCD-04 Secondary Alarm Manager Alarm Status PCD-05 Infusion Pump

27. HIS EHR PDS DOC Smartphone AC Vital Signs Measurements Pager Communication Device Annunciator ITI-030 PCD-01 Patient Id PDC VSM Server Disseminate Alarm PCD-06 Alarm Status PCD-07 DOR AR Report Alarm PCD-04 Note: These interfaces could be built directly into the device Alarm Status PCD-05 AM Secondary Alarm Manager Vital Signs Monitor (VSM)

29. 2011 Significant Profiles • [DEC] Device Enterprise Communication – supports communication of information acquired from point-of-care medical devices to applications such as clinical information systems and electronic health record systems, using a consistent messaging format and device semantic content. Status: Final Text Q2/2011; Connectathon 27 vendors; Registry: 4 products (we estimate ~20 products by end of year). • [IDCO] Implantable Device – Cardiac – Observation specifies the creation, transmission, and processing of discrete data elements and report attachments associated with cardiac device interrogations (observations) or messages. Status: Final Text Q2/2011; Connectathon 10 vendors; Registry: 0 products. • [PIV] Point-of-care Infusion Verification supports communication of a 5-Rights validated medication delivery / infusion order from a BCMA system to an infusion pump or pump management system. Status: Final Text Q2/2011; Connectathon 7 vendors; Registry: 0 products. • [ACM] Alarm Communication Management enables the remote communication of point-of-care medical device alarm conditions ensuring the right alarm with the right priority to the right individuals with the right content (e.g., evidentiary data).  Status: Trial Implementation, Final text Q2/2012; Connectathon 13 vendors; Registry: 3 products. • [WCM] Waveform Communication Management provides support for the communication of physiological 2-dimensional waveforms. Status: Trial Implementation; expect first Connectathon participants in 2012.

30. 2011 Deployment Activities • Continua has accepted the IHE-PCD DEC profile as a building block for their device communications approach • IHE-Korea held an IHE Connectathon focused on the Continua/IHE WAN which uses the PCD-01 profile in August 2010, and will be holding a second Connectathon this year adding XDS.b support that exchanges information collected from personal glucose monitoring devices • Various discussions have been held with IHE-Japan concerning possible collaboration on testing events and public demonstrations • Cross-domain demonstration with IHE-PCC at HIMSS11 around peri-natal results acquisition and reporting. • HIMSS11 Showcase • The number of participating companies has increased significantly starting with 6 companies in 2007, 12 in 2009 and 20 in 2010 and 23 in 2011 with a marked increase in tour attendees.

31. 2011 Approved Works in Progress [ADQ] Asynchronous Data Queryis a transaction profile which will support a solicited mode of obtaining data from Patient Care Devices or Patient Care data stored in devices or IT systems.  <Status: under development, Supplement should be published Q2 2012> [PCIM] Point of Care Identity Managementwill deal with the association of a patient identity (demographics) to a specific device or set of devices. <Status: under development, Supplement should be published Q2 2012>

32. Medical Equipment Management: Device Maintenance • Working towards effective Predictive Maintenance • In 2011 we plan to establish Content Profiles for acquisition of device status and logs • Rosetta Terminology Mapping: • Establish the required IEEE 11073 terms, and enumerations • Leverage DEC and ACM Profiles and PCD-01 and PCD-04 transactions where possible

33. Medical Equipment Management: Cybersecurity • Cybersecurity Whitepaper final version http://wiki.ihe.net/index.php?title=PCD_MEM_Cybersecurity Cycle 7 Work Item Proposal: CE/IT Integration and Management of Medical Devices

34. In the short and medium term the IHE PCD Domain is focused on: • Completing a number of Change Proposals • Releasing deliverables already under development • Increasing the availability of our profiles in actual commercial products. • IHE PCD continues to solicit more active involvement from Enterprise EMR/EHRS vendors for feedback on requirements and technical implementation details • 5-year Roadmap updated at May 2011 Meeting http://wiki.ihe.net/index.php?title=PCD_Roadmap

35. Q & A www.ihe.net/pcd