Capa de Datos Operativos Híbrida FHIR

Descripción general de la solución

Este proyecto desarrolla un patrón FHIR híbrido ODL para el cuidado de la salud. El objetivo primario es crear una única tienda operativa de alto rendimiento que impulse los servicios web para los clientes. Además, el diseño expone puntos finales compatibles con FHIR para los recursos que se cubren, permitiendo que las futuras funcionalidades se compilen con 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 query.

Porque los mapeos se definen con FHIR en primer lugar, los campos alineados con FHIR se almacenan utilizando la estructura estándar, mientras que los atributos restantes se mantienen en bloques de aplicación separados. Esta estructura híbrida preserva la interoperabilidad sin obligar a que la solución actúe como un servidor FHIR completo.

El backend utiliza FastAPI y expone dos familias de APIs:

• 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.

• FHIR API: proporciona una búsqueda compatible con FHIR para un subconjunto definido de recursos, tales como Patient y Encounter, reutilizando el mismo modelo de sobre e índices. Está diseñado como una fachada pragmática de FHIR, no como un servidor FHIR completo impulsado por perfiles.

El frontend utiliza Next.js e incluye un demostrador interactivo de API, para que los equipos puedan probar juntos los endpoints de la aplicación y las consultas al estilo FHIR.

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

Arquitecturas de Referencia

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

El caso de uso surge de un desafío real de un cliente que implica a una gran institución del sector salud que opera múltiples plataformas de EHR. Cada sistema ofrecía servicios de acceso para pacientes de forma independiente, lo que provocaba acceso fragmentado a los datos, lógica duplicada y ausencia 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ó una oportunidad para avanzar hacia las mejores prácticas de la industria adoptando FHIR como el lenguaje común, en lugar de redefinir las estructuras y la semántica de los datos desde cero. Al diseñar el modelo de datos de ODL como FHIR-first, la organización evitó “reinventar la rueda” para conceptos básicos como pacientes y encuentros. También se alineó con las definiciones estándar de recursos, lo que lo convierte en un posible modelo para otros en el campo.

La arquitectura de referencia muestra cómo las empresas de salud pueden unificar diferentes fuentes de datos, admitir procesos personalizados y ofrecer APIs altamente eficientes usando MongoDB Atlas. La interfaz está dividida en pestañas, con cada pestaña mostrando una capacidad específica de la arquitectura.

Figura 1. Arquitectura de referencia ODL híbrido de FHIR

Inicialmente, la sección de mapeo muestra cómo los campos de datos de atención médica heredados se asignan al modelo de datos ODL, que está 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 entre entidades como Patient y Encounter en una tabla interactiva. Esto les ayuda a entender qué campos provienen de la especificación FHIR y cuáles se modelan como campos específicos de la aplicación o de búsqueda. Esta estrategia de asignación facilita trazar el linaje de datos y evaluar la alineación con los estándares.

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

La plataforma incluye un generador incorporado que crea datos clínicos sintéticos para pruebas de almacenamiento y recuperación, permitiendo a los equipos probar la funcionalidad. Los usuarios pueden personalizar el contenido sintético, incluido el número de pacientes, encuentros por paciente, profesionales y equipos de atención.

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

Después de que se complete la carga de datos, la sección "Visor de datos" permitirá 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, aclarando cómo coexisten los datos estándar y operacionales.

La sección de API de clientes integra los sistemas de salud heredados con la plataforma. Un probador de API permite a los usuarios llamar a endpoints operativos y MDM específicos de clientes. Al seleccionar un endpoint e ingresar los parámetros requeridos, los usuarios pueden ejecutar la query y ver la respuesta formateada como esperan los sistemas a medida.

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 de modelo de datos

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

• resource para el contenido canónico de FHIR: Contiene un objeto válido R4 FHIR, como Patient o Encounter. Este bloque puede ser devuelto directamente por los endpoints de estilo FHIR sin transformación adicional.

• app para los metadatos de la aplicación: Contiene campos que los flujos de trabajo necesitan y 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 query desnormalizada: Aplana los atributos más utilizados en queries, incluidos identificadores como nombres, fechas clave, organizaciones o referencias de ubicación. También convierte las claves de relación en campos que son fáciles de indexar y de usar para la capa de API.

A continuación, puedes encontrar un ejemplo de 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"
   }
}

Compilar 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 demo en tu propio entorno, sigue 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

Lecciones 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 sin cambios en el bloque de recursos para el cumplimiento de estándares, mientras que la información de la aplicación se encuentra en atributos de alto uso, indexados para un rendimiento de búsqueda más rápido. El sistema es adecuado para tableros 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 potenciada por IA: Personalización y precisión
• RAG contextual para Docs técnicos