Typically, fierce competition is a core principle during the development of a new product or solution, where there is the need to differentiate and set the offering apart as being superior to all others. However, when it comes to developing the framework for advanced interoperability, the situation couldn’t be more different.
With the implementation of the 21st Century Cures Act (the Cures Act), all healthcare stakeholders should be laser-focused on collaboration – not competition – as we come together to establish an interoperability framework that will help ensure healthcare 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 glidepath to adopt a set of common data classes for the use cases and permitted purposes considered in the TEFCA.
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.
Historically, providers have had to make point-to-point agreements with other providers and/or multiple networks to share patient health data. This approach tends to be very limiting to scale. Likewise, the primary exchange method is focused on sharing documents rather than sharing learnings.
Streamlining the Glidepath to Interoperability
We believe it is 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. Networks simplify connectivity challenges. Today, the primary exchange method is focused on sharing documents. 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.
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.
It’s not just about the technical standards for transport and content alone. We need to right-size 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, whether that’s a lab result, a past EKG to compare or clinical notes regarding the last follow-up to a referred specialist. 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.
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.
“A Floor Shouldn’t Be a Ceiling That Constrains Innovation”
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.
The views and opinions expressed in this blog or by commenters are those of the author and do not necessarily reflect the official policy or position of HIMSS or its affiliates.
Originally published February 16, 2018