The Time for Interoperability is NOW! An update from the field

1. The Time for Interoperability is NOW!An update from the field Steve Merritt Infrastructure Engineer MS Biomedical Engineering Co-chair IHE Patient Care Devices Planning Committee steve.merritt@baystatehealth.org

3. Why Are We Here? • Barriers to adoption • Momentum moving us forward • How IHE is breaking down these barriers • Planning for Interoperability NOW

4. 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”

5. Safely, Effectively • Rigorousvalidation, verification, and testing of medical devices is required • This slows development to market timelines • We’re creating complex systems of systemsrequiring intricate analysis • Regulatory challenges

6. Complex Problems • Most healthcare organizations do not have the staff to understand requirements of medical device interoperability • Sure it “interfaces” 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 • Increasing need for collaboration between CE and IT

7. 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 PCT • Outcomes data warehousing

8. FY12 FY13 FY14 FY15 FY16 FY12 Request FY12 Request (moved out to FY13) Already Fully Funded (FY11 or HOF) Clinical Technology Patient Monitoring HOF Critical Care Rooms Clinical System HOF Telemetry System Integration HOF Care Rooms BMC Backfill Rooms • Improve Patient Safety • Provide the right information to the right person at the right time • Reduce documentation errors • Interoperability with EMR • Continuous documentation of cardiac rhythms into the EMR BOSC Replace CCN monitors Replace NICU monitors Replace PICU monitors New ED Monitors PACU monitors to CIS BMC PICU monitors to CIS BMC CCN monitors to CIS BMC NICU monitors to CIS PediPACU monitors to CIS Not funded New ED monitors to CIS HOF Critical Care Rms INET BMC Backfill Rooms INET HOF Care Rooms INET All BMC Monitors to Alarm Mgmt All BHS Monitors to Alarm Mgmt BFMC FetalLink HOF Telemetry to Alarm Mgmt Anesthesia HOF Procedure Rooms CVIS Interoperability Anesthesia Information System ORIS Interoperability Ventilators Analog Vent Alarms to Nurse Call • Reduce documentation errors • Interoperability with EMR • Wireless communication • Vendor agnostic interoperability • Increase staff productivity HOF Vents HOF Ventilators to INET Vent Alarms to Alarm Management

9. Alarm Management Example • Multi-input <-> multi-output • Combination of traditional biomedical systems and IT networks, databases, servers, communication devices and systems • Collaboration between CE and IT required • Effective communication of requirements • Deep understanding of criticality • Must work together from inception through technology assessment to implementation and support

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

11. 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 the IHE PCD Rossetta Terminology tables • Vendors test their connectivity at annual connectathons

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

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

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

16. 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 • When do I specify integration requirements? • Ask during the technology assessment phase • Require during the RFP or purchasing process • Don’t wait until you need it

17. Device Lifecycle • Diminishing but still 5 to 7 years • Are you ready to interface your 5 year old patient monitors or ventilators? • Two-fold problem • Life-cycle impedance matching • Not likely that EMR will be replaced at the same time your medical devices are • Need for open-standards based interoperability • Even if you’re not looking to interface your device at implementation, you need to understand its interoperability capabilities at the time of purchase

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

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

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

21. 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 • http://www.ihe.net/Resources/handbook.cfm • 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

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

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

25. 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)

27. Example contract clause • [Vendor] shall ensure that the Hardware and Software provided by [Vendor] is capable of serving as the Device Observation Reporter (DOR) Actor to send data from the applicable patient care devices (PCD) listed in Exhibit F attached hereto to which such Hardware is connected in which the Software is installed as described in the current IHE Device Enterprise Communication (DEC) Integration Profile, provided that the applicable PCD and the applicable Device Observation Consumer (DOC), Device Observation Filter (DOF) and other Customer system components being utilized themselves conform to the IHE Device Enterprise Communication (DEC) Integration Profile. If this functionality is not available as of the Effective Date, [Vendor] shall provide it to Customer in an Update, as that term is defined in Schedule A hereto, at no cost to Customer as soon as is practicable thereafter.  In the event of changes to such IHE DEC Integration Profile terms are made after the Effective Date and additional products or services are necessary to comply with the changes, provision of such additional products or services shall be subject to mutual agreement of the parties as to pricing and other terms.

28. Are These Devices Really Available? • 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/

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. Roadmap • http://wiki.ihe.net/index.php?title=PCD_Roadmap • Deployments - getting products with IHE-PCD actors implemented in the marketplace. • Clinical Integration Profiles - multi-domain projects to encompass entire workflows that involve actors from different domains • Alarm and Event Management • Semantic Interoperability • Device Specialization Profiles • Device and Service Management

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

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

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

34. Take-Aways • Plan for interoperability now • Prepare roadmaps • Leverage IHE • Research other standards work • Monthly CE-IT integration meetings with key stakeholders • Involve all resources necessary at technology inception