• Post By

    Raj Kurup
  • Post Date

    April 26 2020
Data Management Best Practices
  • Raj Kurup
  • June 5 2022
Post COVID American Healthcare Landscape
  • Raj Kurup
  • June 5 2022

Introduction to Healthcare Information Interoperability

Photo by Adeolu Eletu on Unsplash

Background

Nationwide Healthcare Information Interoperability (HI2), where every provider in every care setting be able to reliably exchange all clinically relevant patient information, has been a challenge that has plagued us for almost a decade. While we have made progress, we are nowhere close to achieving noticeable gains in goals. Here is a summary of progress we have made to date

  1. We started with Event Notification Systems where you would push standardized structured and unstructured documents, which would be secure, identity-verified electronic exchanges of protected health information (PHI), between healthcare organizations, providers, and patients to support care coordination. A good example of this is DirectTrust, which is still used by many healthcare organizations.
  2. Later, the concept of Health Information Exchange (HIE) evolved which was a broader coalition of various players and a more robust document exchange collaboration between Payers, Providers, and other key players in the healthcare systems. The two biggest HIEs were Carequality and Commonwell. While these were still widely accepted and leveraged, we still had issues with wider adoption. Some of the challenges we faced were
    1. Too much unneeded data
    2. Missing Key data elements
    3. Information formatting is unwieldy and cumbersome
    4. Information lacks Accuracy

Current State

At the heart of the challenges we have faced so far with the adoption of Healthcare Interoperability (HI2) is the challenge with Document based Exchange vs Data based Exchange. While Document based exchange does standardize the data being shared, it lacks the flexibility that one would want depending on the specific need. That is where we pivoted to a Data based exchange architecture and how HL7 FHIR (Fast Health Interop Resources) came about. The key benefits of FHIR are

  1. Flexible to document-level and data-level exchange
    1. Sometimes individual data elements are important, sometimes entire documents are appropriate
  2. Based on modern internet conventions
    1. RESTful API – same browser-based approach as used by Facebook, google, twitter, etc
    2. Infinitely extensible to detailed resources/profiles to meet any use case
    3. Supports push and pull use cases
  3. Attractive to developers from outside of healthcare
    1. Brings new voices into health care and pushes the industry to innovate at internet speed

HL7 FHIR Accelerator program

As FHIR has become popular and gained wider acceptance, we have the following accelerator programs formed that are looking to accelerate the adoption of HI2.

The Argonaut Project: The purpose of the Argonaut Project is to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology based on Internet standards and architecture

CARIN Alliance: This Accelerator is seeking to improve the ability for consumers and their authorized caregivers to gain digital access to their health information via non-proprietary application programming interfaces or APIs

CodeX: A multi-stakeholder community is forming to address the need to obtain high-quality, computable data for cancer care and research. CodeX — the Common Oncology Data Elements eXtensions project is leveraging the mCODE (minimal Common Oncology Data Elements) FHIR Implementation Guide.

Da Vinci Project: The goal of the Da Vinci project is to help payers and providers to positively impact clinical, quality, cost, and care management outcomes.

Gravity Project: The Gravity Project seeks to identify coded data elements and associated value sets to represent social determinants of health data documented in EHRs across four clinical activities: screening, diagnosis, planning, and interventions.

Blue Button 2.0 – Blue Button 2.0 from CMS is an API that contains four years of Medicare Part A, B and D data for 53 million Medicare beneficiaries. Blue Button 2.0 uses the HL7 FHIR standard for beneficiary data and the OAuth 2.0 standard for beneficiary authorization.

Leave a comment

Your email address will not be published. Required fields are marked *

Share This

Verified by MonsterInsights