Capa de datos operativos FHIR híbridos

Resumen de la solución

Este proyecto desarrolla una Patrón ODL híbridoFHIR para el sector sanitario. El objetivo principal es crear una tienda operativa única y de alto rendimiento que impulse los servicios web para clientes. Además, el diseño expone compatibilidad con FHIR. puntos finales para los recursos dentro del alcance, de modo que se puedan crear funciones futuras utilizando la API REST de FHIR en lugar de nuevos servicios personalizados.

En esencia, el ODL utiliza MongoDB Atlas como una base de datos flexible y escalable que almacena recursos, como Patient o Encounter, en un formato estructurado de tres bloques. Esto incluye:

• La representación FHIR canónica cuando existe un mapeo.

• Campos adicionales específicos de la aplicación.

• Campos de búsqueda preindexados optimizados para el rendimiento de las consultas.

Dado que las asignaciones se definen primero en FHIR, los campos alineados con FHIR se almacenan utilizando la estructura estándar, mientras que los atributos restantes se guardan en bloques de aplicación separados. Esta estructura híbrida preserva la interoperabilidad sin forzar que la solución se comporte como un servidor FHIR completo.

El backend utiliza FastAPI y expone dos familias de API:

• API de Aplicación: Implementa los endpoints operativos del cliente, por ejemplo, búsqueda de pacientes, búsqueda de casos o servicios de identificador local, utilizando el ODL como backend compartido.

• API FHIR: Ofrece búsquedas compatibles con FHIR para un subconjunto definido de recursos, como Patient y,Encounter reutilizando el mismo modelo de envolvente e índices. Está diseñada como una fachada FHIR pragmática, no como un servidor FHIR completo basado en perfiles.

El frontend utiliza Next.js e incluye un demostrador de API interactivo, de modo que los equipos pueden probar puntos finales de aplicaciones y consultas de estilo FHIR juntos.

Para demostraciones y desarrollo, el ODL puede generar conjuntos de datos clínicos sintéticos, lo que permite realizar pruebas realistas sin exponer datos reales de pacientes.

Arquitecturas de Referencia

La arquitectura se centra en el ODL híbrido de FHIR, un modelo de datos de referencia que admite patrones de acceso operativo personalizados y acceso compatible con FHIR sobre el mismo conjunto de datos. En lugar de duplicar datos, este enfoque indexa información valiosa para consultas operativas y mantiene el recurso FHIR completo.

El caso de uso surge de un desafío real de un cliente de una gran institución sanitaria que operaba múltiples plataformas de HCE. Cada sistema ofrecía servicios de acceso a pacientes de forma independiente, lo que generaba acceso fragmentado a los datos, lógica duplicada y falta de interoperabilidad semántica.

Para simplificar esto, esta institución introdujo un ODL para centralizar el acceso a los datos clínicos y proporcionar servicios compartidos de MDM, sin interrumpir las aplicaciones existentes.

Esta situación creó la oportunidad de adoptar las mejores prácticas de la industria al adoptar FHIR como lenguaje común, en lugar de redefinir las estructuras de datos y la semántica desde cero. Al diseñar el modelo de datos ODL priorizando FHIR, la organización evitó reinventar la rueda en conceptos clave como pacientes y encuentros. Además, se alineó con las definiciones estándar de recursos, lo que lo convirtió en un modelo potencial para otros profesionales del sector.

La arquitectura de referencia muestra cómo las empresas sanitarias pueden unificar diferentes fuentes de datos, respaldar procesos personalizados y ofrecer API de alto rendimiento mediante MongoDB Atlas. La interfaz se divide en pestañas, cada una de las cuales muestra una función específica de la arquitectura.

Figura 1. Arquitectura de referencia ODL híbrida FHIR

Inicialmente, la sección de asignaciones muestra cómo los campos de datos de salud heredados se asignan al modelo de datos ODL, diseñado en torno a un esquema centrado en FHIR. Cada documento almacena:

• Un recurso FHIR canónico (cuando existe un mapeo FHIR)

• Campos específicos de la aplicación requeridos por los flujos de trabajo actuales

• Campos optimizados para búsqueda utilizados por las API

Los usuarios pueden explorar un conjunto completo de asignaciones de campos en entidades como Patient y Encounter en una tabla interactiva. Esto les ayuda a comprender qué campos provienen de la especificación FHIR y cuáles están modelados como campos de aplicación o de búsqueda. Esta estrategia de asignación facilita el rastreo del linaje de datos y la evaluación de su conformidad con los estándares.

Figura 2. Pestaña de asignaciones en la demostración ODL híbrida FHIR

La plataforma incluye un generador integrado que genera datos clínicos sintéticos para pruebas de almacenamiento y recuperación, lo que permite a los equipos probar su funcionalidad. Los usuarios pueden personalizar el contenido sintético, incluyendo el número de pacientes, las consultas por paciente, los profesionales y los equipos de atención.

Figura 3: Creador de datos clínicos sintéticos

Una vez completados los datos, la sección Visor de Datos permite a los usuarios explorar los recursos FHIR almacenados en MongoDB. Muestra el contenido FHIR canónico y los campos ODL adicionales en un solo lugar, lo que explica cómo se integran los datos estándar y operativos.

La sección API del cliente integra los sistemas de salud heredados con la plataforma. Un probador de API permite a los usuarios acceder a los endpoints operativos y de MDM específicos del cliente. Al seleccionar un endpoint e introducir los parámetros necesarios, los usuarios pueden ejecutar la consulta y ver la respuesta con el formato que los sistemas personalizados esperan.

Por último, la sección Probador de API FHIR permite a los usuarios realizar búsquedas estándar FHIR en el dataset subyacente. Los resultados muestran la canalización de consulta MongoDB y la respuesta FHIR. Esta vista destaca cómo la plataforma mantiene un output conforme a los estándares FHIR, entrega perspectivas sobre el rendimiento y proporciona detalles de depuración.

Enfoque del modelo de datos

La arquitectura se basa en un esquema ODL centrado en FHIR y almacenado en MongoDB. En lugar de distribuir los datos de pacientes y encuentros en varias tablas, cada registro se conserva como un único documento con tres secciones. Cada sección cumple una función específica dentro del ODL:

• resource Para el contenido FHIR canónico: Contiene un 4 objeto FHIR R válido, como Patient Encountero. Este bloque puede ser devuelto directamente por los puntos finales de estilo FHIR sin transformación adicional.

• app Para los metadatos de la aplicación: Contiene los campos requeridos por los flujos de trabajo, pero que forman parte del recurso FHIR base. Incluye campos como códigos internos, indicadores de clasificación u otros atributos específicos del cliente.

• search Para la superficie de consulta desnormalizada: Aplana los atributos más utilizados en las consultas, incluyendo identificadores como nombres, fechas clave, organizaciones o referencias de ubicación. También convierte las claves de relación en campos fáciles de indexar y usar para la capa de API.

A continuación, puede encontrar un ejemplo JSON comentado para el recurso Encounter:

{
   "_id": "ObjectId",
   "tenant": "tenant-1",
   "resourceType": "Encounter",
   // 1 Canonical FHIR block
   "resource": {
      "resourceType": "Encounter",
      "id": "036fcfcd-797c-4ae2-a30f-49226357deb2",
      ...,
      "status": "onhold",
      "class": {
         "code": "EMER"
      },
      "serviceType": {
         ...
      },
      "period": {
         "start": "2025-10-31T17:43:00",
         "end": "2025-11-02T17:43:00"
      },
      "serviceProvider": {},
      "hospitalization": {},
      "participant": [],
      "location": [],
      "type": [
         { ... }
      ]
   },
   // 2 Application block
   "app": {
      "caseNum": "QH-1761928980-83",
      "doctorCode": "DR100",
      "specialistCode": "DR100",
      ...,
      "sourceIndicator": "SELF",
      "patientGroup": "G2"
   },
   // 3 Search block
   "search": {
      "start": "2025-10-31T17:43:00",
      "end": "2025-11-02T17:43:00",
      "local_id": "A108548(0)",
      ...,
      "caseNum": "QH-1761928980-83",
      "statusCode": "onhold",
      "caseType": "E"
   }
}

Construir la solución

Para obtener instrucciones detalladas de configuración, sigue los pasos descritos en el README de este repositorio de GitHub. Este repositorio aloja el backend y el front-end de esta demo.

Para reproducir esta demostración en su propio entorno, siga estos pasos:

git clone https://github.com/mongodb-industry-solutions/hybrid-fhir-odl.git
cd hybrid-odl

MONGODB_URI=mongodb+srv://<user>:<password>@<cluster-url>/?retryWrites=true&w=majority
MONGODB_DB=fhir_demo
MONGODB_COLLECTION=fhir
MONGODB_TENANT=tenant-1

NEXT_PUBLIC_ENABLE_FHIR = true
BACKEND_URL=http://localhost:3100

make install

make backend

make frontend

Aprendizajes clave

• Modernización de los sistemas de salud heredados: Esta solución muestra cómo los hospitales pueden actualizar su infraestructura de datos clínicos sin tener que abandonar sus flujos de trabajo operativos. En lugar de exigir que las instituciones mantengan sus servicios completamente personalizados o cambien completamente a FHIR, este enfoque permite integrar estos sistemas de manera incremental. Los datos siguen estando disponibles como recursos FHIR, y los endpoints de aplicaciones personalizadas y los patrones de query existentes continúan funcionando a través de la capa de API de la aplicación. Los hospitales que usan esta solución pueden modernizar progresivamente su infraestructura, trasladando a los equipos clínicos y sistemas asociados a su propio ritmo.

• Optimizar el rendimiento de los datos clínicos: Este enfoque permite que los datos FHIR permanezcan inalterados en el bloque de recursos para cumplir con los estándares, mientras que la información de la aplicación reside en atributos de alto uso, indexados para una búsqueda más rápida. El sistema es ideal para paneles clínicos en tiempo real, análisis operativos y búsquedas rápidas durante el registro, el triaje y la gestión de camas.

• Acelera la interoperabilidad y la productividad del desarrollador: la arquitectura dual de la API, la generación de datos sintéticos de funcionalidad incorporada y las herramientas interactivas de prueba de API ayudan a que los equipos prototipen, validen e implementen rápidamente soluciones compatibles con FHIR sin alterar los procesos hospitalarios existentes.

Autores

• Patricia Renart Carnicero, MongoDB

• Francesc Mateu Amengual, MongoDB

Obtén más información

• Atención médica impulsada por IA con MongoDB y Microsoft

• Venta minorista impulsada por IA: personalización y precisión

• RAG contextual para Docs técnicos