Procuring Interoperability: Achieving High-Quality, Connected, and Person-Centered Care (2018)
Chapter: Technical Supplement - Section 3: Examples of Interoperability Specification Language
Technical Supplement—Section 3
EXAMPLES OF INTEROPERABILITY SPECIFICATION LANGUAGE
UPGRADE OF A LABORATORY INFORMATION SYSTEM (LIS)
This example addresses the need of a hospital to upgrade their laboratory information system (LIS). The specification language below pertains to required interoperability between the hospital’s legacy EHR system and the new LIS. Note that the RFP would typically include other specification statements not considered here, such as addressing the features, capabilities, and cybersecurity provisions of the system.
Under the guidance of the interoperability steering group, the procurement team begins the specification development process by reviewing the existing IHE Technical Frameworks (IHE, 2016). They find that the Laboratory Testing Workflow (LTW) integration profile in the IHE Pathology and Laboratory Medicine Technical Framework addresses the interface between the LIS and the EHR system, where the former is termed the order filler and the latter the order placer. The LTW profile identifies three pertinent information “transactions”: (1) lab orders from the EHR system to the LIS, (2) lab test results from the LIS to the EHR, and (3) order status from the LIS to the EHR system.
Next, the interoperability steering group facilitates the consultation of the ONC Interoperability Standards Advisory (ISA) to determine if the ISA addresses the information transactions above. The ISA recommends two HL7 2.5.1 Implementation Guides as best-of-breed for transactions (1) and (2). Confirming that the hospital EHR system is compliant with the guides, the LIS RFP references these implementation guides identified. Because the ONC ISA does not provide a recommendation for the interface for transaction 3 above, the interoperability steering group may advise referencing the IHE LTW profile directly in the RFP.
Sample RFP language follows.
Interoperability with the Legacy EHR:
The vendor’s LIS shall receive laboratory orders from a legacy EHR system that is compliant with the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 DSTU Release 2—US Realm.
The vendor’s LIS shall transmit laboratory results to a legacy EHR system in accordance with the HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm.
The vendor’s LIS shall transmit the status of laboratory orders to a legacy EHR in accordance with the IHE Pathology and Laboratory Medicine Technical Framework, Laboratory Testing Workflow Integration Profile, where the LIS has the role of the order filler. The vendor shall include implementation of the order filler actor option “Report Facsimile for Order Group.”
In the proposal, the vendor shall provide a statement of compliance to the requirements above that includes the specific LIS model and software version being proposed, the deployment date, specifics on how compliance was verified, and the evidence that the vendor or an independent certification agent can provide to support their compliance statement.
If the vendor’s LIS is not, or only partially, compliant, with the requirements above, the vendor shall specify which requirements their system can meet and the evidence the vendor can provide to support this. The vendor shall give specifics of future upgrades to their system that will increase compliance with the requirements above. The proposal evaluation criteria will give credit to proposals that have partial compliance and/or have definitive future plans for increased compliance.
Note that this example makes no mention of the EHR system being compliant with the IHE profile for receiving order status from the LIS. If the EHR system is not compliant, the hospital could contract the EHR vendor to update the EHR system to make it compliant, in conjunction with the new LIS procurement. In some cases, the hospital may also procure an open architecture interoperability layer (preferably not a middleware with proprietary interfaces) that connects the new LIS’s IHE compliant interface into a data exchange format that the EHR system can receive.
USE-CASE-DRIVEN INTEGRATION SCENARIO IN OBSTETRICS
An important interoperability use case at both the macro- and meso-tiers involves the passing of appropriate clinical information associated with a series of related
episodes of care from one specific care setting to another within the organization’s enterprise health information systems (e.g., the EHR).
For example, obstetrical patients will typically see a clinician (physician, nurse, midwife) in an ambulatory/office setting, deliver in a hospital or freestanding birthing center, and return for postpartum care in the clinical office setting afterward. Depending on the organization, that may take place both within and external to the enterprise health IT. Additionally, obstetrical patients may encounter illnesses, injuries, or complications of pregnancy while traveling outside the area of their usual care.
After the obstetrical care-use case is identified as a priority, the interoperability steering group may be tasked with including interoperability specifications in procurement contexts such as these:
- Upgrading of legacy Labor and Delivery niche EHR system
- Ensuring full (bidirectional) data liquidity and connectivity between the Labor and Delivery EHR system(s) and the Enterprise EHR
- Ensuring full data liquidity and connectivity between Labor and Delivery EHR and the enterprise quality reporting systems and registries
- Ensuring full data liquidity and connectivity between Labor and Delivery EHR systems and the pediatrician office EHRs for beginning the newborn EHR
The interoperability steering group consults the Integrating the Healthcare Enterprise (IHE) Antepartum and Labor and Delivery Profiles found in the IHE Patient Care Coordination (PCC) Technical Framework for specifying and implementing the interfaces associated with an interoperability middleware layer and/or an enterprise IT system such as the EHR.
The IHE library contains the following types of resources:
- Profiles—Organized sets of IHE actors and transactions to address specific patient care needs. Multiple IHE profiles may be implemented together to achieve more complex clinical workflows.
- Actors—Information systems or applications that produce, manage, or act on information in the context of an IHE profile. Each actor supports a specific set of IHE transactions. A given information system may support one or more IHE actors.
- Transactions—Exchanges of information between actors using messages based on established standards. Each transaction is defined with reference to a specific standard and additional detailed information.
Examples of procurement language follow.
For EHR system vendors (niche Labor and Delivery EHR or enterprise EHR systems):
The EHR system shall be upgraded to be compliant with the IHE Patient Care Coordination (PCC) Technical Framework Integration Profile Antepartum Summary (APS), where the EHR system has the role of the Content Consumer (APS) actor. The EHR system shall also be compliant with the Content Bindings with XDS, XDM, or XDR Integration Profiles in the IHE IT Infrastructure (ITI) Technical Framework, upon which various PCC profiles depend, and the EHR system has the role of the Content Consumer actor. The EHR system shall receive data from the Content Creator actor (originating Obstetrical EHR system) conforming to the IHE PCC APS profile and related obstetrical profiles (e.g., Antepartum Education [APE], Antepartum History and Physical [APHP] records, Antepartum Laboratory [APL], and Immunization Content [IC]). The EHR system shall also be required to support actor and transaction requirements in profiles bound to the aforementioned PCC profiles (e.g., Document Source actor in XDS).
The EHR system shall also be upgraded to be compliant with the IHE Patient Care Coordination (PCC) Technical Framework Integration Profile Labor and Delivery History and Physical (LDHP), and Labor and Delivery Summary (LDS), where the EHR system has the role of the Content Creator actor. The EHR system shall also be compliant with Content Bindings with XDS, XDM, or XDR Integration Profiles in the IHE IT Infrastructure Technical Framework, upon which various PCC profiles depend, and the EHR system has the role of the Content Creator actor. The EHR system shall send data to the Content Consumer actor (receiving ambulatory OB EHR system) conforming to the IHE PCC LDHP profile and LDS profile, and other related obstetrical profiles. The EHR system shall also be required to support actors and transaction requirements in profiles bound to the aforementioned PCC profiles (e.g., Document Source actor in XDS).
NEWBORN DISCHARGE SUMMARY
The EHR system shall also be upgraded to be compliant with the IHE Patient Care Coordination (PCC) Technical Framework Integration Profile Newborn Discharge Summary (NDS), where the hospital EHR system has the role of the Content Creator actor. The EHR system shall also be compliant with Content Bindings with XDS, XDM, or XDR Integration Profiles in the IHE IT Infrastructure Technical Framework, upon which various PCC profiles depend. The EHR system shall send
data to the Content Consumer actor (receiving ambulatory pediatric EHR system) conforming to the IHE PCC NDS profile and other related profiles. The EHR system shall also be required to support actors and transaction requirements in profiles bound to the aforementioned PCC profiles (e.g., Document Source actor in XDS).
POSTPARTUM VISIT SUMMARY
The EHR system shall also be upgraded to be compliant with the IHE Patient Care Coordination (PCC) Technical Framework Integration Profile Postpartum Visit Summary (PPVS), where the hospital EHR system has the role of the Content Creator actor. The EHR system shall also be compliant with Content Bindings with XDS, XDM, or XDR Integration Profiles in the IHE IT Infrastructure Technical Framework, upon which various PCC profiles depend. The hospital EHR system shall send data to the Content Consumer actor (receiving ambulatory OB EHR system) conforming to the IHE PCC PPVS profile and other related profiles. The EHR system shall also be required to support actors and transaction requirements in profiles bound to the aforementioned PCC profiles (e.g., Document Source actor in XDS).
INTEGRATION OF PATIENT CARE DEVICES WITH THE EHR SYSTEM
An important interoperability use case involves the passing of data from sensors and devices into the organization’s enterprise EHR system. This is in contrast to the practice of a nurse recording the device outputs on paper and manually entering them into a computer terminal—a practice that is inefficient and error prone.
In this example, suppose an organization identifies the need for a particular set of devices to pass data directly to the EHR system as part of a modernization initiative. In an earlier section, Figure A1-5 shows the configuration supportive of an open business model, where a number of devices connect to the EHR system through various adapters using industry-standard interfaces. The interoperability steering group oversees the modernization initiative through enhancing interoperability specifications in RFPs, which may include:
- upgrading the legacy EHR system,
- curating and implementing an open architecture interoperability platform layer, and
- purchasing new devices.
A number of different courses of action are possible to implement the open business model concept illustrated in Figure A1-5. A representative approach, one relying on open standards, draws on the ONC ISA, which recommends the Device Enterprise Communications (DEC) Integration Profile found in the IHE Patient Care Device (PCD) Technical Framework for implementing the interface between the Open Architecture Interoperability Layer and Health IT Systems depicted in Figure A1-5. In addition, the ONC ISA identifies the IEEE 11073 family of standards as the best-of-breed for “push communication of vital signs from medical devices.” The interoperability steering group consults the ONC ISA, which recommends the Device Enterprise Communications (DEC) integration profile found in the IHE Patient Care Device (PCD) Technical Framework for implementing the interface between an open architecture platform and the EHR. The ONC ISA identifies the IEEE 11073 family of standards as best-ofbreed for “push communication of vital signs from medical devices” (the Food and Drug Administration also endorsed IEEE 11073 standards).1
As a reminder, some related IHE terms are as follows:
- Transaction—a particular information exchange
- Actors—systems or components involved in an information exchange
- Dependent profile—Some IHE integration profiles (such as DEC) require support services described by another integration profile. For example, when specifying the DEC profile, one also needs to specify the Consistent Time (CT) profile.
In addition, the interoperability steering group consults online resources developed by the MD PnP program and develops the following example procurement language:
For the EHR system vendor:
The EHR system shall be upgraded to be compliant with the IHE Patient Care Device (PCD) Device Enterprise Communications (DEC) profile where the EHR system has the role of the Device Observation Consumer (DOC) actor. The
__________________
1 The National Committee for Clinician Laboratory Systems (NCCLS) issued a “Point of Care Testing” standard (POCT1-x) in 2001 and revised it in 2006. The purpose of this standard is to “allow users to integrate data seamlessly between hospital information systems and POC devices such as handheld glucose meters” (CAP Today, 2011). Adoption of this standard, however, is reportedly limited (CAP Today, 2011). Accordingly, for the illustrated example described here, we focus on the ONC guidance related to the IHE PCD Technical Framework.
EHR system shall also implement the Time Client actor in the Consistent Time (CT) Integration Profile found in the IHE IT Infrastructure Technical Framework. The EHR system shall accept messages from an IHE PCD DEC compliant Open Architecture Interoperability Platform serving as the Device Observation Reporter (DOR) actor. The EHR system shall receive, via the Open Architecture Interoperability Platform, data from the device types specified in Table 1 (not shown in this example).
For the Open Architecture Interoperability Platform suppliers:
The vendor shall provide an Open Architecture Interoperability Platform that conditions medical device data for input into the EHR system. The Open Architecture Interoperability Platform shall be compliant with the IHE Patient Care Device (PCD) Technical Framework Integration Profile Device Enterprise Communications (DEC) where the Open Architecture Interoperability Layer has the role of the Device Observation Reporter (DOR). The Open Architecture Interoperability Platform will implement the Time Client actor in the Consistent Time (CT) Integration Profile in the IHE IT Infrastructure Technical Framework. The Open Architecture Interoperability Layer shall interface with an IHE PCD DEC compliant EHR system serving as the Device Observation Consumer (DOC) actor.
The Open Architecture Interoperability Platform shall receive data from the device types and manufacturers listed in the enclosed table (not shown in this example). Open Architecture Interoperability Platform products that provide the option of communicating with the highlighted device types in Table 2 in compliance with IEEE 11073–20601 Optimized Exchange Protocol will be ranked higher as described in the proposal evaluation criteria [would be included elsewhere in the RFP].
Device Suppliers:
The vendor shall describe device products they can provide within the classes of devices specified in the enclosed table. For the device types highlighted in the table, products that communicate with an IHE PCD compliant Open Architecture Interoperability Platform having the role of the Device Observation Report (DOR) actor using a full implementation of the IEEE 11073 standard will receive higher ranking during the source selection process.2
__________________
2 The IHE PCD DEC Device Observation Reporter (DOR) uses HL7 V2.6 messaging, IEEE 11073 nomenclature and elements of the IEEE 11073 Domain Information Model (DIM). A significant and growing number of devices directly implement IHE, PCD, DEC, and AMC capability inside the device (personal communication, 2017) signaling wider adoption of the IHE approach.
Full IEEE 11073 implementation is defined here as compliance with IEEE 11073–10101, IEEE 11073–20601, and the appropriate device-specific standards IEEE 11073-104XX, where XX is the number corresponding to the device type. Full IEEE 11073 implementation also includes use of the Personal Connected Health Alliance design and interface guides. Devices that use adapters to convert nonstandard interfaces to be IEEE 11073 compliant are acceptable.
If devices do not fully comply with IEEE 11073, the vendor should specify the parts of the standard that their device(s) complies with. The supplier will identify evidence they can provide that supports their IEEE 11073 compliance assertions. Upon delivery of devices the vendor shall provide complete engineering documentation of the interfaces.
It is important to note that device vendors may indicate that they are compliant with the IEEE 11073 standard but, in reality, be compliant only with the nomenclature part of the standard (which is widely adopted). Open system solutions require compliance with all parts of the standard.
REQUEST FOR SPECIFIC FUNCTIONALITY AND INTEROPERABILITY CAPABILITIES OR REQUEST FOR INFORMATION
After the interoperability steering group identifies a specific medical device that can benefit from enhanced interoperability, it identifies sections of example RFP languages from the MD FIRE program (Box A1-4). Working closely with specific clinical departments seeking to replace their existing devices, the interoperability steering group helps customizing the following example RFP texts to request a complete description of specific functionality and interoperability capabilities from vendors. As noted by MD FIRE (MD FIRE Version 2.6, 2017), the actual content should be selected by the health care delivery organization as appropriate for their clinical, business, or technical requirements.
RFP Text Example 1: Request for specific functionality and interoperability capabilities
This text, excerpted from MD FIRE Version 2.6, 2017, may be used if the HCDO knows what interoperability capabilities it is seeking, what product functions support that interoperability, and which standards are to be implemented.
Current Interoperability Functionality by Specific Capability
Describe the extent to which the product conforms to the following requirements:
-
The product must have the following capabilities:
- Pulse oximeter sends % oxygen saturation and pulse rate data to other clinical systems in compliance with [IEEE 11073 Data Information Model].
- Pulse oximeter sends clinical and technical (equipment) alarms, and upper and lower oxygen saturation and pulse rate alarm settings to other clinical systems using standard [IEEE 11073 Data Information Model].
- Pulse oximeter interfaces with clinical systems and accepts data and control to set alarm limits [and averaging time and sensitivity mode].
Current Interoperability Functionality by Use Case
Describe the extent to which the product conforms to the following requirements:
-
The product must implement the HITSP Lab Results Reporting (EHR) Use Case, which is
- HITSP Interoperability Specification 1 (IS 01) Version 3.1, recognized 2009, as described at http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=44&PrefixAlpha=1&APrefix=IS&PrefixNumeric=01
-
The HITSP Lab Results Reporting (EHR) Use Case requires partial or complete compliance and implementation of the following standards:
- Health Level 7 (HL7) Versions 2.5 and 2.5.1
- HL7 Clinical Document Architecture (CDA) Release 2.0
- IETF RFC 2818: Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS)
- HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1
- HL7 Version 3.0 Privacy Consent–related specifications
- IETF RFC 1305: Network Time Protocol (Version 3)
- IHTSDO Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)
- Logical Observation Identifiers Names and Codes (LOINC)
- OASIS Security Assertion Markup Language (SAML) Version 2.0
- OASIS WS-Federation Version 1.1
- OASIS WS-Trust Version 1.3
- OASIS eXtensible Access Control Markup Language (XACML) Version 2.0
- Unified Code for Units of Measure (UCUM)
Future Interoperability Functionality by Use Case
Describe the extent to which the product conforms to the following requirements:
[By January 1, 2019, within 12 months of contract award] the product must implement the
-
HITSP Lab Results Reporting (EHR) Use Case, which is HITSP Interoperability Specification 1 (IS 01) Version 3.1, recognized 2009, as described at http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=44&PrefixAlpha=1&APrefix=IS&PrefixNumeric=01
-
- The HITSP Lab Results Reporting (EHR) Use Case requires partial or complete compliance with and implementation of the following standards:
- Health Level 7 (HL7) Versions 2.5 and 2.5.1
- HL7 Clinical Document Architecture (CDA) Release 2.0
- IETF RFC 2818: Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS)
- HL7 Version 3 Standard: Role Based Access Control (RBAC) Healthcare Permissions Catalog, Release 1
- HL7 Version 3.0 Privacy Consent related specifications
- IETF RFC 1305: Network Time Protocol (Version 3)
- IHTSDO Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)
- Logical Observation Identifiers Names and Codes (LOINC)
- OASIS Security Assertion Markup Language (SAML) Version 2.0
- OASIS WS-Federation Version 1.1
- OASIS WS-Trust Version 1.3
- OASIS eXtensible Access Control Markup Language (XACML) Version 2.0
- Unified Code for Units of Measure (UCUM)
-
RFP TEXT EXAMPLE 2: DESCRIPTION OF ALL CURRENT AND PLANNED INTEROPERABILITY
Capabilities and Related Functionality
Alternatively, the health care organization may wish to request in a Request for Information (RFI) a complete description of the product’s “current” interoperability capabilities, but not call for any particular function or standard. The below example provided from MD FIRE also includes language anticipating the possibility that a respondent will engage in product development to satisfy the requirements of the health care delivery organization.
Please include in the RFI response the approach and plans for interoperability of your product(s), specifically:
- all interoperable interface standards, technology standards, terminology standards, communication standards, and design guidelines that the products will implement and
comply with (including but not limited to USB, WiFi, ZigBee, Bluetooth, HL7, and Continua Design Guidelines).
For each standard and guideline, describe:
- the current and proposed scope of compliance with each standard and guideline, including but not limited to the exact specifications and guideline versions;
- a description of the current and proposed product functions that are interoperable and supported by the standards and guidelines; and
- an estimate of the [not to exceed, time and materials] cost and schedule to implement the proposed capabilities and standards listed above. If updates or compliance are included in the regular maintenance agreement, please describe those terms.
The following clause would be inserted only if the health care organization intends to fund some or all of the company’s product development work that is necessary to meet actual contract or RFP requirements.
- Describe your process for demonstration, acceptance testing, and certification and validation of the product’s interoperability for the standards listed above. If you propose to provide independent validation and verification of capability, the full price of that effort should be described.
- Describe your processes for product maintenance and upgrades to accommodate new interface technology, new interface standards, updated interface standards, or new product functionality.
MODULAR OPEN SYSTEMS ARCHITECTURE LANGUAGE
Interoperability steering groups and procurement teams within health care organizations and networks may find the DoD Open Systems Architecture Contract Guidebook for Program Managers, v1.1 (DoD Open Systems Architecture Data Rights Team, 2013) useful in developing procurement strategies and contract languages. The guidebook includes the following items that procurement teams can tailor for their respective “open systems” declaration statements and general vendor guidance:
Modular Open Systems Architecture—highlights the need for contractors to describe their approach to modularization of their product and emphasizes the need for these modules to be of a size that supports competitive acquisition as well as reuse.
Technology Insertion—highlights the importance of the contractor’s use of an architectural approach supportive of the rapid and affordable insertion and refreshment of technology through modular design, the use of open standards, and open interfaces.
Interface Design and Management—outlines the level of detail needed related to the description of interfaces between all components and systems, including but not limited to mechanical, electrical (power and signal wiring), software, firmware, and hardware interface specifications.
Treatment of Proprietary or Vendor-Unique Elements—emphasizes the importance of requiring the contractor to (a) explain the use of proprietary, vendor-unique, or closed components or interfaces and (b) identify and justify proprietary, vendor-unique, or closed interfaces, code modules, hardware, firmware, or software to be used. Further, the guidebook underscores the importance of requiring the contractor to demonstrate that proprietary elements do not preclude or hinder other component or module developers from interfacing with or otherwise developing, replacing, or upgrading open parts of the system.
Open Business Practices—highlights the importance of describing how modularity of the system design promotes the identification of multiple sources of supply and/or repair, and supports flexible business strategies that enhance subcontractor competition.
Use of Standards—prioritizes the order of importance of standards based on the nature of those standards (descending importance):
- standards as specified within the contract’s commercial standards;
- standards developed by international or national industry standards bodies that have been widely adopted by industry;
- standards adopted by industry consensus-based standards bodies and widely adopted in the marketplace; and
- de facto standards (those widely adopted and supported in the marketplace).
