Sistema de apoyo a la toma de decisiones clínicas para la detección de deficiencias en la atención.

MongoDB Atlas: capacidades clave

Diseñado para cargas de trabajo complejas de atención médica, MongoDB Atlas reemplaza los sistemas heredados con un ecosistema de datos nativo y altamente optimizado. A continuación se presenta una descripción general de las capacidades principales que permiten a la plataforma proporcionar soporte de decisiones en tiempo real.

Figura 3. Capacidades clave de Atlas

Modelo orientado a documentos flexible: El patient_360 collection almacena un registro completo del paciente en un solo documento, incluidos datos demográficos, afecciones, medicamentos, análisis, resúmenes de signos vitales, brechas de atención, alertas, umbrales personalizados y procedencia de los datos. Un solo documento responde a preguntas que requerirían uniones de varios recursos en un almacén FHIR.

Colección de series de tiempo: la colección synthetic_vitals almacena datos de dispositivos portátiles mediante las colecciones de series de tiempo nativas de MongoDB. Estas colecciones proporcionan agrupación automática de datos, query de rango eficientes y almacenamiento especialmente diseñado para datos de alta frecuencia y ordenados por tiempo.

Cambiar transmisiones: la plataforma utiliza transmisiones de cambio para reaccionar a nuevas constantes vitales en tiempo real. Cuando llega una lectura, el sistema evalúa las reglas de CDS y genera alertas clínicas sin sondeo.

Queryable Encryption: MongoDB Queryable Encryption protege los campos confidenciales de los pacientes en reposo. La aplicación consulta los campos PHI cifrados sin exponer texto sin formato, lo que cumple los requisitos de HIPAA y elimina la necesidad de una capa de cifrado independiente.

Pipeline de agregación: este framework gestiona las agregaciones del tablero, el cálculo de la brecha de atención, el análisis de tendencias de signos vitales y la puntuación HEDIS, resolviendo query clínicas complejas en milisegundos.

Estructura para IA y análisis: El documento patient_360 entrega hechos clínicos normalizados, evidencia estructurada y procedencia de metadatos a los pipelines de IA y análisis posteriores sin transformación adicional.

El pipeline de generación de datos

Tras la inicialización, esta solución utiliza un pipeline de varios pasos para sembrar y activar el sistema CDS, como se ilustra a continuación.

Figura 4. Pipeline de generación de datos

El pipeline de generación de datos impulsa la secuencia de inicialización que crea datos clínicos sintéticos y materializados, calcula umbrales personalizados y brechas de atención, e inicia la supervisión en tiempo real. El pipeline funciona de la siguiente manera:

1. Genera paquetes de pacientes FHIR: crea paquetes de transacciones FHIR R4 que incluyen afecciones, medicamentos, observaciones de laboratorio, encuentros y alergias. Almacena estos paquetes en el almacén de datos FHIR, que sirve como capa de interoperabilidad.

2. Genera historiales de signos vitales: produce una serie temporal de 24horas de signos vitales por paciente, que representa patrones fisiológicos normales, deteriorados o agudos. Almacena los datos en la colección de series de tiempo synthetic_vitals.

3. Materializa documentos patient_360: transforma cada paquete FHIR en un documento patient_360 desnormalizado en MongoDB Atlas. La transformación incluye un bloque data_provenance que enlaza con el registro FHIR de origen.

4. Reglas de CDS de semillas: inserta definiciones de reglas de soporte de decisiones clínicas en la colección cds_rules.

5. Calcula umbrales personalizados: calcula los umbrales de signos vitales por paciente en función de los medicamentos y las afecciones activas. Almacena estos resultados en el documento patient_360.

6. Evalúa las reglas de CDS: ejecuta el AlertEngine con los signos vitales actuales y guarda las alertas generadas en la colección alerts.

7. Calcula las carencias de atención de HEDIS: ejecuta el QualityEngine en el historial clínico de cada paciente y guarda los resultados estructurados de las carencias de atención en el documento patient_360.

8. Atribuciones del proveedor de semillas: genera relaciones de atribución proveedor-paciente en la colección attributions, determinando qué proveedores reciben resultados y alertas de brechas.

9. Inicia la supervisión en tiempo real: activa el trabajador de simulación de constantes vitales y comienza la transmisión de datos de constantes vitales en vivo a la plataforma clínica a través de eventos enviados por el servidor.

Los motores CDS

Los motores de CDS analizan los datos de los pacientes para proporcionar perspectivas procesables a los equipos de atención. Esta solución separa la supervisión clínica del cálculo de medidas de calidad en dos motores independientes. Este patrón arquitectónico se adhiere a la iniciativa Da Vinci, un programa acelerador HL7 FHIR para la interoperabilidad de la atención, que recomienda desacoplar las alertas en tiempo real y la lógica de brechas de HEDIS.

Flujo de trabajo de carencias de atención

El flujo de trabajo de brecha de atención sirve como el proceso sistemático que las organizaciones de atención médica utilizan para identificar, rastrear y resolver las discrepancias entre la atención clínica real de un paciente y las pautas médicas establecidas. La detección de brechas de atención sigue una ruta estructurada desde la identificación hasta el cierre que consta de estas acciones:

• Evaluar: El QualityEngine evalúa el historial clínico de cada paciente según los criterios de medición de HEDIS.

• Guardar: el sistema guarda las brechas abiertas en el documento patient_360, junto con sus pruebas de respaldo, la acción recomendada y la prioridad.

• Revisión: Los coordinadores de atención revisan las brechas abiertas en la plataforma clínica, clasificadas por prioridad y período de vencimiento.

• Intervenir: Para brechas procesables como KED y CDC-HBA, la plataforma abre un espacio de trabajo de intervención estructurado donde el coordinador ordena laboratorios, registra la finalización o programa el seguimiento.

• Cerrar: Cuando finaliza la intervención, el estado de la brecha se actualiza en el documento patient_360 y el QualityEngine se vuelve a evaluar en el siguiente ciclo.

• Escalar: cuando el AlertEngine detecta una alerta clínica, eleva la prioridad de las brechas abiertas relacionadas y notifica al equipo de atención. Las alertas sin una brecha relacionada, como una advertencia de sepsis, se dirigen directamente al equipo de atención como notificaciones clínicas independientes.

Datos clínicos como arreglos de documentos

En el documento patient_360, cada condición representa una entrada en el arreglo conditions, mientras que cada medicamento representa una entrada en el arreglo medications. Como se muestra a continuación, el documento almacena las entidades clínicas en la forma en que se utilizan, en lugar de dividirlas en tablas separadas:

{
   "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"
      }
   ]
}

Campos operativos calculados

El paquete FHIR contiene datos de interoperabilidad estándar, mientras que el documento patient_360 incorpora campos operativos que FHIR no define, incluidas marcas clínicas, resultados de brechas de atención, umbrales personalizados y alertas activas.

Por ejemplo, el pipeline de materialización, incrustado en el pipeline de generación de datos más amplio, calcula las marcas clínicas del paquete FHIR y las guarda directamente en el documento patient_360. El AlertEngine lee estas marcas para determinar qué reglas de CDS se aplican a un paciente, incluidas:

• flags.has_beta_blockerActiva la regla de frecuencia cardíaca del betabloqueante.

• flags.has_insulin: activa la regla de hipoglucemia multifactorial.

• flags.has_ckd: Activa las reglas de acidosis metabólica y respiratoria de la CKD.

• flags.condition_codes: códigos SNOMED para todas las condiciones activas.

Los resultados de la brecha de atención utilizan el mismo enfoque. El pipeline de materialización calcula los resultados de la brecha de atención y los agrega directamente al documento patient_360. Cada medida HEDIS calculada se almacena dentro del arreglo care_gaps junto con su status, priority, evidence y recommended_action asociados. A diferencia de FHIR estándar, el modelo orientado a documentos almacena esta información junto con el registro clínico del paciente. A continuación se muestra un ejemplo de esta estructura:

{
   "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"
      }
   ]
}

Este enfoque ofrece flexibilidad adicional; cuando cambian los requisitos clínicos, puede extender el documento. Las nuevas reglas de CDS guardan nuevos campos en el mismo documento sin afectar a los existentes.

Trazabilidad al registro de origen

El documento patient_360 constituye una vista operativa derivada, no un reemplazo del registro FHIR. El pipeline de materialización produce esta vista a partir de los recursos FHIR. Para auditar cualquier decisión clínica o resultado de brecha de atención, cada documento incluye un bloque data_provenance:

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

El almacén de datos de FHIR sigue siendo la fuente canónica de información para la interoperabilidad, mientras que MongoDB Atlas contiene la vista operativa, manteniendo un vínculo directo con sus datos de origen.

Campos cifrados dentro del modelo orientado a documentos

Las regulaciones sanitarias exigen que las aplicaciones cifren la PHI. Un enfoque común consiste en almacenar la PHI cifrada en un sistema separado y recuperarla solo cuando sea necesario. Sin embargo, este marco introduce un segundo almacén de datos, una capa de gestión de claves independiente y una mayor latencia para cada recuperación de registros de pacientes.

MongoDB Queryable Encryption elimina esta sobrecarga manteniendo la PHI en el mismo documento. Protege campos altamente confidenciales, como el nombre del paciente, el MRN y la fecha de nacimiento, haciéndolos legibles solo para las aplicaciones cliente autorizadas con la llave de cifrado. El resto del documento sigue siendo consultable para uso operativo:

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

Por ejemplo, los microservicios como AlertEngine y QualityEngine leen indicadores, umbrales y campos de brechas de atención, ninguno lee los campos demográficos cifrados.