<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 8 of 8: CMS Interoperability & Patient Access Rule - Data Ingestion Framework and Data Loader

In Part 7, we shared five key ingredients needed to develop a SMART on FHIR mHealth application. In the final part of the series, we highlight the need for payers to build a robust data ingestion framework and data loader for seamless payer-to-payer data exchange.

CMS’ Interoperability and Patient Access rule mandates payer-to-payer exchange of member information on member’s request. By Jan 1, 2022 (compliance date for the payer-to-payer data exchange mandate), payers must have the capability to ingest member clinical data (in USCDI format) from other payers. Payers should also have the ability to share an ex-member’s information to his/her current payer on the ex-member’s request. By Jan 1, 2021, payers are required to share the information in HL7 FHIR R4 format as per CMS regulations. To enable sharing of member information in the FHIR format, payers will need to build the capability for loading member information from their source of truth into a FHIR data repository. This will enable sharing of data with third-party apps / payers via FHIR APIs.

For payer-to-payer exchange of FHIR data, CitiusTech’s FAST+ solution is equipped with a FHIR parser and pre-built data ingestion pipeline for data ingestion. Payers will need to adopt a data ingestion framework to cleanse the incoming data from other payer systems and reconcile it into its source of truth (ODS/EDW). The data ingestion pipeline performs various activities including – validating data for data quality, data transformation, and data reconciliation. After the data parses through the FHIR Parser, it is validated for accuracy, completeness, consistency, and integrity. Validation is performed using quality and standardization rules across clinical, financial, and operational entities. Pre-built data mappers transform the data using transformation functions and reconcile the data into a single source of truth.

figure displaying data

If payers have the entire member information stored in a single source of truth, they would need to load the data into a centralized repository. It should also be able to store the member information in a FHIR-ready format. The data loader enables payers to load data from their single source of truth on a FHIR data repository. This component extracts initial and incremental data from the payer’s source of truth into a specified view and loads it in a staging area. Data mappers then transform the current format into a FHIR format and populate it in the FHIR data repository, which is ready to be consumed by the multiple portals and third-party applications.

figure showing payers EDW data

Both data ingestion and data loader components are integral for end-to-end CMS Interoperability rule compliance. The FAST+ solution for CMS rule compliance has repurposed these pre-built components – data loader, configurable and scalable data quality rules, and capabilities to transform and reconcile data from disparate source systems. This will enable payer organizations to go live faster and adhere to CMS deadlines. This architecture is a foundational step for payer organizations to accelerate their transformation journey to next-gen interoperability across their ecosystem.

 

Explore other blogs

Payvider Value Chain Blog Series | Part 2 of 5 | Data Management – Trends, Challenges & Considerations for Payviders
Payvider Value Chain Blog Series | Part 2 of 5 | Data Management – Trends, Challenges & Considerations for Payviders
Top 5 Factors Affecting the Performance of IoMT Devices
Top 5 Factors Affecting the Performance of IoMT Devices
MLR 2021 Outlook: Is normalcy on the horizon for health plans post pandemic?
MLR 2021 Outlook: Is normalcy on the horizon for health plans post pandemic?

Sorry!

No items currently match your filtering criteria.