System Interfaces

Download Guide

Download the PDF guide to access the checklist of recommended practices for self assessment and a supporting worksheet to identify action steps to achieve those recommended practices.

The System Interfaces SAFER Guide identifies recommended safety practices intended to optimize the safety and safe use of system-to-system interfaces between EHR-related software applications. Many healthcare organizations are involved in planning, implementing, or maintaining enterprise- or community-wide clinical information systems that require integration.1 Such integration occurs most often via interfaces between software applications, often from different system developers. These interfaces send and receive information, enabling disparate systems to operate on the same data.

System interface projects are complex because they involve many stakeholders (e.g., clinicians, administrators, and information technologists) in various departments, often with differing agendas. Stakeholders must work with hardware devices and software applications that are developed independently, while integrating them flawlessly with complex clinical work processes. Well-designed and well-developed system interfaces enable reliable physical and logical connection of different systems. System interfaces require physical equipment (e.g., hardware such as plugs, cables, and cards), software that controls the data and information that is exchanged, and concepts (e.g., data protocols and controlled vocabularies) that control the interactions between systems. In addition to these technical issues, interfaces involve social and organizational factors, such as agreements to provide data in a consistent format and to use data to refer to concepts in a consistent manner (i.e., multiple systems must manage and coordinate any change to the meaning of a data item). Processes and preparations must be in place to ensure appropriate configuration and maintenance of interfaces.2 For example, a mapping error between the order entry system and the pharmacy can cause dispensing of the wrong drug.3 Similarly, researchers have identified errors in the transmission of free-text comment fields between the order entry application and the pharmacy system.4

Completing the self-assessment in the System Interfaces SAFER Guide requires the engagement of people both within and outside the organization (such as EHR technology developers). Because this guide is designed to help organizations prioritize interface-related safety concerns, including the meaning of the data in the EHR, clinician leadership in the organization should be engaged in assessing whether and how any particular recommended practice affects the organization's ability to deliver safe, high quality care. Collaboration between clinicians and staff members while completing the self-assessment in this guide will enable an accurate snapshot of the organization’s system interface status (in terms of safety), and even more importantly, should lead to a consensus about the organization's future path to optimize EHR-related safety and quality: setting priorities among the recommended practices not yet addressed, ensuring a plan is in place to maintain recommended practices already in place, dedicating the required resources to make necessary improvements, and working together to prevent and mitigate the highest priority interface-related safety risks introduced by the EHR.

1

The EHR supports and uses standardized protocols for exchanging data with other systems.5

More About This Practice

Rationale:

Standards, such as those developed by HL7, greatly simplify the establishment and maintenance of safe and effective interfaces between EHRs and external systems (e.g., ancillaries such as laboratory, radiology, or pharmacy), thereby reducing communication errors.

Examples:

  • At a minimum, the EHR satisfies ONCs’ certification requirements related to electronic exchange of information.
  • The EHR is capable of sending and receiving clinical and administrative data using HL7 version 2.x messages where the sending and receiving systems use the same version.
  • The EHR has 2-way, HL7 v 2.x-compatible interfaces to mission critical ancillary systems (at a minimum: pharmacy, laboratory, blood bank, and radiology).
  • The EHR is capable of generating, exporting, importing, and decoding clinical patient summary documents encoded in the Continuity of Care Document (CCD) standard.6 This includes procedures such as placing the correctly decoded clinical data into the proper location in the EHR, rather than just adding a human-readable version of the document to the patient’s list of free text reports.
  • If the organization has an “interface engine,” the hardware running this application is duplicated (i.e., operational backup hardware is installed).7
  • Both the sending and receiving side of the interfaces are documented in sufficient detail to allow both sides to validate the adequacy of the interface for use.8
  • The EHR has links to external clinical information reference resources using the HL7 InfoButton standard.9
  • When sending data across the Internet or other public networks, the EHR uses a secure, encrypted, transmission protocol (e.g., SSL - Secure Sockets Layer or TSL - Transport Layer Security) to ensure the data’s security while in transit (e.g., when sending a prescription to an outside pharmacy via Surescripts).

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff, Diagnostic services, Pharmacy

2

Established and up-to-date versions of operating systems, virus and malware protection software, application software, and interface protocols are used.

More About This Practice

Rationale:

Failure to stay up-to-date with the latest versions of software and interface protocols places the organization at risk of clinical and administrative data loss, corruption, or theft.

Examples:

  • The organization has policies and procedures to determine
    how soon version testing and implementation will occur
    after the release of new software.
  • The organization has employees or service providers
    responsible for monitoring and upgrading software and
    communication protocols as needed.
  • Operating systems, virus and malware protection software,
    application software, and interface protocols in use are
    supported by their suppliers.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

3

System-to-system interfaces support the standard clinical vocabularies used by the connected applications.

More About This Practice

Rationale:

Use of standard clinical vocabularies is essential to ensure semantic interoperability (i.e., consistent interpretation of the meaning of terms) between systems.

Examples:

  • The interface supports and encourages use of clinical vocabularies from ONC’s certification requirements, for example: RxNorm for medication names,10 SNOMED-CT for clinical problems,11 and LOINC for laboratory tests.12
  • A process is in place to ensure that standard clinical vocabularies are updated and consistent in all interfaced software applications.
  • Organizations evaluate interfaced software prior to purchase to ensure that it uses compatible versions of standard clinical vocabularies.

Suggested Sources of Input:

EHR developer, Health IT support staff

4

System-to-system interfaces are properly configured and tested to ensure that both coded and free-text data elements are transmitted without loss of or changes to information content.

More About This Practice

Rationale:

Maintaining a system-to-system interface within a rapidly evolving clinical information system environment is challenging, in part because many changes are required. Without the ability to implement and test these changes prior to go-live, and a consistent practice of doing so, patients would be placed at significantly increased risk of data loss, corruption, or theft. Failure to test system interface components is one of the leading causes of EHR-related patient safety events.13

Examples:

  • System-to-system interfaces are tested before going into production and after changes to hardware, software, or content (e.g., the allowable list of data elements to be exchanged) on either side of the interface.
  • Free text data fields accessible to clinical end users of one system are transferred intact (i.e., no changes or truncation of characters) to the other system.
  • The organization (or interface developer) should develop a reference or validation dataset that includes boundary cases (i.e., data that are slightly below, at, and slightly above key thresholds). These test data are run through the interface repeatedly after any change to the hardware or software on either end of the interface to document that the interface is continuing to work appropriately.

Suggested Sources of Input:

EHR developer, Health IT support staff

5

The intensity and the extent of interface testing is consistent with its complexity and with the importance of the accuracy, timeliness, and reliability of the data that traverses the interface.14

More About This Practice

Rationale:

While ideally everything should be carefully tested, the demands of testing must also be reasonable. The more important the data is to patient safety, the more interface testing should be conducted.

Examples:

  • When testing an interface, both anticipated and unanticipated types of data (e.g., text characters in a numeric field) and amounts of data should be used to ensure that the interface does not respond incorrectly in either case.
  • Organizations, through policies and/or job descriptions, address responsibility for evaluation of the intensity and extent of interface testing for all new software purchases or upgrades of systems that must be interfaced.
  • Organizations address the role of EHR technology developers in the testing of interfaces, and incorporate expectations in contractual and service obligations.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff, Diagnostic services, Pharmacy

6

At the time of any major system change or upgrade that affects an interface, the organization implements procedures to evaluate whether users (clinicians or administrators) on both sides of the interface correctly understand and use information that moves over the interface.15

More About This Practice

Rationale:

At the time of major system changes, social factors can interact with technical factors to create new risks. Information, even when correctly encoded and transmitted, can be misinterpreted because of differences in how users conceptualize their work.

Examples:

  • Testing uses a wide range of cases and scenarios including those where users of the external application or users in the external facility or service may interpret things differently (e.g., “day” may mean different things to a 24/7 facility and a 9-5 facility; and “home phone” means different things to a college campus clinic, a nursing home, an urban “safety net” community clinic, and a private physician practice).
  • When a new system is connected or integrated, testing includes looking for ways that correctly transmitted and coded information could nevertheless be misinterpreted. For example, in the first few weeks of using a newly integrated system, staff is designated to observe use of the software or to talk to users (in person or by phone) to confirm the receipt and intended interpretation and use of information and messages sent via the interface.16
  • Testing should include real-world, clinical scenarios of information exchange, such as: schedule an appointment; admit a patient; place an order; process order in ancillary lab; report results; record medication administration.

Suggested Sources of Input:

Clinicians, support staff, and/or clinical administration, EHR developer, Health IT support staff, Diagnostic services, Pharmacy

7

Changes to hardware or software on either side of the interface are tested before and monitored after go-live.

More About This Practice

Rationale:

Hardware and software updates are inevitable. If the new hardware or software is unable to handle the load of transactions or otherwise work as intended in the actual workplace, it may shut down or compromise data integrity.

Examples:

  • Upgrades to EHR and ancillary systems are supported by additional testing of the system-to-system interfaces involved.
  • The organization carries out "load testing" (e.g., run a large number of transactions through the interface in a short period of time), and "stress testing" (e.g., send erroneous random data through the interface to potentially induce unexpected outputs) to ensure that the system can handle the required load at peak times and when confronted with erroneous data.17

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

8

There is a hardware and software environment for interface testing that is physically separate from the live environment.

More About This Practice

Rationale:

EHRs and the many applications they must interface with are continually changing. System administrators and application developers need a "safe" place to develop and test these changes without fear of causing harm to patients.

Examples:

  • Changes to applications (or the content to be exchanged) on either side of the interface, or to the interface itself, are implemented and tested in the test/development environment before being put into production.
  • Develop and test batch processing jobs for applications and interfaces.
  • Regression testing (i.e., to ensure that all previous functionality is still working appropriately) is conducted in the test environment before changes are promoted to the production system.18

Suggested Sources of Input:

EHR developer, Health IT support staff

9

Policies and procedures describe how to stop and restart the exchange of data across the interface in an orderly manner.

More About This Practice

Rationale:

Failure to stop and restart an interface properly can result in "in transit" data being lost or corrupted without any warning to users.

Examples:

  • Ensure that all system interface buffers are empty prior to stopping or restarting the system.
  • If the interface must be disconnected while the sending system continues to produce data for transmission, e.g., lab tests ordered through CPOE, the buffers are of adequate size and behavior to prevent any loss of data.
  • The organization has a method of communicating to users when a clinical interface is not functioning properly (e.g., an alert on the login page, or a user-appropriate alert in the EHR whenever data retrieval or transmission is attempted but not completed).
  • Ensure reliable procedures are in place and used for stopping and starting system interfaces. The procedures are available and consulted during hardware/software upgrades.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

10

Security procedures, including role-based access, are established for managing and monitoring key designated aspects of interfaces and data exchange.9

More About This Practice

Rationale:

The integrity and confidentiality of data within applications must be well protected. When data moves between systems there is an increased risk of data loss, corruption, or theft. Both physical and logical security controls are required over this exchange of data to prevent unintended changes.

Examples:

  • The server hosting the interface hardware and software is maintained in a physically secure (i.e., locked room) location.
  • The server hosting the "interface engine" has a secure administrator login to prevent unauthorized changes to the interface configuration or access to the data as it crosses the interface.
  • System security is tested to ensure that unauthorized individuals or applications cannot alter or gain access to protected health information.
  • The security procedures identify and protect key designated aspects of the interfaces, including content mapping applications,19 the content maps themselves, error logs, and clinical data.

Suggested Sources of Input:

EHR developer, Health IT support staff

11

The organization has access to personnel with the skills required to configure, test, and manage all operational system-to-system interfaces.

More About This Practice

Rationale:

Configuring, testing, and managing system-to-system interfaces are complex tasks. The organization must ensure that only certified or qualified personnel are assigned to configure, test, and manage the system prior to go-live.

Examples:

  • Help desk operator manuals for quick reference are developed, readily available, and up-to-date.
  • Assigned personnel are trained on all system-to-system interface maintenance and monitoring activities, or have appropriate access to qualified personnel.
  • The organization identifies who is able to access help from the EHR developer and other external experts.
  • The organization has a plan for getting access to key individuals during off-hours (i.e., after routine business hours and on weekends and holidays).
  • Training or certification of personnel assigned to configure, test, and manage interfaces is reviewed on a regular basis, at least annually, to ensure staff is adequately trained and afforded the opportunity to update training.

Suggested Sources of Input:

EHR developer, Health IT support staff

12

Administrative, financial, and clinical data exchange needs are clearly documented and include how data will be used and who is responsible for maintaining the interface and the systems connected to it.20

More About This Practice

Rationale:

Failure to document the business needs and responsibilities for the interface can result in miscommunication regarding the meaning and timing of the exchange of information and lead to patient harm.

Examples:

  • All types of data to be exchanged via the interface are clearly specified including: allowable values (e.g., text vs. numeric, length or size of fields, etc.); clinical vocabularies used; and how associated values (i.e., metadata) will be communicated (e.g., representation of units on measurements, sources of data, etc.).
  • The interface is designed to handle the estimated mean and maximum amounts of data expected to cross the interface with acceptable performance and errors generated.
  • The organization maintains a comprehensive data dictionary that includes, for each data element:
    • Data type (e.g., coded, text, numeric)
    • Data definition
    • Metadata – (e.g., creator, date created, users)
  • The organization maintains a comprehensive interface data map that includes data recodes or conversions, as required.
  • The organization maintains a set of interface system performance requirements including the expected throughput of the system, uptime requirements, and protocols supported.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

13

The organization notifies people involved in maintenance or use of system interfaces when changes are made that affect the content of the standard data files or allowable values transmitted via the interface (e.g., the orderable catalog or charge master).

More About This Practice

Rationale:

EHR-related hardware and software change frequently. Failure to notify all parties involved in the maintenance or use of the system interfaces often results in interface errors. Some of these errors may be subtle and difficult to identify. Failure to account for and manage the changes can lead to serious patient safety events.

Examples:

  • Changes are clearly communicated and tested prior to go-live, including changes to: conversion programs, interfaces, databases, screens (e.g., length of data entry or display fields), tables (e.g., data interpretation, numeric values, times, dates, or text-based data fields), and vocabularies.
  • Documentation that appropriate testing has occurred after all system modifications is available.
  • There is a policy describing configuration control procedures that includes: who must be notified before any change is made, who can make the changes, who is responsible for testing the changes, who is responsible for approving the changes, and when the changes can be implemented in the live system.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

14

The operational status of the system interface is clear to its users with regard to clinical use, such as knowing when the interface cannot transmit or receive messages, alerts, or crucial information.

More About This Practice

Rationale:

Users must be notified when the interface between clinical systems is not functioning properly. Failure to distinguish between "there are no results" and "the interface to the system containing the results is not functioning" could lead to diagnostic or therapeutic delays.

Examples:

  • The user is informed when the interface cannot transmit a message.
  • The user is informed when the remote system from which they are requesting information is unavailable, due to errors in the interface or the remote system itself.
  • The user is notified when drug-allergy testing is performed on local medications only, excluding those identified by remote pharmacies or health information exchanges.
  • EHR applications that depend on system interfaces should report the interface status when in use (e.g., while reviewing imaging studies, the EHR shows the last update time or current connection with the PACS system).

Suggested Sources of Input:

EHR developer, Health IT support staff

15

The interface is able to transmit contextual information, such as units for measures or sources of information, to enable clinicians to properly interpret information.

More About This Practice

Rationale:

Failure to transmit the relevant metadata (i.e., context or details) related to the data, and necessary for its interpretation, can lead to misunderstandings and erroneous decisions.

Examples:

  • The interface can transmit the units for measurements
    along with the measurements, and the units are stored in
    structured data fields (e.g., 175 lbs. or 500 mg).
  • The interface can transmit information associated with
    a particular measure (e.g., fraction of inspired oxygen
    accompanies the arterial blood gas results to allow
    clinicians to interpret the blood gas values in the proper
    context).

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

16

Interface problems associated with known system interface risks and data field size limits are managed to avoid readily preventable errors.21

More About This Practice

Rationale:

Physical and logical interfaces have limitations. Failure to acknowledge and plan for these limitations often results in patient safety events.

Examples:

  • The sending system identifies and restricts messages that are not transmittable (e.g., incorrect data type).
  • The user is notified if what he or she is typing exceeds the maximum size for either the storage location or the system-to-system interface.22
  • The organization has a process for managing and minimizing known risks associated with interface problems, such as two systems with different field size limits. The system with the smaller limit can cause data to be truncated unless the risk is addressed properly.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

17

The organization monitors the performance and use of system interfaces regularly, including monitoring the interface error log and the volume of transactions over the interface.24

More About This Practice

Rationale:

System-to-system interfaces are complex and many of their actions are not directly visible. Extensive system monitoring is required to help identify and track hidden errors before they affect patients.

Examples:

  • The system-to-system interface error log is automatically monitored and all failed transactions are brought to the attention of the appropriate staff member, investigated, and fixed within one week.23
  • The number of transactions crossing the interface is monitored to ensure that the number of transactions is "normal" (e.g., displayed in a control chart showing the mean and reasonable upper and lower bounds, such as, 2 or 3 standard deviations from the mean).

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

18

When interface errors are detected, they are reported, fixed, and used to construct new test cases to improve the interface testing.

More About This Practice

Rationale:

Failure to fix interface errors in a timely manner can lead to patient harm or to loss of clinicians’ confidence in the data.

Examples:

  • After any interface error is detected and fixed, additional tests are added to the standard set of tests to check for the same error in future releases.

Suggested Sources of Input:

EHR developer, Health IT support staff, Diagnostic services, Pharmacy

{@Wednesday, February 26, 2014@}
{@Tuesday, February 25, 2014@}