Capa de datos operativos FHIR híbridos

Resumen de la solución

Este proyecto desarrolla una FHIR patrón híbrido ODL para el sector sanitario. El objetivo principal es crear una única tienda de operaciones altamente eficiente que impulse los servicios web para clientes. Además, el diseño expone Compatible con FHIR puntos finales para los recursos en alcance, para que futuras funcionalidades se puedan compilar utilizando la FHIR REST API 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.

• 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 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 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 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 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ó 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íbrida 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 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 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 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 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 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 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 impulsada por IA: personalización y precisión

• RAG contextual para Docs técnicos