71.1.1Multi-Repo Data Blend

The Data Blend feature leverages the Master Data Management (MDM) module to link patient records from multiple sources that are segregated into separate repositories using Enterprise Identifiers (EIDs). Once linked, Smile CDR FHIR Gateway provides a unified front door to these distributed patient records, enabling provider systems to retrieve a complete view of patient information during a data export — even if only a single identifier is listed in a FHIR Group resource — without querying multiple repositories directly. The Auto-Expansion feature of MDM ensures that all records linked via an EID are automatically included in the export.

71.1.2Key Concepts

• Primary Patient: The patient record stored in the payer’s own repository (primary repository). This is the main record used in a FHIR Group for data exports.
• Secondary Patient: Related patient records stored in other repositories that contain data collected from other payers. These records are linked to the primary patient to provide a complete view of the patient’s information.
• Patient Stub: A minimal representation of the primary patient created in secondary repositories to enable linking across repositories.
• Enterprise Identifier (EID): A unique identifier that connects primary and secondary patient records, ensuring all related records are recognized as belonging to the same individual.
• MDM Auto‑Expansion: The mechanism by which, when enabled (via the MDM module), all patient records linked by an EID are automatically included in a query or export.
• Group-based Export: The $davinci-data-export operation uses the PDex Provider Group to determine attributed members. The Data Blend feature ensures that all patient records linked through an EID are included in the export, even if only the primary patient is explicitly listed in the Group.

71.1.3Data Blend Use Case:

Since patient data can come from different sources, a payer may choose to segregate member data into separate repositories: one storing the payer’s own information and another storing data collected from other payers. The Data Blend feature links all related patient records across these repositories, allowing the Provider Access API to export a complete set of patient data.

71.1.4Example Scenario

Patient Context:
A payer maintains two separate repositories for member data:

• Repository 1 (Repo-1): Stores the payer’s internal patient data.
• Repository 2 (Repo-2): Stores patient data collected from external sources (e.g., other payers).

71.1.4.1Before Data Blend (No EID Auto-Expansion)

• The FHIR Group resource used for $davinci-data-export includes only Patient/123 (the internal record from Repo-1).

  {
      "resourceType": "Group",
      "id": "provider-group-1",
      "member": [
       { "entity": { "reference": "Patient/123" } }
      ]
  }
  

• During export, only the data associated with Patient/123 is retrieved.
• Result: The export misses relevant information stored in Repo-2 under Patient/ABC, which refers to the same individual.

71.1.4.2After Data Blend (With EID Auto-Expansion Enabled)

1. The MDM module identifies that:

   • Patient/123 (from Repo-1)
   • Patient/ABC (from Repo-2)
   • Patient/XYZ (from Repo-2)
     all refer to the same individual, and assigns them a shared Enterprise Identifier (EID: EID-001).

2. When a $davinci-data-export request is initiated for a Group that lists only Patient/123, the system:

   • Automatically expands the Group membership using the EID.
   • Includes Patient/ABC and Patient/XYZ in the export scope.

3. The resulting export bundle contains a comprehensive view of the patient’s data, aggregated across all repositories.

71.1.4.3Example Outcome:

71.1.5Configuration Requirements

To leverage the Data Blend feature, the payer must complete the following:

1. Enable the MDM module with minimal configuration MATCH_ONLY to link related patient records across sources.
2. Configure the relevant MDM properties under the Payer Persistence module to control how patient records are matched and merged.
3. Ensure any other modules that the MDM module depends on are properly configured, such as the Subscription module.

For step-by-step instructions on enabling the feature, see How to Enable Data Blend.

71.1.6How It Works

The FHIR Gateway handles Data Blend operations by routing and aggregating patient records across multiple repositories:

• Patient Identity Routing: When a query (e.g., Patient/$everything) is initiated via the Gateway using a Patient ID from Repo 1, the Gateway recognizes that this Patient ID is also present in Repo 2 due to replication (via Patient Stub record).
• Dual-Repo Aggregation:
  • The Gateway executes federated searches against both Repo 1 and Repo 2.
  • Using the replicated Patient ID and MDM's EID linkage, it retrieves all resources associated with the member (e.g., Coverage, ExplanationOfBenefit, Condition, Encounter, MedicationRequest).
• Normalization & Response Assembly:
  • The Gateway merges and deduplicates the data (as needed) before constructing a single, FHIR-compliant response bundle.
  • Optionally, Gateway policies can be applied to redact sensitive data or enforce record provenance tagging.