<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">

FHIR Blog Series | Part 5 of 8: CMS Interoperability & Patient Access Rule - FHIR Data Repository

doctor writing on clipboard

By Gati Patel – Healthcare Business Analyst, FAST+ Faiz Chachiya – Solution Architect, FAST+

In Part 4, we explored the potential of the FHIR Bulk Data API to make population level data transfer and analytics possible. Part 5 of the series addresses the importance of a FHIR data repository to aggregate and normalize data from multiple sources into the FHIR standard.

The FHIR data repository is an enterprise-level, centralized repository where healthcare data (clinical, claims, formulary, and cost sharing) is stored, and sourced from external payer systems or physician EHRs. FHIR data repository serves as a single source of truth (SSOT) for queries and searches for data-based requests raised from FHIR APIs.

Traditionally, data extraction for any FHIR API request made by third party apps and portals / EHRs takes place in the backend system as shown below:

On Demand Transformation (Non-FHIR Data Repository)

All incoming API requests need data through the transformation layer, which communicates to the payer specific SSOT (Operational Data Store or Enterprise Data Warehouse), extracts data based on the search request, and maps it into FHIR resources as part of the API response.

This approach is beneficial in scenarios where the request gets a response as per the defined SLAs, and the payer data is available in single source systems instead of disparate systems.

figure showing non FHIR repository

To overcome single source FHIR repository and SLAs compliance challenges, a FHIR data repository helps store all the data received from client source systems and also streamlines complex queries and searches.

FHIR data repository: Advantage for payers and PSPs

All API requests are fulfilled by querying and searching data from the FHIR data repository. All the external changes from the EHR/ODS/EDW/payer systems are updated in the data repository to ensure the data is in sync with other systems.

Addition of text-based searches to the FHIR data repository simplifies complicated use cases and FHIR related searches.

CitiusTech has developed a FHIR data repository that queries multiple databases for incoming FHIR data queries. It is designed to ensure faster turnaround time and maintain an organization wide FHIR resource repository.

figure showing FHIR data repository

Key design features of CitiusTech’s FHIR data repository:

1. Multitenancy

  • The FHIR data repository is multi-tenant and accounts for multiple client datasets.
  • Shared schema: Uses dedicated “Organization” and “Domain” columns to link the data as per the source system. Multiple organizations can be onboarded within the same database and schema using this approach. Views can be created based on organization and domain needs, along with necessary authorization to isolate data.
  • Separate schema: Can be created within the same database to accommodate multiple organizations / sources.
  • Separate DB instance: Creates separate databases for each incoming source.

2. Data Protection

  • Authentication: Verifies the identity of a client.
  • Authorization: Regulates access based on the roles of users using Role-Based Access Control (RBAC).
  • Storage: Encrypts the storage of FHIR data repository.
  • Encryption-in-flight: Client connected to the FHIR data repository for querying connect over secured channel using SSL / TLS.
  • Encryption-at-rest: Encrypts data while writing to disk and decrypts during reading from the disk.

3. Scalability

FHIR data repository can be scaled vertically by adding extra resources. Based on the underlying tools used to host the repository, organizations can also scale it horizontally. Scalable FHIR data repository helps achieve better query response times.

4. Search / Query Operation

The data required for the FHIR APIs is stored in FHIR data repository. This allows FHIR APIs to perform complex search operations efficiently. The FHIR data model also stores entity specific JSON objects in FHIR resource structure along with resource specific search metadata. As a part of the FHIR API calls, query/search operations are performed on data stored in the repository.

To Summarize, the FHIR data repository enables payer organizations and PSPs to normalize and store their clinical, claims and other healthcare data in the FHIR standard. It helps drive complex search operations, support multitenancy, and provide various ways of securing data effectively.

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 4: CMS Interoperability & Patient Access Rule - FHIR Bulk Data API

Part 6: CMS Interoperability & Patient Access Rule - Payer to Payer Data Exchange

Next in the blog series, Part 7: "SMART on FHIR”.


Related to topics:

Explore other blogs

CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
CMS 21st Century Cures IPA Rule & its Impact on State Health Agencies
Analytics Opportunities for Payers from CMS Regulations
Analytics Opportunities for Payers from CMS Regulations
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2
Payviders: Enhancing the member experience by creating more personalized digital touchpoints I Part 2 of 2


No items currently match your filtering criteria.