This blog post originally published on the HIMSS Conference blog. View that post here.
We’re accustomed to fierce competition as a core principle during the development of a new product or solution. It’s important for the producer to differentiate the offering and position it as superior to any other options. This principle, however, must be abandoned when it comes time to develop the framework for advanced interoperability.
The 21st Century Cures Act (Cures Act) calls all health care stakeholders to focused on collaboration – not competition. It’s our responsibility to work together toward an interoperability framework that will help ensure health data will be seamlessly available across the continuum of care.
As mandated by the Cures Act, the Office of the National Coordinator (ONC) released its draft for Trusted Exchange Framework and Common Agreement (TEFCA) in early January. TEFCA is one part of the Cures Act implementation that will lay the groundwork for how national networks operate. Released at the same time was the draft U.S. Core Data for Interoperability (USCDI), which is intended to define a path for adopting a set of common data classes for the use cases and permitted purposes considered in the TEFCA.
Both TEFCA and the USCDI are open for public comment through February 20. This provides an ideal opportunity for health IT stakeholders to unite in a collaborative effort to shape the framework.
A large portion of TEFCA lays out the minimum requirements for trusted data exchange across networks. As we discuss the proposed framework, we must consider how it potentially changes the fabric and architecture of national networks that are currently in place.
Streamlining the path to interoperability
Historically, providers have had to make point-to-point agreements with other providers and/or multiple networks to share patient health data. The primary exchange method is focused on sharing documents rather than sharing learnings. The Consolidated Clinical Data Architecture (C-CDA) establishes the primary/preferred format and content for the preferred document types, but non-C-CDA documents can be exchanged as well.To help facilitated the exchange of health data, it’s important to build on the national networks that are currently in place. The intention of these networks is to establish a platform for national data exchange and simplify connectivity challenges.
Connecting networks, such as the collaboration between CommonWell and Carequality, demonstrate the intent of TEFCA. By sharing a common set of principles, it should become easier for national networks to work together and create common access methods across networks. For example, Fast Healthcare Interoperability Resources (FHIR®) and other modern, RESTful APIs (an approach that's based on modern Internet conventions and is commonly deployed in other industries) are the primary standards targeted to enable data element-level access.
Understanding the needs of health data exchange
It’s not just about the technical standards for transport and content alone. We need to understand the data content so that we’re not sending too much or too little to support a particular workflow or data request.Today, one of the struggles clinicians face is receiving too much data in large documents, which isn’t always helpful. Physicians don’t always have the time to sort through reams of records – they want just the pieces of information they need. If the physician can’t find that information simply and quickly, they may just follow their old ways of asking the patient or ordering a new test.
Some automated validators for this data are available today, but they don’t clinically substantiate the threshold that defines a complete piece of information. Instead, today’s validators mostly check the technical specifications: Is it formatted correctly? Will it fit into a C-CDA? Although checking these technical specifications is important, we also must consider if this information is structured in a helpful manner.
Emerging APIs using FHIR standards will enable access to discrete data, enabling exchanges to only see the essential and contextually relevant data for that workflow. Understanding the data set that is relevant for access or exchange is critical. For certain use cases, such as e-prescribing, lab results reporting, registry submissions, claims and more, that is very clear. For general purposes, such as data element-level queries and documentation, that is not as clear.
Because the Cures Act and TEFCA primarily focus on document and data element-level queries, it is important to understand what data will be covered. The proposed USCDI suggests an evolving data set over several years that should be accessible as part of documents (using C-CDA) or as individual data elements (using FHIR) to query across networks. We suggest this starts with the 2015 Certification Edition Common Clinical Data Set (CCDS) and expands from there, and we appreciate that the USCDI uses that construct.
While we may not all agree yet on what data should and can be realistically available or when, providers are becoming accustomed to using certain clinical vocabulary based on standards that have been clearly defined. We need to follow suit and make it happen in our systems.
Interpreting TEFCA: Facilitating interoperability across networks
On the other hand, other data may still require definition of supporting standards (i.e., section/template definitions for C-CDA documents, resource definitions in FHIR and/or acceptable national vocabulary). We must collaborate to agree on a core set of standards that establish a floor that can evolve as time goes on. These standards become a starting point that allows us to continuously raise the bar over time.
Along the way, we must be flexible. We should always be able to consider alternatives that provide a better way to achieve our objectives. In other words, a floor shouldn’t be a ceiling that constrains innovation. We must empower innovators to explore and deploy equivalent or richer capabilities.
As the language of TEFCA implies, consistency of interoperability across networks and IT solutions is critical. It not only requires clear and unambiguous standards, but also robust testing tools that enable developers throughout development and deployment to validate their capabilities. Recognizing the value of transparency and certainty, these tools can be used to streamline the certification process as well. These tools can also help reduce cumbersome and time-consuming interactions with test labs and certification bodies by providing necessary evidence and reporting, which will enable developers to attest to their capabilities to an appropriate authority.
As evidenced by the proposed USCDI glidepath approach, interoperability is a journey that spans multiple years. It takes all stakeholders, including our respective competitors, to make this work. We are ready – and we ask you to take advantage of industry gatherings like summits, roundtables and forums to push this discussion, so we can ultimately come together to establish the path forward, inclusive of standards and capabilities, and achieve the vision of nationwide interoperability.
Interoperability is ripe to improve efficiencies while bettering consistency at the same time. Let’s use this opportunity to make that a reality as well.
Now is the time for national discussion and active participation to ensure that we, as an industry, are on the right path to achieve nationwide interoperability. To drive this discussion, Cerner offers up The Building Blocks of Nationwide Interoperability, which includes recommendations, based on practical principles and a strategic approach. Download the whitepaper here.
Kashif Rathore is an exhibitor at the HIMSS 2018 Interoperability Showcase. Details here.
