and commercially developed health care systems and devices there is no single overarching authority or government entity that coordinates, controls, and funds the comprehensive changes required to achieve interoperability across the entire health care system. The government plays an important role in portions of the landscape, establishing guidance, policy, regulations, and funding development of interoperability enablers such as health data exchange standards. Even so, the hard work and resources needed for success falls to enlightened hospital executives and staff, forward-thinking health care system and device suppliers, and many others as part of a coalition of the willing.

There are no effortless solutions to achieving interoperability. Long-term vision, leadership commitment, a technical knowledgebase, and, perhaps most of all, persistence will be required for a health care organization to make progress. At the same time, numerous organizations have made great strides in the field of interoperability, which can be used to both make the individual hospital’s task easier and move the industry forward. Figure A1-1 shows the common foundation from which each hospital can build their procurement strategy. That foundation comprises work done by organizations such as the Office of the National Coordinator for Health IT (ONC), the National Institute of Standards and Technology (NIST), Integrating the Healthcare Enterprise (IHE), Health Level Seven International (HL7), Institute of Electrical and Electronics Engineers (IEEE), the Center for Medical Interoperability (CMI), and others.

• Oversee the translation and customization of shared or open-source platforms or interoperability profiles to unique local contexts;
• Set performance metrics on progress over time and consistently measure them; and
• Represent the organization in external consortium efforts to promote information sharing, consensus building, and the establishment of common resources.

LONG-RANGE INTEROPERABILITY ROAD MAP

As described in earlier sections of this publication, health care organizations should have a multiyear procurement strategy, and this plan should include a road map that sets the vision for improving interoperability and system openness within the organization. The long-range interoperability road map provides guideposts for planned adjustment and/or transformation in the procurement practice that, over time, aims to move the organization closer to the vision.

This road map should be a living document based upon the best available information, adapting to both internal and external changes that influence procurement priorities of the organization. The interoperability steering group will develop the road map through engagements with stakeholders to understand their interoperability needs and identify opportunities to improve workflow and outcomes. To maintain visibility, focus, and relevance, the interoperability steering group should communicate the road map within the health care organization and continuously seeking feedback toward procuring interoperable solutions. Along with the organization’s multiyear procurement plan, the road map should be updated at least annually to keep pace with technological developments in the field as well as evolving organizational needs.

INTEROPERABILITY NEEDS IDENTIFICATION PROCESS

The interoperability steering group should engage their organization’s health care system stakeholders at least annually to identify needs and opportunities for making systems more interoperable and open, and subsequently to reflect them in updates of the interoperability road map. Note that this is more than a simple polling process. A single hospital unit includes many interactions between technology and staff; an entire hospital multiplies the number of interactions enormously. Comprehending and tracking all these interwoven and interdependent interactions can be daunting, yet understanding these relationships is essential to identifying interoperability needs and opportunities that drive a procurement

strategy. Because of this complexity, it is not likely that stakeholders will simply submit their respective lists of interoperability requirements; rather, the interoperability steering group must lead the stakeholders through a series of methodical design development exercises from which these needs can be distilled.

The field of engineering offers many diagramming tools that may help organizations grapple with their respective interoperability challenges. These tools include diagrams such as flowcharts, block diagrams, and technical illustrations such as the family of diagrams defined by Unified Modeling Language (Object Management Group Unified Modeling Language, 2017) or SysML (Object Management Group Systems Modeling Language, 2017). One of the tools routinely used by systems engineers in industries such as space and military system development is the N-squared diagram (Figure A1-2, and Technical Appendix Section B). It is a technique used to document complex interactions among hardware or software systems (NASA, 2007), and it can afford health care the same benefits.

For example, the interoperability steering group can work with relevant stakeholders within the organization to develop an N-squared diagram of a care unit such as an intensive care unit (ICU).

At the start, the table shown in Figure A1-2 would have all blank fields. The first step is entering the diagonal elements. These represent the entities (technologies, equipment, and people) that currently interact in the unit. The nondiagonal elements represent the interactions (including data exchange) between the various diagonal elements. By convention, any output of a diagonal element is identified in the row containing that element (shown by the green arrow). Any input of a diagonal element is represented in the column containing that element (shown by the blue arrow). Although there is no constraint on the type of interactions captured, a typical first step is to capture all manual (verbal and written) and electronic data transactions.

The process of developing the diagram motivates important discussions with stakeholders, including the following:

• Which processes currently rely most heavily on manual entry by staff, especially physicians and nurses?
• Which manually entered data fields have the greatest influence on care decisions and patient outcomes?
• Can any recurring data field (e.g., body weight, blood pressure, known allergies) be automated, thus minimizing manual entry or copying/pasting?
• Based on the nature of the data field, what is the level of data security and privacy protection needed?
• What are clinicians’ needs for data accessibility, timeliness, and refresh rates?

• Do the data fields need to be shared with other clinical or administrative departments and/or external entities?
• What is the estimated staff time and resource cost of manual data exchange?

Once the diagram is populated, the layout of the information can reveal interoperability needs and opportunities that were not previously obvious. Lining up interoperability needs highlighted in the diagram with the organization’s priorities informs the development of the Interoperability Road Map included in the organization’s multiyear procurement plan (Section 1). Technical Supplement Section 2 demonstrates the development of an N-squared diagram for an endoscopy suite as a representative example of how to use this tool.

INTEROPERABILITY PROCUREMENT SPECIFICATION PROCESS

As described earlier, a particular need for interoperability involves the exchange of digital information among health care technologies. To acquire open system solutions, the health care organization must require the supplier to implement the interface between the technologies according to industry-accepted health data exchange standards. As of 2017, commonly used standards include the HL7 standards for exchange between health information systems, the IEEE 11073 standards for patient care devices, the SNOMED-CT medical diagnosis codes, the RxNORM medication codes, LOINC for laboratory and other observation identifiers, and a host of other notable health care-related standards.

a modular open system architecture is more likely to provide the basis for modular upgrades or new integration profiles.

• Require vendor to describe methods and results of compliance testing. The health care organization’s proposal evaluation criteria should reward vendors who will perform best-practice standards and profile compliance testing.

Technical Supplement Section 3 describes examples of interoperability procurement language for several cases—(1) upgrade of a laboratory information system, (2) use-case-driven integration scenario in obstetrics, (3) integration of patient care devices with the EHR system, (4) request for specific functionality and interoperability capabilities or request for information, (5) modular open systems architecture language—that would result from following the process illustrated in Figure A1-3.

As a final note to this section, a health care organization’s effective use of integration profiles and implementation guides in writing specifications is a discipline that can result in more open commercial products that reduce overall integration costs for new or upgraded capabilities. That said, some of these guiding resources may lack adequate specifics, forcing developers to make some design decisions. This leaves open the possibility of subtle variations in developer implementations that challenge achieving the ideal of plug-and-play system openness.

INTEROPERABILITY PROCUREMENT CONSIDERATIONS AND GUIDANCE

Taking into account the current state of the industry, this section will address general procurement guidance and considerations at each of the three interoperability tiers. No matter what type of system is being purchased, it can be useful to include a declaration statement at the start of the RFP to affirm the need for interoperability and security, as well as any unique missions and relevant clinical contexts worth noting.

RFP interoperability declaration statement

A health care organization should include in all RFPs for its technology acquisition a declaration statement that affirms the organization’s commitment to seeking interoperable and open architecture solutions and favor vendors who offer those solutions. Even without further stipulation, the strength of many health care organizations making such statements may influence vendor business practices in a favorable direction. Such declarations also cultivate open-systems expectations and commitment within the organization. A sample declaration statement follows.

is shared mainly through the HL7 Clinical Document Architecture (CDA), a clinical document framework designed to be readable by both humans and computers (Oemig and Snelick, 2016). Given that connectivity exists and is spreading across the country, the discussion here focuses on reported challenges related to usability, quality, and security of the data exchanged.

Usability. One issue affecting usability of data exchanged at the macro-tier level is the sheer volume of information. For example, a very common type of document—a discharge summary—may be on the order of 50 pages. The number of documents, combined with the detail contained in each, can easily overwhelm a provider. Large volumes of data for each patient from each provider creates fragmented snapshots that are challenging for clinicians to absorb, potentially leading to misdiagnoses, unneeded testing, medical errors, and workload fatigue.

Next-generation HIEs may offer enhanced controls and capabilities that substantially reduce unnecessary data volume. Health care organizations should engage with regional and state HIE headquarters to understand requirements that may be levied on their individual systems to support these initiatives. Not all stakeholders require access to all of the patient’s data. Stakeholders (clinicians, payers, researchers, and so on) should define default “views” specifying only the data they require—views that capture relevant data across all “fragments”—and assemble that data into a seamless view of the patient’s record (i.e., a dashboard). The use of well-contrived views may reduce the amount of redundant information in the overall network. Research has been performed on methods for identifying, extracting, and aggregating unique content from multiple clinical documents on the same patient (Dixon et al. 2017). Individual hospitals should advocate further research in this area and monitor developments in commercially available predictive analytic algorithms and population health management tools.

Quality. Challenges with quality at the macro-tier include data accuracy, timeliness, and meaning (semantics). Data accuracy and completeness issues include wrong fields; incorrect use of terminology codes; missing data (empty fields); and invalid, unreadable, or inconsistent entries. The issues with data timeliness result in outdated, incorrect information. Variation in data semantics means different health information systems can use different dictionaries for various medical domains. Translation of services provided into documentation codes can vary among clinicians and among health care organizations.

Automated tools exist to validate the quality of CDA documents. ONC’s C-CDA Scorecard, for example, provides implementers with industry best practice and usage. The Scorecard promotes best practices in C-CDA implementation by assessing key aspects of the structured data found in individual documents, as well as assessments on key areas for improvement. Health care organizations should

push for the maturation and transitioning of these tools from today’s stand-alone “test tools” into background real-time Continuity of Care Document (CCD)quality check tools that can trigger alerts caused by data entry issues and can ensure that interoperability does not degrade system performance.

Finally, patient matching is a challenge that exists at all tiers and is especially important to quality at the macro-tier where records for a single individual may exist at multiple locations, provider organizations, and health systems that have yet to come together to form a comprehensive picture of a patient’s care. Accurate patient-matching approaches is an active area of research, and given the importance of correct patient matching, health care organizations are encouraged to track developments in this area (e.g., the Sequoia Project, 2015; Office of the National Coordinator for Health IT, 2017a) and the subsequent effect on interoperability-related procurement language.

Cybersecurity and privacy. Security and privacy at the macro-tier starts with an identified threat model. In inter-facility information exchanges, there is a greater risk of data aggregation and exposure for a wide variety of nefarious purposes ranging from identity theft, fraud, and public exposure to deliberate life-critical modifications of data between facilities. Key mitigations at the macro-tier include common authentication/authorization between facilities, immutable logs to identify threat actors, and encrypted communications between facilities. Typically, these would be included in requirements for the use of information exchange gateways.

Envisioning the macro-tier of the future. The future of macro-tier interoperability can best be described by analogy: in the cellular communications industry today, regardless of whether one person uses Mobile Service Provider A and another uses Provider B, we expect to be able to communicate via voice and/or data (e.g., text message). In health care today, the situation is such that a hospital using Provider A can talk only to other Provider A hospitals. Organizations such as CommonWell Health Alliance (which is a trade association of health IT vendors that provides technical infrastructure to enhance patient matching, data query and retrieval, and person enrollment) are taking on the interoperability challenges at the macro-tier to support cross-vendor data exchange.

MESO-TIER CONSIDERATIONS AND GUIDANCE

At the meso-tier, individual hospitals or clinics handle data and information associated with the EHR and other medical IT systems such as labs or pharmacies, and from operational and administrative IT systems such as food services or facilities,

and admission/discharge/transfer (ADT). Data at this tier support the operation and administration of activities within the hospital, including clinical activities such as forming and maintaining a picture of the patient’s care and condition over time; moving patients and supplies where they are needed; scheduling resources; and so on.

In the current state, hospitals tend to procure pharmacy, laboratory, and other health information technology (HIT) systems that integrate with their respective EHR. EHR vendors may include these HIT systems as part of their product line, which hospitals might opt to purchase as “bundled” services. Alternatively, hospitals might procure solutions for these HIT systems from other (i.e., non-EHR) vendors and pay additional costs for integrating these systems with the EHR. These custom integrations may involve vendor-to-vendor agreements that must be managed over the long term. Although interoperability between these systems can be achieved, neither of these approaches—bundled HIT or custom integrations—are open architecture solutions, and significant additional resource investments and maintenance will be required over the product’s life cycle. These models of achieving meso-tier interoperability are typically not scalable and hence not sustainable as a long-term solution for the industry.

Requiring health IT vendors to use best-practice data exchange standards, integration profiles, and implementation guides for their products’ interfaces is part of the strategy to achieving more open systems. A complicating factor at the meso-tier is that health IT systems are typically large-scale capital investments that health care organizations retain over many years. Given the lengthy life cycles for these systems and the disparity of types of systems, progress toward open systems must be incremental.

As an example, a hospital procures an upgrade to the laboratory information system (LIS) that includes the ONC Interoperability Standards Advisory (ISA)–recommended standard interface between the LIS and the EHR system. Suppose the hospital’s EHR system is an older design that does not support the ONC Interoperability Standards Authority (ISA)-recommended LIS interface. The hospital could update the EHR system, but the current HIT budget might not support this. Another alternative is the use of an interoperability platform—(i.e., software and host computer systems that translate or transform a data interface from one form to another and facilitate the interconnection of different systems or subsystems). An open architecture interoperability platform, which is a data exchange framework composed of open and standard components and interfaces, is key to achieving the full benefit of interoperability and an open business model.

In this example, open architecture middleware serves as a bridge between the new LIS and legacy EHR, enabling retention of interoperability between the two.

At some point in the future when the EHR system is upgraded to the standard LIS-EHR interface, the open architecture middleware may be deemed unnecessary. Alternatively, the open architecture middleware might be retained to serve as the bridge interface to other systems having noncompatible interfaces within the same tier (e.g., meso-tier), but also across tiers (i.e., macro- or micro-tiers).

In addition to considering the potential benefits of open architecture middleware, health care organizations should monitor the progress of the new Fast Interoperability Healthcare Resources (FHIR) health data exchange standard. FHIR is the newest addition to the HL7 family of standards and includes many components of prior versions. The ONC has recognized the standard as being the “best available” one, and several major EHR system developers are incorporating early FHIR capabilities into their new systems.

FHIR bundles different types of health care information (e.g., administrative, clinical, financial, research, public health, and so on) into units called resources. HIT systems interconnect through a network and request and exchange resources with each other through a simple-to-use, web-based application programming interface (API). In this way, FHIR resources are available to all systems (though not always in real time), and a requesting system receives only the resources they request, making management of health-related data significantly easier and more reliable. Like other health data exchange standards, integration profiles and implementation guides are being developed for FHIR-based interfaces to satisfy various interoperability needs. FHIR development has largely focused on the macro- and meso- interoperability tiers, but use of FHIR at the micro-tier is also being considered (HL7 Wiki, 2017).

Cybersecurity and privacy. Within a facility, privacy is usually assured through physical access controls and traditional user authentication to critical systems. The automated information sharing between systems benefits from these factors. However, integration within a single vendor or between vendors may require a significant security infrastructure to ensure that all organizations sharing information use a common system authentication infrastructure to ensure that threats cannot gain access by disguising themselves as a legitimate organization for the purpose of violating privacy or modifying data within critical systems. Additionally, the increased use of wireless communications for meso-tier interoperability enables the connection of a threat that may be outside the security perimeter of the facility (e.g., in the parking lot). These facility authentication systems are historically difficult to configure and manage in a dynamic health care environment that includes automated department-to-department sharing, so it is important to address these growing complexities as increased meso-tier information sharing is established.

organization that operates in this space is the Center for Medical Interoperability (CMI, Box A1-5). The CMI’s conceptual framework envisions a future of micro-tier health data exchange where an interoperability platform developed through collaborative research and development interfaces with devices as well as the application layer. If successful, such an API-based platform can enable more efficient procurement of plug-and-play technology, circumventing the frustration and cost challenges associated with closed middleware solutions that are prevalent today.

Interoperability is only a means to an end. Health care organizations should characterize the specific interoperability needs for these technologies, and demonstrate how enhanced connectivity improves patient care and workflow. Health care provider organizations can then leverage the processes outlined in this Technical Supplement to identify data exchange standards, best-practice integration profiles, and implementation guides that specifically target their

interoperability needs for vendors to comply. As of now, some interoperability needs may require the vendor to build a custom interface as a last resort. In this case, the RFP should stipulate that the vendor demonstrate use of open architecture practices highlighted in Section 3 of this Technical Supplement, in particular full documentation and disclosure of the interface design.

Cybersecurity and privacy considerations. At the micro-tier, specific concerns take the form of secured and authenticated communications between individual devices. Within a single vendor, these security features may be enabled and be transparent to the use of the equipment, but when linking devices across vendors, there may be additional concerns that require more extensive configuration and maintenance. Open standards and security-enabled APIs will encourage security controls between devices, but the risk here is that the security controls may be disabled to facilitate rapid integration. Health care organizations are encouraged to review the imperatives, recommendations, and actions described by the Healthcare Industry Cybersecurity Task Force (PHE, 2017) related to medical devices and health IT systems. Some of the recommendations have long been implemented widely, such as requiring strong authentication and staff training on security and privacy protection. Other considerations may require additional governance and processes to secure legacy systems, improve transparency among developers and users, and employ strategic and architectural approaches to reduce physical breach or cyberattack of medical devices and health IT technologies. The Food and Drug Administration (FDA) also disseminates guidance on mitigating and managing cybersecurity threads and convenes experts on approaches to safeguarding medical devices and health IT systems.

CONCLUSION

Many health care organizations face constant challenges in adopting new capabilities and improving care when their devices and IT systems do not work together as an integrated system. Health care of tomorrow must develop an enterprise-wide architecture that enables system-wide interoperability to fuel a learning organization, as well as encouraging rapid development and adoption of technology innovations. In the interim, health care organizations must adopt a different approach in procuring technology that prioritizes interoperability with greater specificity. Health care organizations must commit to a requirements-driven approach for purchasing new technology that rewards interoperability, modularity, and openness. For many organizations, this means establishing a governance structure to coordinate and guide various internal efforts in leveraging existing implementation profiles and data standards in their procurement

processes. Health care organizations must also work with standards development organizations, vendors, and other provider organizations to expand best practices and share resources. An industry-wide commitment toward this requirements-driven approach, driven by strategic partnerships among provider systems, patients, technology vendors, federal agencies, and other health IT societies, is the only viable path toward a safer, more efficient, and high-value health care enterprise.

This page intentionally left blank.