Construcción de microservicios sanitarios: un enfoque nativo en FHIR

Arquitectura de microservicios sanitarios

Los microservicios son un patrón de arquitectura ampliamente adoptado que estructura las aplicaciones como un conjunto de servicios débilmente acoplados e implementables de forma independiente. Este enfoque permite que múltiples equipos desarrollen componentes en paralelo utilizando diferentes lenguajes de programación. Cada equipo puede elegir la mejor tecnología para su servicio específico y escalarlo según sus necesidades particulares sin afectar a otros servicios.

Por ejemplo, en un sistema sanitario:

• El servicio de Registro de Pacientes podría estar escrito en Java y gestionar 1000 solicitudes/minuto
• El servicio de Programación de Citas podría estar en Node.js y gestionar 500 solicitudes/minuto
• El servicio de Apoyo a la Decisión Clínica podría usar Python con TensorFlow para procesar 2000 casos de pacientes/minuto, analizando resultados de laboratorio y sugiriendo diagnósticos

Un desafío clave en la arquitectura de microservicios radica en la gestión de la comunicación entre servicios. Las APIs deben estar bien definidas y ser estables para garantizar una interacción fluida manteniendo la independencia de los servicios.

Aquí es donde entra en juego HL7 FHIR (Fast Healthcare Interoperability Resources).

Por qué FHIR es adecuado para arquitecturas de microservicios

Desarrollado inicialmente como estándar de interoperabilidad, FHIR ofrece varias ventajas clave que lo hacen especialmente apropiado para arquitecturas de microservicios:

1. Modelo de dominio predefinido

Contar con un modelo de dominio bien definido es fundamental para las arquitecturas de microservicios. Modificar el modelo puede afectar a las APIs expuestas, lo que requiere coordinación entre los equipos.

Por ejemplo, añadir un nuevo campo «preferredPharmacy» al recurso Patient requeriría actualizaciones en el servicio de Gestión de Pacientes, el servicio de Medicación, la interfaz del Portal del Paciente y todas sus APIs, lo que exige una coordinación cuidadosa entre múltiples equipos.

FHIR proporciona:

• Recursos específicos para la sanidad: Un conjunto completo de 145 recursos listos para usar (Patient, Encounter, Observation, etc.) desarrollados por expertos del dominio sanitario a través de miles de horas de trabajo colaborativo. Cada tipo de recurso es una raíz agregada en términos de DDD (Domain Driven Design).
• Marco de extensibilidad: Capacidad para extender y restringir recursos base para casos de uso específicos mediante Profiling. Por ejemplo, puede añadir extensiones al recurso Patient para almacenar información no incluida en la especificación FHIR, o hacer obligatorios algunos elementos del recurso Patient sin vulnerar las reglas de interoperabilidad. Consulte el US Core Patient Profile como ejemplo.
• Guías de implementación: Esquemas listos para usar para implementar dominios sanitarios específicos en FHIR. Estas guías proporcionan extensiones, perfiles y operaciones para subdominios particulares (como Programación, Oncología, etc.).

2. Gestión estandarizada de Terminology

Existen varios sistemas de códigos de gran tamaño y amplio uso en el ámbito sanitario:

• SNOMED CT (más de 350 000 conceptos médicos)
• LOINC (casi 100 000 códigos de pruebas de laboratorio)
• ICD-10 (alrededor de 70 000 códigos de diagnóstico)
• RxNorm (más de 100 000 códigos de medicamentos)
• etc.

Diseñar una forma de almacenar y utilizar conceptos de estos sistemas de códigos en sus microservicios es todo un reto. Por ejemplo, al registrar el diagnóstico de un paciente:

• El código «I21.3» en ICD-10 significa «infarto agudo de miocardio con elevación del ST de localización no especificada»
• La misma afección en SNOMED CT es «401303003»
• Distintos servicios pueden usar diferentes sistemas de códigos
• Los códigos deben validarse y mapearse entre sistemas
• Los sistemas de códigos se actualizan periódicamente con nuevas versiones

FHIR proporciona:

• Sistemas de codificación integrados: Compatibilidad con terminologías médicas estándar (SNOMED CT, LOINC, ICD-10, RxNorm, etc.)
• Servicios de vocabulario: APIs estándar para validación y consulta de Terminology. Por ejemplo: cuando un clínico introduce el diagnóstico de un paciente en un sistema de historia clínica electrónica, en lugar de teclear el diagnóstico manualmente, lo selecciona desde un servicio de Terminology de FHIR que proporciona códigos SNOMED CT en tiempo real. Una vez introducidos, los datos pueden ser validados por el servidor FHIR antes de almacenarse como recurso Condition.
• Gestión de Value Sets: Enfoque definido para gestionar conjuntos de códigos. Por ejemplo: puede definir un subconjunto reutilizable de códigos SNOMED CT como recurso ValueSet para ofrecer a los clínicos una lista enfocada de códigos de diagnóstico relevantes para su especialidad.
• Mapeo entre versiones: Compatibilidad con el versionado y el mapeo de Terminology. Por ejemplo: si ICD-10 se actualiza, el sistema puede mapear los códigos de diagnóstico antiguos a los nuevos.

3. Modelo de API predefinido

La gestión de APIs es una parte esencial de la arquitectura de microservicios. Es necesario diseñar los patrones de comunicación para las interacciones síncronas y asíncronas entre servicios.

Por ejemplo, considere un flujo de trabajo de alta hospitalaria:

• El servicio Clínico necesita verificar de forma síncrona si los medicamentos están disponibles
• El servicio de Farmacia debe ser notificado de forma asíncrona para preparar los medicamentos
• El servicio de Programación debe ser notificado para reservar las citas de seguimiento
• El servicio de Facturación debe recibir el resumen final del alta

Sin patrones estandarizados, cada una de estas interacciones requeriría un diseño e implementación de API personalizados.

FHIR lo hace por usted.

• Interfaz RESTful: Operaciones CRUD estándar alineadas con los métodos HTTP.
• Soporte de transacciones: Soporte integrado para operaciones atómicas sobre múltiples recursos que evitan actualizaciones parciales peligrosas. Por ejemplo: al prescribir medicación para un nuevo diagnóstico, o bien ambos —el diagnóstico y la orden de medicación— se guardan juntos, o bien ninguno se guarda. Esto evita situaciones peligrosas en las que existe una medicación sin su diagnóstico asociado, o viceversa, lo que podría dar lugar a errores médicos. Si cualquier parte de la transacción falla (por ejemplo, una verificación de interacción medicamentosa), toda la operación se revierte automáticamente.
• Marco de búsqueda: Capacidades de búsqueda completas con parámetros estándar. Por ejemplo: puede crear una única consulta FHIR Search que devuelva todos los Patients que han dado su consentimiento para compartir datos con un determinado Practitioner e incluir el Encounter relacionado en los resultados de búsqueda:

GET /fhir/Patient?_has:Consent:patient:actor=<practitioner-id>&_has:Consent:patient:scope=Encounter&_revinclude=Encounter:subject

• Marco de Subscriptions: Soporte integrado para comunicación basada en eventos: las aplicaciones pueden reaccionar ante cambios en los recursos. Por ejemplo: si se actualiza un resultado de laboratorio, el sistema del médico recibe una alerta automática.

Arquitectura objetivo de una solución de microservicios nativa en FHIR

El primer paso para construir una solución de microservicios nativa en FHIR es decidir el almacenamiento de datos.

Dos patrones habituales son:

• Base de datos (servidor FHIR) por servicio: cada servicio tiene su propio almacenamiento FHIR aislado
• Base de datos compartida (servidor FHIR): todos los servicios utilizan el servidor FHIR compartido para almacenar todos los recursos FHIR

La arquitectura de base de datos por servicio contribuye a garantizar que los servicios estén débilmente acoplados. Los cambios en la base de datos de un servicio no afectan a ningún otro servicio. Los inconvenientes son:

• Gestión e implementación de múltiples servidores FHIR
• Esfuerzo adicional para implementar transacciones que abarquen múltiples servicios
• Mayor complejidad al implementar búsquedas entre servicios

La base de datos compartida parece más natural para una solución de microservicios nativa en FHIR, por los siguientes beneficios:

• Menor esfuerzo de implementación: Operaciones CRUD y capacidades de búsqueda predefinidas para todos los recursos

• Soporte de transacciones integrado entre recursos

• Gestión simplificada de la consistencia de datos

• Consistencia de datos: Fuente única de verdad para todos los recursos FHIR

• Transacciones atómicas entre múltiples recursos

• Gestión más sencilla de la integridad referencial

• Menor riesgo de acoplamiento: Aunque las bases de datos compartidas suelen generar un acoplamiento estrecho, este riesgo se mitiga en las arquitecturas nativas en FHIR. El modelo FHIR es inherentemente estable y extensible, lo que elimina la necesidad de cambios de esquema coordinados

El siguiente diagrama ilustra la arquitectura objetivo de una solución de microservicios nativa en FHIR:

Componentes principales de la arquitectura

• Servicios sanitarios

Microservicios específicos de dominio que implementan la lógica de negocio para distintos flujos de trabajo sanitarios (por ejemplo, gestión de pacientes, programación, documentación clínica). Interactúan con el servidor FHIR a través de APIs REST FHIR estándar y consumen eventos mediante Subscriptions.

• Servidor FHIR: Almacenamiento de datos compartido que: proporciona APIs FHIR para el almacenamiento, recuperación y búsqueda de recursos

• Notifica a los consumidores de eventos relacionados con recursos mediante subscriptions

• Gestiona la validación de datos.

• Servidor de Terminology

Gestiona vocabularios y sistemas de códigos sanitarios (SNOMED CT, LOINC, ICD-10, etc.). Proporciona operaciones de validación, consulta y mapeo de Terminology para garantizar la interoperabilidad semántica en toda la plataforma.

• Servicios de infraestructura y seguridad: Aspectos transversales que incluyen: autenticación y autorización
• API gateway y enrutamiento
• Registro de auditoría y monitorización
• PACS (Picture Archiving and Communication System)

Pasos para construir un sistema nativo en FHIR con arquitectura de microservicios

El enfoque de implementación difiere significativamente entre proyectos nuevos y la modernización de sistemas heredados. Mientras que los sistemas nuevos pueden diseñarse con principios nativos en FHIR desde el principio, los sistemas sanitarios existentes requieren una estrategia de migración cuidadosa.

Proyecto nuevo (greenfield)

Para nuevos sistemas sanitarios, puede implementar los principios nativos en FHIR desde el inicio siguiendo estos pasos:

• Descomposición de dominio orientada a recursos: Mapear los dominios de negocio a recursos FHIR Ejemplo de mapeo: Gestión de Pacientes → Patient, Person, RelatedPerson

• Programación → Appointment, Schedule, Slot

• Documentación Clínica → Observation, DiagnosticReport, Condition

• Definir los límites entre microservicios Aunque los límites óptimos de los servicios dependen en gran medida de su caso de uso específico y del contexto del sistema, aquí se ofrecen algunas pautas para facilitar la decisión:- FHIR proporciona orientación sobre cómo organizar los recursos en grupos lógicos: https://hl7.org/fhir/overview-arch.html#organizing

• Consulte las guías de implementación FHIR (IGs) relevantes para orientación específica del dominio, por ejemplo para programación: https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html

• Las definiciones de recursos en la especificación FHIR también son una buena fuente de inspiración, ya que a menudo proporcionan información sobre recursos relacionados y su uso previsto. Por ejemplo: https://hl7.org/fhir/appointment.html#scope

• Configuración de la infraestructura: Desplegar un servidor FHIR de grado productivo

• Implementar servicios de seguridad y autenticación

• Configurar la infraestructura de monitorización y registro

• Configurar los servicios de Terminology

• Implementación de servicios Comenzar con los servicios principales (gestión de pacientes, programación)

• Usar las APIs CRUD y Search FHIR del servidor FHIR para trabajar con recursos FHIR desde los microservicios

• Implementar la lógica de negocio en los microservicios diseñando e implementando operaciones sobre recursos FHIR. Tomar inspiración de la especificación FHIR o de las guías de implementación. Por ejemplo, el FHIR Scheduling IG ha definido un conjunto de operaciones para la gestión de citas

Arquitectura de ejemplo

Implementar servicios adicionales

Implementar servicios adicionales (por ejemplo, recopilación de comentarios)

• Añadir funcionalidades (por ejemplo, notificaciones)

• Usar FHIR Subscriptions para la comunicación orientada a eventos

Modernización de sistemas heredados

• Selección estratégica de servicios: Elegir un servicio inicial bien delimitado para la prueba de concepto (POC)

• Considerar candidatos de alto valor y bajo riesgo, como el Portal del Paciente o el Índice Maestro de Pacientes

• Arquitectura de integración

Establecer una integración bidireccional entre los sistemas heredados y los nuevos microservicios nativos en FHIR.

Ampliar gradualmente la presencia nativa en FHIR

Migrar servicios adicionales de forma incremental:

Validar el servicio POC en el entorno de producción

• Identificar y priorizar los servicios siguientes para la migración

• Ampliar gradualmente la presencia nativa en FHIR añadiendo nuevos microservicios y migrando los existentes

Ejemplo: Portal del Paciente que permite a los pacientes programar y gestionar sus visitas

Paso 1: Comenzar con una POC: un portal del paciente que permita a los pacientes consultar su información y sus citas. Paso 2: Añadir un nuevo servicio para la programación de citas. Paso 3: Añadir un servicio adicional para recopilar las opiniones de los pacientes sobre las visitas.

Conclusión

Aunque adoptar un enfoque nativo en FHIR requiere una inversión inicial en el aprendizaje del estándar FHIR y sus patrones de implementación, los beneficios a largo plazo superan con creces la curva de aprendizaje inicial.

Una plataforma nativa en FHIR es:

• A prueba de futuro – Garantiza la interoperabilidad a largo plazo con otros sistemas sanitarios
• Eficaz – Reduce el tiempo de desarrollo mediante patrones estandarizados
• Robusta – Aprovecha un estándar maduro y específico para la sanidad
• Conforme – Simplifica el cumplimiento de normativas como los perfiles US Core para la 21st Century Cures Act
• Ecosistema enriquecido – Se beneficia del creciente ecosistema FHIR de herramientas e implementaciones

¿Está listo para implementar microservicios nativos en FHIR en su organización sanitaria? En Health Samurai, hemos ayudado a decenas de organizaciones sanitarias a realizar con éxito la transición a plataformas nativas en FHIR. Ya sea que esté iniciando un nuevo proyecto o modernizando sistemas heredados, nuestro equipo puede ayudarle.

Conéctese conmigo, Aleksandr Kislitsyn, en LinkedIn para hablar sobre su caso de uso específico y conocer cómo podemos ayudarle a alcanzar sus objetivos de interoperabilidad sanitaria.

Véase también: Por qué necesita un servidor FHIR independiente.