Last week we continued our three-part blog series by reviewing how data can be organized once it’s consumed within the healthcare data platform, so as to add value and be more useful to stakeholders. To conclude the series, let’s consider “interoperability 2.0” concepts in terms of how data can ultimately be shared from a healthcare data platform.
Part 3: Interoperability 2.0 relative to how data is shared by a healthcare data platform
There are really two conventional methods for sharing healthcare data today – 1) leveraging basic industry standards such as HL7 and IHE to push and/or query and retrieve data, and 2) utilizing some sort of user interface (portal, inbox, worklist) to allow end users to access the information. Certainly the potential for APIs such as FHIR must be recognized, but current usage is still fairly limited in production environments. A typical shortcoming with the standards and the UIs is that end users always see the original transactions or documents distinctly; they may somehow be appended to each other, but they are still separate objects. Furthermore, one of the most fundamental challenges with interoperability today is presenting the information in a way that allows end users to remain in their native workflows, most likely the EHR or other system they live in day to day.
As we look to evolve interoperability, our collective aim should be an end-user experience where data is presented in a single view – one consisting of both transaction-based and document-based elements that are aggregated and intermingled side-by-side. To maximize user adoption, that single view must be presented in a way that’s consistent with the user’s workflow. Requiring a user to navigate to a separate application, log in, search, etc. is not acceptable. We need to take it even one step further: the single view of normalized and de-duplicated data really should be customizable by the end user. Take a CCD for example – there is no reason we should allow interoperability standards to dictate the format of the data that’s presented. Users should have the flexibility to designate which sections matter to them most and have those listed first. Maybe only the last year’s data is relevant to them instead of the patient’s entire history. Ultimately it’s about enabling the end user to find the “needle in the haystack” of data quicker. Both how the data is organized, as well as how the content is formatted when presented, contribute to that objective.
In today’s world of value-based care though, we’re no longer just focused on the outcomes of an individual patient; we’re looking to enable insights on the population level as well. Therefore, a comprehensive healthcare data platform must be expected to publish its data asset in a way that can be consumed by external applications across the spectrum of population health management – analytics, care management, patient engagement applications to name a few. This business driver has given rise to a new dimension of interoperability that some have termed “analytic interoperability”. To achieve analytic interoperability, extracts may be created, whereby the data set is packaged in a way that is consistent with unique specifications required by the consuming application. Alternatively, an API may be developed for standardizing data publication to third parties. But making data available for population health, and even generating certain insights such as gaps in care, social determinants of heath burden, and risk for opioid abuse, are not enough. Such valuable insights won’t matter unless those in a position to take action are aware. So how do we make them aware? This goes back to the workflow – we must enable those insights to be injected into the care team’s workflow. Example methods for delivering such critical information into the workflow may be incorporating it into a customized view of a CCD, through Direct Secure Messaging, or a notifications platform.
In summary, it’s time we move forward toward a new generation of interoperability – “interoperability 2.0” – where truly meaningful, useful data is incorporated into workflow and is easily consumable by both end users and external applications. To get there, we must innovate in all phases of a comprehensive healthcare data platform – how data is consumed into a healthcare data platform, how data is organized and put into context once it’s within the platform, and how that data is ultimately shared to end users or to external applications.
Medicity is proud of its accomplishments with over 15 years experience building clinical information networks:
21 State and
Transactions Per Year
285 Unique EMRs Integrated