IHE An Introduction for Source Atlantic

1. IHEAn Introduction for Source Atlantic

2. IHE PCD: Simplify Specs!

3. 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 content and semantics that is also clearly defined by IHE • Vendors test their connectivity at annual connectathons

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

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

6. IHE Profile Actor Transaction

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

8. 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 The intended use is to serve in 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. *Note that in 2009 this profile is being extended to other alarms including from systems such as patient/asset tracking, bed management, etc

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

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

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

12. How to ask • 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

13. IHE PCD Profiles Existing Profiles Device Enterprise Communication (DEC) Patient Identity Binding to Device Data (PIB) Subscribe to Patient Data (SPD) Rosetta Terminology Management Project (RTM) Alarm Communication Management (ACM) Infusion Pump Integration (PIV) Implanted Cardiac Devices (IDCO) Works in Progress Waveform Communication Management (WCM) Medical Equipment Management (MEM) Device Point-of-Care Integration (DPI, a multiyear effort) Real-time data archiving and communication

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

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

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

17. Sample language • “The device shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Reporter (DOR) Actor.” • “The device shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Patient Identity Binding (PIB) 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.”

18. What else? • Leverage the work done within IHE even if your vendor doesn’t conform • Use the IHE Technical Framework as a basis for interface requirements • EUI-64 unique device identification • Time synchronization • HL7 v2.6 • Semantics • Rossetta Terminology Mapping

19. Where to start • Connectathon Results • http://sumo.irisa.fr/con_result/ • If you’re looking for Alarm Reporters just see who has already passed connectathon