Clinical Decision Support for Care Gap Detection

MongoDB Atlas: Key Capabilities

Designed for complex healthcare workloads, MongoDB Atlas replaces legacy systems with a highly optimized, native data ecosystem. Below is an overview of the core capabilities that enable the platform to provide real-time decision support.

Figure 3. Atlas Key Capabilities

Flexible document model: The patient_360 collection stores a complete patient record in a single document—including demographics, conditions, medications, labs, vitals summaries, care gaps, alerts, personalized thresholds, and data provenance. A single document answers questions that would require multi-resource joins against a FHIR store.

Time series collections: The synthetic_vitals collection stores wearable device data using MongoDB's native time series collections. These collections provide automatic data bucketing, efficient range queries, and purpose-built storage for high-frequency, time-ordered data.

Change streams: The platform uses change streams to react to new vitals in real time. When a reading arrives, the system evaluates CDS rules and generates clinical alerts without polling.

Queryable encryption: MongoDB Queryable Encryption secures sensitive patient fields at rest. The application queries encrypted PHI fields without exposing plaintext, meeting HIPAA requirements and eliminating the need for a separate encryption layer.

Aggregation pipeline: This framework handles dashboard aggregations, care gap computation, vitals trend analysis, and HEDIS scoring, resolving complex clinical queries in milliseconds.

Structure for AI and analytics: The patient_360 document delivers normalized clinical facts, structured evidence, and metadata provenance to downstream AI and analytics pipelines without additional transformation.

The Data Generation Pipeline

Upon initialization, this solution uses a multi-step pipeline to seed and activate the CDS system, illustrated below.

Figure 4. Data Generation Pipeline

The Data Generation Pipeline drives the initialization sequence which creates synthetic and materialized clinical data, computes personalized thresholds and care gaps, and starts the real time monitoring. The pipeline works as follows:

1. Generates FHIR patient bundles: Creates FHIR R4 transaction bundles including conditions, medications, lab observations, encounters, and allergies. It stores these bundles in the FHIR data store, which serves as the interoperability layer.

2. Generates vitals histories: Produces a 24-hour time series of vital signs per patient, representing normal, deteriorating, or acute physiological patterns. It stores the data in the synthetic_vitals time series collection.

3. Materializes patient_360 documents: Transforms each FHIR bundle into a denormalized patient_360 document in MongoDB Atlas. The transformation includes a data_provenance block that links back to the source FHIR record.

4. Seeds CDS rules: Inserts clinical decision support rule definitions into the cds_rules collection.

5. Computes personalized thresholds: Calculates per-patient vital sign thresholds based on active medications and conditions. It stores these results in the patient_360 document.

6. Evaluates CDS rules: Runs the AlertEngine against current vitals and writes generated alerts to the alerts collection.

7. Computes HEDIS care gaps: Runs the QualityEngine against each patient's clinical history and writes structured care gap results to the patient_360 document.

8. Seeds provider attributions: Generates provider-patient attribution relationships in the attributions collection, determining which providers receive gap results and alerts.

9. Starts real-time monitoring: Activates the vitals simulation worker and begins streaming live vital sign data to the clinical platform via server-sent events.

The CDS Engines

CDS engines analyze patient data to provide actionable insights for care teams. This solution separates clinical monitoring from quality measure computation into two independent engines. This architectural pattern adheres to the Da Vinci initiative, an HL7 FHIR accelerator program for care interoperability, which recommends decoupling real-time alerting and HEDIS gap logic.

Care Gap Workflow

The care gap workflow serves as the systematic process healthcare organizations use to identify, track, and resolve discrepancies between a patient's actual clinical care and established medical guidelines. The care gap detection follows a structured path from identification to closure consisting of these actions:

• Evaluate: The QualityEngine assesses each patient's clinical history against HEDIS measure criteria.

• Write: The system writes open gaps to the patient_360 document, along with their supporting evidence, recommended action, and priority.

• Review: Care coordinators review open gaps in the clinical platform, sorted by priority and overdue period.

• Intervene: For actionable gaps such as KED and CDC-HBA, the platform opens a structured intervention workspace where the coordinator orders labs, records completion, or schedules follow-up.

• Close: When the intervention completes, the gap status updates in the patient_360 document and the QualityEngine re-evaluates on the next cycle.

• Escalate: When the AlertEngine detects a clinical alert, it elevates the priority of related open gaps and notifies the care team. Alerts without a related gap, like a sepsis warning, route directly to the care team as independent clinical notifications.

Clinical Data as Document Arrays

In the patient_360 document, each condition represents an entry in the conditions array, while each medication represents an entry in the medications array. As shown below, the document stores clinical entities in the shape they are used, rather than splitting across separate tables:

{
   "conditions": [
      {
         "code": "44054006",
         "display": "Type 2 diabetes mellitus",
         "clinical_status": "active",
         "onset_date": "2017-10-21T21:29:59.716351+00:00"
      },
      {
         "code": "433144002",
         "display": "Chronic kidney disease stage 3",
         "clinical_status": "active",
         "onset_date": "2023-09-12T21:29:59.716372+00:00"
      }
   ],
   "medications": [
      {
         "display": "Insulin glargine 100 units/mL injection",
         "dose": "20.0 units",
         "route": "subcutaneous",
         "frequency": "once daily at bedtime",
         "status": "active"
      },
      {
         "display": "Atenolol 50 mg oral tablet",
         "dose": "50.0 mg",
         "route": "oral",
         "frequency": "once daily",
         "status": "active"
      }
   ]
}

Computed Operational Fields

The FHIR bundle contains standard interoperability data, whereas the patient_360 document incorporates operational fields that FHIR does not define, including clinical flags, care gap results, personalized thresholds, and active alerts.

For instance, the materialization pipeline, embedded within the broader Data Generation Pipeline, computes clinical flags from the FHIR bundle and writes them directly to the patient_360 document. The AlertEngine reads these flags to determine which CDS rules apply to a patient, including:

• flags.has_beta_blocker: Activates the beta-blocker heart rate rule.

• flags.has_insulin: Activates the multi-factor hypoglycemia rule.

• flags.has_ckd: Activates the CKD metabolic acidosis and respiratory rules.

• flags.condition_codes: SNOMED codes for all active conditions.

Care gap results use the same approach. The materialization pipeline computes care gap results and appends them directly to the patient_360 document. Each computed HEDIS measure is stored within the care_gaps array along with its associated status, priority, evidence, and recommended_action. Unlike standard FHIR, the document model stores this information alongside the patient's clinical record. An example of this structure is shown below:

{
   "care_gaps": [
      {
         "hedis_measure": "CDC-HBA",
         "measure_name": "Comprehensive Diabetes Care — HbA1c Testing",
         "status": "open",
         "days_overdue": 34,
         "priority": "high",
         "evidence": {
            "found": ["HbA1c 5.13% (2025-10-07)"],
            "missing": []
         },
         "recommended_action": "Schedule or order an HbA1c follow-up"
      }
   ]
}

This approach offers additional flexibility; when clinical requirements change, you can extend the document. New CDS rules write new fields to the same document without affecting existing ones.

Traceability to the Source Record

The patient_360 document constitutes a derived operational view, not a replacement for the FHIR record. The materialization pipeline produces this view from the FHIR resources. To audit any clinical decision or care gap result, every document includes a data_provenance block:

{
   "data_provenance": {
      "layer": "cds_operational",
      "source_fhir_collection": "synthetic_patients",
      "source_patient_id": "1b3bbaec-def8-4b55-8e87-9d04b55d6890",
      "materialization_version": "1.0",
      "last_materialized_at": "2026-05-09T21:30:04.873754+00:00",
      "fhir_resource_count": 22
   }
}

The FHIR data store remains the canonical source of truth for interoperability, whereas MongoDB Atlas holds the operational view, maintaining a direct link back to its source data.

Encrypted Fields Within the Document Model

Healthcare regulations require applications to encrypt PHI. A common approach involves storing encrypted PHI in a separate system and retrieving it only when needed. However, this framework introduces a second data store, a separate key management layer, and increased latency to every patient record fetch.

MongoDB Queryable Encryption eliminates this overhead keeping PHI in the same document. It secures highly sensitive fields, such as the patient's name, MRN, and date of birth, making them readable only to authorized client applications with the encryption key. The remainder of the document remains queryable for operational use:

{
   "demographics": {
      "name": { "$binary": { "base64": "EAXZmoXjO0re...", "subType": "06" } },
      "given": { "$binary": { "base64": "EF1RChFVFEJC...", "subType": "06" } },
      "family": { "$binary": { "base64": "EK18iT8qVki8...", "subType": "06" } },
      "birth_date": { "$binary": { "base64": "EJOsqgLJPEjI...", "subType": "06" } },
      "gender": "female",
      "age": 77
   }
}

For example, microservices like the AlertEngine and QualityEngine read flags, thresholds, and care gap fields, neither reads the encrypted demographic fields.