1. INTRODUCCIÓN: NECESIDAD Y ALCANCE DE LA NORMALIZACIÓN

La normalización es una actividad técnica y organizativa destinada a establecer especificaciones comunes para productos, procesos, servicios, interfaces y datos. En tecnologías de la información sanitarias su importancia es crítica porque un mismo episodio asistencial atraviesa múltiples aplicaciones: identificación del paciente, admisión, petición de pruebas, laboratorio, imagen, farmacia, documentación clínica, facturación, explotación analítica y continuidad entre niveles asistenciales. Sin acuerdos comunes, cada conexión se convierte en un desarrollo particular, difícil de mantener y propenso a errores.

Una norma no obliga necesariamente a que todas las organizaciones utilicen el mismo producto ni la misma arquitectura. Lo que fija son reglas compartidas: estructura de los datos, significado de los campos, operaciones disponibles, comportamiento ante errores, mecanismos de identificación, requisitos de seguridad o forma de declarar la conformidad. De este modo pueden coexistir soluciones de fabricantes distintos sin que cada pareja de sistemas tenga que inventar un protocolo privado.

1.1. Interoperabilidad técnica, sintáctica, semántica y organizativa

La interoperabilidad puede analizarse por niveles. La interoperabilidad técnica garantiza conectividad, transporte y mecanismos de comunicación. La sintáctica asegura que el receptor puede analizar la estructura recibida. La semántica persigue que ambas partes atribuyan el mismo significado a códigos, unidades, estados y relaciones. La organizativa alinea procesos, responsabilidades, tiempos y reglas de actuación. En el sector público debe añadirse la dimensión jurídica, porque el intercambio tiene que respetar competencias, base legitimadora, protección de datos, conservación y derechos de las personas.

1.2. Por qué la sanidad necesita estándares sectoriales

La información sanitaria es heterogénea y sensible. Conviven textos narrativos, medidas, señales, imágenes de gran tamaño, documentos firmados, listas de medicación, diagnósticos codificados y datos administrativos. Además, la seguridad del paciente exige conservar la relación correcta entre persona, episodio, muestra, orden, imagen e informe. Un error de identidad o de unidad puede tener consecuencias clínicas aunque la transmisión sea técnicamente correcta.

Los estándares generales de Internet son imprescindibles, pero no describen por sí solos un estudio radiológico, una observación de laboratorio o un documento clínico. Para esos dominios se utilizan estándares sectoriales. DICOM modela y comunica imágenes médicas y datos relacionados; HL7 ofrece varias familias para mensajería, documentos y recursos clínicos; IHE define perfiles que restringen y combinan estándares para casos de uso concretos. Las terminologías aportan significado computable.

1.3. Beneficios y límites

• Intercambiabilidad: permite comparar y conectar soluciones de distintos proveedores.
• Reducción del acoplamiento: limita las interfaces propietarias y facilita la evolución.
• Calidad y seguridad: establece identificadores, reglas de validación y estados de error.
• Reutilización: una guía de implementación puede aplicarse a múltiples centros y productos.
• Contratación verificable: convierte necesidades abstractas en requisitos comprobables.
• Continuidad asistencial: favorece el intercambio entre niveles, organizaciones y territorios.

No obstante, un estándar suele permitir opciones y extensiones. Dos implementaciones pueden declarar la misma familia normativa y no ser compatibles si usan versiones, perfiles o vocabularios diferentes. Tampoco elimina la necesidad de gobierno de datos, identificación maestra, seguridad, observabilidad, acuerdos de servicio y gestión del cambio.

1.4. Papel del TFA-STI

El TFA-STI participa en análisis funcional, arquitectura, contratación, integración, aceptación y explotación. Debe leer declaraciones de conformidad, identificar actores y responsabilidades, revisar mensajes y recursos, interpretar logs, definir pruebas, gestionar catálogos y valorar el impacto de una actualización. En una incidencia no basta con comprobar que «hay red»: hay que localizar en qué nivel se rompe el flujo, desde el transporte hasta la semántica o el proceso organizativo.

2. CONCEPTOS, TIPOS DE ESTÁNDARES Y CICLO DE NORMALIZACIÓN

En lenguaje cotidiano se utilizan como equivalentes «norma» y «estándar», pero en un examen conviene distinguir el contexto. Una norma técnica es un documento aprobado por un organismo reconocido mediante un procedimiento de consenso. Un estándar de facto puede alcanzar una adopción general sin haber nacido en el sistema formal de normalización. En sanidad, muchos productos sectoriales se desarrollan en organizaciones especializadas y después se relacionan con normas ISO, CEN o UNE.

2.1. Norma, especificación, guía y perfil

2.2. Estándares abiertos y neutralidad tecnológica

El Esquema Nacional de Interoperabilidad promueve el uso de estándares y define criterios para su selección. En contratación pública, la referencia a estándares debe servir a la interoperabilidad, la conservación y la independencia tecnológica, evitando formular requisitos arbitrarios que solo pueda cumplir un producto. «Abierto» no significa necesariamente «gratuito en todos sus componentes» ni «sin propiedad intelectual»; interesa que la especificación, las condiciones de uso y la gobernanza permitan implementación, competencia y evolución.

La neutralidad tecnológica tampoco impide imponer requisitos precisos. Es legítimo exigir una determinada clase SOP, un evento HL7, un perfil IHE o una guía FHIR cuando son necesarios para integrarse con la plataforma corporativa. Lo que debe justificarse es la necesidad y describirse de forma funcional y comprobable.

2.3. Ciclo de elaboración y mantenimiento

1. Identificación de la necesidad: se documenta un problema recurrente o una laguna.
2. Propuesta y alcance: se define qué cubrirá y qué queda fuera.
3. Trabajo técnico: expertos elaboran borradores, modelos, reglas y ejemplos.
4. Consulta y consenso: miembros y partes interesadas formulan observaciones.
5. Aprobación y publicación: el documento alcanza el estado previsto por la organización.
6. Implementación y pruebas: la experiencia real revela ambigüedades y defectos.
7. Mantenimiento: se publican correcciones, suplementos, nuevas ediciones o retiradas.

El estado de un documento importa. Puede ser borrador, versión para comentario público, uso en prueba, texto final, norma publicada, documento sustituido u obsoleto. Una contratación no debe citar solamente el nombre de una tecnología: debe fijar la versión y, cuando proceda, el estado de cada artefacto.

2.4. Conformidad, certificación y acreditación

Conformidad significa cumplimiento de requisitos especificados. Puede declararla el fabricante, verificarla el comprador o evaluarla una tercera parte. La certificación es una atestación de tercera parte dentro de un esquema definido. La acreditación reconoce la competencia de una entidad para realizar actividades de evaluación de la conformidad. Son conceptos relacionados, pero no intercambiables.

En DICOM, el fabricante publica una Conformance Statement; en IHE, una Integration Statement identifica perfiles, actores y opciones; en FHIR, un servidor expone un CapabilityStatement y se vincula a perfiles y guías. Ninguno de estos documentos sustituye por sí solo las pruebas de aceptación.

2.5. Marco público español y europeo

El Real Decreto 4/2010 regula el Esquema Nacional de Interoperabilidad y sus principios organizativos, semánticos y técnicos. Sus Normas Técnicas de Interoperabilidad desarrollan materias como documento y expediente electrónicos, política de firma, reutilización, catálogo de estándares y conservación. En salud, este marco general se combina con regulación sanitaria, protección de datos, seguridad y especificaciones del Sistema Nacional de Salud.

En la Unión Europea, la interoperabilidad transfronteriza se articula mediante iniciativas como MyHealth@EU y, desde 2025, el Reglamento del Espacio Europeo de Datos de Salud. Estos instrumentos no sustituyen a DICOM, HL7 o IHE; crean obligaciones y marcos de gobernanza en los que los estándares técnicos son piezas de implementación.

3. ORGANISMOS INTERNACIONALES: ISO, IEC E ITU

3.1. ISO

La International Organization for Standardization es una federación de organismos nacionales de normalización. Sus trabajos se organizan en comités técnicos, subcomités y grupos de trabajo. Las normas internacionales se elaboran mediante votación y consenso entre miembros nacionales; ISO no es una administración mundial ni una entidad que certifique directamente todas las normas que publica.

En tecnologías de la información, ISO colabora estrechamente con IEC. En informática sanitaria destaca ISO/TC 215, Health informatics, cuyo ámbito comprende la normalización de datos, información y conocimiento de salud para apoyar la atención, la investigación, la gestión y otros usos legítimos.

3.2. IEC

La International Electrotechnical Commission desarrolla normas internacionales en electricidad, electrónica y tecnologías relacionadas. En el entorno sanitario son especialmente relevantes sus normas de equipos electromédicos, software de producto sanitario, usabilidad, compatibilidad electromagnética y seguridad. Debe diferenciarse la interoperabilidad de sistemas clínicos de la regulación y seguridad del producto sanitario: pueden converger en un mismo proyecto, pero responden a objetivos normativos distintos.

3.3. ISO/IEC JTC 1

ISO/IEC JTC 1, Information technology, es el comité técnico conjunto de ISO e IEC para la normalización general de TI. Bajo su estructura se trabajan áreas como seguridad y privacidad, inteligencia artificial, lenguajes y descripción de documentos, identificación automática, computación en la nube, biometría o arquitectura de datos.

La distinción con ISO/TC 215 es examinable: JTC 1 cubre tecnologías de la información con alcance transversal, mientras ISO/TC 215 se concentra en informática sanitaria. Ambos pueden colaborar cuando un asunto sanitario utiliza tecnologías generales, por ejemplo seguridad, identificación o inteligencia artificial.

3.4. ISO/TC 215 y normas sanitarias relevantes

ISO/TC 215 trabaja en modelos, arquitecturas, mensajería, terminologías, seguridad, dispositivos, farmacia e identificación. Algunas normas se originan en otras organizaciones y se adoptan o coordinan internacionalmente. ISO 12052:2026 corresponde a DICOM e incluye imagen digital, comunicación, flujo de trabajo y gestión de datos. ISO 13606 aborda la comunicación de la historia clínica electrónica mediante un modelo de referencia y arquetipos. ISO 27799 proporciona controles de seguridad de la información aplicados a salud.

3.5. ITU y el sector ITU-T

La Unión Internacional de Telecomunicaciones es un organismo especializado de Naciones Unidas. Su sector de normalización, ITU-T, publica Recomendaciones sobre redes, señalización, calidad, vídeo, seguridad e identidad digital. Son conocidos, entre otros, la familia H para sistemas audiovisuales y X.509 para infraestructuras de clave pública.

En un sistema sanitario, las recomendaciones ITU pueden estar presentes en videocomunicación, redes y certificados, pero no sustituyen a los estándares clínicos. Una consulta de telemedicina combina capas: conectividad y codificación audiovisual, autenticación, aplicación clínica y representación de la información.

3.6. Relaciones y adopción

Las organizaciones cooperan para evitar normas contradictorias. ISO e IEC comparten JTC 1; ISO, IEC e ITU mantienen mecanismos de coordinación; ISO/TC 215 colabora con CEN/TC 251 y con organizaciones sectoriales. Las adopciones pueden producir designaciones encadenadas como UNE-EN ISO, que reflejan la incorporación nacional de una norma europea basada en una ISO.

4. IEEE, W3C, IETF Y OTROS FOROS TÉCNICOS

4.1. IEEE

El Institute of Electrical and Electronics Engineers es una asociación profesional y una organización de desarrollo de estándares. La familia IEEE 802 es fundamental para redes locales: 802.3 para Ethernet, 802.11 para redes inalámbricas y 802.1 para funciones de arquitectura, puenteado y control de acceso. Estos estándares proporcionan la base de comunicaciones sobre la que operan las aplicaciones clínicas.

En dispositivos sanitarios debe conocerse la familia ISO/IEEE 11073, relacionada con comunicación y representación de datos de dispositivos médicos y de salud personal. No debe confundirse con HL7: 11073 se centra en determinados dispositivos y observaciones, mientras HL7 aborda el intercambio entre aplicaciones sanitarias mediante varias familias.

4.2. IETF

La Internet Engineering Task Force desarrolla y mantiene gran parte de los protocolos de Internet mediante un proceso abierto. Sus documentos se publican como RFC. Sin embargo, RFC no equivale automáticamente a estándar: la serie incluye documentos Standards Track, Best Current Practice, Informational, Experimental e históricos, y un RFC puede ser actualizado u obsoleto.

4.3. W3C

El World Wide Web Consortium desarrolla estándares y recomendaciones de la Web. HTML, CSS, XML, RDF y las pautas WCAG influyen en aplicaciones sanitarias, accesibilidad, documentos y servicios. W3C e IETF tienen ámbitos distintos pero coordinados: HTTP se normaliza en IETF, mientras tecnologías de presentación, datos y accesibilidad se desarrollan en W3C.

La accesibilidad de sitios y aplicaciones públicas se apoya en normas europeas y requisitos legales que remiten a pautas WCAG. No debe memorizarse WCAG como un estándar clínico: es un estándar web transversal que condiciona la interfaz de los servicios digitales sanitarios.

4.4. OASIS, OMG y otros consorcios

OASIS produce estándares abiertos en seguridad, identidad, servicios y documentos, como SAML. OMG mantiene especificaciones de modelado como UML, BPMN y CMMN. El Unicode Consortium mantiene Unicode, imprescindible para representar nombres, textos clínicos y alfabetos de forma consistente. GS1 desarrolla identificadores y estándares de trazabilidad utilizados también en cadenas sanitarias y medicamentos.

Estas organizaciones no tienen el mismo estatus jurídico ni el mismo procedimiento que ISO, IEC o CEN, pero sus especificaciones pueden ser ampliamente adoptadas e incluso referenciadas por normas o contratos. En examen importa asociar cada organización a su ámbito, no asumir que toda especificación técnica procede de ISO.

4.5. Capas y complementariedad

La pila muestra por qué no debe compararse directamente DICOM con TCP o HL7 con Ethernet: resuelven problemas en capas distintas. Una integración completa depende de todas ellas.

5. NORMALIZACIÓN EUROPEA Y ESPAÑOLA: CEN, CENELEC, ETSI Y UNE

5.1. Sistema europeo: CEN, CENELEC y ETSI

En Europa, los tres organismos reconocidos de normalización son CEN, CENELEC y ETSI. CEN cubre un amplio conjunto de sectores; CENELEC se ocupa del ámbito electrotécnico; ETSI se especializa en telecomunicaciones y tecnologías digitales. Las normas europeas se adoptan por los organismos nacionales y, cuando corresponde, desplazan normas nacionales incompatibles.

La relación entre norma europea y legislación no es automática. Algunas normas se elaboran a petición de la Comisión Europea y pueden servir para demostrar conformidad con requisitos legales, pero la obligación deriva del marco jurídico o contractual aplicable, no simplemente de que el documento lleve la designación EN.

5.2. CEN/TC 251, Health informatics

CEN/TC 251 es el comité técnico europeo de informática sanitaria. Trabaja en interoperabilidad, modelos de información, terminologías, seguridad, identificación y otras materias de salud digital. Mantiene coordinación con ISO/TC 215 para reutilizar trabajo y favorecer normas coherentes a escala internacional y europea.

Entre las familias vinculadas a este ámbito figuran la comunicación de historia clínica electrónica, la identificación de medicamentos y requisitos de seguridad y semántica. Para el opositor es más importante comprender el papel del comité que memorizar un inventario cambiante de normas.

5.3. UNE como organismo español de normalización

La Asociación Española de Normalización, UNE, es el organismo nacional de normalización. Representa a España en ISO, IEC, CEN, CENELEC y ETSI en los términos del sistema correspondiente, y organiza la participación española mediante comités técnicos de normalización. En salud digital destaca el CTN 139, Tecnologías de la información y las comunicaciones para la salud.

Desde la reorganización realizada en 2017 debe distinguirse entre UNE, responsable de la normalización, y AENOR, que desarrolla principalmente evaluación de la conformidad, certificación y otros servicios. La respuesta «AENOR es el organismo español de normalización» aparece en materiales antiguos, pero hoy es desactualizada.

5.4. Lectura de designaciones

5.5. Aplicación en contratación pública

Una referencia normativa debe traducirse en criterios de aceptación. Para DICOM se indicarán clases SOP, roles SCU/SCP, sintaxis de transferencia, servicios web, seguridad y declaración de conformidad. Para HL7 v2 se concretarán versión, eventos, estructuras, segmentos Z, ACK, transporte y vocabularios. Para FHIR se fijarán versión, guía de implementación, perfiles, terminologías, búsquedas, operaciones y requisitos de seguridad. Para IHE se declararán perfiles, actores, opciones y transacciones.

El principio de proporcionalidad exige no imponer más de lo necesario, pero también evitar expresiones vagas. «Compatible con estándares sanitarios» no permite evaluar una oferta. Una matriz de conformidad y un plan de pruebas aportan trazabilidad entre necesidad, requisito, evidencia y resultado.

6. DICOM: ORGANIZACIÓN, MODELO DE INFORMACIÓN Y OBJETOS

DICOM —Digital Imaging and Communications in Medicine— es el estándar dominante para representar, almacenar y comunicar imágenes médicas y la información relacionada. Lo mantiene el DICOM Standards Committee con apoyo administrativo de NEMA. Se publica como un conjunto de partes coordinadas y se actualiza mediante suplementos y propuestas de cambio.

A agosto de 2026, el portal oficial identifica 2026c como edición consolidada vigente. Ese mismo año se publicó la tercera edición de ISO 12052:2026, que describe DICOM en informática sanitaria, incluido el flujo de trabajo y la gestión de datos. La edición debe citarse cuando un requisito dependa de funcionalidades recientes.

6.1. Origen y evolución

ACR y NEMA iniciaron en la década de 1980 trabajos para evitar que cada equipo de imagen utilizara interfaces y soportes incompatibles. Las publicaciones ACR-NEMA precedieron a la revisión de 1993, que consolidó la denominación DICOM e incorporó una arquitectura de comunicación en red. Desde entonces, el estándar ha evolucionado de forma continua para cubrir nuevas modalidades, objetos tridimensionales, radioterapia, cardiología, oftalmología, patología digital, vídeo, segmentaciones, presentación, informes y servicios web.

La expresión histórica «DICOM 3.0» se empleó para distinguir aquella gran revisión, pero el estándar actual ya no se versiona como 3.1, 3.2, etc. Se identifica por ediciones consolidadas y por el conjunto de partes, suplementos y cambios incorporados.

6.2. Partes del estándar

No es necesario memorizar todas las partes, pero sí relacionar PS3.3 con objetos, PS3.4 con clases de servicio, PS3.5 con codificación, PS3.6 con el diccionario, PS3.7 con DIMSE, PS3.15 con seguridad y PS3.18 con DICOMweb.

6.3. Modelo de información

Un Information Object Definition o IOD especifica la información de un tipo de objeto. Se construye mediante módulos y atributos organizados alrededor de entidades como paciente, estudio, serie y equipamiento. Un IOD puede representar una imagen CT, una imagen MR, una presentación, una segmentación, un informe estructurado o muchos otros objetos.

Los atributos se identifican mediante un tag formado por grupo y elemento, por ejemplo (0010,0020) para Patient ID o (0020,000D) para Study Instance UID. Cada elemento tiene una Value Representation que indica su tipo de dato, una multiplicidad y reglas de presencia. Las categorías de tipo distinguen atributos obligatorios con valor, obligatorios que pueden estar vacíos, condicionales y opcionales.

6.4. UID, IOD, SOP Class e instancia

Los Unique Identifiers son cadenas numéricas jerárquicas diseñadas para ser globalmente únicas. No deben confundirse con UUID, aunque ambos persiguen unicidad. Se utilizan para identificar clases, sintaxis de transferencia, estudios, series e instancias.

Una SOP Class combina una definición de objeto con un servicio aplicable. Una SOP Instance es una realización concreta de esa clase e incluye un SOP Class UID y un SOP Instance UID. Esta distinción permite expresar tanto qué tipo de objeto se intercambia como qué comportamiento se espera.

6.5. Codificación y transfer syntaxes

La transfer syntax define cómo se codifica el conjunto de datos durante el intercambio o almacenamiento: endianness, explicitud del VR y, cuando procede, compresión de píxel. Emisor y receptor deben negociar una sintaxis común. Que dos sistemas soporten la misma SOP Class no basta si no comparten una transfer syntax adecuada.

El fichero DICOM puede incluir un preámbulo y metainformación definidos para intercambio en medios. La extensión .dcm es una convención frecuente, no un requisito universal del estándar. Tampoco todo objeto DICOM contiene píxeles: existen informes, estados de presentación, segmentaciones, estructuras de radioterapia y otros objetos.

6.6. Declaración de conformidad

Una implementación que declara conformidad con DICOM debe documentar sus capacidades conforme a PS3.2. La declaración identifica entidades de aplicación, clases SOP, roles SCU/SCP, transfer syntaxes, comportamiento, seguridad, opciones y limitaciones. Es la base para analizar compatibilidad, pero no demuestra por sí sola que un flujo completo funcionará con la configuración local.

7. DICOM: SERVICIOS DIMSE, PACS, DICOMWEB Y CONFORMIDAD

7.1. Entidades de aplicación y asociaciones

La comunicación DICOM clásica se establece entre Application Entities. Cada entidad se identifica lógicamente mediante un AE Title y se configura con información de red. Antes de intercambiar instancias se negocia una asociación. En ella se proponen contextos de presentación que combinan una sintaxis abstracta —normalmente una SOP Class— con una o varias transfer syntaxes.

La aceptación de la asociación no garantiza que todas las operaciones sean posibles. Deben coincidir roles, clases, sintaxis, límites de tamaño, comportamiento ante errores y políticas de seguridad. Los términos SCU y SCP se interpretan respecto de una clase de servicio: una misma aplicación puede actuar como usuario para una operación y proveedor para otra.

7.2. Servicios DIMSE-C

1. La modalidad y el archivo negocian una asociación.
2. Se acuerdan SOP Class y transfer syntax.
3. La modalidad, como C-STORE SCU, envía una instancia.
4. El archivo, como C-STORE SCP, responde con un estado.
5. Las aplicaciones registran el resultado y gestionan reintentos o errores.

7.3. Servicios normalizados y flujo de trabajo

DICOM también define servicios normalizados DIMSE-N y objetos de gestión. En radiología son relevantes Modality Worklist, que permite consultar procedimientos programados, y Modality Performed Procedure Step, que comunica el estado de la ejecución. Al evitar la reintroducción manual de datos, estos mecanismos reducen errores de identidad y de procedimiento.

La lista de trabajo no es una agenda completa ni sustituye al RIS. Es una vista normalizada de información necesaria para la modalidad. La calidad depende de códigos de procedimiento coherentes, identificación correcta y sincronización de estados.

7.4. PACS, VNA y visores

Un PACS recibe, indexa, conserva, distribuye y presenta objetos de imagen. Suele integrar archivo, base de metadatos, servicios DICOM y herramientas de visualización. Un VNA persigue conservar contenidos con menor dependencia del visor o del PACS de un fabricante, aunque su verdadera neutralidad debe evaluarse mediante exportabilidad, formatos, metadatos, API y costes de salida.

Las estaciones diagnósticas requieren capacidades de presentación, calibración y rendimiento acordes con el uso clínico. Los visores de revisión pueden tener requisitos distintos. En ambos casos debe diferenciarse la representación de los píxeles, los estados de presentación, las anotaciones y las mediciones.

7.5. DICOMweb

PS3.18 define servicios web conocidos conjuntamente como DICOMweb. Utilizan HTTP y representaciones web para buscar, almacenar y recuperar objetos. No son meros nombres alternativos de DIMSE, aunque resuelven funciones comparables.

DICOMweb facilita integración con navegadores, aplicaciones móviles, servicios cloud y arquitecturas API. La autenticación y autorización se proporcionan mediante la arquitectura de seguridad que rodea al servicio; no debe afirmarse que DICOMweb, por sí solo, imponga OAuth o un producto concreto.

7.6. Seguridad y operación

La seguridad abarca cifrado del canal, autenticación de nodos, autorización, auditoría, gestión de certificados, segmentación y protección de datos en reposo. Los objetos pueden contener atributos identificativos y datos privados de fabricante, por lo que la anonimización requiere perfiles y validación; borrar el nombre visible no garantiza desidentificación.

En explotación se monitorizan colas, estados de asociación, tiempos de respuesta, espacio, integridad, replicación, fallos de almacenamiento y coherencia de UIDs. Las pruebas deben incluir duplicados, sintaxis no aceptada, clase no soportada, pérdida de conexión, reintentos y recuperación tras contingencia.

8. HL7: ORGANIZACIÓN, FAMILIAS Y MENSAJERÍA VERSION 2

HL7 International es una organización internacional sin ánimo de lucro acreditada por ANSI para desarrollar estándares. «Level Seven» hace referencia a la capa de aplicación del modelo OSI: HL7 normaliza la comunicación entre aplicaciones sanitarias, no las capas físicas, de enlace o de red.

HL7 es una familia, no un único protocolo. Incluye Version 2, productos de Version 3, CDA, FHIR, terminología y modelos funcionales. Estas familias coexisten y resuelven unidades de intercambio distintas.

8.1. Mensajería Version 2

HL7 Version 2 se diseñó para intercambiar eventos clínicos y administrativos. Su amplia implantación se debe a una sintaxis compacta, extensibilidad y adaptación a sistemas heterogéneos. Esa flexibilidad tiene un coste: las implementaciones locales pueden divergir, por lo que se necesitan perfiles, acuerdos de interfaz y pruebas.

La publicación normativa más reciente de la serie es HL7 Version 2.9.1. Sin embargo, muchas interfaces productivas utilizan versiones anteriores. La versión declarada en MSH-12 condiciona estructuras, segmentos, campos y tablas, y no debe cambiarse sin análisis de compatibilidad.

8.2. Estructura del mensaje

Un mensaje se compone de segmentos terminados por retorno de carro. Los campos se separan normalmente con |; MSH-2 declara los caracteres de codificación para componentes, repeticiones, escape y subcomponentes. Los delimitadores no deben interpretarse sin tener en cuenta la cabecera.

MSH|^~&|HIS|CENTRO|LIS|LAB|20260804123000+0200||ADT^A01^ADT_A01|MSG0001|P|2.5.1
EVN|A01|20260804123000+0200
PID|1||PAC000123^^^CENTRO^MR||PACIENTE^EJEMPLO||19800101|U
PV1|1|I|PLANTA^201^A

8.3. Tipos de mensaje, eventos y estructuras

La combinación del tipo de mensaje y el evento desencadenante expresa el motivo del intercambio, por ejemplo ADT^A01 para una admisión o ORU^R01 para resultados no solicitados. El tercer componente de MSH-9 puede identificar la estructura abstracta. No debe asumirse que todas las versiones usan exactamente los mismos mensajes para un caso de uso.

8.4. ACK y control de errores

Los mensajes de reconocimiento permiten confirmar recepción y procesamiento según el modo acordado. Los códigos de MSA distinguen aceptación, error o rechazo. Deben definirse identificadores de control, timeouts, reintentos, idempotencia, colas de errores y reconciliación. Un ACK positivo no siempre significa que el dato se haya incorporado correctamente al proceso clínico final; puede confirmar solo una capa del procesamiento.

8.5. Transporte MLLP

Minimal Lower Layer Protocol es un mecanismo de encuadre usado habitualmente para delimitar mensajes HL7 v2 sobre una conexión de transporte, normalmente TCP. Utiliza caracteres de inicio y fin de bloque. El puerto no es intrínseco al estándar y debe configurarse; memorizar un puerto fijo como «el puerto HL7» es incorrecto.

La protección del canal puede incluir TLS, VPN o controles de red, pero la seguridad completa requiere autenticación, autorización, auditoría y protección de los sistemas extremos.

8.6. Perfiles y extensiones locales

Los segmentos Z permiten extensiones locales, aunque un uso excesivo reduce interoperabilidad. La guía de interfaz debe documentar obligatoriedad, cardinalidad, longitud, tablas, codificación, zonas horarias, identificadores, escape, nulidad y comportamiento ante valores desconocidos. Conviene reutilizar campos estándar antes de crear extensiones.

9. HL7 V3, CDA Y FHIR

9.1. HL7 Version 3 y el RIM

HL7 Version 3 nació con la intención de proporcionar un método más formal y coherente que la mensajería v2. Su núcleo conceptual fue el Reference Information Model o RIM, acompañado de vocabularios, tipos de datos y un proceso de refinamiento para derivar modelos y mensajes. Este enfoque aportó rigor, pero también una complejidad elevada y una curva de implementación difícil. La adopción de la mensajería v3 fue desigual y no sustituyó globalmente a v2.

La lección para arquitectura es que la formalidad del modelo no garantiza por sí sola la implantación. Un estándar debe equilibrar precisión, coste, herramientas, comunidad, compatibilidad y capacidad de evolución.

9.2. CDA: documento clínico persistente

Clinical Document Architecture Release 2 es un estándar de HL7 derivado del ecosistema v3 para representar documentos clínicos. Un CDA tiene una cabecera, con identidad del documento, paciente, autoría, custodia, contexto y confidencialidad, y un cuerpo, que puede ser no estructurado o estructurado en secciones. La narrativa del documento debe poder presentarse a una persona; las entradas estructuradas permiten procesamiento computable.

Las propiedades clásicas de un documento clínico incluyen persistencia, custodia, posibilidad de autenticación, contexto y completitud. «Documento» no significa necesariamente PDF ni fichero aislado: se trata de una unidad clínica con identidad y significado, que puede transportarse mediante distintas infraestructuras.

<ClinicalDocument>
  <id root="2.16.840.1.113883.3.999" extension="DOC-0001"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1"/>
  <title>Resumen clínico</title>
  <effectiveTime value="20260804100000+0200"/>
  <recordTarget>...paciente...</recordTarget>
  <author>...autor...</author>
  <component>
    <structuredBody>
      <component>
        <section>
          <title>Problemas de salud</title>
          <text>Narrativa legible</text>
          <entry>...contenido estructurado...</entry>
        </section>
      </component>
    </structuredBody>
  </component>
</ClinicalDocument>

La interoperabilidad con CDA depende de plantillas y guías de implementación. Dos documentos que cumplen el esquema XML base pueden no ser semánticamente equivalentes si usan plantillas, códigos o cardinalidades distintos.

9.3. FHIR: recursos y artefactos de conformidad

Fast Healthcare Interoperability Resources organiza la información en recursos modulares, como Patient, Encounter, Observation, Condition, MedicationRequest, DiagnosticReport o ImagingStudy. Los recursos comparten elementos de infraestructura y se relacionan mediante referencias.

FHIR no pretende que el recurso base resuelva todas las necesidades locales. Los perfiles restringen cardinalidades, fijan terminologías, definen extensiones y establecen invariantes. Las Implementation Guides reúnen perfiles, extensiones, ValueSet, CodeSystem, ejemplos, operaciones y reglas de intercambio para un contexto.

9.4. Paradigmas de intercambio

FHIR suele asociarse a una API REST sobre HTTP, pero admite varios paradigmas. En REST se utilizan interacciones como read, search, create, update o historial. Los Bundle permiten lotes y transacciones. FHIR también define documentos basados en Composition, mensajes, servicios, suscripciones y operaciones.

GET /fhir/Observation?patient=123&category=laboratory
Accept: application/fhir+json

La respuesta no es «FHIR» solo por ser JSON. Debe utilizar el tipo MIME apropiado, la estructura de recursos, identificadores, perfiles, códigos y reglas de la guía. La seguridad tampoco viene resuelta automáticamente: se aplican TLS, autenticación, autorización, consentimiento, auditoría y minimización según el escenario. SMART App Launch es un marco común para autorización y contexto de aplicaciones, pero no es obligatorio para toda implementación FHIR.

9.5. Versiones y madurez

A agosto de 2026, la versión publicada más reciente es FHIR R5 5.0.0. R5 contiene elementos con distintos estados de madurez; parte de la especificación es normativa y parte continúa en uso de prueba. Muchas implantaciones productivas mantienen R4 o R4B porque las guías y los ecosistemas se construyeron sobre ellas. Por ello, «usar la última versión» no es una regla universal: debe seleccionarse una versión y una guía compatibles con todos los participantes.

9.6. Comparación razonada

10. IHE: ENFOQUE, PERFILES, ACTORES Y TRANSACCIONES

Integrating the Healthcare Enterprise es una iniciativa internacional que especifica usos coordinados de estándares existentes para resolver necesidades clínicas y operativas. Sus Technical Frameworks se organizan por dominios y describen perfiles, actores, transacciones, contenido y opciones. IHE no es una nueva sintaxis alternativa a HL7 o DICOM.

10.1. Perfil, actor y transacción

Un perfil parte de un problema concreto y define cómo deben colaborar los sistemas. Un actor es una responsabilidad funcional abstracta; no equivale necesariamente a una aplicación física. Una transacción es una interacción normalizada entre actores. Un producto puede implementar varios actores y un actor puede formar parte de varios perfiles.

10.2. Dominios y Technical Frameworks

IHE mantiene dominios como Radiology, IT Infrastructure, Cardiology, Laboratory, Pharmacy, Patient Care Coordination y Quality, Research and Public Health. Cada dominio publica un marco técnico con una visión de perfiles y volúmenes de transacciones o contenido. Los suplementos pasan por estados como comentario público, implementación de prueba y texto final; las propuestas de cambio corrigen y evolucionan los documentos.

10.3. Declaraciones de integración

Una IHE Integration Statement es publicada por el proveedor para indicar qué perfiles, actores y opciones implementa una versión concreta de su producto. Debe leerse junto con las declaraciones de conformidad de los estándares subyacentes. La afirmación genérica «cumple IHE» carece de precisión si no identifica perfil, actor, opción, versión y producto.

10.4. Connectathon y evaluación

Los Connectathons son eventos de pruebas supervisadas en los que múltiples implementaciones ejecutan casos definidos. Proporcionan evidencia útil de que determinadas combinaciones han sido probadas y permiten detectar ambigüedades. No son una garantía universal ni una certificación regulatoria del producto completo. Los resultados deben interpretarse con su fecha, versión, actor y perfil.

10.5. Valor arquitectónico

La principal aportación de IHE es reducir opcionalidad. Un estándar amplio puede permitir múltiples mensajes, campos y comportamientos; un perfil selecciona un camino para un caso de uso. Esto mejora la comparabilidad de ofertas, la documentación y el diseño de pruebas. También ofrece un lenguaje común entre profesionales clínicos, arquitectos, integradores y fabricantes.

11. PERFILES IHE DE MAYOR RELEVANCIA

11.1. Scheduled Workflow

Scheduled Workflow coordina el flujo radiológico programado desde la orden hasta la adquisición y disponibilidad de imágenes. Intervienen responsabilidades como Order Placer, Order Filler, Acquisition Modality e Image Manager/Image Archive. El perfil combina mensajería administrativa y de órdenes con servicios DICOM como Modality Worklist, Modality Performed Procedure Step y almacenamiento.

La finalidad es mantener coherentes identidad, orden, procedimiento programado y objetos adquiridos. La modalidad consulta una lista de trabajo en vez de reintroducir manualmente los datos, reduciendo errores tipográficos. La conformidad con SWF no elimina la necesidad de parametrizar códigos de procedimiento, identificadores y reglas locales.

11.2. XDS.b: compartición documental

Cross-Enterprise Document Sharing facilita el registro, localización y recuperación de documentos dentro de un dominio de afinidad. El Document Source aporta documentos y metadatos; el Document Repository conserva el contenido; el Document Registry mantiene los metadatos de búsqueda; el Document Consumer consulta y recupera.

XDS.b es neutral respecto al contenido: puede compartir documentos CDA, PDF u otros tipos admitidos por la política del dominio. El significado clínico depende del formato de contenido, las terminologías y los metadatos. XDS.b organiza la infraestructura de compartición, no define por sí solo el contenido clínico.

11.3. XCA, XDR y MHD

• XCA: permite consultas y recuperaciones entre comunidades, sin exigir un único registro global.
• XDR: soporta el envío directo y fiable de conjuntos documentales cuando se conoce el destinatario.
• MHD: proporciona un enfoque basado en FHIR para publicación, búsqueda y recuperación de documentos en escenarios móviles o web, interoperando con patrones de compartición documental.

No deben confundirse. XDS.b trabaja dentro de un dominio de afinidad, XCA enlaza comunidades y XDR se orienta a intercambio directo. MHD no convierte automáticamente cualquier repositorio en FHIR: define actores, recursos, perfiles e interacciones concretas.

11.4. Identidad: PIX, PDQ, PIXm y PDQm

PIX gestiona la correlación de identificadores de un mismo paciente entre dominios. PDQ permite consultar información demográfica. Las variantes PIXm y PDQm utilizan FHIR. Ningún perfil resuelve por sí solo la calidad de identidad: se requieren políticas de alta, fusión, desvinculación, revisión humana y tratamiento de homónimos.

11.5. Seguridad: ATNA y XUA

ATNA define patrones para autenticación de nodos y trazas de auditoría. Su objetivo es que los eventos relevantes puedan registrarse y que los nodos participantes establezcan relaciones de confianza. XUA aborda la propagación de aserciones de identidad de usuario en determinadas transacciones entre organizaciones.

Estos perfiles son componentes técnicos. No sustituyen la autorización de acceso, el principio de mínimo privilegio, la gestión del consentimiento, la protección de logs ni las obligaciones del ENS y del RGPD. Una traza correcta debe contener identificadores consistentes, tiempo sincronizado, actor, acción, objeto y resultado, además de conservarse y protegerse.

11.6. Imagen entre organizaciones

XDS-I amplía patrones de compartición para referencias y manifiestos de imagen, de forma que los consumidores puedan localizar y recuperar estudios distribuidos. Debe distinguirse de almacenar las instancias en un PACS local y de transportar un documento clínico convencional. En arquitecturas modernas pueden coexistir DIMSE, DICOMweb y perfiles IHE.

11.7. Selección contractual de perfiles

La selección debe partir del caso de uso. Para cada perfil se identificarán actor que implementará el producto, opciones requeridas, versión del Technical Framework, estándares subyacentes, terminologías, seguridad y pruebas. Una matriz puede vincular cada requisito con una Integration Statement, una Conformance Statement y un caso de prueba.

12. TERMINOLOGÍAS Y ESTÁNDARES COMPLEMENTARIOS

La sintaxis permite intercambiar estructuras; la interoperabilidad semántica pretende que los participantes interpreten los datos del mismo modo. Para ello se combinan sistemas terminológicos, clasificaciones, nomenclaturas, identificadores y unidades. DICOM, HL7 e IHE proporcionan campos y mecanismos donde declarar esos códigos, pero no sustituyen su gobierno.

12.1. SNOMED CT

SNOMED CT es una terminología clínica mantenida por SNOMED International. Su contenido se organiza en conceptos identificados de forma estable, descripciones y relaciones. Las jerarquías y el modelo lógico permiten consultas y expresiones más ricas que una simple lista de términos.

Una implementación debe controlar edición, extensión nacional o local, subconjuntos, estado activo, equivalencias y traducciones. Dos sistemas que usan «SNOMED CT» pueden diferir si emplean ediciones o subconjuntos incompatibles.

12.2. LOINC y UCUM

LOINC identifica observaciones, pruebas, mediciones y documentos. El código describe qué se observa y bajo qué propiedades; no incluye por sí mismo el valor del resultado. UCUM representa unidades de medida de forma computable. Ambas piezas se complementan: una glucosa necesita el código de la observación, el valor numérico y una unidad inequívoca.

12.3. CIE

La Clasificación Internacional de Enfermedades de la OMS se utiliza en estadística de mortalidad y morbilidad, registro y otros fines. CIE-11 es la revisión más reciente de la OMS, pero la versión exigida en un procedimiento depende de la implantación y normativa de cada jurisdicción. Una clasificación agrupa casos para análisis y no ofrece necesariamente la granularidad clínica de una terminología como SNOMED CT.

12.4. Otras referencias semánticas

• ATC: clasificación anatómica, terapéutica y química de medicamentos.
• IDMP: familia ISO para identificación de medicamentos.
• RxNorm: terminología de medicamentos con especial uso en Estados Unidos.
• GS1: identificadores y trazabilidad de productos y unidades logísticas.
• ISO 13606 y openEHR: modelos y arquetipos para representación de historia clínica, con enfoques relacionados pero no idénticos.

12.5. Mapeos y calidad semántica

Un mapa entre terminologías no siempre es uno a uno ni reversible. Debe documentar dirección, finalidad, versión, reglas y grado de equivalencia. Los mapeos automáticos requieren revisión cuando afectan a decisiones clínicas, facturación o estadística. También deben gobernarse los códigos locales y su retirada.

13. APLICACIÓN EN EL SAS, EL SNS Y EL CONTEXTO EUROPEO

13.1. Integración en el SSPA

En el Sistema Sanitario Público de Andalucía, la interoperabilidad debe entenderse como una capacidad corporativa, no como una suma de interfaces aisladas. Los sistemas asistenciales, departamentales, de imagen, laboratorio, farmacia y atención a la ciudadanía requieren identificación coherente, catálogos maestros, trazabilidad, seguridad y mecanismos de intercambio gobernados. La documentación pública del SAS contempla catálogos corporativos de servicios de interoperabilidad, tablas maestras y componentes reutilizables.

Los pliegos y expedientes públicos del SAS muestran que se exigen con frecuencia capacidades HL7 y DICOM para integrar equipamiento y aplicaciones con los sistemas corporativos. Esa exigencia debe traducirse en pruebas concretas: mensajes admitidos, perfiles, tags, clases SOP, informes estructurados, seguridad, rendimiento, reintentos, gestión de colas y soporte de incidencias.

13.2. Caso de uso radiológico de extremo a extremo

El diagrama es deliberadamente lógico: la implementación concreta puede agrupar actores en un mismo producto, emplear perfiles IHE y combinar DICOM clásico con DICOMweb. La corrección no se evalúa por la marca del producto, sino por el cumplimiento de los contratos de interoperabilidad y por el resultado del flujo clínico.

13.3. Caso de uso de laboratorio

En laboratorio, la mensajería HL7 v2 suele separar orden, espécimen, observaciones y resultados mediante segmentos y eventos definidos. La semántica se refuerza con identificadores de pruebas, unidades y códigos de estado. Un resultado técnicamente bien formado puede seguir siendo clínicamente inservible si el código local no está mapeado, la unidad es ambigua o el paciente está mal identificado.

13.4. Interoperabilidad nacional y europea

El Nodo de Interoperabilidad del SNS conecta servicios como la Historia Clínica Digital del Sistema Nacional de Salud y la Receta Electrónica Interoperable del SNS. En el ámbito europeo, MyHealth@EU —nombre actual de la infraestructura antes conocida como eHDSI— permite intercambios transfronterizos como resumen de paciente y receta electrónica. El Reglamento (UE) 2025/327 establece el Espacio Europeo de Datos de Salud y refuerza la necesidad de formatos, componentes, seguridad y gobernanza comunes.

13.5. Función del TFA-STI

• Definir requisitos de interoperabilidad verificables y trazables.
• Revisar declaraciones de conformidad DICOM, perfiles IHE y guías HL7/FHIR.
• Coordinar catálogos, identificadores y terminologías con responsables funcionales y clínicos.
• Diseñar pruebas positivas, negativas, de volumen, recuperación y seguridad.
• Analizar errores sin limitarse al transporte: identidad, estructura, semántica, negocio y autorización.
• Evitar dependencias propietarias mediante exportabilidad, estándares y documentación contractual.

14. CONFORMIDAD, PRUEBAS, SEGURIDAD Y CONTRATACIÓN

14.1. Declaraciones de conformidad

La interoperabilidad debe poder auditarse. En DICOM, la Conformance Statement documenta servicios, clases SOP, roles, syntaxes, comportamiento, seguridad y restricciones. En FHIR, el servidor publica su CapabilityStatement, complementado por perfiles, StructureDefinitions, ValueSets, CodeSystems y ejemplos de una guía de implementación. En IHE se declaran actores, perfiles y opciones. Estos documentos no sustituyen las pruebas, pero permiten diseñarlas con precisión.

14.2. Estrategia de pruebas

Una prueba completa cubre varios niveles: conectividad, negociación, sintaxis, validación estructural, reglas de negocio, semántica, seguridad, rendimiento, recuperación y experiencia del usuario. Deben incluirse casos de error: paciente desconocido, duplicado, código no reconocido, instancia repetida, mensaje fuera de orden, rechazo, caída de red, timeout, reintento y reconciliación posterior.

Los IHE Connectathons ofrecen un entorno estructurado para probar implementaciones entre múltiples participantes. Superar pruebas de conectividad no equivale a certificar todo un producto para cualquier entorno: el comprador debe revisar alcance, versión, perfiles, opciones y fecha de los resultados.

14.3. Seguridad, privacidad y trazabilidad

Los datos de salud son categorías especiales de datos personales. La interoperabilidad debe aplicar minimización, control de acceso, autenticación, autorización, cifrado, integridad, registro, conservación y segregación. Los estándares de intercambio no sustituyen al RGPD, la LOPDGDD, el ENS ni a la gestión de riesgos. Un canal cifrado protege el tránsito, pero no corrige autorizaciones excesivas ni evita la exposición en logs.

14.4. Requisitos de contratación

14.5. Gestión de versiones y cambios

Los estándares evolucionan. La gobernanza debe mantener un inventario de interfaces, versiones, dependencias, guías locales, vocabularios, certificados y fechas de retirada. La actualización requiere análisis de impacto y compatibilidad; cambiar de FHIR R4 a R5 o incorporar un suplemento DICOM no es una mera sustitución de fichero, sino una modificación contractual y técnica que puede afectar a productores, consumidores, validadores y datos históricos.

15. CONCLUSIONES E IDEAS CLAVE PARA EL REPASO

15.1. Ideas esenciales

1. UNE representa la normalización española; AENOR no debe confundirse con el organismo nacional de normalización.
2. ISO/IEC JTC 1 cubre TI general; ISO/TC 215, CEN/TC 251 y CTN 139 se centran en informática sanitaria en sus respectivos niveles.
3. DICOM integra objetos, datos, servicios y comunicaciones para imagen médica y contenidos relacionados; no es solo un fichero.
4. HL7 v2 normaliza mensajería basada en segmentos; CDA normaliza documentos clínicos; FHIR trabaja con recursos, perfiles y diferentes paradigmas de intercambio.
5. IHE no compite con HL7 o DICOM: especifica cómo aplicarlos mediante perfiles, actores y transacciones.
6. La semántica requiere terminologías como SNOMED CT, LOINC y UCUM, además de clasificaciones como CIE.
7. La interoperabilidad real exige conformidad documentada, pruebas, seguridad, gobierno de identidad y gestión del cambio.

15.2. Método de resolución de preguntas tipo test

Ante una pregunta, identifica primero la categoría del elemento: organismo, norma, perfil, servicio, formato, terminología o producto. Después busca el verbo técnico: almacenar, consultar, recuperar, correlacionar identificadores, compartir documentos, auditar o representar recursos. Finalmente elimina distractores que mezclan niveles, por ejemplo tratar XDS como modelo documental, FHIR como formato exclusivamente JSON o DICOM como compresión de imagen.

15.3. Errores que deben evitarse

• Suponer que una norma técnica es siempre obligatoria o siempre voluntaria.
• Confundir interoperabilidad sintáctica con semántica.
• Creer que un ACK positivo garantiza que el dato se incorporó correctamente al proceso clínico.
• Identificar C-ECHO con una prueba funcional completa del PACS.
• Confundir repositorio y registro en XDS.b.
• Usar códigos locales sin gobernanza ni mapeo.
• Admitir declaraciones genéricas de compatibilidad sin evidencias ni versiones.

16. MAPA CONCEPTUAL