Procuring Interoperability: Achieving High-Quality, Connected, and Person-Centered Care (2018)
Chapter: III. Interoperability Procurement Specification Strategies
III.
INTEROPERABILITY PROCUREMENT SPECIFICATION STRATEGIES
Drawing on the lessons of other industries and using a systems engineering approach, the initial priority for both manufacturers and health care organizations is the identification of the goals for the product being acquired, followed by a disciplined process for acquiring the product. In principle, only after functional requirements and design specifications of the product have been listed should decisions be made about which technologies to include. Interoperability should be a functional requirement.
The process of establishing requirements first necessitates a clear definition of the clinical use cases and needs, which include all aspects of capability, performance, process, and workflow. A needs statement should articulate what the user is attempting to accomplish as well as how this capability relates to the broader mission. In other words, the requirements should state what the health IT products must be able to do, expressed as desired outcomes for health IT interoperability (e.g., producing required clinical quality metrics, decision support, safety interlocks) (Medical Device Plug-and-Play Interoperability & Cybersecurity [MD PnP] Program at Massachusetts General Hospital, 2018), as well as how the health IT module uses various data exchange standards (e.g., Clinical Document Architecture [CDA], Application Programming Interfaces [APIs], or other standards that support clinical information exchange). Several organizations such as IHE and HL7 provide free resources, including use cases, integration profiles, and implementation guides that can help organizations delineate the scope, capabilities, desired outcomes, and potential limitations. Box A1-1 in Appendix A describes them in more detail.
Once user needs are defined, the next layer of technical requirements should be derived from those user needs. Requirements may include functional requirements, including interoperability, and other operational requirements or constraints such as timeliness and accuracy. Once the requirements have been derived from the user needs, they must be articulated in contracting documents to minimize
ambiguity. The onus then falls on the industry supplier of the system or capability to demonstrate their compliance with the open architecture required to support industry standards and specifications in the contract.
For example, a hospital upgrading their laboratory information system (LIS) may require interoperability between the hospital’s legacy EHR system and the new laboratory system. The RFP may include language such as, “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.” Another hospital that aims to procure an open architecture interoperability platform to integrate a set of patient care devices to pass data directly to the EHR system may include language such as, “The open architecture interoperability platform shall receive data from the device types and manufacturers listed in Table X . . . products that provide the option of communicating with the highlighted device types in Table Y in compliance with IHE PCD DEC Optimized Exchange Protocol will be ranked higher as described in section Z.” (See Appendix A Technical Supplement, Section 3.)
Additional sample language specification with corresponding applications, as well as sample language for modular open systems architecture (further discussed below) and an open business model can be found in Appendix A, Section 3.
Interface standards, given the lack of a centralized authority, must be leveraged across organizations. To achieve this, each institution must provide guidance and a strategy—in the form of a long-range road map—to enable the organization to meet its objectives and to allow for cross-organizational sharing of interface standards. Accounting for needed organizational resources is, of course, imperative—including not only dedicated budget and human resources to assess, select, and implement interoperable solutions, but a process to obtain and train interoperability enablers within the organization.
MODULAR OPEN SYSTEMS ARCHITECTURE
The concept of Modular Open Systems Architecture (MOSA) is prevalent throughout this holistic view. By definition, an open system architecture is “organized decomposition, using carefully defined execution boundaries, layered onto a framework of software and hardware shared services and a vibrant business model that facilitates competition.” (Guertin and Hurt, 2013, page iii). An expedient way to determine whether a system employs an open system is to ask, “Can one or more qualified third parties add, modify, replace, remove, or provide support for a component of a system, based on open standards and
published interfaces for the component of that system?” (Guertin and Hurt, 2013, page viii).
A modular open systems architecture embodies five features:
- Modular design standards that allow for independent acquisition of plug- and-play components;
- Enterprise investment strategies, based on collaboration and trust, that maximize reuse of proven hardware system designs and ensure health care organizations spend the least to get the best;
- Transformation of the life cycle sustainment strategies for software intensive systems through proven technology insertion and software product upgrade techniques;
- Lower development risk through transparency of system designs and continuous design disclosure; and
- Strategic use of data rights to ensure a level playing field and access to alternative solutions and sources across the life cycle.
The US military is one of the pioneers in adopting such a model as a broad strategic choice. Box 1 describes the lessons learned from transitioning to the requirement-driven acquisition at the Department of Defense military health system. Two additional case studies (Appendix A Technical Supplement, Section 4) detail the processes undertaken by the US Navy, which enabled more open and modular procurement models for its submarines and unmanned ground vehicle system.
Incubating a wide adoption of such modular open system architecture across the macro-, meso-, and micro-tiers requires many external factors: the existence of independent organization(s) to specify technical standards for data exchange
(technical, syntactic, semantic, and operational, Figure 4); a vendor-neutral reference architecture based on open architecture principles offered to multiple industry integrators for commercialization; multiple “integrators” capable of producing modules (or components within a module) that adhere to the technical standards for data exchange and the detailed reference architecture; certification bodies to ensure compliance to standards; and a framework to evaluate the “maturity” of interoperability that specific devices, systems, and/or clinical domains have achieved. One example is the CMI Interoperability Maturity Model described earlier (Figure 5), which provides a mechanism by which to analyze the requirements of a situation and match it with the optimal level of interoperability along a number of dimensions: infrastructure, syntactic, terminology/semantic, conversational complexity, and contextual/dynamic. While the field as a whole continues to evolve toward this vision, health technology purchasers can take strategic steps today to enhance interoperability and optimize their investment in health IT.
FRAMEWORK FOR PROCURING SYSTEMS THAT ARE PROGRESSIVELY INTEROPERABLE
Fundamentally, driving system-wide interoperability requires more than technical resources and competencies; it also requires alignments of culture, governance structure, and a viable and sustainable business model. For an individual hospital system, the institution’s leadership must start by prioritizing interoperability as mission critical, as well as by providing a carefully built accountability structure to execute, maintain, and continuously improve. In addition, to incrementally improve connectivity of new technology acquisitions, continuous improvement involves versioning and backward compatibility checks. Recognition that interoperability must be managed as a component of a long-term business strategy rather than as numerous uncoordinated, one-off purchase decisions must permeate individual organizations and the entire health care sector. Collectively and over time, the health IT industry and health care providers require a shared understanding that data liquidity and openness must be the norm, not the exception. Conformance testing and certification requirements are also essential shared infrastructure for the field at large.
Specifically, the steering committee identified five priorities for health care organization and system leader action:
- COMMIT: Declare interoperability a primary priority and form an organization-wide interoperability steering group or related capacity to champion the IT acquisition strategy.
-
IDENTIFY: Charge this group with identifying the set of interoperability goals, requirements, and model use cases for the procurement process to deliver on organizational priorities and patient outcome goals.
Health care organizations must rethink how disparate health IT modules are connected, not just within one hospital, but also among every entity involved in a patient’s care, including physicians’ offices, home health agencies, other postacute-care facilities, and social services. With strong engagement from the organization’s interoperability steering group, health system leaders should define their strategic priority and goals for interoperability in various clinical interactions and applications on an annual basis. The interoperability steering group should also oversee the identification of key clinical use cases that bear the highest urgency for improvement in interoperability and require strategic technology acquisition. Guided by a road map charting the path toward a modular open system architecture model, these priorities should reflect direct linkages to the organization’s overall strategic planning process for quality improvement as well as for technology acquisition and management. (See Appendix A Technical Supplement, Section 1.) Because not all organizations will have internal capacity to write detailed specifications, work in this arena should be openly and freely shared among health care organizations, vendors, and researchers (see below).
-
COLLABORATE: Create a sector-wide strategy and partner with other sector stakeholders to align on common contracting requirements and specifications for the next generation of interoperable health IT.
Health system leaders should assertively collaborate with other health care providers, payers, and vendors to form a shared vision for digital interoperability and shared resources for procuring health IT. In
Each health system leader should articulate how enhancing interoperability is key to the organization’s mission as health care providers and emphasize the priority of purchasing strategies to achieve these goals. By identifying stakeholders and enablers within the organization, forming an interoperability steering group (or a working group with related capacity within the existing steering committee), health systems can create the clear governance structure to develop, oversee, and sustain a long-term road map toward interoperability that can continuously improve technology procurement driven by end-user needs and adapt to industry-wide best practices. (See Appendix A Technical Supplement.)
-
SPECIFY: Use the collaboratively developed specifications to state clear, functional interoperability requirements in existing and future proposals and contracts.
Each health system leader should mandate that the interoperability steering group build institutional capacity to provide clear, unambiguous technical specifications on high-priority IT acquisitions and upgrades. In many industries, such specifications often span hundreds of pages and provide detailed information to avoid vendor latitude in interpreting requested data exchange and other plug-and-play standards. Health systems should leverage existing and emerging resources to translate their interoperability needs into procurement specification language, but doing so takes institutional commitment of will and resources. (See Appendix A Technical Supplement, Section 1.)
-
ASSESS: Establish and monitor short-term and long-term metrics for the progress and contributions of interoperability to system-wide learning and improvement of health outcomes.
Each health system leader should define the desired end-state and key performance indicators related to interoperability across the macro-, meso-, and micro-tiers. At the organizational level, metrics that demonstrate the short-term and long-term value from acquiring the right technology portfolio through achieving their articulated quality, outcome, and cost goals should be developed and monitored over time. From the business infrastructure standpoint, there should be an accompanying data dimension for each of the three tiers that centers on allowable use cases for data sharing at a business level beyond how each device on the system can communicate.
addition to ad hoc strategic partnerships, a national coordinated initiative should be launched to create a shared “commons” that includes basic requirement specifications for trust, common data elements and definitions, data security, connectivity, timeliness, accuracy, and usability to clinicians and patients. Such alignment can then be realized over time by embracing a clearly defined procurement strategy and demanding that these specifications be met. As part of this effort, a public platform test bed or a certification body should be established that allows for low-cost access to connectivity testing for providers and developers of all sizes and resource levels. Through collaboration and coordination, the purchasers of health care technology can benefit from more efficient acquisition, while the marketplace becomes more competitive and encouraging to innovations.
In accordance with the five action priorities for interoperability—Commit, Identify, Collaborate, Specify, and Assess—several organizational steps are common elements:
- An interoperability steering group: This team, with the CEO’s direct engagement, serves as the organizational champion that motivates the procurement framework toward interoperability and system openness and guides the procurement decisions and specifications. The group should include diverse representatives within the health care organization (e.g., clinical, engineering, administrative, business, operations, supply chain, and IT) and be responsible for staying abreast of advances in interoperability and open systems, developing objectives and a long-range interoperability road map, identifying interoperability and data security requirements, translating requirements to procurement specifications, and measuring return on investment.
- Long-range interoperability road map: The road map is a component of the organization’s multiyear procurement plan that pursues the vision for system openness and interoperability with incremental objectives and guideposts. The interoperability steering group should update the road map annually to reflect organizational or market changes that influence procurement priorities.
- Interoperability needs identification process: The interoperability steering group should engage key stakeholders internally to identify needs and opportunities for enhanced interoperability in its care processes. This means documenting and visualizing the complex information and workflow interactions in a health care setting and the translation of these interactions to interoperability needs for new or upgraded health IT systems. Data security and privacy protection needs should be identified as part of the process. The N-square diagram, one of the tools routinely used in systems engineering for tabulating interactions between hardware and/or software systems, may facilitate this process (see Appendix A Technical Supplement, Section 2).
- Interoperability procurement specification process: The interoperability steering group should lead the translation of interoperability needs to procurement specifications in RFPs by leveraging various data exchange standards, supporting resources, and existing reference architecture. The ONC Interoperability Standards Advisory provides some useful resources, including best practice guidance on data exchange standards, production of security and patient privacy, implementation guides, and integration profiles as well as guidance on contracting with EHR vendors (Office of the National Coordinator for Health Information Technology, 2016).
Depending on the size of the organization and the resources at hand, the prerequisite elements proposed here may vary in their scale and vigor. Nevertheless, executives in every health care organization should ensure all four elements are present as part of a long-term capacity and infrastructure-building strategy. The Technical Supplement, in Appendix A, provides more detailed guidance for developing each element within health systems.
CONTRACTING AND MANAGING VENDORS THROUGH REQUESTS FOR PROPOSAL (RFPs)
Once the steering group, road map, and appropriate needs and resources have been identified within a health care organization or network, the detailed procurement strategy must also be developed and implemented. This includes describing the organization’s interoperability requirements in any contractual RFPs and selecting those vendor solutions that meet these requirements. It is also important to certify that the delivered system or component meets the requirements before acceptance. A common approach for a vendor is to offer its services to provide the subsystem integration. Although this can be an attractive option, it is critical for the purchaser to ensure that the vendor’s interoperability expertise and commitment are not limited to that vendor’s products; otherwise, the health care organization risks becoming “locked in” to one vendor. An alternative is to select an independent integration agent who would ensure cross-vendor interoperability. This approach allows modularity in the system so that new capabilities can easily be added in the future without relying on one vendor’s solutions.
As part of the procurement process, metrics and measurements must be included for acceptance and functionality testing. Many use cases can be defined in the requirements specification with a clear listing of expected outcomes (including interoperability). Test scripts must be created to verify that the requirements are met, including steps that verify interoperability standards. The usefulness of conformance and interoperability testing tools depends not only on the quality of available standards, but also on the rigor of a sustained practice that continuously identifies relevant standards and reduces ambiguity. Such practice forms an imperative business infrastructure—it requires a dedicated team of people (an interoperability advisory committee) with an adequate mix of technical and clinical expertise, a structured process (e.g., the N-squared diagram), and a road map to achieve the end state. In many industries that achieved interoperability, that end state reflects some form of modular, open system architecture, where many IT components can be standardized and commoditized so that replacing and updating over time becomes easier for the health care providers.
The accompanying Technical Supplement (Appendix A) provides tools and terminology intended to facilitate such a process. It has four parts: Section 1 describes an overarching framework and implementation strategy for purchasing interoperable systems, including a step-by-step procurement specification process for organizations to follow when purchasing interoperable technology and guidance for making procurement decisions at each interoperability tier. Section 2 describes the application of the N-squared diagram, a systems engineering tool routinely used in the space and military sectors, to organize complex interactions among hardware and software systems. This prototypical approach represents an exemplary strategy to systematically identify and prioritize interoperability needs. Section 3 provides examples of interoperability specification language for several use cases. Section 4 describes two relevant case studies from nonhealthcare settings within the defense industry that have engaged similar interoperability challenges.
Looking ahead, each institution should not only take initiatives and overcome inertia to drive purchasing strategies internally but also actively drive interoperability among organizations at the macro-tier. In addition to building the technical infrastructure, health system leaders should recognize and pursue an overall business infrastructure that allows for more assertive procurement practices. More importantly, active collaboration among health care leaders is key to driving the entire health IT market toward interoperability at all three levels, as well as seamless interfaces with the rapidly expanding tools for individuals, families, and communities.
