Sin interoperabilidad, la sanidad digital no funciona.

HL7, FHIR, DICOM, IHE. Los estándares que permiten que un sistema sanitario se entienda con otro — y la especialidad técnica que determina si tu proyecto llega a producción o se queda en piloto.

El problema

La capa de integración de la sanidad moderna.

Un hospital no es un sistema único. Es decenas de sistemas — HIS, RIS, PACS, LIS, anatomía patológica, farmacia, sistemas departamentales que un proveedor instaló hace quince años — que tienen que comportarse como si fueran uno. La imagen radiológica que un médico ve al lado de un informe ha atravesado cuatro sistemas y media docena de transformaciones de formato sin que el clínico tenga que saberlo.

Eso lo hace la interoperabilidad. Y cuando falla, la consecuencia no es un dashboard equivocado — es un retraso diagnóstico, una prueba duplicada, un dato perdido entre dos sistemas que tendrían que haberse entendido.

"Cuando falla la interoperabilidad, la consecuencia no es un dashboard equivocado. Es un retraso diagnóstico."
Estándares

Los estándares que aplicamos a diario.

01

HL7 versión 2.x — el lenguaje que sigue moviendo la sanidad real.

Treinta años después de su nacimiento, HL7 v2 sigue siendo el estándar de integración más usado en hospitales del mundo. ADT para movimientos del paciente, ORM/ORU para órdenes y resultados, MDM para documentos clínicos. Conocerlo en profundidad no es haberlo leído — es haber resuelto en producción las particularidades del sistema concreto que tienes delante. Eso se acumula con el tiempo.

02

HL7 FHIR — el estándar hacia el que el sector avanza.

FHIR está reordenando la interoperabilidad sanitaria a nivel internacional. APIs REST con recursos JSON, suscripciones, perfiles para casos de uso concretos, capacidad de extender sin romper la compatibilidad. Construimos servidores y clientes FHIR, definimos perfiles para casos específicos, e integramos con infraestructuras nacionales y europeas — incluida HCDSNS y los proyectos del Espacio Europeo de Datos Sanitarios.

03

DICOM — la imagen médica.

DICOM es mucho más que un formato de archivo. Es worklists, store, retrieve, modality performed procedure step, structured reports. Y la última década ha añadido DICOMweb sobre HTTP para integrar la imagen médica en arquitecturas modernas sin perder compatibilidad. Trabajamos con la pila completa, desde la estación radiológica hasta el archivo y la distribución multicentro.

04

IHE — los perfiles que las administraciones especifican.

Los perfiles IHE (Integrating the Healthcare Enterprise) son el "cómo se aplican estos estándares en un caso concreto". XDS para compartir documentos clínicos, XCA entre comunidades, PIX/PDQ para identificación de pacientes, ATNA para auditoría. Cuando una administración incluye IHE-compliance en un pliego, sabe lo que está pidiendo. Nosotros también.

05

Codificaciones clínicas.

SNOMED CT, CIE-10-ES, LOINC, ATC. Los catálogos terminológicos que dan sentido a los datos. El mapeo entre codificaciones no es una tabla — es trabajo de modelado clínico que mantiene la semántica entre sistemas con distintas formas de representar la realidad.

Casos

Casos de integración que resolvemos.

01

HIS con sistemas departamentales.

Conectar el sistema de información hospitalaria con RIS, LIS, anatomía patológica, agendas, farmacia. ADT que viaja en una dirección, órdenes que viajan en la otra, resultados que vuelven correlacionados con el episodio correcto. La capa que hace que un hospital funcione como un sistema coherente y no como aplicaciones inconexas.

02

Distribución de imagen entre centros.

Mover imagen médica entre instituciones manteniendo trazabilidad, autorización y rendimiento. Que un radiólogo en un centro pueda leer estudios de otro sin depender del soporte físico. La tecnología concreta — PACS federados, DICOMweb, almacenamiento en nube — se adapta a lo que cada entorno requiera.

03

Migración progresiva de HL7 v2 a FHIR.

La transición al mundo FHIR no es inmediata. Es un proceso de varios años en el que los dos mundos conviven. Construimos las capas de mediación que permiten que un sistema nuevo basado en FHIR se comunique con un parque legacy de v2 — y viceversa — sin interrumpir la operación clínica mientras tanto.

04

Integración con infraestructura nacional y europea.

HCDSNS, receta electrónica interoperable entre comunidades autónomas, proyectos del Espacio Europeo de Datos Sanitarios (EHDS). Cuando un sistema tiene que conectar con la infraestructura nacional o europea, hay un conjunto concreto de especificaciones que cumplir. Las conocemos en detalle.

05

Reporting epidemiológico y registros poblacionales.

Captura, validación y envío de datos a registros nacionales o autonómicos — cribados, enfermedades raras, registros de cáncer, vigilancia epidemiológica. Donde la calidad del dato y la trazabilidad son tan importantes como la oportunidad del envío.

La realidad

Por qué la interoperabilidad sanitaria no se improvisa.

El punto de partida habitual es pensar que el estándar resuelve el trabajo. No es así.

El estándar indica qué campos puede tener un mensaje. No dice cómo el HIS concreto que tienes delante interpreta el campo de prioridad. Ni qué hace cuando recibe un MFN de actualización de catálogo en medio de la lectura. Ni cómo responde el RIS heredado cuando le mandas un ORM con un código que no conoce.

La interoperabilidad real combina conocer el estándar, entender dónde el fabricante concreto se ha apartado de él, comprender el dominio clínico, y haber pasado tiempo frente a trazas de mensajes en producción. Es trabajo paciente y muy difícil de adquirir en poco tiempo.

Conocemos este terreno desde antes de que FHIR existiera. Cada nueva capa de estándares se construye sobre un edificio que ya conocemos desde los cimientos.

"Saber el estándar es la mitad. Saber dónde el fabricante se ha apartado del estándar es la otra mitad."
Enfoque

Sobre pilas open source de referencia.

Construimos la capa de interoperabilidad sobre dos pilas open source de referencia internacional en el sector: HAPI — para mensajería HL7 v2 y servidores/clientes FHIR — y dcm4che para la pila DICOM completa. Sobre ellas construimos la lógica específica del caso en .NET o Python según el contexto.

Aplicamos a los flujos de integración la misma observabilidad con OpenTelemetry que al resto — porque un mensaje sanitario perdido es un dato clínico perdido, y eso no puede descubrirse meses después.

¿Tienes un proyecto de interoperabilidad por delante?

Si lo que tienes encima de la mesa es una integración entre sistemas heterogéneos, una migración progresiva de HL7 v2 a FHIR, una conexión con la infraestructura nacional o europea, o un proyecto que se ha detenido en la fase de integración — hablemos.