The Time for Interoperability is NOW An update

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

At a Glance Type of Organization: IDN/ teaching hospital FTE’s: 10, 000 Physicians: 1, 663 (492 employed) Residents: 311 residents, 250 medical students Baystate Medical Center Baystate Franklin Medical Center Baystate Health Baystate Mary Lane Hospital Inpatient Statistics Inpatient Facilities: 3 Beds: 774 Admissions: 44, 000 Patient Days: 210, 000 Average Length of Stay: 4. 7 Avg Daily Census for all hosps combined: 580 D’Amour Center for Cancer Care Baystate Medical Practices Baystate VNA & Hospice

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

Barriers: Market Forces v Healthcare organization financial priorities • • v 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”

Safely, Effectively v v Rigorous validation, verification, and testing of medical devices is required This slows development to market timelines We’re creating complex systems of systems requiring intricate analysis Regulatory challenges

Complex Problems v 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? v We need to simplify the integration requirements • Vendor salespeople wouldn’t be able to blow as much smoke v Imaging devices as an example v Increasing need for collaboration between CE and IT

Key Benefits of Point of Care Medical Device Interoperability v More accurate data (10 to 20% errors introduced with data transcription) • • v v v 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 • v Improved patient safety and care outcomes Improved discharge decisions Improved Case Management, Infection Prevention and QA 1 to 1. 5 hrs day savings per RN or PCT More “real time” data available to MD, clinicians and care managers Increased MD productivity and satisfaction Increased Nursing productivity and satisfaction Outcomes data warehousing

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

Alarm Management Example v v v 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 v Must work together from inception through technology assessment to implementation and support

IHE PCD: Simplify Specs! Photo courtesy Jack Harrington

IHE v International organization of manufacturers, standards organizations, and users • IHE is not a standard, IHE is a user of standards v 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 HL 7 v 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 HL 7 v 2. 6 and must structure their HL 7 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 v Vendors test their connectivity at annual connectathons

IHE Technical Frameworks v v v Profiles • Describe clinical information management use cases and specify how to use existing standards (HL 7, 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 HL 7, DICOM or W 3 C) to exchange information.

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. Alarm Reporter (AR) Alarm Source Alarm Aggregator . . . Alarm Manager (AM) Alarm Receiver Alarm Coordinator Alarm Communicator (AC) Alarm Disseminator Alarm Communication Alarm Reporter . . . Alarm Cache Alarm Archiver (AA) Communication detailed in this profile Communication not detailed in this profile Alarm Endpoint

Case A 1: Location Sourced Patient wants a pillow Patient pulls nurse call Nurse call system lights the room’s dome light and light at central station. AR -> AM AM -> AC 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). AC -> Nurse The nurse receives the alarm on their assigned device. The information minimally AR -> AM 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.

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

Leveraging IHE for purchasing v How do you get IHE Integration Profiles? • Specify IHE capabilities as requirements • State in the RFP which IHE Actors and Integration Profiles you want. v What do IHE Integration Profiles cost? • Nothing in most cases • Any cost should be a fraction of the overall v 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

Device Lifecycle Diminishing but still 5 to 7 years v Are you ready to interface your 5 year old patient monitors or ventilators? v Two-fold problem v • 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

Why Specify IHE v 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 v 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 v Users can concentrate on the clinical requirements of their equipment – not how it is going to interface to other systems v Removes custom interfaces as obstacles for future upgrades and additions

The Business Case for Implementing IHE Profiles v v 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. v v v 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

What Can You Do? v Plan, Evaluate, Purchase IHE Conforming Devices v 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 v In RFPs • Refer to profiles, Conformance Statements • Use Conformance Statements to “nail down” vendor’s representations • Adopt very specific language

PCD User Handbook 2011 Edition v v v v v 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

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

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

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

Example contract clause v [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.

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

2011 Significant Profiles v v v [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 Q 2/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 Q 2/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 Q 2/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 Q 2/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.

Roadmap v http: //wiki. ihe. net/index. php? title=PCD_Roadmap 1. Deployments - getting products with IHE-PCD actors implemented in the marketplace. 2. Clinical Integration Profiles - multi-domain projects to encompass entire workflows that involve actors from different domains 3. Alarm and Event Management 4. Semantic Interoperability 5. Device Specialization Profiles 6. Device and Service Management

Medical Equipment Management: Device Maintenance v 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

Medical Equipment Management: Cybersecurity v 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

P I E H r d a E o e s d n y D u t e c i t m t f o o s y n i s w a n t i v r t a e a h i g t l r i I a o H b t n E l e s e p s r t Document Use Case o a Requirements d IHE Standards Adoption Process Testing at Connectathons Improved safety, quality & efficiency! 33 33

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