El sistema sanitario por dentro · Módulo 13 · Ficha resumen

Interoperabilidad y máquinas

HL7 v2, FHIR, DICOM y PACS, perfiles IHE, monitores y constantes, motores de integración, terminologías e identificación del paciente.

Qué es interoperar: niveles, paradigmas y motor de integración

Las tres dimensiones de la interoperabilidad, mensajes, documentos y API, y por qué un hospital centraliza sus interfaces en un motor de integración.

Una definición oficial y tres dimensiones
Por qué la sanidad necesita interoperar
Tres paradigmas: mensajes, documentos y API
De la telaraña punto a punto al motor
Qué hace un motor de integración
El marco europeo que llega: el EEDS
Caso práctico
Qué implica para los sistemas

Interoperabilidad: Capacidad de los sistemas de información, y de los procedimientos a los que dan soporte, de compartir datos e intercambiar información y conocimiento (Real Decreto 4/2010).
Interoperabilidad técnica: Dimensión de la interoperabilidad que trata de interfaces, interconexión, integración de datos y servicios, presentación y seguridad entre sistemas.
Interoperabilidad semántica: Dimensión de la interoperabilidad que consigue que la información intercambiada se interprete de forma automática y la reutilicen aplicaciones que no intervinieron en su creación.
Interoperabilidad organizativa: Dimensión de la interoperabilidad que trata de que las entidades y sus procesos colaboren para alcanzar logros acordados en los servicios que prestan.
Motor de integración: Pieza central de una red de interfaces: recibe los mensajes de cada sistema, los valida, transforma y enruta a sus destinos, y deja traza de cada intercambio.
Interfaz punto a punto: Conexión directa entre dos sistemas, hecha a medida para ese par. Con muchos sistemas, el número de conexiones crece muy deprisa y cada cambio obliga a tocar varias.
EEDS: Espacio Europeo de Datos de Salud: marco creado por el Reglamento (UE) 2025/327 para el acceso de las personas a sus datos de salud y su intercambio en la UE, y para su reutilización.
Formato europeo de intercambio de historias clínicas electrónicas: Especificación común, legible por máquina, que fijará la Comisión Europea para las categorías prioritarias de datos de salud del EEDS.

HL7 v2: admisiones, peticiones y resultados

Cómo se construye un mensaje HL7 v2, qué eventos ADT avisan de ingresos y altas, y cómo viajan peticiones y resultados con ORM, OML y ORU.

Un estándar nacido de los eventos
Anatomía de un mensaje
ADT: el pulso del hospital
Peticiones: ORM y OML
Resultados: ORU
Acuses, transporte y dialectos
Caso práctico
Qué implica para los sistemas

HL7 v2: Estándar de mensajería de HL7 basado en eventos: un hecho asistencial dispara un mensaje de texto, formado por segmentos y campos separados por delimitadores, hacia los sistemas interesados.
Evento disparador: Hecho real (un ingreso, un resultado disponible) que crea la necesidad de enviar datos a otros sistemas. En HL7 v2 se codifica en la tabla 0003, por ejemplo A01 o R01.
Segmento: Línea de un mensaje HL7 v2 que agrupa datos de un tema, identificada por tres caracteres: MSH (cabecera), PID (paciente), PV1 (visita), OBX (resultado).
ADT: Admission, discharge and transfer: familia de mensajes HL7 v2 que comunica ingresos, altas, traslados, registros y cambios de datos del paciente.
ORU: Mensaje HL7 v2 de observaciones no solicitadas: el sistema que produce un resultado lo envía sin que se lo pidan (evento R01).
OML: Mensaje HL7 v2 específico para peticiones de laboratorio (eventos O21 y O33, entre otros).
ORM: Mensaje HL7 v2 de petición general (evento O01), usado históricamente para pedir pruebas y servicios a otros departamentos.
ACK: Mensaje de acuse de recibo de HL7 v2. Su segmento MSA dice si el receptor aceptó (AA), encontró un error (AE) o rechazó (AR) el mensaje.
Segmento Z: Segmento propio que una implementación añade a HL7 v2 para datos no previstos por el estándar. Su significado solo lo conoce quien lo pactó.

FHIR: recursos, API web y perfiles

Qué aporta FHIR frente a HL7 v2: recursos modulares, una API REST con JSON, perfiles y guías de implementación, y el resumen internacional de paciente.

Qué es FHIR y de dónde viene
Recursos: piezas pequeñas y enlazadas
La API: leer, buscar y crear por la web
Perfiles y guías de implementación
Un ejemplo de guía: el resumen de paciente
Caso práctico
Qué implica para los sistemas

Recurso FHIR: Unidad modular de información de FHIR, con estructura definida e identificador propio: Patient, Encounter, Observation, ServiceRequest, DiagnosticReport…
Perfil FHIR: Conjunto de restricciones sobre un recurso base para un uso concreto: qué elementos son obligatorios, qué códigos se admiten, qué extensiones se añaden.
Extensión FHIR: Elemento añadido a un recurso, identificado por una dirección web única que define su significado, para recoger datos que el núcleo del estándar no prevé.
Guía de implementación: Conjunto coherente de perfiles, extensiones y reglas publicado como una unidad para una comunidad: internacional, nacional, regional o de una sola institución.
IPS: International Patient Summary: conjunto mínimo de datos clínicos de una persona, pensado para la atención no planificada y transfronteriza; lo especifica la norma ISO 27269.
REST: Estilo de arquitectura web en que cada recurso tiene su dirección y se manipula con las operaciones estándar del protocolo HTTP: leer, crear, actualizar, borrar, buscar.

DICOM, PACS y el flujo de trabajo de la imagen

Cómo se identifica y guarda una imagen médica con DICOM, qué servicios unen la petición, el equipo y el PACS, y qué ordena el perfil IHE de flujo programado.

Qué es DICOM
La jerarquía: paciente, estudio, serie, instancia
Los servicios que mueven la imagen
El PACS y el RIS
El flujo programado: el perfil SWF.b
Caso práctico
Qué implica para los sistemas

Estudio DICOM: Conjunto de series de imágenes y objetos de una misma exploración de un paciente. Lo identifica de forma única el Study Instance UID.
Accession Number: Número que identifica la petición o el procedimiento de imagen en el sistema del servicio. Une la orden, las imágenes del PACS y el informe.
Modality Worklist: Servicio DICOM con el que el equipo de imagen consulta la lista de exploraciones programadas y recibe los datos del paciente y de la petición sin teclearlos.
MPPS: Modality Performed Procedure Step: servicio DICOM con el que el equipo avisa de que una exploración ha empezado y ha terminado, y de qué se hizo realmente.
Storage Commitment: Servicio DICOM con el que el archivo confirma al equipo que ha asumido la custodia de las imágenes, para que el equipo pueda borrarlas sin riesgo.
DICOMweb: Servicios web de DICOM (parte 18) para buscar (QIDO-RS), recuperar (WADO-RS) y almacenar (STOW-RS) objetos DICOM por HTTP.
SWF.b: Perfil IHE de radiología Scheduled Workflow.b: ordena el flujo desde el registro del paciente y la petición hasta la adquisición, el archivo y la disponibilidad de las imágenes.
RIS: Radiology information system: sistema departamental que gestiona las peticiones, la agenda, la realización y el informe de las pruebas de imagen.

Perfiles IHE y la integración de monitores y constantes

Qué es un perfil IHE, los de identidad y documentos (PIX, PDQ, XDS.b) y cómo llegan a la historia clínica los datos de monitores, respiradores y bombas.

IHE: de los estándares a los perfiles
Los perfiles de identidad: PIX y PDQ
Compartir documentos: XDS.b y su familia
Monitores y constantes: el perfil DEC
Semántica de dispositivos: 11073 y RTM
Caso práctico
Qué implica para los sistemas

Perfil de integración IHE: Especificación que resuelve un caso de uso concreto combinando estándares existentes (HL7, DICOM…): define actores, transacciones y opciones.
Actor IHE: Papel funcional de un sistema dentro de un perfil IHE (por ejemplo, quien envía datos de dispositivos o quien los consume). Un mismo producto puede hacer de varios actores.
Declaración de integración IHE: Documento en que un fabricante declara qué perfiles, actores y opciones IHE implementa su producto.
PIX: Patient Identifier Cross-referencing: perfil IHE que relaciona los identificadores que una misma persona tiene en distintos dominios de identificación.
PDQ: Patient Demographics Query: perfil IHE para consultar a un servidor de datos de pacientes una lista de candidatos según criterios demográficos.
XDS: Cross-Enterprise Document Sharing (hoy XDS.b): perfil IHE para registrar, distribuir y consultar documentos clínicos entre organizaciones de un mismo dominio de afinidad.
DEC: Device Enterprise Communication: perfil IHE que lleva los datos de dispositivos de cabecera (monitores, respiradores, bombas) a los sistemas corporativos con una semántica común.
RTM: Rosetta Terminology Mapping: conjunto de valores de IHE que armoniza los términos, unidades y valores de los dispositivos médicos con la nomenclatura ISO/IEEE 11073-10101.

Terminologías e identificación del paciente

SNOMED CT, LOINC y UCUM para que un dato signifique lo mismo en todas partes, y TSI, CIP y CIP-SNS para que se refiera a la misma persona.

Por qué no basta con el texto
SNOMED CT, la terminología de referencia
LOINC y UCUM: pruebas y unidades
El conjunto mínimo de los informes clínicos
Identificar al paciente: de la historia al CIP-SNS
La Historia Clínica Digital del SNS
Caso práctico
Qué implica para los sistemas

SNOMED CT: Terminología clínica multilingüe y codificada para registrar e intercambiar datos clínicos. Es la terminología de referencia del SNS por acuerdo del Consejo Interterritorial.
Concepto SNOMED CT: Significado clínico identificado por un código numérico único e invariable (conceptId), con descripciones en varios idiomas y relaciones con otros conceptos.
LOINC: Logical Observation Identifiers Names and Codes: códigos para identificar pruebas de laboratorio y otras observaciones. Lo mantiene el Regenstrief Institute.
UCUM: Unified Code for Units of Measure: sistema de códigos para expresar todas las unidades de medida de forma inequívoca.
Terminología frente a clasificación: Una terminología (SNOMED CT) representa el detalle clínico para la asistencia; una clasificación (CIE-10-ES) agrupa en categorías para estadística, gestión y financiación.
CMDIC: Conjunto mínimo de datos de los informes clínicos: los datos y códigos que deben llevar los informes clínicos del SNS según el Real Decreto 1093/2010.
Texto codificado: Tipo de dato del Real Decreto 1093/2010 formado por el identificador de la fuente (un OID), el código que permite la interoperabilidad y el término legible.
Servidor de terminologías del SNS: Plataforma del Ministerio de Sanidad, en producción desde 2023, que distribuye SNOMED CT, CIE-10-ES, LOINC y otros recursos, con servicios REST y FHIR.
Dominio de identificación: Ámbito en que un identificador de paciente es único: un hospital (número de historia), un servicio de salud (CIP autonómico) o todo el SNS (CIP-SNS).

El sistema sanitario por dentro