<img height="1" width="1" style="border-style: none;" alt="" src="//googleads.g.doubleclick.net/pagead/viewthroughconversion/1064346053/?value=0&amp;guid=ON&amp;script=0">
Blog

FHIR Blog Series | Part 4 of 8: CMS Interoperability & Patient Access Rule - FHIR Bulk Data API

people smiling in a meeting

In Part 3, we addressed the need for payers and providers to proactively invest in a next gen provider engagement solution using SMART on FHIR apps framework for sharing data using Patient Access APIs. Part 4 explores the potential of the FHIR Bulk Data API to make population level data transfer and analytics possible.

Payer and provider organizations constantly exchange large volumes of clinical, claims, and administrative datasets. Given the continuous exchange of information, there is a need to efficiently access bulk volumes of data on a group of individuals for:

  • Health systems to periodically retrieve updated clinical data from an EHR to a research database.
  • Providers to send patient clinical data to their ACO for calculating quality measures.
  • Payers to drive personalized care management plans and improve member engagement.

Bulk data API based on REST principles aims to optimize the limitations within a payer’s existing FHIR data model, especially data extraction challenges, by addressing:

  • Cost Management: Existing FHIR APIs need a multi-step process for data extraction that increases the cost of integration projects and acts as a counter incentive to data liquidity.
  • Performance Issues: Current FHIR APIs require hundreds and thousands of requests, issued serially, for exporting large volumes of data.
  • Regulatory Compliance: ONC expects the FHIR community to add new FHIR capabilities to increase support for API-based access, and push data for large number of patients to drive provider-based exchange, analytics and other value-based services.

Existing FHIR APIs within a payer’s data infrastructure work well for accessing small amounts of data, but are inefficient for retrieving or exporting large volumes of data. This is due to the limited capability of the FHIR APIs which support synchronous calls and returns paged results.

However, the FHIR Bulk Data API can make asynchronous calls and return results in the form of a newline delimited JSON (ND-json). The final output is a Flat FHIR, an easily consumable resource. The FHIR Bulk Data API outlines a standardized asynchronous approach for exporting bulk data from a FHIR server to a pre-authorized client.

Stakeholders

Clinical and Public Health Laboratories, Immunization Registries, Quality Reporting Agencies, Regulatory Agency, Payors.

Vendors

Pharmaceutical, EHR, PHR, Clinical Decision Support Systems, Lab, HIS

Providers

Clinical and Public Health Laboratories Local and State Departments of Health Healthcare Institutions (hospitals, long term care, home care, mental health)

Fig – FHIR Bulk Data API Users

The Asynchronous Approach

Because of the large volumes of data that results from Bulk API searches, the FHIR specification describes an ‘asynchronous’ approach – in other words, the client does not need to wait for the server to create the extract as this could take a long time. The asynchronous process takes place in the following manner:

Step1 - Request Trigger: The client makes a “kickoff” request to the server. The server returns a location that the client can query when the extraction is complete.

Step 2 - Status Check: The client periodically polls the server using the address to monitor progress of the extraction. The server returns an ‘outcome’ response upon completion.

Step 3 - Download Ready: The client downloads the files containing the extracted data (in ndjson format which has multiple JSON objects in a single file) from the specified location.

Step 4 - Acknowledgement: Finally, the client informs the server that the data has been downloaded, and the files can be deleted.

figure showing asynchronous request and response

Fig. FHIR Bulk Data API – Asynchronous Request-Response

Data Sets for FHIR Bulk Data API Implementation

  • Common Clinical Data Set: Exports all resources needed for common clinical data set (as profiled by Argonaut).
  • Common Financial Data Set: Exports all resources required to convey a patient’s healthcare financial history such as explanation-of-benefit, coverage, claim, etc.

Benefits: FHIR Bulk Data API

  • Enables healthcare organizations to transmit large batches of data for entire population or cohorts from systems / apps to another system (internal / external).
  • Facilitates regulation for more standardized methods for transmitting all health data and reporting.

Potential Applications: FHIR Bulk Data API

  • Exchange of patient records between payers and providers to report use cases.
  • Back up of data contained within a clinical data repository.
  • Public health use cases on population level data.

Read all Blogs in the FHIR Series

Part 1: CMS Interoperability & Patient Access Rule - Impact & Opportunities

Part 2: CMS Interoperability & Patient Access Rule - Patient Consent on Data Sharing

Part 3: CMS Interoperability & Patient Access Rule - Provider Engagement using ‘SMART on FHIR®’ Apps

Part 5: CMS Interoperability & Patient Access Rule - FHIR Data Repository

Next in the blog series, Part 6: "Payer to Payer Data Exchange”.

 

Related to topics:

Explore other blogs

Payvider Value Chain | Part 1 of 5 | Data Integration & Interop – Trends, Challenges & Considerations for Payviders
Payvider Value Chain | Part 1 of 5 | Data Integration & Interop – Trends, Challenges & Considerations for Payviders
Digital Transformation for HealthCare Payers
Digital Transformation for HealthCare Payers
CMS Proposes New Rules to Streamline Prior Authorization Workflow
CMS Proposes New Rules to Streamline Prior Authorization Workflow

Sorry!

No items currently match your filtering criteria.