Respuesta corta: un hospital utiliza docenas de sistemas, y la integración es el trabajo de hacer que todos estén de acuerdo sobre un paciente. En el centro se encuentra el HIS (sistema de información hospitalaria) o EHR, que posee la identidad del paciente, las admisiones y el registro clínico. A su alrededor: el sistema de laboratorio (LIS), radiología (RIS y PACS), farmacia, quirófano, urgencias, facturación, dispositivos (monitores, bombas de infusión) y, cada vez más, aplicaciones para pacientes, dispositivos vestibles y telemedicina. Un motor de interfaz en el medio recibe, transforma y enruta mensajes, de modo que cada sistema se conecta una sola vez en lugar de a todos los demás. El tráfico son principalmente mensajes HL7 v2 sobre MLLP para eventos (admisiones, pedidos, resultados), DICOM para imágenes, CDA o PDF para documentos, y FHIR sobre REST para cualquier cosa nueva, orientada al paciente o externa.
Los sistemas y lo que intercambian
El entorno de integración de un hospital está formado por el HIS o EHR, que gestiona la identidad del paciente, las visitas y el historial clínico, además del sistema de laboratorio, radiología (RIS y PACS), farmacia, dispositivos, aplicaciones para pacientes, telemedicina y sistemas regionales. Intercambian mensajes HL7 v2 como ADT, órdenes y resultados ORU, imágenes DICOM, documentos CDA y recursos FHIR.
| Sistema | Posee | Envía | Recibe |
|---|---|---|---|
| HIS / EHR | Identidad del paciente, encuentros, pedidos, el registro clínico | ADT (admisiones, traslados), pedidos ORM/OML, programación SIU | Resultados ORU, documentos MDM, cargos DFT |
| LIS (laboratorio) | Muestras, análisis, resultados, rangos de referencia | Resultados ORU^R01, respuestas de pedidos ORR | Pedidos ORM/OML, ADT para datos demográficos |
| RIS / PACS | Pedidos de imagen, listas de trabajo, informes, imágenes | Informes ORU, DICOM a visores, SIU | Pedidos ORM/OMI, ADT; DICOM MWL a modalidades |
| Farmacia | Formulario, dispensación, stock | Dispensación RDS, administración RAS | Pedidos de medicación OMP/RDE, ADT |
| Dispositivos y monitores | Signos vitales, formas de onda, alarmas | Observaciones ORU^R01 (IHE PCD), propietario | ADT para contexto del paciente |
| Portal del paciente / aplicaciones | Datos introducidos por el paciente, acceso | Observaciones FHIR, cuestionarios, mensajes | Lectura FHIR de resultados, citas, documentos |
| Telemedicina | Visitas por video, monitorización remota | Encuentro FHIR, Observación, ReferenciaDocumento | Cita, contexto del paciente, inicio SMART |
| Sistemas regionales y nacionales | Registros compartidos, registros, prescripción electrónica | Documentos CDA (XDS), FHIR, mensajes nacionales | Consultas, notificaciones |
El motor de interfaz
Un motor de interfaz es el centro de mensajería del hospital: recibe tráfico HL7 v2, FHIR, archivos y bases de datos de cada sistema, lo transforma y lo dirige a cualquier otro sistema que lo necesite, y gestiona colas, reintentos, monitorización y auditoría. Sin uno, N sistemas necesitan hasta N×(N−1)/2 interfaces creadas a mano; con uno, cada sistema se conecta una vez.
El motor (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare e IRIS for Health, Infor Cloverleaf, Qvera QIE, entre otros) proporciona listeners (MLLP, HTTP, archivos, bases de datos), transformaciones (mapear campos, corregir códigos, convertir v2 a FHIR), enrutamiento (enviar un ADT a ocho sistemas con ocho filtros), colación y reintentos, monitorización y auditoría. También es donde se reconcilia la identidad del paciente cuando los sistemas discrepan, y donde a menudo se crea una fachada FHIR sobre una base de datos heredada. Consulte Motores de interfaz explicados.
Los flujos que más importan
Los flujos de integración hospitalaria que más importan son ADT (altas, bajas, traslados y actualizaciones demográficas distribuidas desde el HIS), órdenes y resultados entre el EHR y el laboratorio o radiología, órdenes y dispensación de medicamentos, documentos como cartas de alta, datos de dispositivos de monitores, e intercambio de resultados, citas y mediciones en casa para el paciente a través de FHIR.
- ADT: cada admisión, alta, traslado, registro y actualización demográfica (A01, A03, A02, A04, A08, A40 merge) se difunde desde el HIS a todos los demás. Si el ADT es tardío o incorrecto, cada sistema descendente archiva datos bajo el paciente o encuentro incorrecto. Ver Mensajes HL7 v2 explicados.
- Pedidos y resultados: ORM/OML saliente, ORU de vuelta, con números de colocador y llenador que los vinculan; LOINC y UCUM en los resultados. Ver Mensajes de pedido HL7 v2 y Integración de un sistema de laboratorio con un EHR.
- Imágenes: pedidos al RIS, listas de trabajo DICOM a los escáneres, imágenes al PACS, informes de vuelta como ORU, visores a través de DICOMweb. Ver PACS vs RIS vs VNA.
- Medicamentos: pedidos a farmacia, dispensación y administración de vuelta, con el circuito cerrado (código de barras en el lugar de atención) como objetivo de seguridad.
- Documentos: cartas de alta, notas operatorias y documentos escaneados como mensajes MDM, CDA o PDFs en un repositorio de documentos, publicados en registros regionales.
- Dispositivos: monitores que alimentan signos vitales al registro a través de perfiles IHE PCD o pasarelas de proveedores, con gestión de alarmas como disciplina separada.
- Orientado al paciente: resultados, citas y documentos al portal y aplicaciones sobre FHIR; cuestionarios, mediciones en casa y datos de dispositivos vestibles de vuelta, con procedencia que los marca como informados por el paciente. Ver Monitorización remota de pacientes con FHIR.
Patrones que funcionan
Los patrones de integración hospitalaria que funcionan son: un sistema maestro para la identidad del paciente, con todos los demás suscritos a ADT; mapeo de códigos a LOINC, SNOMED CT y ATC una vez en el motor; acuses de recibo, colas y reintentos para cada mensaje; resultados y documentos idempotentes; una capa FHIR para aplicaciones de pacientes y socios externos; y entornos de prueba con pacientes sintéticos antes de la puesta en marcha.
- Un maestro para la identidad. El HIS (o un índice maestro de pacientes) posee los identificadores; todos los demás se suscriben a ADT y nunca inventan pacientes.
- Códigos en el límite. Mapear códigos locales a LOINC, SNOMED CT, ATC en el motor, una vez, y mantener el código local junto.
- Acusar recibo, poner en cola, reintentar. Cada mensaje v2 recibe un ACK; el motor persiste y reproduce; nadie pierde un resultado porque un sistema se estaba reiniciando.
- Idempotencia. Los resultados y documentos llevan identificadores; una reproducción actualiza en lugar de duplicar.
- Una capa FHIR para todo lo nuevo. Las aplicaciones para pacientes, la telemedicina, los extractos de investigación y los socios externos hablan FHIR a una fachada o a un servidor FHIR dedicado alimentado desde los flujos internos, en lugar de directamente al HIS.
- Entornos de prueba con pacientes sintéticos, y un paso de conformidad (perfiles IHE Connectathon, suites de prueba nacionales) antes de que algo toque producción.
Modos de fallo vistos en todas partes
Los modos de fallo observados en casi todas las integraciones hospitalarias son pacientes duplicados por errores tipográficos en el registro, resultados archivados en la visita incorrecta después de una fusión, códigos locales no mapeados, errores de zona horaria y horario de verano en las marcas de tiempo, unidades en texto libre, interfaces que se detienen silenciosamente sin monitorización, segmentos Z de proveedores que rompen los analizadores, y feeds CSV temporales que nunca se retiran.
Pacientes duplicados por errores tipográficos en el registro; resultados archivados en el encuentro equivocado después de una fusión; códigos de prueba locales que nadie mapeó; zonas horarias y horario de verano en las marcas de tiempo de los mensajes; unidades en texto libre; una interfaz que se detuvo silenciosamente y nadie la monitorizó; segmentos Z específicos del proveedor que rompen los analizadores; y el feed CSV "temporal" que todavía funciona diez años después.
Dónde FHIR está cambiando el panorama
FHIR está cambiando la integración hospitalaria en los bordes en lugar del núcleo. Dentro del edificio, HL7 v2 y DICOM permanecen porque los analizadores, escáneres y módulos heredados los utilizan; FHIR se encarga del acceso del paciente, las aplicaciones SMART on FHIR, el soporte de decisiones CDS Hooks, las suscripciones, el intercambio regional y nacional bajo EHDS y TEFCA, y las extracciones para investigación.
Internamente, HL7 v2 y DICOM permanecen durante años, porque cada analizador, escáner y módulo heredado los habla. FHIR gana en los bordes: acceso del paciente, aplicaciones lanzadas dentro del EHR (SMART on FHIR), soporte de decisiones (CDS Hooks), suscripciones para integración basada en eventos, intercambio regional y nacional bajo el EHDS y TEFCA, y extractos de investigación. Muchos hospitales ahora ejecutan un servidor FHIR alimentado por el motor como su capa de integración para todo lo que está fuera del edificio; ver Estándares de interoperabilidad sanitaria: el mapa.
En Anpheros
Anpheros Platform se sitúa en el borde FHIR de la integración hospitalaria: un registro FHIR R4 al que un hospital o clínica puede escribir y del que puede leer con el consentimiento del paciente, alimentado por la propia integración del hospital a través del conector de laboratorio (HL7 v2 ORU, CSV o JSON), con webhooks y procedencia por fuente. No reemplaza al HIS ni al motor.
Anpheros Platform se encuentra en ese borde: un registro FHIR R4 al que un hospital o clínica puede escribir y leer con el consentimiento del paciente, alimentado por la propia integración del hospital (el conector de laboratorio toma HL7 v2 ORU, CSV o JSON), con webhooks para notificación de cambios y procedencia por fuente. No reemplaza al HIS ni al motor; le da al paciente un registro que lo acompaña fuera del edificio.
Páginas relacionadas
- Motores de interfaz explicados
- Cómo integrar un sistema de laboratorio con un EHR
- Mensajes HL7 v2 explicados: ADT y ORU
- PACS vs RIS vs VNA
- Monitorización remota de pacientes con FHIR
- Estándares de interoperabilidad sanitaria: el mapa
- Integrar sistemas de clínica con FHIR (sitio para desarrolladores)
Fuentes
- Suite de productos HL7 Version 2
- Marco técnico de infraestructura IHE IT
- Dominio IHE Dispositivos (perfiles de Dispositivos de Atención al Paciente)
- HL7 FHIR R4: Mensajería y flujo de trabajo
- Guía de implementación de HL7 v2 a FHIR
Preguntas frecuentes
¿Debería un nuevo hospital integrar todo con FHIR?
No todo. Los analizadores, escáneres y la mayoría de los sistemas departamentales hablan HL7 v2 y DICOM, y eso no cambiará pronto. Utilice FHIR para integraciones orientadas al paciente, externas y nuevas, y un motor para tender puentes.
¿Cuál es la diferencia entre un HIS y un EHR?
El uso varía según el país. HIS a menudo significa el sistema hospitalario administrativo y clínico juntos; EHR enfatiza el registro clínico. En términos de integración, ambos son el sistema que posee la identidad, los encuentros y el registro.
¿Cuántas interfaces tiene un hospital de tamaño mediano?
Típicamente entre cincuenta y unos pocos cientos de flujos de mensajes a través del motor, contando cada dirección y cada sistema receptor. La pantalla de monitorización del motor es donde viven los equipos de integración.
¿Quién es el responsable de la integración en un hospital?
El equipo de integración de TI del hospital, generalmente con el apoyo del proveedor del motor, y cada proveedor departamental por su parte. Los programas nacionales y los perfiles IHE reducen pero no eliminan el trabajo del proyecto.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →