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

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 Fast Healthcare Interoperability Resources (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 Electronic Health Records (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 Service Level Agreements (SLAs), and the payer data is available in single-source systems instead of disparate systems.

Figure 1: Information flow through a non FHIR repository

To overcome single-source FHIR repository and SLAs compliance challenges, a FHIR data repository helps store all data received from client-source systems and 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.

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 2: Information flow through a 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.

Deploying CitiusTech FHIR Data Repository in AWS

The metadata and JSON objects are stored in tables in CitiusTech FHIR Data Repository. This can be deployed on Amazon Redshift. Amazon Redshift is a fast, fully managed, petabyte-scale data warehouse service that makes it simple and cost-effective to efficiently analyze all your data using your existing business intelligence tools.

The FHIR Data Repository can also be deployed on Amazon Healthlake, as both support leaf-level resources. Amazon HealthLake is a HIPAA-eligible service that healthcare providers, health insurance companies, and pharmaceutical companies can use to store, transform, query, and analyze large-scale health data.

Figure 3: A FHIR data repository architecture deployed in AWS

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 provides several 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”.