IHE Patient Care Device User Handbook (Also known as “PCD … · 2019-12-18 · How to Use this Handbook This handbook was assembled by the IHE Patient Care Device (PCD) Planning

Copyright copy 2018 IHE International Inc

Integrating the Healthcare Enterprise

IHE Patient Care Device User 5

Handbook (Also known as ldquoPCD Cookbookrdquo)

2018 Edition 15

April 12 2018 20

Please verify you have the most recent version of this document which is published here 25

IHE Patient Care Device User Handbook (also known as ldquoPCD Cookbookrdquo ______________________________________________________________________________

___________________________________________________________________________ 2018 Edition ndash 2018-04-12 2 Copyright copy 2018 IHE International Inc

Contents Executive Summary 4 30 How to Use this Handbook 6 Glossary 8 1 Scenario Integrating Medical Devices into a CIS 11

11 The Planning and Purchasing Process 11 111 Selecting IHE Integration Profiles and Actors 12 35 112 Organizational Goals and Integration Profiles 12 113 Putting Integration Requirements in Your RFP 15 114 Identifying Suitable Products 16 115 Reading Integration Statements from Vendors 16

12 The Design Configuration and Implementation Process 16 40 121 Considering Changes to Your Workflow 17 122 Confirming That Itrsquos Working 17

1221 Device Enterprise Communication (DEC) 17 1222 Alert Communication Management (ACM) 19 1223 Medical Equipment Management Device Management Communication 45

(MEMDMC) 20 1224 Medical Equipment Management Location Services (MEMLS) 20

123 Considering Installation Issues 21 124 Identifying and Addressing ldquoLegacyrdquo Problems 21

1241 Connecting the IHE Device to a Non-IHE CIS 22 50 Appendix A Developing an Integration Strategy 23

A1 Integration Approaches in IT Environments with Legacy Systems 25 Appendix B Understanding IHE Integration Profiles 27

B1 Integration Profile Summaries and Tutorials 27 B2 Reading the IHE Technical Framework 27 55 B3 Rosetta Terminology Mapping 27 B4 Content Profiles 28

Appendix C Writing Integration Capabilities into an RFIRFP 29 Appendix D Identifying Suitable Products 32

D1 IHE Connectathon Results 32 60 D2 IHE Integration Statements 32 D3 Reading Integration Statements 33 D4 Verifying Integration Statements 34

Appendix E Obtaining and Reading HL7 Interface Specifications 35 Appendix F Conducting Acceptance Testing 36 65 Appendix G Performance Metrics 38

G1 What to Measure 38 Appendix H Mapping Clinical Requirements to Purchasing Requirements 40

Introduction 40 Structure and Nomenclature 40 70 Use Case 1 Infusion Pumps Selection Criteria 42 Use Case 2 Vital Signs Monitor (VSM) Interoperability Criteria 45

Appendix I Deployment of Alert Communication Management solutions 47 Introduction 47 Common Solution for a Common Need 47 75 Solution Best Suited for Each Role 47 Alert Retrospective Traceability 49

Executive Summary Integrating the Healthcare Enterprise (IHE) is an initiative by care providers (including ACCE 80 HIMSS and RSNA) and vendors to improve the way information systems communicate to support patient care IHE defines Integration Profiles that use established data standards to integrate systems for effective interoperability and efficient workflow IHE makes it possible to achieve the level of integration required in the era of the electronic health record This handbook targets 85

bull Administrators who make purchasing decisions

bull Information Systems Analysts

bull Clinical Engineers

bull Technology evaluators What is an Integration Profile 90 Each IHE integration profile describes a clinical requirement for systems integration and a solution to address it It defines functional components called IHE actors by specifying in careful detail the transactions each actor must perform based on standards such as IEEE 11073 Digital Imaging and Communication in Medicine (DICOMreg)1 and Health Level 7 (HL7reg)2 How do you get IHE Integration Profiles 95 You specify IHE capabilities as requirements on the information systems and medical devices that you are purchasing or upgrading Simply state in the Request For Proposal (RFP) which IHE actors and integration profiles you want What do IHE Integration Profiles cost and what is the return on investment In some cases integration profiles cost nothingmdashthey are integral to a productrsquos capabilities In 100 other cases vendors may package IHE integration profiles at an added cost with new systems or offer them as upgrades to installed systems Healthcare providers should insist that any costs for IHE integration profiles be less than the cost of integration services that do not utilize IHE integration profiles It takes less resources time and money to design and implement IHE integration profiles than customized interfaces for both the vendor and the healthcare provider 105 This should be reflected in the costs What is the business case for implementing Integration Profiles Integration profiles enable you to efficiently manage the array of integrated information systems necessary to support effective healthcare The alternativemdashbuilding site-specific interfacesmdashis more expensive and requires maintaining these custom interfaces for the life of the system 110 involved Integration via IHE is less costly at the start and makes future acquisitions easier to plan and execute as well as more productive in delivering valuable functionality Integration profiles give clear definitions based on widely accepted standards of how the pieces fit together 1 DICOM is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information 2 HL7 is the registered trademark of Health Level Seven International

What other benefits does IHE provide IHE makes it practical for healthcare providers to use advanced information technology to 115 improve the quality and efficiency of care By ensuring the integrity of medical information IHE enhances patient safety By reducing the time spent in solving data problems such as lost incomplete and misplaced information IHE allows the most efficient use of staff time By providing care providers comprehensive patient information IHE enables users to make better-informed medical decisions 120 Semantic Interoperability Interoperability messages of IHE Patient Care Device Profiles make use of IEEE 11073 internationally recognized standards for nomenclature in identification of data items and in data item enumerations Units of measure follow the Unified Code for Units of Measure (UCUM) Such standards are the underpinnings for semantic interoperability across device manufacturers 125 The same data item is identified by the same identifier Observations are rationalized for consistency in their units of measure What should you do next Learn about the IHE integration profiles available for Patient Care Device and other parts of the Enterprise and consider how they meet your organizationrsquos goals Read this IHE Userrsquos 130 Handbook to learn how to require these capabilities in an RFP and how to implement them in your setting These resources and more are available at wwwihenet

Contributors Editors Monroe Pattillo Current Practical Health Interoperability LLC PCD Planning Committee

Co-Chair Steve Merritt Original Baystate Health previous PCD Planning Committee Co-Chair Authors Sofia Iddir Baystate Health Ploypan Thongpradit Baystate Health Erin Sparnon ECRI Institute Ioana Singureanu AmbitEversolve Jeff Rinda Hospira Infusion Systems a part of ICU Medical Inc

Reference Kevin OrsquoDonnell et al IHE Radiology Userrsquos Handbook 2005 edition June 20 2005

How to Use this Handbook 135

This handbook was assembled by the IHE Patient Care Device (PCD) Planning and Technical committees with input from healthcare professionals who have implemented IHE capabilities at their sites It is modeled after the IHE Radiology User Handbook published in 2005 The IHE Patient Care Device User Handbook describes how and why to acquire and implement systems and devices with IHE capabilities for device interaction IHE capabilities outside of device 140 interactions are not addressed in this Handbook IHE was designed to make the complex intricate and time-consuming tasks involved with integrating healthcare systems easier faster and more reliable This handbook describes how you can leverage IHE to improve the integration capabilities of your systems which interact with devices and the medical devices themselves This handbook illustrates methods to select specify 145 purchase and deploy IHE capable devices and systems The principles outlined can be applied to any systems acquisition and deployment project that involves integration of systems with IHE-defined transactions The handbook includes advice for those selecting and purchasing new systems and for the technical staff who will handle the installation and configuration of the new system A series of appendices provide advice and information applicable to each scenariomdashor 150 any other deployment project linking systems using IHE profiles This document includes the following sections

bull Sections 111 and 112 Selecting IHE integration profiles by mapping goals and needs to the benefits provided by each profile

bull Section 113 Writing RFPs to obtain the desired profiles (sample text for some 155 recommended profiles is included)

bull Sections 114 and 115 Identifying and evaluating relevant products

bull Section 121 Workflow changes that maximize the benefit of the IHE profiles

bull Section 122 Installation testing to confirm that IHE capabilities are functioning properly 160

bull Section 123 Issues to consider when installing and configuring IHE-compliant system

bull Section 124 Identifying and addressing potential problems in order to maximize your benefit despite existing ldquolegacyrdquo systems

This Handbook provides direction on how to make use of the information developed by the IHE initiative to deploy patient care devices and systems that exchange information effectively using 165 standards-based transactions to meet critical clinical needs It does not attempt to take account of the many other factors that determine the efficiency and suitability of an application for clinical use The information provided by IHE is only a partmdashalbeit an essential onemdashof the full set of resources required to select purchase deploy and upgrade systems that support IHE Note This is the third edition of the IHE Patient Care Device Userrsquos Handbook Future editions 170 will be expanded and enhanced It is envisioned that this document will be refreshed from time to time on an unscheduled basis to update it for additional and information corrections and for

new and updated IHE profiles The newest edition will always be available at httpihenetTechnical_Frameworks The Handbook is intended to meet the needs of the healthcare community Comments and 175 suggestions are welcome Send them by email to pcdcommentsgooglegroupscom or submit them online at httpihenetPCD_Public_Comments 2018 Changes

1 Added details regarding infusion systems 180 2 Added field deployment information for the Alert Communication Management (ACM)

Profile 3 Added more information on the Point of care Infusion Verification (PIV) Profile and

added the Infusion Pump Event Communication (IPEC) Profile 4 Added recent new IHE PCD profiles in the area of Medical Equipment Management 185

(MEM) the Device Management Communication (DMC) Profile and the Location Services (LS) Profile

Glossary Actor [IHE] A system or application responsible for certain information or tasksmdasheg the 190 Device Observation Consumer Actor Each actor supports a specific set of IHE transactions to communicate with other actors A vendor product may support one or more actors Admission Discharge and Transfer (ADT) message [HL7] Provides for transmitting new or updated demographics and patient visit information Generally information will be entered into a Patient Administration system and passed on to nursing ancillary and financial systems either in 195 the form of an unsolicited update or in response to a record-oriented query Clinical Information System (CIS) An umbrella term that has been applied to a broad range of clinical information technology and to various configurations of clinical application components Additional terms are used to describe information systems that support delivery of health care electronic medical record system (EMR) health information system (HIS) electronic health 200 record (EHR) clinical data repositories (CDR) clinical decision support systems (CDSs) and computer-based patient record systems (CPRs)are a few Note Clinical Information Systems in common use typically refer to the departmental systems (critical care information systems for example) These systems usually manage clinical information locally with respect to a ward or unit They can be integral to the larger enterprise electronic health record system as a repository 205 of the master ADT and administrative information regarding specific patients Connectathon [IHE] An annual event where participating vendors test their implementations of IHE capabilities with other vendors in a supervised environment This is IHE profile actor implementation verification testing It shouldnrsquot be confused with commercial product certification testing 210 Domain [IHE] A working group in IHE that addresses a particular clinical areamdasheg Patient Care Device Radiology Cardiology Laboratory or IT Infrastructure Each domain publishes a Technical Framework (TF) General order message (ORM) [HL7] The function of this message is to initiate the transmission of information about an order This includes placing new orders cancellation of 215 existing orders discontinuation holding etc ORM messages can originate also with a placer filler or interested third party Health Level 7 (HL7) The established standard for the exchange management and integration of data that support clinical patient care and the management delivery and evaluation of healthcare services 220 IEEE 11073 A set of standards for point-of-care device communications Integrating the Healthcare Enterprise (IHE) An initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information Integration Profile [IHE] A precise description of how standards are to be implemented to address a specific clinical integration need Each integration profile includes definitions of the 225 clinical use case the clinical information and workflow involved and the set of actors and transactions that address that need Integration profiles reference the fully detailed integration

specifications defined in the IHE TF in a form that is convenient to use in requests for proposals (RFPs) and product descriptions Integration Statement [IHE] A document prepared and published by a vendor to describe the 230 IHE integration profiles actors and options supported by a specific version of a product Medical Device Communication (MDC) A general term or acronym used to describe the communication of data from a medical device Observation Result (ORU) [HL7] The function of this message is to provide clinical observations in response to an order 235 Patient Care Device (PCD) A medical device used in the process of diagnosing monitoring treating or preventing disease Profile [IHE] See Integration Profile Registration System The system used for patient registration under normal workflow usually the ownersource of patient demographics 240 Supplement [IHE] A proposed addition to the TF After public comment review trial implementation and testing it is generally merged into the TF Technical Framework (TF) [IHE] The document that defines integration profiles the problems and use cases they address and the actors and transactions involved It provides detailed implementation instructions for each transaction (primarily used as a guide for vendors) 245 Transaction [IHE] An exchange of information between actors For each transaction the TF describes how to use an established standard (such as HL7 DICOM or W3C) to exchange information

Table of Acronyms Acronym Definition

ACM Alert Communication Management ADT Admission Discharge and Transfer BPOC Barcode-enabled Point of Care (often used interchangeably with BCMA) BCMA Barcode computer assisted medication administration (often used interchangeably with BPOC) CDR Clinical Data Repository CDSS Clinical Decision Support System CE Clinical Engineer CIS Clinical Information System CMMS Computerized Maintenance Management System CPOE Computerized Physician Order Entry DEC Device Enterprise Communication DICOM Digital Imaging and Communications in Medicine DMC Device Management Communication EC Event Communication eMAR Electronic Medication Administration Record system EHR Electronic Health Record

Acronym Definition EMR Electronic Medical Record HIS Hospital Information system IEEE Institute of Electrical and Electronics Engineers IHE Integrating the Healthcare Enterprise IPEC Infusion Pump Event Communication LS Location Services MDC Medical Device Communication MEM Medical Equipment Management PACS Picture Archiving and Communication Systems PCA Patient Controlled Anesthesia PCD Patient Care Device PIV Point of Care Infusion Verification RFID Radio Frequency Identification RTLS Real-Time Location Services TF Technical Framework as in PCD TF UCUM Unified Code for Units of Measure VSM Vital Signs Monitor WG Working Group

1 Scenario Integrating Medical Devices into a CIS 250

When considering integrating medical devices to a CIS there are many considerations Implementing a device or CIS with IHE integration capabilities can provide many benefits over using vendor-proprietary interfaces Integrating medical devices to a CIS can help ease staff shortages and transcription accuracy and consistency issues with documenting vital signs medications and responding to alerts There are a number of medical devices that are capable of 255 transmitting information to a CIS The Patient Care Device domainrsquos goals are to

bull Improve patient safety and clinical efficacy

bull Reduce healthcare delivery cost by improving efficiency reliability and operational flexibility for healthcare providers 260

bull Enable innovative patient care capabilities

11 The Planning and Purchasing Process 265

Intended for administrators who make purchasing decisions this section lists organizational goals to consider when specifying requirements for a device how to select the IHE integration profile that will address those goals how to clearly state IHE requirements in a Request For Proposal (RFP) and how to interpret vendor responses

111 Selecting IHE Integration Profiles and Actors 270

Specifying integration requirements for the system or devices you are purchasing is a simple matter of selecting which IHE integration profiles and which IHE actors you want supported Some profiles include options that provide functionality differences which you may decide to select The integration profiles relevant to the purchase of a patient care device and the functionality each provides are given below 275 Device Enterprise Communication (DEC) transfers patient care device (PCD) data to Enterprise applications (CIS CDR CDS EHR EMR etc) It addresses the need for consistent communication of PCD data to the enterprise that supports efficient patient care and better patient safety by reducing manual data entry (eg patient demographics) and populating data from medical devices into enterprise systems automatically 280 Point-of-Care Infusion Verification (PIV) brings infusion systems into the electronic medication administration process The workflow provides for the electronic transmission of infusion information from a barcode-enabled medication administration system (BCMA) to an infusion pump as part of the medication administration process This reduces the need for manual programming of the pump and leverages the use of the pumprsquos onboard drug library to 285 reduce medication errors Infusion Pump Event Communication (IPEC) defines the communication of events associated with infusion sequences to management systems Alert Communication Management (ACM) defines the communication of alerts (physiologic and technical alarms and advisories) from alert source systems to alert management systems and 290 from alert management systems to alarm communication systems This profile provides for alert dissemination between alert source devices and systems from the connector to and within the communication services to the required abstract semantics in a manner that if complied with enables multi-vendor multi-device interoperation in particular with phones pagers and other portable and desktop devices ACM is for the purpose of alert communication to communication 295 devices associated with people (pagers PBX phones smartphones tablets personal computers etc) Event communication is considered to be system or device to system or device communication Medical Equipment Management Device Management Communication (MEMDMC) defines the communication of devices to Computerized Maintenance Management Systems (CMMS) 300 Medical Equipment Management Location Services (MEMLS) defines the communication of location monitoring systems and additional information from location monitoring tags (environmental operator input accelerometers etc)

112 Organizational Goals and Integration Profiles

Clearly identifying organizational goals is important for defining the requirements for equipment 305 acquisition Each IHE integration profile is designed to meet a specific set of organizational goals Below is a list of goals an institution might have in acquiring a new device or system and the contributions that each relevant integration profile may make in supporting these goals

Reduce Errors and Enhance Patient Care Device Enterprise Communication (DEC) on medical device 310

bull Prevents or reduces manual data entry errors at the device by retrieving patient demographics information from master ADT systems via an HL7 interface and binding the demographics to the device

bull Prevents stale demographic data by updating current information to the device

bull Prevents or reduces manual data entry errors to the CIS by transmitting information 315 electronically from the device

bull Reduces delays in patient care by transmitting patient device data electronically reducing the number of manual steps and allowing the data to be viewed across the enterprise

bull Mitigates the risk of loss of data Point-of-Care Infusion Verification (PIV) on medical device 320

bull Reduces or eliminates errors in data entry during infuser programming

bull Improves patient safety by providing correct medication orders to the right patient at the right time

bull Mitigates the risk of errors that may be introduced by the manual administration of medications at the point of care 325

bull Applies the ldquofive rightsrdquo of medication administration electronically (right patient right route right dose right time right drug)

Alert Communication Management (ACM) on medical device

bull Allows centralization of alerts (physiological and technical alarms) and advisory notifications 330

bull Improves alert notification delivery time to the caregiver

bull Reduces alert confusion

bull Reduces noise levels in care environment

bull Allows alert active status and histories to be reviewed and managed

bull Improves safety by delivering alert notifications to the appropriate personnel 335 Improve Throughput

Device Enterprise Communication (DEC)

bull Saves manual data entry time at the device by enabling communication with master ADT systems

bull Improves data collection efficiency and homogeneity by sending directly and regularly to 340 CIS

bull Reduces delays in the reviewreporting processmdashdevice sends complete data or data in progress to the CIS allowing faster initial and final diagnosis

bull Reduces staff administrative time by electronically recording data instead of manual entry 345

Point-of-Care Infusion Verification (PIV) on medical device

bull Improves caregiver efficiency by integrating the infusion pump into the electronic medication administration process

bull Reduces staff time by electronically programming the infusion pump dosing and delivery data 350

bull Improves alert quality and response time

bull Allows different alert priorities to be managed efficiently and effectively Reduce Costs

Device Enterprise Communication (DEC) 355

bull Reduces extra steps in the workflow by utilizing automatic communication between the device and CIS

bull Prevents lost data by electronically transmitting to CIS

bull Improves billing accuracy

bull Promotes automated validation for more complete electronic charting 360

bull Reduces delays in the reviewreporting processmdashdevice specifically sends complete data or data in progress to the CIS allowing faster initial and final diagnosis

bull Reduces staff administrative time by electronically recording data instead of manual entry

Point-of-Care Infusion Verification (PIV) on medical device 365

bull Mitigates the possibility of introducing medication errors

bull Promotes more complete medication administration records

bull Improves billing accuracy for medications and consumables 370 Alert Communication Management (ACM) on CIS

bull Allows different alert priorities to be managed efficiently and effectively Reduce Deployment CostsTime

All IHE profiles on the device 375

bull Eliminates the need to create custom interface specifications for the medical device saving the hospital time and expense

bull Reduces interface compliance testing time and expensemdashIHE TF provides a detailed specification for a powerful interface supported and tested by many vendors

bull Reduces intersystem testing time and expensemdashmany combinations of systems have 380 already been directly tested together at IHE Connectathons

bull Reduces custom interface maintenance time and expense by mainlining a single IHE interface instead of multiple custom interfaces

Improve Device Management Medical Equipment Management ndash Device Management Communication (MEMDMC) 385

bull Communicates device status information to Computerized Maintenance Management System (CMMS)

bull Awareness of devices on infrastructure reduces rogues

bull Through communication with devices that support consuming MEMDMC observations can add information to DEC observations IPEC observations and ACM alerts 390

Medical Equipment Management ndash Location Services (MEMLS)

bull Communicates equipment and people location information (movement boundary crossings)

bull Communicates information provided by location tags for environmental information (temperature humidity pressure gasses) 395

bull Communicates tag interaction information (buttons pulls falls)

bull Through communication with devices that support consuming MEMLS observations can add information to DEC observations IPEC observations and ACM alerts

It is not always possible to address all organizational goals by making a single equipment purchase Achieving the full benefit of an IHE integration profile requires that the systems 400 interacting with the device also play their roles as defined in the profile Frequently partial benefits can be achieved by implementing an integration profile on a single actor such as the device in an environment where the interacting systems have some but not all of the functionality described in the profile Appendix A provides a general discussion of sequencing requirements and planning individual purchases as part of a long-range plan 405 To track progress toward organizational goals and determine return on investment a well-defined set of performance metrics is neededmdashsee Appendix G

113 Putting Integration Requirements in Your RFP Requiring IHE support in your RFP is as simple as stating which IHE integration profiles and options you want the system to support and which IHE actor roles the system should play in each 410 profile The following are sample statements to specify the profiles and actors for a medical device

1 ldquoThe device shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Reporter (DOR) Actorrdquo

2 ldquoThe device shall support the IHE Device Enterprise Communication (DEC) Integration 415 Profile as the Device Observation Filter (DOF) Actorrdquo

3 ldquoThe pump shall support the IHE Point-of-Care Infusion Verification (PIV) Integration Profile as the Infusion Order Consumer (IOC) Actorrdquo

4 ldquoThe device shall support the IHE Alert Communication Management (ACM) Integration Profile as the Alert Reporter (AR) Actorrdquo 420

The following are sample statements to specify profiles and actors for a CIS 1 ldquoThe CIS shall support the Device Enterprise Communication (DEC) Profile as the

Device Observation Consumer (DOC) Actor using the MLLP Optionrdquo 2 ldquoThe CIS shall support the Point Of Care Infusion Verification (PIV) Profile as the

Infusion Order Provider (IOP) Actorrdquo 425 3 ldquoThe CIS shall support the Alert Communication Management (ACM) Profile as the

Alert Manager (AM) Actorrdquo For products that do not currently support IHE integration profiles it may be possible to include contract language that binds the vendor to agree to support IHE over time Some vendors may also be actively developing compliant products that will soon be on the market this should be 430 addressed during the RFP process Appendix H also explains how to map clinical requirements to particular specification language For further discussion of the RFP process see Appendix C

114 Identifying Suitable Products

While you may choose to proceed directly to sending your RFP to a broad group of potential 435 vendors find out which vendors have products with relevant IHE integration capabilities by referring to public sources For a description of these sources see Appendix D

115 Reading Integration Statements from Vendors

An Integration Statements is a direct statement of which IHE profiles actors and options are supported by a particular product from a particular vendor For the contents of an Integration 440 Statement see Appendix D Vendors may respond to your RFP by providing an IHE Integration Statement document IHE Integration Statements are also available for many products at the IHE Product Registry

httpihenetIHE_Product_Registry The existence of an Integration Statement is a statement of conformance by the vendor and 445 should not presume that the vendor implementation of the IHE profiles actors and options has undergone IHE Connectathon verification testing

12 The Design Configuration and Implementation Process The following sections are intended for the design and implementation team They cover important clinical and IT considerations when planning to deploy a device or CIS with IHE 450

capabilities including dealing with ldquolegacyrdquo issues when connecting a device or CIS to systems that do not support IHE profiles

121 Considering Changes to Your Workflow

IHE Patient Care Device profiles are designed to transmit data or alerts in a streamlined clinical workflow For instance they eliminate the need to enter patient information at the device and 455 transcribing information into the electronic chart They also allow device data to be immediately available for viewing To gain the full benefit of these changes there are several tasks that need to be performed in the correct manner A current state assessment should be performed then a future state assessment and a gap analysis will help to identify significant changes that would be required For example a nurse may no longer need to manually record vital signs in a patientrsquos 460 chart but there may be additional tasks within the charting application that must be performed to properly document them One common task may be to confirm or accept the data that is provided

122 Confirming That Itrsquos Working

The following section provides guidance on how to confirm that the device is operating 465 according to the IHE profile implemented This section provides elements for testing an individual profile as it relates to the device Often there are other ways than the ones described to confirm the data and the transactionsmdashsee Appendix F

1221 Device Enterprise Communication (DEC)

12211 Device 470

For devices it is important that patient demographics be available to the device through a CIS Verify that the critical information is available for reviewing on the device and that information sent from device to the CIS is correct Confirm that the correct information is maintained by checking information associated with the orders The following is an example of the high-level list of tests that may need to be run on a new device with DEC 475

a Confirming the scenario Verify that the patient demographics including location information on the device match the CIS Compare the physiological parameters displayed on the device matches the data shown in the CIS Verify that data are being sent as programmed Verify that data are not lost when a break in communications occurs 480 For each of these areas detailed test sets need to be developed with the appropriate data sets For example when a device sends physiological data to the CIS the following types of items must be taken into account a What type of data can the device gather

b What types of data can the device send 485

c What types of data can the CIS receive

d How much data can be buffered in the event of a loss of connectivity

Develop tests that ask for the relevant fields (eg check all parameters for accuracy) b Verifying information Verify the information that this device can display and send

Develop tests to review all of the data and verify each of the DEC fields returned and 490 displayed on the device (patient name patient ID etc) Develop tests to review all of the resulting information which was generated from the device and used in the resulting HL7 messages out to the CIS For example check that the physiological parameters such as SPO2 heart rate blood pressures that are displayed in the CIS match those on the devices (with special attention to units of measure and nomenclature) 495

12212 CIS

It is important that the patient demographics and order information sent from the CIS are recorded correctly by the medical device This information along with additional patient demographics and order and procedural information must be correctly forwarded to the medical device so that the proper care is performed and reported on Likewise the data returned to the 500 CIS from the medical device is critical in providing the enterprise with appropriate information Confirming the CIS interoperability requires checks at several points in the process Confirm that the patient demographics have been received by the medical device Confirm the information sent from the medical device is available and accurate in the CIS The following are examples of the high-level list of tests that may need to be run on a new CIS 505 with DEC Some or all may be relevant to a specific enterprise These test scenarios are based on the use cases identified in Section 33 of Vol 1 of the IHE PCD TF Along with each scenario is a mechanism to verify that the test scenario is provided Note that in many cases there are multiple ways to confirm the data and the transactions Communicate patient data to CIS 510

1 Associate a patient to the medical device and begin sending both periodic (eg heart rate) and aperiodic data (eg NIBP) to the CIS Confirming the scenario Verify that the information displayed on the medical device matches the information displayed in the CIS with particular attention to value and units of measure Verify that these match Verify that the timestamps in the medical device and 515 the CIS are the same Review the transactions at the message level for conformance to the IHE TF specification

Communicate validated periodic data to CIS 1 Associate a patient to the medical device and send a set of validated periodic data from

the medical device to the CIS Note Some CIS systems or medical devices do not 520 support validated versus unvalidated data in which case this test should be skipped Confirming the scenario Verify that the information displayed on the medical device matches the information displayed in the CIS and that the data is represented as being verified Verify that the timestamps in the medical device and the CIS are the same Review the transactions at the message level for conformance to the IHE TF 525 specification

Subscribe to PCD data for patients from a specific location 1 Associate a patient to the medical device and send a subscription request from the CIS to

the medical device to retrieve the information for a specific location in the enterprise Confirming the scenario Verify that the information displayed on the medical device 530 matches the information displayed in the CIS Verify that the timestamps in the medical device and the CIS are the same Verify that only parameters from the requested subset of patients are sent Review the transactions at the message level for conformance to the IHE TF specification

1222 Alert Communication Management (ACM) 535

12221 Alert Reporter (AR) Actor

If a device supports the ACM Profile as an AM Actor and it has been configured to send Report Alert messages to an Alert Manager (AM) Actor then when an alert occurs in the device the device will output a Report Alert message to the AM Actor

12222 Alert Manager (AM) Actor 540

The AM Actor will receive the alert and map it to a destination endpoint communication device associated with an Alert Communicator (AC) Actor The AM will then send the alert notification text message to the AC Actor for disseminate by the AC Actor The AM Actor will likely expect to receive signaling from the AC Actor for delivery confirmation read receipt and endpoint communication device operator responses minimally accept and reject The AM Actor uses such 545 signaling to implement escalation of alert notifications to alternate alert notification destinations While the ACM Profile recognizes that an internally implemented escalation mechanism is best implemented within the AM Actor the manner in which such escalations are processed is left up to the AM Actor implementing vendor

12223 Alert Consumer (ACon) Actor 550

While the AM Actor has responsibility for mapping alerts to assigned endpoint communication devices and disseminating the alert notification to the associated AC there is often a need to maintain the alert status for active alerts The display of such information can be considered an active alerts dashboard The Alert Consumer (ACon) Actor was added to the ACM Profile to fill this role The ACon Actor has no further obligation than to receive alerts from AR Actors 555

12224 Alert Communicator (AC) Actor

The AC Actor will receive the alert notification text message and dispatch it to the destination endpoint communication device Depending upon whether or not the endpoint communication device supports one-way or two-way notifications the operator of the endpoint communication device can send responses back to the AC Actor which can then send them back to the AM 560 Actor and if supported then the AM Actor can close the loop and send the status of the disseminated alert back to the AR Actor

12225 Endpoint Communication Protocol

In order for the AM Actor to remain endpoint communication device type agnostic the protocol between the AM and AC Actors is defined in the ACM Profile to be the Wireless 565 Communication Transfer Protocol (WCTP) In order to support existing deployments of endpoint communication devices most commercially available AM Actor systems will support additional endpoint communication device proprietary protocols While this would not be conformant to the ACM Profile it is recognized as a deployment reality The deployed AM ndash AC Actors interface would hopefully support the ACM Profile defined advantageous signaling for delivery 570 confirmation read receipt and endpoint communication device operator responses minimally accept and reject Absent such signaling the AM Actor would be hard pressed to internally implement certain forms of alert notification escalation to alternate destinations

1223 Medical Equipment Management Device Management Communication (MEMDMC) 575

12231 Device Management Information Reporter (DMIR) Actor

If a device sends equipment status or configuration information to a CMMS independent of observations relating to a possibly associated patient then that device is a candidate for use of the MEMDMC Profile If a device is conformant to the profile as a DMIR Actor then when device events are triggered observations are send to the DMIC Actor Such messages can be any of the 580 following

bull Power on or change of power source identifying current power source (mains battery)

bull Battery charging status

bull Device self-test status

bull Device requires maintenance (cleaning calibration other) 585

12232 Device Management Information Consumer (DMIC) Actor

The DMIC Actor can use the reports from the DMIR Actor to identify devices not already in the CMMS inventory This helps the Clinical Engineering (CE) team maintain device inventory information If a device is no longer visible on the network after identifying that it has gone on battery 590 sourced power then it is likely that its battery is exhausted If there is a patient associated with the device when the battery goes low it is expected that this would result in an alert notification under the ACM Profile as immediate clinical assistance is required

1224 Medical Equipment Management Location Services (MEMLS)

12241 Location Observation Reporter (LOR) Actor 595

If a device or a person has been outfitted with a location reporting capability then it is the function of the LOR Actor to receive the information and communicate it to the LO Actor This allows the LOR Actor to maintain abstraction to the technology utilized in identifying the

location Multiple LOR Actor implementations can utilize different technologies and standard or proprietary technologies and communication the information in a standards based uniform 600 manner to the LOC Actor The reported observations are not constrained to only reporting location Contemporary reporting systems can also report environmental information (temperature pressure gasses etc) and operator interaction information (button presses tampers pulls falls etc) If an observation exceeds a boundary or limit or requires immediate response (panic button 605 falls) then it is better sent to an AM Actor as an alert notification

12242 Location Observation Consumer (LOC) Actor

The LOC Actor receives the location observations and can utilize that information for many purposes including active mapping of reported locations dashboards of environmental status etc 610 Another way in which vendor systems utilize consumed location information is to include that information in messages associated with other IHE PCD profiles such as DEC ACM or IPEC The location observation can be consumed filtered to only cache location for specific devices (brandtype) and then to include that information when communicating DEC ACM or IPEC observational messages 615

123 Considering Installation Issues

Even with IHE installation is not entirely ldquoplug amp playrdquo(yet)mdashthe systems are not self-configuring Required information such as HL7 interface IP address and ports must be coordinated between the medical device and the CIS There should be a pre-coordination of the parameters to be exchanged and the frequency of transactions The nomenclature and units of 620 measure will also have to be coordinated and verified between the CIS and medical devices in conjunction with the Rosetta Terminology Mapping tables Furthermore this step should be coordinated with clinical leadership and points of contact to ensure that flow sheets contain required and desired information for use in various enterprise clinical environments (eg specific parameters required for review during rounding in ICUs MedicalSurgical wards etc) 625 There are some compatibility issues that are outside the scope of the IHE TF that must be evaluated to ensure the proper workflow is safely maintained Some bar code medication administration (BCMA) systems will verify the patient once while all activities for that encounter occur while some require that the patient be bar-coded again for each interaction Some BCMA systems will assume functionality at the pump such as those implemented in 630 typical smart pumps To maintain a safe workflow implementers must understand the IHE TF and be able to recognize workflows that are outside the framework specification Functional testing of all feasible scenarios is critical

124 Identifying and Addressing ldquoLegacyrdquo Problems

IHE integration profiles are built assuming that all relevant systems support these profiles If 635 some systems do not support the profiles you have selected but do support the standards the profile is built on (for example HL7) some benefit is still possible If you have deficient

systems consider how to work around the deficiencies in the short term and when you plan to replace or upgrade those systems

1241 Connecting the IHE Device to a Non-IHE CIS 640

Interoperability between the CIS and a medical device enables the electronic flow of device physiological and operational parameters from the bedside to the medical record The same interoperability may still be available when connecting the IHE device to a non-IHE CIS based on the capabilities of the CIS The organization should request a current HL7 interface specification from your CIS vendor to determine how to integrate the IHE device with a non-IHE 645 CIS (See Appendices F and G) The following section provides brief guidelines to be followed when verifying IHE device and non-IHE CIS interoperability

In the DEC Profile the device outputs HL7 messages in a specific format with constraints beyond the normal HL7 specification (refer the TF) The following standards are utilized by the 650 IHE PCD DEC transactions

bull HL7 - Health Level 7 Version 26 Ch5 Query and CH7 Observation Reporting

bull ISOIEEE 11073-10201 Domain Information Model

bull ISOIEEE 11073-10101 Nomenclature If your CIS also supports these standards the next step is to confirm that critical attributes 655 provided in the messages by the device are acted on in the CIS A summary of the key identifying attributes defined by IHE to ensure information consistency throughout the acquisition workflow is found in the technical framework These attributes should also be reviewed with clinical and IT leadership within the enterprise to ensure clinical requirements are met For a complete mapping of the key attributes see the Patient Care Device TF Vol 2 660 Appendix B and Appendix C If your CIS does not act on any of these key attributes your vendor may have an option or upgrade to provide proper support for these attributes

Appendix A Developing an Integration Strategy Integration does not begin and end with the purchase of a single piece of equipment Integration involves all the systems in the department or enterprise contributing efficiently and intelligently 665 to the overall flow of work and information It is important to develop an overall departmental or enterprise strategy for integration Envision what the completed integration will look like and how it will work and consider what steps will lead you from where you are now to that destination This will help dictate what integration interfaces and capabilities your current purchase should support to play its part in the grand scheme 670 Information technology is a crucial component of an efficient workflow process The implementation of such a process usually requires purchasing new equipment or upgrading existing equipment IHE provides a useful vocabulary for writing the integration portions of purchasing specifications On rare occasions an opportunity arises to outfit a complete healthcare enterprise with all new 675 equipment In these situations while the flexibility this affords may facilitate a more completely integrated medical device and information technology environment challenges will still exist Usually however a complete or nearly complete suite of partially integrated information systems already exists and a pragmatic stepwise development and integration strategy is easier to manage and fund 680 In either case the planning method is the same Focus on integrating operational workflow processes Start by understanding the basic process flow and then include ldquotributariesrdquo and special cases Next identify the systems and transactions involved in those processes Then for each system involved in the process and already existing in the enterprise determine whether the product can be upgraded to implement the required transactions For existing product upgrades 685 or new products to be purchased include the requirement to implement the necessary IHE transactions in the purchasing specification There are two ways to specify the required transactions the hard way and the easy way The hard way is to understand each of the transactions defined in the IHE TF decide which specific transactions are required to meet the objectives of the current phase of the project and require in 690 the purchasing specification that the purchased product or upgrade implement those transactions The easy way is to systematically use IHE integration profiles and the detailed use case and solutions specified in these integration profiles which offer a smooth evolution path toward higher interoperability Systematic use of the IHE integration profiles will ease the burden of device integration but will 695 not eliminate all challenges A careful review of these profiles together with clinical engineering and care providers will be necessary during planning implementation and rollout to establish the best approach suited for a particular healthcare environment The IHE integration profiles and detailed use cases can greatly facilitate this and can serve as boilerplate for such discussions Unless you purchase all your equipment at once a single purchase will not achieve all the goals 700 but will typically result in incremental benefits immediately and the integration features will bear additional fruit as other components are added and integrated in the future As an example of a stepwise integration strategy in a hospital (which demonstrates that incremental benefits are possible) consider the following

Assume that at the start the situation in the hospital is such that there are some medical devices 705 connected to proprietary networks What IHE brings you in this situation is the vision blueprint and strategy for the quest toward the IHE The first simple and pragmatic step could be to have a few medical devices sending data to a clinical information system (CIS) IHE has a profile available for this step the DEC Profile which ensures the proper flow of physiological data to the CIS Clinical workflow is paramount 710 here The second step could be to introduce an electronic medication administration process IHE has a profile available for this step the PIV Profile which integrates the administration of IV medications using infusion pumps into systems that support the 5 Rights of Medication Administration 715

bull Right Patient

bull Right Drug

bull Right Dose

bull Right Route

bull Right Time 720 In summary with the IHE approach to enterprise integration one may expect a reduction of the hospitalrsquos integration costs which represent a significant portion of the hospitalrsquos total IT budget As a result more funding becomes available for healthcare-specific investments The reduction is caused by using standard protocols in products according to IHE specifications These products are tested at regular interconnectivity sessions (Connectathons) where most 725 healthcare vendors participate Reduced product prices can also be expected owing to the market dynamics of products based on open and mature standards IHE provides a proven and pragmatic roadmap for integrating existing IT systems within and among hospitals The roadmap covers new clinical domains such as Cardiology and Laboratory and the infrastructure for the patientrsquos Electronic Health Record and Clinical Pathways in a 730 Regional Health Information Network The user and iteration driven standardization process ensures that IHE specifications address real-world integration problems The IHE roadmap is divided into 1-year iterations where each iteration provides self-contained integration solutions The availability of IHE-compliant products from multiple vendors is ensured since IHE is 735 endorsed by a growing number of healthcare IT and device vendors As a result a hospital can choose from a large variety of available products to build best-of-breed IHE-based systems and reduce its dependencies on single vendors The interoperability among IHE products from different vendors is improved because of the detailed message description the validation of IHE implementations at multi-vendor testing sessions (Connectathons) and the publication of 740 Integration Statements describing specific IHE capabilities of a product

A1 Integration Approaches in IT Environments with Legacy Systems Interoperability between systems in IHE means that the systems use precisely defined interfaces for data exchange In addition essential system behavior on how to compose data to be exchanged or how to process data received in such an exchange is often defined This reduces 745 installation or configuration efforts and realizes communication of essential data in a defined quality In legacy systems that do not follow such integration mechanisms specific adaptation of existing interfaces may help to establish data exchange in a less comprehensive but potentially transitionally sufficient manner Therefore common legacy integration approaches are described 750 here that may be a viable step to connect non-IHE-capable equipment to IHE-capable machines to match integration needs at your institution In the ldquonon-IHErdquo integration scenarios described above the communicating systems provide at least the most important standards-based interfaces mainly IEEE 11073 HL7 v2x interfaces This should ease integration efforts because defined messages with a limited variability need to 755 be adapted The non-HL7 integration scenarios are based primarily on proprietary interfaces between communicating systems which may complicate the integration effort In these cases interface adaptation may work Interface adaptation or conversion can be a tedious but valuable effort Check relevant interfaces 760 including data structures content meanings and configuration options or variability on each side of the systems to be prepared for communication If the message types structures or contents do not match between sending and receiving systems (eg different message versions data differently structured different codes used) the receiving system cannot accept or understand the sent message A message conversion mechanism may solve this communication and integration 765 problem Depending on the purpose scope of the involved systems and your organization or equipment there are different approaches to interface adaptation

1 Individual mapping of interfaces (ldquomanual interfacingrdquo) The adaptation is done for this specific case and for the two communicating systems only Such a non-reusable ldquocustomrdquo solution can only be recommended for peripheral systems with specific usage in a limited 770 organizational scopemdasheg to realize data collection for research

2 Medical devices connect to a translator gateway In this case the gateway will translate the data coming from medical devices into HL7 messages Where such gateways exist medical device vendors should be consulted to supply user documentation to assist with the implementation of outbound and inbound messaging 775

3 General multipurpose high-throughput message adaptation system (ldquointerface enginerdquo) Such a system has highly configurable message conversion mechanisms often combined with different message distribution functionsmdasheg routing broadcasting It can connect many system types and is normally offered as a central service in an enterprise For instance a patient monitor may get ADT data via the interface engine from a registration 780 system

Implementing any of the above alternative approaches is subject to the costs benefits to the organization and must be determined by the stakeholders with the help of medical device

vendors A ldquoone size fits allrdquo approach usually does not work Therefore those implementing such systems should educate themselves as completely as possible in the capabilities of their 785 existing medical devices relative to interoperability and integration to determine what the true cost will be to the enterprise in achieving the intended goal

Appendix B Understanding IHE Integration Profiles

There are several sources of additional information for understanding the integration profiles depending on the depth you are interested in 790

B1 Integration Profile Summaries and Tutorials Presentations and documents providing summaries and tutorials on IHE and its profiles are available at wwwihenet Detailed descriptions of each profile are contained in Volume 1 of the IHE TF which contains a chapter dedicated to each profile outlining the problem solved the actors involved in the 795 solution and the associated transactions they use to interact If you wish to dig deeper explore the IHE TF documents Refer to the section below on reading the IHE TF

B2 Reading the IHE Technical Framework The complete IHE Technical Framework (TF) of each domain is available for download at httpihenetTechnical_Frameworks Each IHE domain publishes a separate TF however they 800 are compatible and interoperable In fact domains often make use of transactions and profiles from other domains and products often implement profiles from more than one domain When new profiles are first published their documentation status is Trial Implementation (TI) They are considered as Technical Framework Supplement documents Profiles whose documentation is at TI status may make use of interim nomenclature not yet normalized in a 805 standard This is to permit demonstration and verification testing Once a profile has been verification tested in multiple vendor implementations it would seek to have nomenclature normalized in a version of a released standard Once a profile has been judged stable and sufficiently verified to achieve Final Text (FT) documentation status the profile supplement document is merged into the next release of the 810 appropriate TF document A TF is structured in roughly the same way in each of the domains Vol 1 of the TF has a chapter for each integration profile It explains what problem the profile is intended to solve and then outlines a solution in terms of actors (the different roles to be played in the solution) and transactions (how the actors are required to communicate and behave) Vol 2 of the TF specifies 815 in detail how each transaction is performed This volume describes the use of the relevant standards in great detail It is essentially an implementation guide for the vendor engineers Technical staff at healthcare sites that wish to understand the operation of IHE in detail may also find it useful In some domains where the number of transactions is large Vol 2 is split into a Vol 2a 2b etc (or a Vol 3) Vol 4 of the TF when required includes any variations required to 820 meet the particular needs of individual countries These are referred to as National Extensions Since the goal of IHE is to serve common global needs Vol 4 is generally brief

B3 Rosetta Terminology Mapping The Patient Care Device Domain is working towards complete semantic interoperability of medical devices This means not only allowing devices to be able to speak to each other but 825

allowing them to understand each other This is also of benefit for retrospective analysis to examine and evaluate recorded information long after the point in time at which it was recorded The primary purpose of the Rosetta Terminology Mapping (RTM) Working Group within PCD is to harmonize the use of existing nomenclature terms defined by the ISOIEEE 11073-10101 nomenclature standard The RTM work also specifies the appropriate units-of-measure and 830 enumeration values for each communicated data item to facilitate safe and interoperable communication between devices and systems This vendor-neutral specification makes implementing and verifying PCD profiles quicker safer cheaper and more efficient by eliminating the process of custom mapping each device interfacersquos terms and units of measure The RTM WG effort has amassed a great many identifiers enumerations and units of measure 835 To automate the management of these values the National Institutes of Standards and Technology (NIST) a unit of the US Department of Commerce has established and maintains a freely accessible Internet based online system to maintain and to lookup the identifier enumeration and units of measure information It is the RTM Management Service or RTMMS located at httpsrtmmsnistgov 840

B4 Content Profiles The Patient Care Device Domain of IHE is further advancing the interoperability of medical devices by creating Content profiles within the Technical Framework Many use cases within the PCD domain can be accomplished by leveraging the existing actors and transactions of the DEC Profile The difference in most cases is the content within the messages and not the structure or 845 behavior of the message itself For example the content of an infusion pumprsquos communication to an EMR will look much different that the content of a physiological monitor These Content profiles will further constrain existing actors and transactions to facilitate interoperability

Appendix C Writing Integration Capabilities into an RFIRFP Integration profiles provide precise shorthand communication between purchasers and vendors 850 of medical equipment A purchaser can include a requirement for a particular actor within a particular profile and IHE provides several hundred pages documenting what the vendor needs to do to claim conformance to that requirement Referencing an actor within an IHE profile has the advantage of being both brief and precise When using IHE integration profiles to express your requirements you may want to reference the IHE Patient Care Device Technical 855 Framework and include a link to httpihenetTechnical_Frameworkspcd in your RFIRFP The simplification of using IHE leaves the details of the TF for the vendors to implement in their products You may want to specifically request that a prospective vendor provide an integration statement for applicable products either before or in response to the RFIRFP The format of the integration 860 statement should follow the template of an IHE integration Statement which can be found at httpswikiihenetindexphpStatements The existence of a vendor provided integration statement formatted per the IHE integration Statement template is not an assertion by IHE regarding the verification of the product to the indicated IHE profile and actor It is an assertion by the vendor that the product they are offering 865 to you can be verified as conformant to the actor role of the indicated profile The next step in verification that the prospect product is conformant to an indicated IHE profile and actor is that the vendor profile actor implementation has successfully passed a recent IHE Connectathon The successful participation by the vendor implementation in a Connectathon can be verified independent of the vendor at the IHE Connectathon Results site at 870 httpsconnectathon-resultsihenet RFI versus an RFP An RFI asks a vendor to describe their technology and how it would solve the requesting enterprisersquos integration and workflow challenges An RFP is a proposal of what the enterprise intends to accomplish and includes a project schedule budget and statement of need This 875 Appendix describes an RFI To make this RFI into an RFP the enterprisersquos timetable and budget should be added to the RFI Methodology for Ranking Vendors on Integration Integration is key for evaluating and ranking competing systems For each area of integration the buyer will need to determine their ldquoLIMitsrdquo Like to haves Intend to haves and Must haves For 880 each IHE integration profile identify the integration problem it solves for you and internally assign a rating of how important this integration is for you to accomplish successful implementation in your facility Use 1 for Like to haves 3 for Intend to haves and 5 for Must haves Perform this task internally and then decide if you want to share this prioritization of integration 885 features with your vendors For each integration profile provide a brief description of what you intend to accomplish through integration and ask how the vendorrsquos solution can solve that problem Rate the answers from the vendors on the following scale 0 points if they cannot perform that integration 1 point if they integrate through proprietary methodologies 3 points if

they integrate through standards such as HL7 but not according to IHE specifications 4 points if 890 they use IHE but not with all the options you want and 5 points if they integrate fully through IHE methodologies An evaluation of integration features might look like the following example for an electronic Medication Administration Record (eMAR)

Table C-1 Evaluation of Integration Features Example Integration Profile Problem Internal

Rating Vendor

Capability Rank

Integrating vendor independent multi-modality patient care device data to enterprise applications using consistent semantics

5 4 20

Point of Care Infusion Verification (PIV)

Electronic transmission of medication orders from a bedside medication administration system to a pump and documenting the administration parameters to the eMAR

5 3 15

Infusion Pump Event Communication (IPEC)

4 3 12

Alert Communication Management (ACM)

Communicating alerts (alarms both physiological and technical and advisories) from source systems to management systems and from management systems to communication systems

4 3 12

Medical Equipment Management Device Management Communication (MEMDMC)

Communicating medical device equipment management information to the Computerized Maintenance and Management System (CMMS)

Medical Equipment Management Location Services (MEMLS)

Communicating equipment and people location and tag related information to systems that need it

Total 73

895 Summing the total product of the all the ranks together with their respective vendor capability will provide an objective metric for the vendorrsquos ability to integrate to your individual needs The Language of the RFP For your Must-haves and perhaps your Intend-to-haves use ldquoshallrdquo terminology in your RFP as shown in the following examples Please also see Appendix H for further information on 900 mapping clinical requirements into specific purchasing specification language ldquoThe device shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Reporter (DOR) Actorrdquo ldquoThe gateway shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Filter (DOF) Actorrdquo 905

ldquoThe pump shall support the IHE Point-of-Care Infusion Verification (PIV) Integration Profile as the Infusion Order Consumer (IOC) Actorrdquo ldquoThe pump shall support the IHE Infusion Pump Event Communication (IPEC) Integration Profile as the Device Observation Reporter (DOR) Actorrdquo ldquoThe device shall support the IHE Alert Communication Management (ACM) Integration Profile 910 as the Alarm Reporter (AR) Actorrdquo ldquoThe Barcode Medication Administration system shall support the IHE Point-of-Care Infusion Verification (PIV) Integration Profile as the Infusion Order Provider (IOP) Actorrdquo ldquoThe CIS shall support the IHE Device Enterprise Communication (DEC) Integration Profile as the Device Observation Consumer (DOC) Actorrdquo 915 For your Like-to-haves and especially for newer integration profiles (MEMDMC MEMLS) vendors may not yet be able to comply with shall language as they may not currently offer that functionality in their product offering Decide how you will include promissory components of a contract negotiation to include future roadmaps You are putting unrealistic expectations on a vendor to deliver functionality if it is not incorporated in the contract 920 ldquoThe device shall support the IHE Medical Equipment Management Device Management Communication (MEMDMC) Integration Profile as a Device Management Information Reporter (DMIR) Actorrdquo ldquoThe CMMS shall support the IHE Medical Equipment Management Device Management Communication (MEMDMC) Integration Profile as a Device Management Information 925 Consumer (DMIC) Actorrdquo ldquoThe Location Services System (LSRTLS) shall support the IHE Medical Equipment Management Location Services (MEMLS) Integration Profile as a Location Observation Reporter (LOR) Actorrdquo Or if the location monitoring technology is embedded in a medical device then 930 ldquoThe device shall report location information by supporting the IHE Medical Equipment Management Location Services (MEMLS) Integration Profile as a Location Observation Reporter (LOR) Actorrdquo 935

Appendix D Identifying Suitable Products

There are several ways to find vendors and products involved in IHE

D1 IHE Connectathon Results IHE Connectathon results indicate which vendors are developing and successfully testing which integration profiles IHE Connectathons are annual testing events that vendors participate in on a 940 voluntary basis They allow vendors to test the IHE integration capabilities of their products with those of many other vendors in a structured and supervised environment The results indicate which vendors have demonstrated proficiency in implementing a given actor in a given profile The results do not list specific products or versions Vendors are not required to participate in the Connectathon to claim support for IHE in their products The Connectathon should not be 945 considered a certification of a vendor or product rather published results can be considered a useful litmus test When a vendor that has successfully tested a given profile at a Connectathon makes a direct claim that their product has implemented said profile you have some evidence they know what they are talking about For direct claims of conformance to IHE for a specific version of a specific product refer to the IHE Integration Statement published by the vendor 950 which is discussed in the next section IHE Connectathons are held each year in North America Europe and Asia Obtain Connectathon Results fromhttpsconnectathon-resultsihenet The PCD domain utilizes NIST test tools during the Connectathon for more rigorous testing of interface messages The results are generally laid out with a row for each vendor and a dot showing which actors in which profiles 955 the vendor was judged to have tested successfully at the Connectathon Success is judged by the Connectathon Project Management Staff who are independent technical experts hired by the sponsoring professional society (eg HIMSS RSNA ACCE) and Connectathon Monitors who are technically knowledgeable individuals hired by IHE who manage the test execution and examine and log the testing results They report to domain specific project managers Success 960 generally means a vendor successfully tests their product with products from at least three other vendors Profile options are currently not listed on the Connectathon results web site However the vendors do have the opportunity to test profile options at Connectathons If you require functionality that is specified in a profile option then ask the vendor if they tested that option at the Connectathon 965

D2 IHE Integration Statements IHE Integration Statements are declarations by vendors of support for specific IHE integration profiles in specific products Many vendors post product Integration Statements on their Web sites These are linked to a single index page at IHE Integration Statements Vendors who wish to have a link to their Integration Statements on this page can follow the instructions there for 970 submitting a request An Integration Statement is a claim made by the vendor to the consumer Vendors are not required to test the system in question at a Connectathon before publishing an Integration Statement See Appendix D for details on interpreting the contents of an Integration Statement 975

D3 Reading Integration Statements

IHE Integration Statements are simple statements (frequently a single page) of which IHE integration profiles are supported by a product and which IHE actor roles the system plays in 980 those profiles Vendors may publish Integration Statements on their Web sites or provide them in response to an RFP Herersquos an example

IHE Integration Statement

Vendor Product Name Version Date

Integrated Medical Systems

Alarms-A-Lot Central Station

17 Oct 2009

This product implements all transactions required in the IHE TF to support the IHE integration profiles actors and Options listed below

Integration Profiles Implemented Actors Implemented Options Implemented

Device Enterprise Communication Device Observation Reporter Device Observation Filter

MLLP WS

Alert Communication Management Alert Reporter none

Web address for vendorrsquos IHE information wwwintegratedmedicalsystemscomihe

Links to Standards Conformance Statements for Implementation

HL7 wwwintegratedmedicalsystemcomdevicesHL7

IHE at Integrated Medical Systems wwwintegratedmedicalsystemcomIHE

Links to general IHE information

In North America wwwihenet In Europe wwwihe-europeorg

The first part of the statement indicates that it applies to version 20 of the Alarms-A-Lot Central 985 Station from a vendor called Integrated Medical Systems and it was published on 17 Oct 2009 The middle part of the statement indicates that this Central Station supports the IHE Device Enterprise Communication Profile as the Device Observation Reporter Actor and it supports the MLLP Transport Option as well as the Device Observation Filter Actor It also supports the Patient Demographics Query Profile as a Patient Demographics Consumer Actor 990

Integration statements from a growing number of companies are included in the IHE Product Registry at httpproduct-registryihenet

D4 Verifying Integration Statements A vendor can claim conformance to IHE specifications without ever testing or verifying their product This is why it is important to leverage the Integration Statement only as an introduction 995 to discussing specific interoperability requirements For example you should first check the Connectathon results to see if the vendor has successfully completed testing at this venue If they have then you should also ask the vendor

1 What years did the vendor pass their Connectathons 2 What version of software was tested at the Connectathon 1000 3 What version of the domain specific Technical Frameworks does the product conform to 4 Was the commercially available product version that will be delivered tested at a

Connectathon

Appendix E Obtaining and Reading HL7 Interface Specifications

Purchasers should ask the vendor to provide an HL7 ldquointerface specificationrdquo that details the 1005 types of messages their system produces and accepts the fields in those messages when the messages are sent or expected and how the fields are filled Often HL7-based systems can be quite flexible and their HL7 interface behavior can be adapted to your needs Depending on the complexity of your needs you may want to hire someone experienced with these sorts of interfaces to help you in the process of evaluating and customizing your HL7 interfaces 1010 If your vendor asks you to provide some details on what you want their interface to do you may find it useful to provide the vendor with a pointer to the IHE TF and tell them which profile and actor roles you expect their system to fulfill While this does not address the full use to which you will put their system it will at least provide detailed specifications for part of the functionality 1015 The IHE TF serves as a basis to constrain the options and HL7 message structure In the Patient Care Device domain the TF makes use of the ISOIEEE 11073-10201 Domain Information Model standard and the ISOIEEE 11073-10101 Nomenclature standard These standards provide a framework for modeling the communication between medical device applications 1020

Appendix F Conducting Acceptance Testing

Sites are strongly encouraged to include Acceptance Testing as part of the implementation phase This requires developing an Acceptance Plan which includes the Acceptance Tests to be performed specification of what constitutes a pass or failure and some kind of a schedule Typically Acceptance Tests to be included in the plan are agreed on by the vendor and the 1025 customer Acceptance Tests can be developed once the systems to be integrated have been identified It is preferable to run the Acceptance Tests only after all of the physical systems are installed and properly connected to the network It may be possible to do Acceptance Tests on a subset of the systems but that may require additional analysis and test setup The development of the Acceptance Plan requires technical staff (consultants or internal 1030 development resources) Note that this Handbook deals only with Acceptance Testing of interoperability features and not all the other features provided by the individual systems Also the testing here focuses on functionality not on performance issues such as speed Once all of the IHE profiles actors and transactions involved in the installation have been identified a list of Acceptance Tests can be written for each of the systems involved Using Vol 1035 1 of the IHE TF a high-level list of transaction tests can be developed by reviewing the Table of ActorsTransactions for each of the relevant profiles Using Vols 2 and 3 (and 4 for country-specific changes) of the IHE TF (along with your project specifications and HL7 specifications) details of Acceptance Test data sets and expected results of running the tests can be developed Once all of the test specifications are brought together the test plan is developed The test plan 1040 should include the following components

bull What systems are required to perform the testing

bull Which tests should be executed

bull What data are required to perform the testing

bull How will the operation of the test be verified and which tools must be acquired to 1045 support verification testing

bull What are the goals of each test

bull Has sufficient time been allocated to develop these specifications Test System Suite The Test System Suite needs to include all of the systems that interconnect In some cases a separate test environment will need to be set up to ensure that the live 1050 environment is not impacted by testing In other cases the live environment may be used but the timing and the data used to test the system will need to be carefully thought through Development of Tests Test strategies will depend on which systems are being integrated Likewise confirmation of the results will depend on the capabilities of the systems being deployed and the workflow of the institution itself Note that if non-IHE systems are involved in 1055 the enterprise additional evaluation is needed to determine what the expected results should be since they may deviate from what would happen in a full IHE environment Some test specifics are listed in the Acceptance Testing section of each chapterscenario in this Handbook Additionally many of the profiles documented in Vol 1 of the TF include use cases

which detail variations addressed by IHE that you may want to include in your testsmdasheg 1060 unscheduled network interruptions many Device Observation Reporters sending data to one Device Observation Consumer multiple Device Observation Reports sending data to many Device Observation Reports Test Data Specific test data will depend on the use cases being tested and what data are relevant to the operations of the site The data should be representative of real cases and include complete 1065 sets of patient demographics and order and procedural information In some cases it may be necessary to have representative ldquosimulated resultsrdquo using device emulators that output the same values repeatedly An array of medical devices from several manufacturers with specific data fields may be required to fully test interoperability features Not all IHE use cases may be relevant to implementation for a given site For example a site 1070 may always construct their procedures so that there is only a single procedure step per requested procedure In this case IHE functionality dealing with multiple scheduled procedure steps is not relevant Test Tools Verification of results may require the use of tools and multiple systems For example HL7 tools the use of the medical device to display results or alternatively the use of an 1075 EMR to verify that the information within EMR contains the same data displayed on the medical device The following are classes of tools that may be used to verify results

bull HL7 Parsers Parse out the fields of HL7 messages and present the components in a more human-readable way

bull NIST Test Tools 1080 o ICSGenerator - tests implementations against the ISOIEEE 11073 set of standards o ValidatePDU - validates the basic syntax and structure of messages

bull HL7 v2 IHE-PCD Pre-Connectathon Test Tool ndash available at the NIST HL7 version 2 tools portal (httphl7v2toolsnistgovportaltools) ndash Supports vendor IHE-PCD Pre-Connectathon static HL7 V2 message verification according to the HL7 Standard IHE-1085 PCD Technical Framework and Supplement documents Harmonized Rosetta Terminology Mappings (hRTM) and test cases

bull MESA Tools As a part of the IHE testing process HIMSS and RSNA commissioned the development of a set of software tools by the Electronic Radiology Laboratory at the Mallinckrodt Institute of Radiology Washington University of St Louis They provide 1090 communication partners test data and test plans to allow vendors to perform baseline testing as they implement the IHE TF These tests are limited in scope but may be useful in the development of test plans (See httpihedocwustledumesasoftware)

In some cases it may be advantageous to use multiple tool sets to verify different system behaviors Your vendors may also provide tools to test their systems It should be noted that IHE 1095 does not promote specific vendor tools

Appendix G Performance Metrics Use of relevant performance metrics is extremely important to any process you intend to effectively manage and improve The workflow and other processes of a hospital are no different Selecting relevant metrics collecting measurements and responding to resulting 1100 feedback can make the difference between informed management and ad-hoc intervention Even considering what metrics to measure is a useful exercise in reflecting on your current priorities and goals and what they should be Diligently selecting measuring and tracking relevant metrics has proven to be easier said than done One argument in favor of IHE is that by facilitating the shift from paper to electronic 1105 workflow collecting many relevant values automatically is more practical than manually collecting measurements which disrupts and diverts the actual work (the Heisenberg Principle in action) When considering an integration project the time to start collecting metrics is now Metrics are particularly useful when planning changes Good metrics help with establishing a baseline 1110 measurement of your current practice making the case that there is room for improvement estimating the impact from the proposed process and technology changes tracking the potential initial disruption caused by the changes and the return to equilibrium and confirmingrevising the impact on the process and ultimately the success of the project Additionally metrics are useful for the healthcare industry at large as they deal with pressures to 1115 improve care reduce costs and effectively apply new technologies for those goals Sites that collect metrics are strongly encouraged to share results

G1 What to Measure Choosing what to measure and optimize can be a non-trivial task Systems and the people in them will adapt to optimize the chosen target sometimes using unexpected strategies that make 1120 undesirable sacrifices Although not all clinical benefits can be boiled down to a representative measurable value many can and metrics are a valuable way of establishing targets and measuring progress toward those targets Some values to consider are given below as a starting point Select metrics that reflect your priorities and your process Refer to the sources mentioned later in this section for more academic information 1125 Departmental Operational Metrics time to document physiological data Patient Experience Metrics code team response times Project Implementation Metrics time to specify systems and interfaces time to test integration and timemoney spent on custom interfaces

One approach to metrics is to record for each exam the time stamps at certain key 1130 milestonesprogress points in your process

Reimbursement patient demographics collected

With raw time stamps many time-related metrics can be calculated Specific milestones will depend on your institutionrsquos workflow The order of time stamps will likely vary at some 1135 institutions and some may vary between exams Some flexibility will be required Another source is your peers Ask about their goals and what they measure To find ldquobest in classrdquo hospitals consider winners of the annual HIMSS Davies Award of Excellence in healthcare IT

Appendix H Mapping Clinical Requirements to Purchasing 1140 Requirements

Introduction The purpose of this guidance document is to provide ldquodrop-inrdquo requirements that facilities can use to request conformance to IHErsquos standardized information transfer profiles in their purchasing documents such request for proposal (RFP) documents These requirements ask 1145 suppliers to spell out conformance to IHE PCD profiles actors transactions and nomenclature By including these requirements in an RFP a facility can assess how well a new device or information system under consideration will support a standards-based approach to information transfer This document is a living document and will be updated with additional device types and additional clinical requirements as time permits 1150

Structure and Nomenclature There are two main components to standards-based integration sending the right information in the right order (structure) and sending a message using terminology that both the sender and receiver can understand (nomenclature) Both structure and nomenclature are addressed by this document 1155 Structure is specified by supporting an IHE transaction which means that all the information deemed requiredmandatory in the message according to the IHE profile is populated (by the sending system) and usedpersisted (by the receiving system) This document includes tables and diagrams of clinical requirements organized by device type (eg infusion pump vital signs monitor) and will be added to as time permits The diagrams show the relationship between 1160 clinical workflow and IHE profiles when possible and also outline additional requirements that may be required such as terminology and nomenclature stipulations The tables map clinical requirements to specific RFP requirements based on IHE profiles Ideally the diagrams and tables will allow a purchaser to use the right IHE profiles to meet their required clinical objective For more information on specific IHE profiles please refer to the IHE PCD Technical 1165 Framework Structure only solves one part of integration a vendor could support an IHE profile (ie information is present and in the right order) but use terms that connected systems canrsquot understand requiring either the supplier or the facility to perform the translation To identify cases in which a system under consideration does not support standardized nomenclature and 1170 terminologies purchasers must ask suppliers to specify their level of terminology and nomenclature support when responding to an RFP To do this purchasers should copy the Technology and Nomenclature support levels in Table H-1 into their RFP introductory materials and then require this level to be stated on all RFP responses related to integration (eg ldquoCompliant Noncompliant If Compliant state Technology 1175 and Nomenclature Support Level (T0-T3) as defined in xxrdquo)

Table H-1 Terminology and Nomenclature Support Levels for RFP Use Terminology and Nomenclature support levels T0 No support for standardized terms (eg ad-hoc value sets configured at each client site) T1 Vendor-specific codes and value sets consistent across all clients and sites T2 A mix of vendor-specific and standard codes

Specify the code systems___________________________ T3 Standard codes only from the following standards

Specify the standard code systems____________________ T4 IHE PCD Rosetta Terminology Mapping (RTM) specified nomenclature and terminologies

Use Case 1 Infusion Pumps Selection Criteria 1180

Interoperability specifications like the IHE PCD Technical Framework support the automation of clinical tasks Therefore the need for interoperability can be linked directly to a PCD profile Consider a facility with the following clinical need

To automate the clinical task of entering the drug information into an infusion pump we need the medication order details (drug dose volume etc) to be sent from our Bedside 1185 Point of Care (BPOC) system to the pump sever that manages that pump

Figure H-1 illustrates that orders that travel from a Point-of-Care Medication System (BPOC) or to a pump server use an Order request represented by the PCD-03 message Row 3 of Table H-2 provides specific RFP language for both the BPOC system and the pump server to meet this clinical requirement 1190

Pharmacy

Infusion Pump

Pump Server

eMARDOC

Point-of-care Medication

IOPPDS

Report AlarmPCD-04

Alarm StatusPCD-05

SecondaryAlarm Manager

Disseminate Alarm

PCD-06

Alarm Status

PCD-07

Smartphone

Annunciator

Communication Device

Figure H-1 Infusion Pump Information Flow

Table H-2 Infusion Pump RFP Language 1195 I want this

vendor system

(Sender)

To send this information

(Requirements)

To another vendor system

(Receiver)

What is my RFP

language for the

sending system

What is my RFP

language for the

receiving system

What is the related

transaction

1 For All Systems below

Maintain consistent time based with the other systems on the LAN

Shall Support the CT as the TC

NA ITI-1 Maintain Time

2 Pump Server Drug information Pump NA NA None may be PCD-03 or proprietary

3 Pump Results and status Pump Server NA NA None may be PCD-01 or proprietary

4 Pump Server Drug delivery results recorded electronically

eMAR Shall support DEC as the DOR

Shall support DEC as the DOC

PCD-01

5 Point-of-care Medication (BPOC) or Pharmacy

Here are programming parameters for drug dose etc for the patient on this pump

Pump server Shall Support PIV as the IOP

Shall Support PIV as the IOC

PCD-03

6 Point-of-care Medication (BPOC)

Here is the patient ID and pump ID and drug ID that was scanned at the bedside

Pump server Shall Support the PIV as the IOP

PCD-03

7 CPOE BPOC or Pharmacy

An order was entered to start an infusion with these parameters

eMAR Shall Support the PIV as the IOP

PCD-03

8 Pump server An infusion with these parameters was started for this patient

PCD-01

9 Pump server Alarm notification- eg ldquosomethingrsquos wrong with this pumprdquo

Secondary alarm manager

Shall Support ACM as the AR

Shall Support ACM as the AM

PCD-04

10 Secondary alarm manager

Alarm status update- eg ldquonurse has cleared the alertrdquo

Pump server Shall Support ACM as the AM with the Report Alarm Status Option

Shall Support ACM as the AR with the Report Alarm Status Option

PCD-05

I want this vendor system

(Sender)

(Requirements)

(Receiver)

What is my RFP

language for the

sending system

What is my RFP

language for the

receiving system

What is the related

transaction

Alarm condition sent to a clinicianrsquos phone or pager

Communication Device (eg phone pager monitor annunciator)

Shall Support ACM as the AC

PCD-06

12 Communication Device (eg phone pager monitor annunciator)

PCD-07

13 HIS (if no bar code reader on the pump)

Patient identification (eg name medical record number)

Pump Server Shall Support ITI-030 as the PDS

Shall Support ITI-030 as the PDC

ITI-030

14 Bar Code Reader on pump

Patient ID is scanned directly into the pump

Use Case 2 Vital Signs Monitor (VSM) Interoperability Criteria Interoperability specifications like the IHE PCD Technical Framework support the automation of clinical tasks Therefore the need for interoperability can be linked directly to a PCD profile Consider a facility with the following clinical need

To automate the clinical task of entering patient vital signs into our electronic medical 1205 record we need to send patient vital sign results from the vital signs server to the EHR SYSTEM

Figure H-2 illustrates that vital signs that travel from a vital signs monitor server to an electronic health record system use the PCD-01 message and Row 2 of Table H-3 provides specific RFP language for both the EHR SYSTEM and the vital signs server to meet this clinical requirement 1210 Of course if the vital signs monitors itself is capable of transmitting information directly to an EHR SYSTEM the RFP language of Row 2 can be used for the monitor itself This same diagram and table can be substituted for nearly any medical device such as anesthesia systems ventilators beds or bedside physiological monitors 1215

Vital Signs Monitor (VSM)

VSM ServerVSM Server

HISHIS

EHREHRDOCPDS

ITI- 0

Report AlarmPCD-04

Alarm StatusPCD-05

Disseminate Alarm

PCD-06

Alarm Status

PCD-07

Smartphone

Annunciator

Note These interfaces could be built directly into the device

Figure H-2 Vital Signs Information Flow

Table H-3 Vital Signs Monitor RFP Language

I want this

vendor system

(Sender)

(Requirements)

(Receiver)

What is my RFP

language for the

sending system

What is my RFP

language for the

receiving system

What is the related

transaction

2 Vital Signs Monitor (VSM)

Patient vital sign results and status information

VSM Server None may be PCD-01 or proprietary

3 VSM server Vital Signs Results EHR System Shall Support PCD-01 as the DOR

Shall Support PCD-01 as the DOC

PCD-01

4 VSM server Alarm notification- eg ldquosomethingrsquos wrong with this monitorrdquo

Shall Support PCD-04 as the ACM AR

Shall Support PCD-04 as the ACM AM

PCD-04

VSM Server Shall Support PCD-05 as the ACM AM with the Report Alarm Status Option

Shall Support PCD-05 as the ACM AR with the Report Alarm Status Option

PCD-05

PCD-06

PCD-07

8 HIS Patient Identity traits including Patient ID

VSM Server Shall Support ITI-030 as the PDS

ITI-030

9 VSM Server Patient ID (eg from HIS)

VSM Shall Support ITI-030 as the PDS

ITI-030

Appendix I Deployment of Alert Communication Management 1225 solutions

Introduction Vendors that implement Alert Communication Management (ACM) Profile actors create a solution for the communication of alerts (physiologic alarms technical alarms and advisories) from medical devices and systems to the ever growing variety of communication devices 1230 associated with people

Common Solution for a Common Need Communication of alerts from devices and systems to people is a common need that is alerting device type and specific alert agnostic In healthcare institutions alert notification goes way beyond medical device physiologic alarms It extends beyond even device alerts to systems 1235 workflow advisory notifications and reminder notifications To avoid needing to deal with the delivery specific types of alerts to different types or instances of devices having to be carried by the same person a common solution needs to respond to common issues

bull To which recipients (people or devices) is a specific alert to be sent

bull What is the alert text to contain based upon correlated information from all available 1240 sources

bull Who are those recipients at this particular moment in time or shift (staff assignments)

bull To which communication device is this alert to be sent at this time (in office on floor)

bull What is the priority of the alert (immediately actionable or respond when less occupied)

bull What is the phase of the alert (start continuing escalated end) 1245

bull What is the status of the alerting device or system (audibly indicating)

bull What if that person doesnrsquot receive the notification canrsquot currently respond or is occupied

bull How is that response signaled such that escalation of the notification can take place

bull What is the communication protocol for the specific destination communication device 1250

Solution Best Suited for Each Role Which ACM Profile actor in their role is best suited to have access to the information to best answer each of these questions It is readily apparent that the source device currently in an alarming condition is not the one best suited to answer all of these questions The Alert Reporter Actor is best positioned to know the current state of the alert its phase and status However it 1255 simply doesnrsquot have access to sufficient information and the information it does have when initially configured may not be kept current in an automated fashion This makes the alert reporter not a good fit for maintaining the information needed to deal with staff assignments and escalations While a middleware alert management is best positioned and best suited to answer a

great many of these questions it is not the best role to answer all of them A few are best 1260 answered by an actor in a role that knows far more about the alert notification communication devices themselves This is the justification for the Alert Communication Management Profile being comprised of three actors the alert reporter the alert manager and the alert communicator each with specific role responsibilities The alert reporter is the actor that is the source of alerts and of knowing their current signaling 1265 status and the status of the alerting device or system The alert reporter may be the alerting (alarming) device itself or it may be a gateway system that maps the potentially proprietary alarm signal into the HL7 version 26 based common format used by the alert reporter to signal alerts to the alert manager The presumption is that in a hospital there may be many thousands of Alert Reporter Actors It is unrealistic to expect to keep this vast population of alert reporters 1270 current as to who is to receive what alerts on what communication devices from what sources at what times of the day and days of the week The alert reporter may not have access to care unit wide or hospital wide actively updated information which needs to be correlated and potentially included into the alert notification message It is also unrealistic for alert reporters to understand how to directly communicate with the ever growing variety of alert notification communication 1275 destination devices that exist today And it is also unrealistic for the Alert Reporter Actor to be configured to deal with all the details of assignment shifts and organizational hierarchies to execute alert notification escalations By moving all these action decisions to the Alert Manager and Alert Communicator Actors it offloads this burden from the configuration as well as the design of the alert reporter 1280 The alert manager is the alert notification communication middleware Being in the middle it is best suited to identify the recipients that are to get what alerts at what times The alert manager is likely to be tapped into multiple actively updated information flows (the ADT feed being just one of them active directory staff assignments and definitions might be another) that provide alert instance correlated information useful to include in the alert notification message The alert 1285 manager may also be statically configured to provide information not available from the alert reporter Being in the middle it has the opportunity to harmonize alert notification messages across vendors and device types or it can provide alert notification message information unique to a care unit Having access to all these information sources the alert manager is also well positioned to deal with alert escalation should the alert notification be undeliverable not read 1290 not responded to or rejected (if the recipient person is currently occupied) However the alert manager is likely not the best actor to understand all the remote device communication protocols and alert notification communication device user interface behavioral nuances needed to provide the common signaling for the indications of delivered to recipient or not message read or not and the various ways to accept or reject the received alert notification Therefore a message 1295 common signaling protocol is used between the alert manager and the alert communicator That protocol is Wireless Communication Transfer Protocol (WCTP) While historically associated with paging it is the most complete and contemporary protocol currently available for this purpose It utilizes hypertext transport protocol (HTTP) Extensible Markup Language (XML) for message data items and the protocol supports authentication and encryption in requests and 1300 responses WTCP also already supports all the required signaling mechanisms for delivery confirmation read receipt and user interface label to communicated response for operator signals such as accept and reject There are other protocols that utilize HTTP XML and are securable such as XMPP However they lack the signaling in a standardized form

The alert communicator abstracts from the alert manager the ever growing variety of endpoint 1305 communication device protocols and signaling mechanisms (secured SMS JabberExtensible Messaging and Presence Protocol or XMPP proprietary protocols legacy device protocols paging protocols secured e-mail etc) supporting the ever growing variety of endpoint communication device types (personal computers PBX phones proprietary Wi-Fi phones public wireless smartphones tablets communication apps smart watches and legacy one-way 1310 pagers etc) The WCTP based common communication and signaling between the alert manager and the alert communicator provides an endpoint device type and protocol agnostic mechanism for sending messages and for signaling delivery conformation read receipt and endpoint communication device operator responses such as accept and reject 1315 As the Alert Communication Management Profile matured it was realized that an additional actor was needed that of the Alert Consumer or ACon Actor This actor receives carbon copies of alert reports from the alert reporter community However the ACon has no responsibility for mapping people or communication device assignments communication to devices or people or notification escalations It is limited in its access to the complete picture of an alert and so is best 1320 suited to provide a dashboard of active alerts It receives the original alert report It receives phase updates on the alert It receives the indication when the alert has ended

Alert Retrospective Traceability The Alert Communication Management set of actors provide in the messaging sufficient information to implement end to end history of alerts from origination to completion and all the 1325 phases and signals in between The time of day in the messages is synchronized for all actors using the IHE Information Technology Infrastructure (ITI) domainrsquos Consistent Time (CT) Profile In the logs of the actors an alert can be followed from the alert reporter to the alert manager to the alert communicator with bridging identifiers and timestamps all along the way This information may be used in fatigue or workflow optimization analysis to assure that alerts 1330 are handled in a safe and efficient manner

Executive Summary

Contributors

How to Use this Handbook

Glossary

Table of Acronyms

1 Scenario Integrating Medical Devices into a CIS

11 The Planning and Purchasing Process

111 Selecting IHE Integration Profiles and Actors


113 Putting Integration Requirements in Your RFP



12 The Design Configuration and Implementation Process




12211 Device

12212 CIS

1222 Alert Communication Management (ACM)


12222 Alert Manager (AM) Actor

12223 Alert Consumer (ACon) Actor



1223 Medical Equipment Management Device Management Communication (MEMDMC)




12241 Location Observation Reporter (LOR) Actor




1241 Connecting the IHE Device to a Non-IHE CIS


Appendix A Developing an Integration Strategy

A1 Integration Approaches in IT Environments with Legacy Systems


B1 Integration Profile Summaries and Tutorials

B2 Reading the IHE Technical Framework

B3 Rosetta Terminology Mapping

B4 Content Profiles

Appendix C Writing Integration Capabilities into an RFIRFP

Table C-1 Evaluation of Integration Features Example


D1 IHE Connectathon Results

D2 IHE Integration Statements


D4 Verifying Integration Statements



Appendix G Performance Metrics

G1 What to Measure

Appendix H Mapping Clinical Requirements to Purchasing Requirements

Introduction

Structure and Nomenclature

Use Case 1 Infusion Pumps Selection Criteria

Use Case 2 Vital Signs Monitor (VSM) Interoperability Criteria

Table H-1 Terminology and Nomenclature Support Levels for RFP Use


Table H-2 Infusion Pump RFP Language



Appendix I Deployment of Alert Communication Management solutions

Introduction

Common Solution for a Common Need

Solution Best Suited for Each Role

Alert Retrospective Traceability

ltlt13 ASCII85EncodePages false13 AllowTransparency false13 AutoPositionEPSFiles true13 AutoRotatePages None13 Binding Left13 CalGrayProfile (Dot Gain 20)13 CalRGBProfile (sRGB IEC61966-21)13 CalCMYKProfile (US Web Coated 050SWOP051 v2)13 sRGBProfile (sRGB IEC61966-21)13 CannotEmbedFontPolicy Error13 CompatibilityLevel 1413 CompressObjects Tags13 CompressPages true13 ConvertImagesToIndexed true13 PassThroughJPEGImages true13 CreateJobTicket false13 DefaultRenderingIntent Default13 DetectBlends true13 DetectCurves 0000013 ColorConversionStrategy CMYK13 DoThumbnails false13 EmbedAllFonts true13 EmbedOpenType false13 ParseICCProfilesInComments true13 EmbedJobOptions true13 DSCReportingLevel 013 EmitDSCWarnings false13 EndPage -113 ImageMemory 104857613 LockDistillerParams false13 MaxSubsetPct 10013 Optimize true13 OPM 113 ParseDSCComments true13 ParseDSCCommentsForDocInfo true13 PreserveCopyPage true13 PreserveDICMYKValues true13 PreserveEPSInfo true13 PreserveFlatness true13 PreserveHalftoneInfo false13 PreserveOPIComments true13 PreserveOverprintSettings true13 StartPage 113 SubsetFonts true13 TransferFunctionInfo Apply13 UCRandBGInfo Preserve13 UsePrologue false13 ColorSettingsFile ()13 AlwaysEmbed [ true13 ]13 NeverEmbed [ true13 ]13 AntiAliasColorImages false13 CropColorImages true13 ColorImageMinResolution 30013 ColorImageMinResolutionPolicy OK13 DownsampleColorImages true13 ColorImageDownsampleType Bicubic13 ColorImageResolution 30013 ColorImageDepth -113 ColorImageMinDownsampleDepth 113 ColorImageDownsampleThreshold 15000013 EncodeColorImages true13 ColorImageFilter DCTEncode13 AutoFilterColorImages true13 ColorImageAutoFilterStrategy JPEG13 ColorACSImageDict ltlt13 QFactor 01513 HSamples [1 1 1 1] VSamples [1 1 1 1]13 gtgt13 ColorImageDict ltlt13 QFactor 01513 HSamples [1 1 1 1] VSamples [1 1 1 1]13 gtgt13 JPEG2000ColorACSImageDict ltlt13 TileWidth 25613 TileHeight 25613 Quality 3013 gtgt13 JPEG2000ColorImageDict ltlt13 TileWidth 25613 TileHeight 25613 Quality 3013 gtgt13 AntiAliasGrayImages false13 CropGrayImages true13 GrayImageMinResolution 30013 GrayImageMinResolutionPolicy OK13 DownsampleGrayImages true13 GrayImageDownsampleType Bicubic13 GrayImageResolution 30013 GrayImageDepth -113 GrayImageMinDownsampleDepth 213 GrayImageDownsampleThreshold 15000013 EncodeGrayImages true13 GrayImageFilter DCTEncode13 AutoFilterGrayImages true13 GrayImageAutoFilterStrategy JPEG13 GrayACSImageDict ltlt13 QFactor 01513 HSamples [1 1 1 1] VSamples [1 1 1 1]13 gtgt13 GrayImageDict ltlt13 QFactor 01513 HSamples [1 1 1 1] VSamples [1 1 1 1]13 gtgt13 JPEG2000GrayACSImageDict ltlt13 TileWidth 25613 TileHeight 25613 Quality 3013 gtgt13 JPEG2000GrayImageDict ltlt13 TileWidth 25613 TileHeight 25613 Quality 3013 gtgt13 AntiAliasMonoImages false13 CropMonoImages true13 MonoImageMinResolution 120013 MonoImageMinResolutionPolicy OK13 DownsampleMonoImages true13 MonoImageDownsampleType Bicubic13 MonoImageResolution 120013 MonoImageDepth -113 MonoImageDownsampleThreshold 15000013 EncodeMonoImages true13 MonoImageFilter CCITTFaxEncode13 MonoImageDict ltlt13 K -113 gtgt13 AllowPSXObjects false13 CheckCompliance [13 None13 ]13 PDFX1aCheck false13 PDFX3Check false13 PDFXCompliantPDFOnly false13 PDFXNoTrimBoxError true13 PDFXTrimBoxToMediaBoxOffset [13 00000013 00000013 00000013 00000013 ]13 PDFXSetBleedBoxToMediaBox true13 PDFXBleedBoxToTrimBoxOffset [13 00000013 00000013 00000013 00000013 ]13 PDFXOutputIntentProfile ()13 PDFXOutputConditionIdentifier ()13 PDFXOutputCondition ()13 PDFXRegistryName ()13 PDFXTrapped False1313 CreateJDFFile false13 Description ltlt13 ARA ltFEFF06270633062A062E062F0645002006470630064700200627064406250639062F0627062F0627062A002006440625064606340627062100200648062B062706260642002000410064006F00620065002000500044004600200645062A064806270641064206290020064406440637062806270639062900200641064A00200627064406450637062706280639002006300627062A0020062F0631062C0627062A002006270644062C0648062F0629002006270644063906270644064A0629061B0020064A06450643064600200641062A062D00200648062B0627062606420020005000440046002006270644064506460634062306290020062806270633062A062E062F062706450020004100630072006F0062006100740020064800410064006F006200650020005200650061006400650072002006250635062F0627063100200035002E0030002006480627064406250635062F062706310627062A0020062706440623062D062F062B002E0635062F0627063100200035002E0030002006480627064406250635062F062706310627062A0020062706440623062D062F062B002Egt13 BGR ltFEFF04180437043f043e043b043704320430043904420435002004420435043704380020043d0430044104420440043e0439043a0438002c00200437043000200434043000200441044a0437043404300432043004420435002000410064006f00620065002000500044004600200434043e043a0443043c0435043d04420438002c0020043c0430043a04410438043c0430043b043d043e0020043f044004380433043e04340435043d04380020043704300020043204380441043e043a043e043a0430044704350441044204320435043d0020043f04350447043004420020043704300020043f044004350434043f0435044704300442043d04300020043f043e04340433043e0442043e0432043a0430002e002000200421044a04370434043004340435043d043804420435002000500044004600200434043e043a0443043c0435043d044204380020043c043e0433043004420020043404300020044104350020043e0442043204300440044f0442002004410020004100630072006f00620061007400200438002000410064006f00620065002000520065006100640065007200200035002e00300020043800200441043b0435043404320430044904380020043204350440044104380438002egt13 CHS ltFEFF4f7f75288fd94e9b8bbe5b9a521b5efa7684002000410064006f006200650020005000440046002065876863900275284e8e9ad88d2891cf76845370524d53705237300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c676562535f00521b5efa768400200050004400460020658768633002gt13 CHT ltFEFF4f7f752890194e9b8a2d7f6e5efa7acb7684002000410064006f006200650020005000440046002065874ef69069752865bc9ad854c18cea76845370524d5370523786557406300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c4f86958b555f5df25efa7acb76840020005000440046002065874ef63002gt13 CZE ltFEFF005400610074006f0020006e006100730074006100760065006e00ed00200070006f0075017e0069006a007400650020006b0020007600790074007600e101590065006e00ed00200064006f006b0075006d0065006e0074016f002000410064006f006200650020005000440046002c0020006b00740065007200e90020007300650020006e0065006a006c00e90070006500200068006f006400ed002000700072006f0020006b00760061006c00690074006e00ed0020007400690073006b00200061002000700072006500700072006500730073002e002000200056007900740076006f01590065006e00e900200064006f006b0075006d0065006e007400790020005000440046002000620075006400650020006d006f017e006e00e90020006f007400650076015900ed007400200076002000700072006f006700720061006d0065006300680020004100630072006f00620061007400200061002000410064006f00620065002000520065006100640065007200200035002e0030002000610020006e006f0076011b006a016100ed00630068002egt13 DAN ltFEFF004200720075006700200069006e0064007300740069006c006c0069006e006700650072006e0065002000740069006c0020006100740020006f007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400650072002c0020006400650072002000620065006400730074002000650067006e006500720020007300690067002000740069006c002000700072006500700072006500730073002d007500640073006b007200690076006e0069006e00670020006100660020006800f8006a0020006b00760061006c0069007400650074002e0020004400650020006f007000720065007400740065006400650020005000440046002d0064006f006b0075006d0065006e0074006500720020006b0061006e002000e50062006e00650073002000690020004100630072006f00620061007400200065006c006c006500720020004100630072006f006200610074002000520065006100640065007200200035002e00300020006f00670020006e0079006500720065002egt13 DEU ltFEFF00560065007200770065006e00640065006e0020005300690065002000640069006500730065002000450069006e007300740065006c006c0075006e00670065006e0020007a0075006d002000450072007300740065006c006c0065006e00200076006f006e002000410064006f006200650020005000440046002d0044006f006b0075006d0065006e00740065006e002c00200076006f006e002000640065006e0065006e002000530069006500200068006f006300680077006500720074006900670065002000500072006500700072006500730073002d0044007200750063006b0065002000650072007a0065007500670065006e0020006d00f60063006800740065006e002e002000450072007300740065006c006c007400650020005000440046002d0044006f006b0075006d0065006e007400650020006b00f6006e006e0065006e0020006d006900740020004100630072006f00620061007400200075006e0064002000410064006f00620065002000520065006100640065007200200035002e00300020006f0064006500720020006800f600680065007200200067006500f600660066006e00650074002000770065007200640065006e002egt13 ESP ltFEFF005500740069006c0069006300650020006500730074006100200063006f006e0066006900670075007200610063006900f3006e0020007000610072006100200063007200650061007200200064006f00630075006d0065006e0074006f00730020005000440046002000640065002000410064006f0062006500200061006400650063007500610064006f00730020007000610072006100200069006d0070007200650073006900f3006e0020007000720065002d0065006400690074006f007200690061006c00200064006500200061006c00740061002000630061006c0069006400610064002e002000530065002000700075006500640065006e00200061006200720069007200200064006f00630075006d0065006e0074006f00730020005000440046002000630072006500610064006f007300200063006f006e0020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e003000200079002000760065007200730069006f006e0065007300200070006f00730074006500720069006f007200650073002egt13 ETI ltFEFF004b00610073007500740061006700650020006e0065006900640020007300e4007400740065006900640020006b00760061006c006900740065006500740073006500200074007200fc006b006900650065006c007300650020007000720069006e00740069006d0069007300650020006a0061006f006b007300200073006f00620069006c0069006b0065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740069006400650020006c006f006f006d006900730065006b0073002e00200020004c006f006f0064007500640020005000440046002d0064006f006b0075006d0065006e00740065002000730061006100740065002000610076006100640061002000700072006f006700720061006d006d006900640065006700610020004100630072006f0062006100740020006e0069006e0067002000410064006f00620065002000520065006100640065007200200035002e00300020006a00610020007500750065006d006100740065002000760065007200730069006f006f006e00690064006500670061002e000d000agt13 FRA ltFEFF005500740069006c006900730065007a00200063006500730020006f007000740069006f006e00730020006100660069006e00200064006500200063007200e900650072002000640065007300200064006f00630075006d0065006e00740073002000410064006f00620065002000500044004600200070006f0075007200200075006e00650020007100750061006c0069007400e90020006400270069006d007000720065007300730069006f006e00200070007200e9007000720065007300730065002e0020004c0065007300200064006f00630075006d0065006e00740073002000500044004600200063007200e900e90073002000700065007500760065006e0074002000ea0074007200650020006f007500760065007200740073002000640061006e00730020004100630072006f006200610074002c002000610069006e00730069002000710075002700410064006f00620065002000520065006100640065007200200035002e0030002000650074002000760065007200730069006f006e007300200075006c007400e90072006900650075007200650073002egt13 GRE ltFEFF03a703c103b703c303b903bc03bf03c003bf03b903ae03c303c403b5002003b103c503c403ad03c2002003c403b903c2002003c103c503b803bc03af03c303b503b903c2002003b303b903b1002003bd03b1002003b403b703bc03b903bf03c503c103b303ae03c303b503c403b5002003ad03b303b303c103b103c603b1002000410064006f006200650020005000440046002003c003bf03c5002003b503af03bd03b103b9002003ba03b103c42019002003b503be03bf03c703ae03bd002003ba03b103c403ac03bb03bb03b703bb03b1002003b303b903b1002003c003c103bf002d03b503ba03c403c503c003c903c403b903ba03ad03c2002003b503c103b303b103c303af03b503c2002003c503c803b703bb03ae03c2002003c003bf03b903cc03c403b703c403b103c2002e0020002003a403b10020005000440046002003ad03b303b303c103b103c603b1002003c003bf03c5002003ad03c703b503c403b5002003b403b703bc03b903bf03c503c103b303ae03c303b503b9002003bc03c003bf03c103bf03cd03bd002003bd03b1002003b103bd03bf03b903c703c403bf03cd03bd002003bc03b5002003c403bf0020004100630072006f006200610074002c002003c403bf002000410064006f00620065002000520065006100640065007200200035002e0030002003ba03b103b9002003bc03b503c403b103b303b503bd03ad03c303c403b503c103b503c2002003b503ba03b403cc03c303b503b903c2002egt13 HEB ltFEFF05D405E905EA05DE05E905D5002005D105D405D205D305E805D505EA002005D005DC05D4002005DB05D305D9002005DC05D905E605D505E8002005DE05E105DE05DB05D9002000410064006F006200650020005000440046002005D405DE05D505EA05D005DE05D905DD002005DC05D405D305E405E105EA002005E705D305DD002D05D305E405D505E1002005D005D905DB05D505EA05D905EA002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002E05D005DE05D905DD002005DC002D005000440046002F0058002D0033002C002005E205D905D905E005D5002005D105DE05D305E805D905DA002005DC05DE05E905EA05DE05E9002005E905DC0020004100630072006F006200610074002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002Egt13 HRV (Za stvaranje Adobe PDF dokumenata najpogodnijih za visokokvalitetni ispis prije tiskanja koristite ove postavke Stvoreni PDF dokumenti mogu se otvoriti Acrobat i Adobe Reader 50 i kasnijim verzijama)13 HUN ltFEFF004b0069007600e1006c00f30020006d0069006e0151007300e9006701710020006e0079006f006d00640061006900200065006c0151006b00e90073007a00ed007401510020006e0079006f006d00740061007400e100730068006f007a0020006c006500670069006e006b00e1006200620020006d0065006700660065006c0065006c0151002000410064006f00620065002000500044004600200064006f006b0075006d0065006e00740075006d006f006b0061007400200065007a0065006b006b0065006c0020006100200062006500e1006c006c00ed007400e10073006f006b006b0061006c0020006b00e90073007a00ed0074006800650074002e0020002000410020006c00e90074007200650068006f007a006f00740074002000500044004600200064006f006b0075006d0065006e00740075006d006f006b00200061007a0020004100630072006f006200610074002000e9007300200061007a002000410064006f00620065002000520065006100640065007200200035002e0030002c0020007600610067007900200061007a002000610074007400f3006c0020006b00e9007301510062006200690020007600650072007a006900f3006b006b0061006c0020006e00790069007400680061007400f3006b0020006d00650067002egt13 ITA ltFEFF005500740069006c0069007a007a006100720065002000710075006500730074006500200069006d0070006f007300740061007a0069006f006e00690020007000650072002000630072006500610072006500200064006f00630075006d0065006e00740069002000410064006f00620065002000500044004600200070006900f900200061006400610074007400690020006100200075006e00610020007000720065007300740061006d0070006100200064006900200061006c007400610020007100750061006c0069007400e0002e0020004900200064006f00630075006d0065006e007400690020005000440046002000630072006500610074006900200070006f00730073006f006e006f0020006500730073006500720065002000610070006500720074006900200063006f006e0020004100630072006f00620061007400200065002000410064006f00620065002000520065006100640065007200200035002e003000200065002000760065007200730069006f006e006900200073007500630063006500730073006900760065002egt13 JPN ltFEFF9ad854c18cea306a30d730ea30d730ec30b951fa529b7528002000410064006f0062006500200050004400460020658766f8306e4f5c6210306b4f7f75283057307e305930023053306e8a2d5b9a30674f5c62103055308c305f0020005000440046002030d530a130a430eb306f3001004100630072006f0062006100740020304a30883073002000410064006f00620065002000520065006100640065007200200035002e003000204ee5964d3067958b304f30533068304c3067304d307e305930023053306e8a2d5b9a306b306f30d530a930f330c8306e57cb30818fbc307f304c5fc59808306730593002gt13 KOR ltFEFFc7740020c124c815c7440020c0acc6a9d558c5ec0020ace0d488c9c80020c2dcd5d80020c778c1c4c5d00020ac00c7a50020c801d569d55c002000410064006f0062006500200050004400460020bb38c11cb97c0020c791c131d569b2c8b2e4002e0020c774b807ac8c0020c791c131b41c00200050004400460020bb38c11cb2940020004100630072006f0062006100740020bc0f002000410064006f00620065002000520065006100640065007200200035002e00300020c774c0c1c5d0c11c0020c5f40020c2180020c788c2b5b2c8b2e4002egt13 LTH ltFEFF004e006100750064006f006b0069007400650020016100690075006f007300200070006100720061006d006500740072007500730020006e006f0072011700640061006d00690020006b0075007200740069002000410064006f00620065002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b00750072006900650020006c0061006200690061007500730069006100690020007000720069007400610069006b007900740069002000610075006b01610074006f00730020006b006f006b007900620117007300200070006100720065006e006700740069006e00690061006d00200073007000610075007300640069006e0069006d00750069002e0020002000530075006b0075007200740069002000500044004600200064006f006b0075006d0065006e007400610069002000670061006c006900200062016b007400690020006100740069006400610072006f006d00690020004100630072006f006200610074002000690072002000410064006f00620065002000520065006100640065007200200035002e0030002000610072002000760117006c00650073006e0117006d00690073002000760065007200730069006a006f006d00690073002egt13 LVI ltFEFF0049007a006d0061006e0074006f006a00690065007400200161006f00730020006900650073007400610074012b006a0075006d00750073002c0020006c0061006900200076006500690064006f00740075002000410064006f00620065002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b006100730020006900720020012b00700061016100690020007000690065006d01130072006f00740069002000610075006700730074006100730020006b00760061006c0069007401010074006500730020007000690072006d007300690065007300700069006501610061006e006100730020006400720075006b00610069002e00200049007a0076006500690064006f006a006900650074002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b006f002000760061007200200061007400760113007200740020006100720020004100630072006f00620061007400200075006e002000410064006f00620065002000520065006100640065007200200035002e0030002c0020006b0101002000610072012b00200074006f0020006a00610075006e0101006b0101006d002000760065007200730069006a0101006d002egt13 NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken die zijn geoptimaliseerd voor prepress-afdrukken van hoge kwaliteit De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 50 en hoger)13 NOR ltFEFF004200720075006b00200064006900730073006500200069006e006e007300740069006c006c0069006e00670065006e0065002000740069006c002000e50020006f0070007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740065007200200073006f006d00200065007200200062006500730074002000650067006e0065007400200066006f00720020006600f80072007400720079006b006b0073007500740073006b00720069006600740020006100760020006800f800790020006b00760061006c0069007400650074002e0020005000440046002d0064006f006b0075006d0065006e00740065006e00650020006b0061006e002000e50070006e00650073002000690020004100630072006f00620061007400200065006c006c00650072002000410064006f00620065002000520065006100640065007200200035002e003000200065006c006c00650072002000730065006e006500720065002egt13 POL ltFEFF0055007300740061007700690065006e0069006100200064006f002000740077006f0072007a0065006e0069006100200064006f006b0075006d0065006e007400f300770020005000440046002000700072007a0065007a006e00610063007a006f006e00790063006800200064006f002000770079006400720075006b00f30077002000770020007700790073006f006b00690065006a0020006a0061006b006f015b00630069002e002000200044006f006b0075006d0065006e0074007900200050004400460020006d006f017c006e00610020006f007400770069006500720061010700200077002000700072006f006700720061006d006900650020004100630072006f00620061007400200069002000410064006f00620065002000520065006100640065007200200035002e0030002000690020006e006f00770073007a0079006d002egt13 PTB ltFEFF005500740069006c0069007a006500200065007300730061007300200063006f006e00660069006700750072006100e700f50065007300200064006500200066006f0072006d00610020006100200063007200690061007200200064006f00630075006d0065006e0074006f0073002000410064006f0062006500200050004400460020006d00610069007300200061006400650071007500610064006f00730020007000610072006100200070007200e9002d0069006d0070007200650073007300f50065007300200064006500200061006c007400610020007100750061006c00690064006100640065002e0020004f007300200064006f00630075006d0065006e0074006f00730020005000440046002000630072006900610064006f007300200070006f00640065006d0020007300650072002000610062006500720074006f007300200063006f006d0020006f0020004100630072006f006200610074002000650020006f002000410064006f00620065002000520065006100640065007200200035002e0030002000650020007600650072007300f50065007300200070006f00730074006500720069006f007200650073002egt13 RUM ltFEFF005500740069006c0069007a00610163006900200061006300650073007400650020007300650074010300720069002000700065006e007400720075002000610020006300720065006100200064006f00630075006d0065006e00740065002000410064006f006200650020005000440046002000610064006500630076006100740065002000700065006e0074007200750020007400690070010300720069007200650061002000700072006500700072006500730073002000640065002000630061006c006900740061007400650020007300750070006500720069006f006100720103002e002000200044006f00630075006d0065006e00740065006c00650020005000440046002000630072006500610074006500200070006f00740020006600690020006400650073006300680069007300650020006300750020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e00300020015f00690020007600650072007300690075006e0069006c006500200075006c0074006500720069006f006100720065002egt13 RUS ltFEFF04180441043f043e043b044c04370443043904420435002004340430043d043d044b04350020043d0430044104420440043e0439043a043800200434043b044f00200441043e043704340430043d0438044f00200434043e043a0443043c0435043d0442043e0432002000410064006f006200650020005000440046002c0020043c0430043a04410438043c0430043b044c043d043e0020043f043e04340445043e0434044f04490438044500200434043b044f00200432044b0441043e043a043e043a0430044704350441044204320435043d043d043e0433043e00200434043e043f0435044704300442043d043e0433043e00200432044b0432043e04340430002e002000200421043e043704340430043d043d044b04350020005000440046002d0434043e043a0443043c0435043d0442044b0020043c043e0436043d043e0020043e0442043a0440044b043204300442044c002004410020043f043e043c043e0449044c044e0020004100630072006f00620061007400200438002000410064006f00620065002000520065006100640065007200200035002e00300020043800200431043e043b043504350020043f043e04370434043d043804450020043204350440044104380439002egt13 SKY ltFEFF0054006900650074006f0020006e006100730074006100760065006e0069006100200070006f0075017e0069007400650020006e00610020007600790074007600e100720061006e0069006500200064006f006b0075006d0065006e0074006f0076002000410064006f006200650020005000440046002c0020006b0074006f007200e90020007300610020006e0061006a006c0065007001610069006500200068006f0064006900610020006e00610020006b00760061006c00690074006e00fa00200074006c0061010d00200061002000700072006500700072006500730073002e00200056007900740076006f00720065006e00e900200064006f006b0075006d0065006e007400790020005000440046002000620075006400650020006d006f017e006e00e90020006f00740076006f00720069016500200076002000700072006f006700720061006d006f006300680020004100630072006f00620061007400200061002000410064006f00620065002000520065006100640065007200200035002e0030002000610020006e006f0076016100ed00630068002egt13 SLV ltFEFF005400650020006e006100730074006100760069007400760065002000750070006f0072006100620069007400650020007a00610020007500730074007600610072006a0061006e006a006500200064006f006b0075006d0065006e0074006f0076002000410064006f006200650020005000440046002c0020006b006900200073006f0020006e0061006a007000720069006d00650072006e0065006a016100690020007a00610020006b0061006b006f0076006f00730074006e006f0020007400690073006b0061006e006a00650020007300200070007200690070007200610076006f0020006e00610020007400690073006b002e00200020005500730074007600610072006a0065006e006500200064006f006b0075006d0065006e0074006500200050004400460020006a00650020006d006f0067006f010d00650020006f0064007000720065007400690020007a0020004100630072006f00620061007400200069006e002000410064006f00620065002000520065006100640065007200200035002e003000200069006e0020006e006f00760065006a01610069006d002egt13 SUO ltFEFF004b00e40079007400e40020006e00e40069007400e4002000610073006500740075006b007300690061002c0020006b0075006e0020006c0075006f00740020006c00e400680069006e006e00e4002000760061006100740069007600610061006e0020007000610069006e006100740075006b00730065006e002000760061006c006d0069007300740065006c00750074007900f6006800f6006e00200073006f00700069007600690061002000410064006f0062006500200050004400460020002d0064006f006b0075006d0065006e007400740065006a0061002e0020004c0075006f0064007500740020005000440046002d0064006f006b0075006d0065006e00740069007400200076006f0069006400610061006e0020006100760061007400610020004100630072006f0062006100740069006c006c00610020006a0061002000410064006f00620065002000520065006100640065007200200035002e0030003a006c006c00610020006a006100200075007500640065006d006d0069006c006c0061002egt13 SVE ltFEFF0041006e007600e4006e00640020006400650020006800e4007200200069006e0073007400e4006c006c006e0069006e006700610072006e00610020006f006d002000640075002000760069006c006c00200073006b006100700061002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400200073006f006d002000e400720020006c00e4006d0070006c0069006700610020006600f60072002000700072006500700072006500730073002d007500740073006b00720069006600740020006d006500640020006800f600670020006b00760061006c0069007400650074002e002000200053006b006100700061006400650020005000440046002d0064006f006b0075006d0065006e00740020006b0061006e002000f600700070006e00610073002000690020004100630072006f0062006100740020006f00630068002000410064006f00620065002000520065006100640065007200200035002e00300020006f00630068002000730065006e006100720065002egt13 TUR ltFEFF005900fc006b00730065006b0020006b0061006c006900740065006c0069002000f6006e002000790061007a006401310072006d00610020006200610073006b013100730131006e006100200065006e0020006900790069002000750079006100620069006c006500630065006b002000410064006f006200650020005000440046002000620065006c00670065006c0065007200690020006f006c0075015f007400750072006d0061006b0020006900e70069006e00200062007500200061007900610072006c0061007201310020006b0075006c006c0061006e0131006e002e00200020004f006c0075015f0074007500720075006c0061006e0020005000440046002000620065006c00670065006c0065007200690020004100630072006f006200610074002000760065002000410064006f00620065002000520065006100640065007200200035002e003000200076006500200073006f006e0072006100730131006e00640061006b00690020007300fc007200fc006d006c00650072006c00650020006100e70131006c006100620069006c00690072002egt13 UKR ltFEFF04120438043a043e0440043804410442043e043204430439044204350020044604560020043f043004400430043c043504420440043800200434043b044f0020044104420432043e04400435043d043d044f00200434043e043a0443043c0435043d044204560432002000410064006f006200650020005000440046002c0020044f043a04560020043d04300439043a04400430044904350020043f045604340445043e0434044f0442044c00200434043b044f0020043204380441043e043a043e044f043a04560441043d043e0433043e0020043f0435044004350434043404400443043a043e0432043e0433043e0020043404400443043a0443002e00200020042104420432043e04400435043d045600200434043e043a0443043c0435043d0442043800200050004400460020043c043e0436043d04300020043204560434043a0440043804420438002004430020004100630072006f006200610074002004420430002000410064006f00620065002000520065006100640065007200200035002e0030002004300431043e0020043f04560437043d04560448043e04570020043204350440044104560457002egt13 ENU (Use these settings to create Adobe PDF documents best suited for high-quality prepress printing Created PDF documents can be opened with Acrobat and Adobe Reader 50 and later)13 gtgt13 Namespace [13 (Adobe)13 (Common)13 (10)13 ]13 OtherNamespaces [13 ltlt13 AsReaderSpreads false13 CropImagesToFrames true13 ErrorControl WarnAndContinue13 FlattenerIgnoreSpreadOverrides false13 IncludeGuidesGrids false13 IncludeNonPrinting false13 IncludeSlug false13 Namespace [13 (Adobe)13 (InDesign)13 (40)13 ]13 OmitPlacedBitmaps false13 OmitPlacedEPS false13 OmitPlacedPDF false13 SimulateOverprint Legacy13 gtgt13 ltlt13 AddBleedMarks false13 AddColorBars false13 AddCropMarks false13 AddPageInfo false13 AddRegMarks false13 ConvertColors ConvertToCMYK13 DestinationProfileName ()13 DestinationProfileSelector DocumentCMYK13 Downsample16BitImages true13 FlattenerPreset ltlt13 PresetSelector MediumResolution13 gtgt13 FormElements false13 GenerateStructure false13 IncludeBookmarks false13 IncludeHyperlinks false13 IncludeInteractive false13 IncludeLayers false13 IncludeProfiles false13 MultimediaHandling UseObjectSettings13 Namespace [13 (Adobe)13 (CreativeSuite)13 (20)13 ]13 PDFXOutputIntentProfileSelector DocumentCMYK13 PreserveEditing true13 UntaggedCMYKHandling LeaveUntagged13 UntaggedRGBHandling UseDocumentProfile13 UseDocumentBleed false13 gtgt13 ]13gtgt setdistillerparams13ltlt13 HWResolution [2400 2400]13 PageSize [612000 792000]13gtgt setpagedevice13