1. La Necesidad de Normalización en TIC Sanitarias

1.1. El Problema: La Torre de Babel Tecnológica

Imagina un hospital del SAS sin estándares de interoperabilidad:

• El sistema de información clínica (Diraya) almacena los datos de pacientes en un formato propietario de Everis.
• El sistema de radiología (RIS) usa un formato diferente de Philips.
• El PACS (almacenamiento de imágenes) es de GE Healthcare y no se comunica directamente con el RIS de Philips.
• El laboratorio tiene un LIS (Laboratory Information System) de Roche que solo entiende su propio protocolo.
• El sistema de farmacia es de Siemens y no puede consultar medicación en Diraya.
• Las bombas de infusión de las UCIs son de B. Braun y envían datos en formato binario propietario.

Resultado: CAOS TOTAL

• Los médicos tienen que consultar 5 sistemas distintos con 5 usuarios/contraseñas diferentes.
• Los datos no se comparten: la analítica hecha en laboratorio no aparece automáticamente en Diraya.
• Las imágenes radiológicas no están accesibles desde el puesto clínico.
• Imposibilidad de historia clínica unificada.
• Riesgo de errores médicos por información fragmentada.
• Ineficiencia brutal: introducción manual repetida de datos.

Este escenario NO es una exageración. Era la realidad de muchos hospitales antes de la adopción masiva de estándares en los años 90-2000.

1.2. La Solución: Estándares de Interoperabilidad

Los estándares de interoperabilidad son especificaciones técnicas abiertas y consensuadas que definen:

• Formatos de datos: Cómo se estructuran los datos clínicos, imágenes, mensajes.
• Protocolos de comunicación: Cómo los sistemas se intercambian información (TCP/IP, HTTP, SOAP, REST…).
• Semántica común: Qué significa cada campo (un código CIE-10 para diagnóstico, un código LOINC para analítica…).
• Servicios y operaciones: Qué acciones se pueden hacer (almacenar imagen, consultar historia, enviar receta…).

Ejemplo práctico con estándares:

1. Un médico en Diraya solicita una radiografía de tórax.
2. Diraya envía una orden HL7 ORM (Order Message) al RIS de radiología.
3. El paciente acude a radiología, el técnico realiza la placa.
4. La imagen se guarda en el PACS en formato DICOM.
5. El RIS notifica a Diraya que el estudio está listo con un mensaje HL7 ORU (Observation Result).
6. El médico en Diraya hace clic en «Ver imagen» → Diraya solicita la imagen al PACS mediante protocolo DICOM WADO (Web Access to DICOM Objects).
7. La imagen aparece en el navegador del médico (visor DICOM integrado en Diraya).

Todo esto ocurre en segundos, de forma transparente, porque todos los sistemas hablan los mismos idiomas: HL7 y DICOM.

1.3. Beneficios de la Adopción de Estándares en el SAS

1. Interoperabilidad técnica y semántica

• Los sistemas de diferentes fabricantes se comunican entre sí.
• Reducción de «islas de información».
• Historia clínica electrónica unificada.

2. Reducción de costes

• No hay que desarrollar interfaces propietarias específicas entre cada par de sistemas (coste exponencial sin estándares).
• Economías de escala: un mismo interfaz HL7 sirve para múltiples laboratorios.
• Reutilización de componentes: un servidor de integración HL7 centralizado (ej: Mirth Connect) atiende a todos los sistemas.

3. Evitar el vendor lock-in

• Si un sistema cumple estándares HL7/DICOM, se puede cambiar de proveedor sin rehacerlo todo.
• Ejemplo: Si el actual proveedor del PACS (GE) no renueva contrato a un precio razonable, el SAS puede migrar a otro PACS (Philips, Sectra, Agfa…) porque todos hablan DICOM.
• Los datos están en formato estándar (DICOM), no propietario → migración factible.

4. Mejora de la seguridad del paciente

• Información completa y actualizada en tiempo real.
• Menos errores por información fragmentada o transcripción manual.
• Trazabilidad completa: quién accedió a qué datos, cuándo.

5. Eficiencia operativa

• Procesos automatizados: orden → resultado sin intervención manual.
• Ahorro de tiempo de profesionales (no tienen que copiar datos entre sistemas).
• Reducción de pruebas duplicadas (si ya está el resultado en Diraya, no se repite).

6. Innovación y evolución

• Facilita incorporar nuevas tecnologías: apps móviles, telemedicina, IA, IoMT (Internet of Medical Things).
• Los nuevos sistemas pueden integrarse fácilmente si cumplen estándares.
• Ejemplo: Una startup desarrolla una app de telemonitorización de pacientes crónicos. Si usa FHIR para comunicarse con Diraya, la integración es sencilla y rápida.

1.4. Conceptos Clave: Normalización, Interoperabilidad y Estandarización

Normalización

Proceso mediante el cual se establecen especificaciones técnicas (normas, estándares) de forma consensuada por expertos y organismos reconocidos. Las normas pueden ser:

• De jure (legales): Obligatorias por ley o reglamento (ej: ENS, ENI en España).
• De facto (mercado): Adoptadas masivamente por el mercado sin ser legalmente obligatorias (ej: DICOM, HL7, TCP/IP).

Interoperabilidad

Capacidad de sistemas heterogéneos de intercambiar información y utilizarla de forma efectiva. Se distinguen 4 niveles (modelo de interoperabilidad de la UE):

Estandarización

Resultado del proceso de normalización: especificación técnica documentada, publicada y mantenida que define cómo hacer algo de forma reproducible. Los estándares pueden ser:

• Abiertos: Especificación pública, accesible, sin royalties, implementable por cualquiera (ej: HL7, DICOM, FHIR).
• Propietarios/Cerrados: Controlados por una empresa, requieren licencia, especificación no pública (ej: formatos internos de algunos PACSs antiguos).

1.5. Marco Normativo Español y Europeo sobre Interoperabilidad

Esquema Nacional de Interoperabilidad (ENI) – Real Decreto 4/2010

• Norma de aplicación obligatoria a todas las AAPP españolas (incluido SAS).
• Establece principios básicos de interoperabilidad:
  • Art. 7: Carácter multidimensional de la interoperabilidad (organizativa, semántica, técnica).
  • Art. 11: Uso de estándares abiertos.
  • Art. 15: Infraestructura y servicios comunes (ej: @firma, Cl@ve).
• Normas Técnicas de Interoperabilidad (NTI): desarrollo específico del ENI (formatos de firma electrónica, expediente electrónico, documento electrónico, catálogo de estándares…).

Historia Clínica Digital del SNS (HC-SNS)

• Proyecto del Ministerio de Sanidad para compartir historia clínica entre CCAA.
• Basado en estándares HL7 CDA (Clinical Document Architecture).
• Cuando un paciente andaluz viaja a Madrid y necesita atención sanitaria, los médicos madrileños pueden consultar su historia del SAS (con consentimiento del paciente).
• El SAS es uno de los grandes contribuidores de la HC-SNS (Diraya exporta resúmenes clínicos en formato HL7 CDA).

Reglamento eIDAS (UE 910/2014)

• Marco europeo de identificación electrónica y servicios de confianza.
• Relevante para firma electrónica de prescripciones, informes clínicos, consentimientos.
• Interoperabilidad transfronteriza: receta electrónica española válida en Italia, Alemania…

Estrategia de Salud Digital de la UE

• Prioriza interoperabilidad mediante estándares (especialmente FHIR).
• Espacio Europeo de Datos de Salud (EHDS – European Health Data Space): proyecto para compartir datos clínicos entre países UE con fines asistenciales e investigación.
• El SAS participa en proyectos piloto EHDS.

1.6. Ecosistema de Normalización: Panorama General

La normalización TIC es un ecosistema complejo con múltiples actores en varios niveles:

Relaciones entre organizaciones:

• ISO puede adoptar estándares sectoriales como normas ISO (ej: ISO 12052 adopta DICOM).
• CEN armoniza estándares europeos con internacionales (ej: EN ISO 13606 es versión europea de ISO 13606).
• AENOR traduce y adopta normas europeas e ISO como normas UNE (ej: UNE-EN ISO 13606).
• IHE no crea estándares nuevos, define perfiles de integración que combinan HL7, DICOM y otros estándares existentes.

2. Organizaciones Internacionales de Normalización TIC

2.1. ISO (International Organization for Standardization)

Creación y estructura

• Fundada en 1947, con sede en Ginebra (Suiza).
• Federación mundial de organismos nacionales de normalización de 168 países.
• España está representada por AENOR (Asociación Española de Normalización y Certificación).
• ISO NO significa «International Standards Organization» → Es una palabra derivada del griego «isos» (igual), reforzando el concepto de estandarización.

Misión y alcance

• Desarrollar y publicar estándares internacionales voluntarios en prácticamente todos los sectores (excepto electricidad/electrónica que es responsabilidad de IEC, y telecomunicaciones de ITU).
• Más de 24.000 normas ISO publicadas actualmente.
• Cubre: calidad, seguridad, medio ambiente, energía, tecnología, salud, alimentación, transporte…

Proceso de desarrollo de normas ISO

1. Propuesta (NP – New Proposal): Un miembro propone un nuevo estándar.
2. Preparación (WD – Working Draft): Grupo de trabajo elabora borrador.
3. Comité (CD – Committee Draft): Circula entre países miembros para comentarios.
4. Consulta (DIS – Draft International Standard): Votación formal de países.
5. Aprobación (FDIS – Final DIS): Aprobación final (75% votos a favor).
6. Publicación (IS – International Standard): Norma ISO oficial.

El proceso puede durar 2-5 años dependiendo de la complejidad y consenso.

Normas ISO relevantes para TIC y Sanidad

2.2. IEC (International Electrotechnical Commission)

Creación y estructura

• Fundada en 1906, también con sede en Ginebra.
• Organización hermana de ISO, especializada en electrotecnia y electrónica.
• Más de 10.000 normas IEC publicadas.

Ámbito de trabajo

• Tecnologías eléctricas, electrónicas y relacionadas (semiconductores, sensores, baterías, equipos médicos electrónicos…).
• Muchas normas se desarrollan conjuntamente con ISO (normas ISO/IEC).

Normas IEC relevantes para TIC Sanitarias

• IEC 62304: Software de dispositivos médicos (ciclo de vida, validación, mantenimiento).
• IEC 60601 (serie): Seguridad de equipos electromédicos (ventiladores, monitores, bombas de infusión…).
• IEC 80001 (serie): Gestión de riesgo en redes TI de dispositivos médicos (ej: red de monitorización de UCI).
• ISO/IEC 27001: Seguridad de la información (conjunta ISO/IEC).

2.3. ITU (International Telecommunication Union)

Creación y naturaleza

• Fundada en 1865 (la organización internacional más antigua).
• Agencia especializada de las Naciones Unidas para telecomunicaciones.
• Sede en Ginebra.
• 193 Estados miembros + ~900 empresas y organizaciones.

Sectores de ITU

• ITU-T (Telecommunication Standardization Sector): Estándares de telecomunicaciones.
  • Series de recomendaciones: H (multimedia), X (redes de datos), Y (redes futuras), Z (lenguajes)…
  • Ejemplo: H.264 (compresión vídeo), X.509 (certificados digitales).
• ITU-R (Radiocommunication Sector): Espectro radioeléctrico.
• ITU-D (Development Sector): Desarrollo de telecomunicaciones en países en vías de desarrollo.

Aplicación en SAS

• Estándares de videoconferencia (telemedicina): H.323, H.264, H.265.
• Certificados digitales X.509 (firma electrónica de prescripciones, informes clínicos).
• Estándares de redes de telecomunicaciones (backbone del SAS, conexión hospitales).

2.4. IEEE (Institute of Electrical and Electronics Engineers)

Creación y naturaleza

• Fundada en 1963 (fusión de AIEE e IRE), con sede en Nueva York, EE.UU.
• Asociación profesional (no organismo gubernamental), la mayor del mundo en ingeniería eléctrica y electrónica.
• Más de 420.000 miembros en 160 países.
• Publica estándares técnicos, revistas científicas, organiza conferencias.

Estándares IEEE más conocidos

• IEEE 802 (familia): Redes locales (LAN) y metropolitanas (MAN).
  • IEEE 802.3: Ethernet (la tecnología de red cableada más usada en el mundo).
  • IEEE 802.11: Wi-Fi (redes inalámbricas). Variantes: 802.11a/b/g/n/ac/ax (Wi-Fi 6).
  • IEEE 802.1X: Control de acceso a red (autenticación en switches, APs).
• IEEE 1073 (serie): Comunicación de dispositivos médicos (Medical Device Communications).
  • Complementa HL7 para dispositivos de cabecera de cama (monitores, ventiladores, bombas…).
• IEEE 11073 (Personal Health Device – PHD): Dispositivos personales de salud (glucómetros, pulsioxímetros, tensiómetros…).

Aplicación en SAS

• Toda la infraestructura de red del SAS se basa en estándares IEEE 802: switches Ethernet (802.3), APs Wi-Fi (802.11), seguridad de red (802.1X).
• Integración de dispositivos médicos en UCIs y quirófanos mediante IEEE 1073.
• Apps de salud móvil que recogen datos de wearables (IEEE 11073 PHD).

2.5. W3C (World Wide Web Consortium)

Creación y naturaleza

• Fundado en 1994 por Tim Berners-Lee (inventor de la Web).
• Consorcio internacional (no organismo gubernamental) que desarrolla estándares web.
• Sedes: MIT (EE.UU.), ERCIM (Europa), Keio University (Japón), Beihang University (China).
• Más de 440 organizaciones miembros.

Misión

«Llevar la Web a su máximo potencial mediante el desarrollo de protocolos y directrices que aseguren el crecimiento a largo plazo de la Web».

Estándares W3C esenciales

• HTML5: Lenguaje de marcado de páginas web (base de aplicaciones web modernas).
• CSS3: Hojas de estilo en cascada (diseño visual de webs).
• XML: Lenguaje de marcado extensible (usado en HL7 CDA, FHIR XML, configuraciones…).
• SOAP: Protocolo de intercambio de mensajes estructurados (usado en servicios web antiguos).
• WCAG (Web Content Accessibility Guidelines): Accesibilidad web (obligatorio en webs públicas por Ley).
  • WCAG 2.1 nivel AA es el estándar mínimo en España para webs de AAPP.
  • ClicSalud+, Portal del Paciente del SAS deben cumplir WCAG 2.1 AA.
• RDF, OWL: Ontologías y web semántica (usado en terminologías médicas como SNOMED CT).

Aplicación en SAS

• Todas las aplicaciones web del SAS (Diraya web, ClicSalud+, portales de profesionales) se basan en HTML5, CSS3.
• Servicios web de integración usan XML (HL7 v3, FHIR XML).
• Cumplimiento obligatorio de WCAG para accesibilidad.
• Web semántica para gestión de terminologías clínicas (SNOMED CT en formato RDF).

2.6. IETF (Internet Engineering Task Force)

Creación y naturaleza

• Fundado en 1986.
• Comunidad abierta de ingenieros, operadores de red, investigadores, fabricantes… que desarrollan estándares de Internet.
• NO es una organización formal con membresía, es una comunidad abierta (cualquiera puede participar).
• Organizado por grupos de trabajo temáticos.

Documentos IETF: RFCs (Request for Comments)

• Los estándares IETF se publican como RFCs, documentos técnicos numerados.
• Tipos de RFC:
  • Standards Track: Estándares oficiales de Internet.
  • Informational: Información general, no estándar obligatorio.
  • Experimental: Protocolos en fase experimental.
  • Best Current Practice (BCP): Mejores prácticas recomendadas.

Protocolos IETF fundamentales

• TCP/IP (RFC 793, 791): Protocolos de transporte e Internet (base de toda comunicación en red).
• HTTP/HTTPS (RFC 2616, RFC 2818): Protocolo de transferencia de hipertexto (base de la Web).
• TLS (RFC 8446): Seguridad en la capa de transporte (cifrado HTTPS).
• SMTP, IMAP, POP3: Protocolos de correo electrónico.
• DNS (RFC 1035): Sistema de nombres de dominio.
• SNMP: Protocolo de gestión de red (monitorización de routers, switches, servidores…).
• OAuth 2.0 (RFC 6749): Autorización delegada (usado en APIs FHIR, autenticación apps móviles).
• JSON (RFC 8259): Formato de intercambio de datos (usado masivamente en FHIR, APIs REST).

Aplicación en SAS

• TODA la infraestructura de comunicaciones del SAS se basa en protocolos IETF: TCP/IP, HTTP/HTTPS, TLS, DNS…
• APIs REST de Diraya usan HTTPS + JSON (ambos IETF).
• Autenticación OAuth 2.0 para apps móviles que acceden a Diraya vía FHIR.
• Monitorización de red mediante SNMP.
• Correo corporativo del SAS: SMTP, IMAP.

2.7. Otras Organizaciones Internacionales Relevantes

OASIS (Organization for the Advancement of Structured Information Standards)

• Consorcio internacional sin ánimo de lucro.
• Desarrolla estándares abiertos para servicios web, seguridad, e-business, cloud…
• Estándares relevantes:
  • SAML (Security Assertion Markup Language): Single Sign-On (SSO). Usado en portales del SAS para autenticación única.
  • XACML: Control de acceso basado en políticas.
  • ebXML: Intercambio electrónico de información de negocio.

OMG (Object Management Group)

• Consorcio de la industria del software.
• Desarrolla estándares para ingeniería de software, modelado, middleware…
• Estándares relevantes:
  • UML (Unified Modeling Language): Lenguaje de modelado de software (usado para documentar arquitectura de Diraya).
  • BPMN (Business Process Model and Notation): Modelado de procesos (ya visto en Tema 31).
  • CORBA: Middleware de objetos distribuidos (antiguo, menos usado hoy).

Unicode Consortium

• Desarrolla y mantiene el estándar Unicode (codificación universal de caracteres).
• Permite representar texto en cualquier idioma (español, árabe, chino, emojis…).
• Fundamental para internacionalización (i18n) de sistemas como Diraya.

2.8. Coordinación entre Organizaciones

Las organizaciones de normalización NO trabajan en silos, colaboran intensamente:

• ISO e IEC tienen un comité técnico conjunto ISO/IEC JTC 1 (Joint Technical Committee 1) para TIC. Desarrollan normas conjuntas ISO/IEC (ej: ISO/IEC 27001, ISO/IEC 20000).
• W3C e IETF coordinan estándares web. Ejemplo: HTTP fue desarrollado por IETF (RFC 2616), pero el trabajo en HTML, CSS es de W3C.
• ISO, IEC, ITU tienen acuerdos de cooperación. Ejemplo: ITU-T X.509 (certificados digitales) fue adoptado posteriormente por ISO/IEC.
• Estándares sectoriales (HL7, DICOM) pueden «ascender» a normas ISO si tienen suficiente reconocimiento internacional (ej: DICOM → ISO 12052).

3. Organizaciones Europeas y Nacionales de Normalización

3.1. CEN (Comité Europeo de Normalización) y CENELEC

CEN – Comité Européen de Normalisation

• Fundado en 1961, con sede en Bruselas.
• Organización privada sin ánimo de lucro que agrupa a los organismos nacionales de normalización de 34 países europeos (UE + EFTA + países candidatos).
• Homólogo europeo de ISO (misma función pero a nivel regional europeo).
• España está representada por AENOR.

CENELEC – Comité Européen de Normalisation Électrotechnique

• Fundado en 1973, también en Bruselas.
• Homólogo europeo de IEC (normalización electrotecnia y electrónica a nivel europeo).
• Mismos países miembros que CEN.

Misión de CEN/CENELEC

• Desarrollar normas europeas armonizadas (EN – European Norm) que faciliten el comercio dentro del mercado único europeo.
• Garantizar conformidad con legislación europea (directivas, reglamentos).
• Cooperar estrechamente con ISO/IEC para evitar duplicidades: muchas normas CEN/CENELEC son adopciones de normas ISO/IEC.

Tipos de documentos CEN/CENELEC

• EN (European Norm): Norma europea obligatoria de adoptar por todos los países miembros como norma nacional. Ejemplo: EN 13606 (EHR) → en España se publica como UNE-EN 13606.
• ENV (European Prestandard): Pre-norma provisional (menos usada actualmente).
• TS (Technical Specification): Especificación técnica (no obligatoria, pero recomendada).
• TR (Technical Report): Informe técnico (información, no normativa).

Normas CEN/CENELEC relevantes para Sanidad TIC

3.2. ETSI (European Telecommunications Standards Institute)

Creación y estructura

• Fundado en 1988, con sede en Sophia Antipolis (Francia).
• Organización independiente sin ánimo de lucro reconocida oficialmente por la UE.
• Más de 900 miembros de 65 países (fabricantes, operadores, reguladores, investigadores…).

Misión

• Desarrollar estándares de telecomunicaciones e información y comunicaciones electrónicas en Europa.
• Homólogo europeo de ITU-T, pero con enfoque en normativa técnica implementable (no solo recomendaciones).

Áreas de trabajo ETSI

• Redes móviles: GSM, UMTS (3G), LTE (4G), 5G.
• Redes fijas: banda ancha, fibra óptica.
• Seguridad: ciberseguridad, cifrado, firma electrónica.
• IoT (Internet de las Cosas): M2M (Machine to Machine), SmartCities, dispositivos conectados.
• Broadcasting: TV digital (DVB).

Estándares ETSI relevantes para Sanidad

• ETSI EN 301 549: Requisitos de accesibilidad para productos y servicios TIC.
  • Obligatorio en España (RD 1112/2018 transpone Directiva UE 2016/2102).
  • Webs, apps móviles, PDFs de AAPP deben cumplir EN 301 549.
  • ClicSalud+ y portales del SAS deben ser accesibles (nivel AA de WCAG 2.1, integrado en EN 301 549).
• ETSI TS 102 231: Infraestructura de firma electrónica (TSL – Trusted Service Status List).
  • Lista de prestadores de servicios de confianza (certificados digitales, firma electrónica).
  • Relevante para receta electrónica, firma de informes clínicos.
• 5G para e-Health: ETSI desarrolla estándares de redes 5G aplicadas a salud (telemedicina, cirugía remota, telemonitorización en tiempo real).

Aplicación en SAS

• Accesibilidad: Cumplimiento obligatorio EN 301 549 en todas las webs y apps del SAS.
• Firma electrónica: Prescripciones y documentos clínicos firmados con certificados validados según ETSI.
• Redes móviles: Apps ClicSalud+ funcionan sobre redes 4G/5G estandarizadas por ETSI.
• Telemedicina: Videoconferencias médico-paciente sobre infraestructuras ETSI.

3.3. AENOR (Asociación Española de Normalización y Certificación)

Creación y naturaleza

• Fundada en 1986, con sede en Madrid.
• Entidad privada sin ánimo de lucro reconocida por Real Decreto 2200/1995 como organismo español de normalización.
• Representa a España en ISO, IEC, CEN, CENELEC, ETSI y otros organismos internacionales.

Funciones principales

1. Normalización: Desarrollar y publicar normas españolas (UNE).
2. Certificación: Certificar productos, servicios, sistemas de gestión (ISO 9001, ISO 27001…).
3. Formación: Cursos sobre normas y sistemas de gestión.
4. Información: Venta y difusión de normas españolas, europeas e internacionales.

Proceso de elaboración de normas UNE

1. Propuesta: Cualquier entidad puede proponer una norma UNE (empresa, administración, asociación…).
2. Análisis: Comité Técnico de Normalización (CTN) evalúa la propuesta.
3. Redacción: Grupo de trabajo elabora borrador (participación voluntaria de expertos de la industria, administración, universidad…).
4. Consulta pública: Borrador se publica para comentarios (60 días).
5. Aprobación: Votación del CTN.
6. Publicación: AENOR publica la norma UNE.

Comités Técnicos de Normalización relevantes

• CTN 71: Tecnologías de la Información (equivalente español del JTC 1 de ISO/IEC).
  • Subcomités: seguridad TI, bases de datos, lenguajes de programación, oficina electrónica…
• CTN 139: Informática de la Salud.
  • Desarrolla normas UNE específicas sanitarias.
  • Adopta normas ISO 13606, EN 13606 como UNE.
  • Participa en grupos de trabajo europeos e internacionales de e-Health.
• CTN 158: Seguridad de la Información y Ciberseguridad (ISO 27000, ENS…).

3.4. Normas UNE: El Estándar Nacional Español

¿Qué es una norma UNE?

• UNE = Una Norma Española.
• Especificación técnica de aplicación voluntaria (salvo que una ley o reglamento la haga obligatoria).
• Garantiza calidad, seguridad, interoperabilidad, sostenibilidad…

Tipos de normas UNE

• UNE: Norma puramente española (creada originalmente en España).
  • Ejemplo: UNE 93200 (terminología sanitaria española).
• UNE-EN: Adopción de norma europea EN.
  • Ejemplo: UNE-EN 13606 (historia clínica electrónica, adopción de EN 13606).
• UNE-EN ISO: Adopción de norma ISO que también es EN.
  • Ejemplo: UNE-EN ISO 27001 (seguridad de la información).
• UNE-ISO: Adopción directa de norma ISO (sin pasar por armonización europea).
  • Ejemplo: UNE-ISO 9001 (aunque actualmente es UNE-EN ISO 9001 porque también está armonizada en Europa).

Normas UNE relevantes para TIC Sanitaria en el SAS

3.5. Relación entre Organismos: De ISO a UNE

Flujo típico de adopción de normas:

1. ISO publica una norma internacional (ej: ISO 13606)
            ↓
2. CEN evalúa si adopta la norma ISO como norma europea
            ↓
3. CEN publica EN ISO 13606 (norma europea que adopta ISO 13606)
            ↓
4. AENOR (y todos los organismos nacionales europeos) DEBEN adoptar EN ISO 13606 como norma nacional
            ↓
5. AENOR publica UNE-EN ISO 13606 (versión española)
            ↓
6. Las organizaciones españolas (incluido SAS) aplican UNE-EN ISO 13606

¿Por qué este proceso?

• Armonización: Garantiza que en toda Europa se aplica la misma norma (mercado único).
• No duplicidad: Se evita que cada país desarrolle su propia norma incompatible con las demás.
• Actualización coordinada: Cuando ISO actualiza una norma, CEN y AENOR actualizan automáticamente sus versiones.

Obligatoriedad de adopción de normas EN:

• Cuando CEN publica una norma EN, todos los organismos nacionales europeos (incluido AENOR) DEBEN:
  1. Adoptarla como norma nacional (publicar UNE-EN).
  2. Retirar cualquier norma nacional contradictoria.
• Esto garantiza armonización total en Europa.

3.6. Cooperación Europea en e-Health: Iniciativas Clave

eHDSI (eHealth Digital Service Infrastructure)

• Infraestructura europea para intercambio transfronterizo de datos de salud.
• Servicios implementados:
  • Receta electrónica transfronteriza: Un español puede recoger medicación en una farmacia italiana con su receta electrónica del SAS.
  • Resumen de historia clínica del paciente: Profesionales sanitarios de otros países UE pueden consultar resumen clínico de pacientes extranjeros (con consentimiento).
• Basado en estándares: HL7 CDA, IHE perfiles (XCA, XDS).
• España (SAS y otras CCAA) participa activamente en eHDSI.

EHDS (European Health Data Space)

• Proyecto futuro de la UE (Reglamento en tramitación 2024-2025).
• Objetivo: Marco común para compartir datos de salud en toda Europa con fines:
  • Primarios: Asistencia sanitaria (continuidad asistencial transfronteriza).
  • Secundarios: Investigación, salud pública, regulación farmacéutica, IA en salud.
• Basará en estándares abiertos, prioritariamente HL7 FHIR.
• El SAS deberá adaptar Diraya para cumplir requisitos EHDS cuando entre en vigor.

4. DICOM (Digital Imaging and Communications in Medicine)

4.1. Historia y Evolución de DICOM

El Problema Original (años 70-80)

En los años 70-80, cada fabricante de equipos de imagen médica (GE, Siemens, Philips, Toshiba…) usaba su propio formato propietario para almacenar y transmitir imágenes. Resultado:

• Un TAC de GE no podía enviar imágenes a un PACS de Siemens.
• Las imágenes se almacenaban en cintas magnéticas o discos ópticos propietarios.
• Imposibilidad de consultar imágenes desde estaciones de trabajo genéricas.
• Los hospitales quedaban «prisioneros» de un fabricante (vendor lock-in extremo).

ACR-NEMA (1983-1993): Los Precursores de DICOM

• En 1983, el ACR (American College of Radiology) y NEMA (National Electrical Manufacturers Association) crearon un grupo de trabajo para desarrollar un estándar de comunicación de imágenes médicas.
• ACR-NEMA 1.0 (1985): Primera versión, muy básica.
• ACR-NEMA 2.0 (1988): Mejoras significativas.
• Limitaciones: Solo comunicación punto a punto mediante cable específico, no funcionaba en redes TCP/IP.

DICOM 3.0 (1993): El Estándar Definitivo

• En 1993, ACR y NEMA publicaron DICOM 3.0, una revisión completa que:
  • Funciona sobre redes TCP/IP estándar (no requiere hardware específico).
  • Define un modelo de información orientado a objetos.
  • Soporta múltiples modalidades (CT, MR, US, CR, DX…).
  • Incluye servicios de red (almacenar, recuperar, buscar, imprimir…).
  • Define estructuras de datos consistentes (objetos de información).
• DICOM 3.0 fue un éxito rotundo y se convirtió en el estándar de facto mundial para imágenes médicas.

Evolución Post-3.0 (1993-actualidad)

• DICOM NO es un estándar estático. Se actualiza continuamente con suplementos (Supplements) que añaden nuevas funcionalidades.
• Versión actual: DICOM 2024e (actualización «e» del año 2024).
• Nuevas características añadidas con los años:
  • DICOM SR (Structured Reporting): Informes estructurados (no solo imágenes, también datos clínicos).
  • DICOM WADO (Web Access to DICOM Objects): Acceso a imágenes DICOM vía HTTP/HTTPS (permite visualización en navegadores web).
  • DICOM WADO-RS: Versión RESTful de WADO (API moderna).
  • DICOMweb: Conjunto de servicios web (WADO-RS, STOW-RS, QIDO-RS) para acceder a PACS mediante APIs REST.
  • Soporte para vídeo, imágenes 3D/4D, patología digital (whole slide imaging).

Adopción Internacional

• DICOM fue adoptado como norma ISO 12052.
• También norma europea EN 12052 y española UNE-EN 12052.
• Prácticamente el 100% de los equipos de imagen médica modernos cumplen DICOM.

4.2. Arquitectura y Componentes de DICOM

DICOM NO es solo un formato de archivo de imagen. Es un estándar completo que incluye:

1. Modelo de Información (Information Object Definitions – IOD)

Define QUÉ datos se almacenan y transmiten.

2. Servicios de Red (DIMSE – DICOM Message Service Element)

Define CÓMO se comunican los sistemas (operaciones: almacenar, recuperar, buscar…).

3. Protocolos de Comunicación

Define SOBRE QUÉ redes funcionan (TCP/IP, HTTP…).

4. Formatos de Archivo

Define CÓMO se almacenan las imágenes en disco (.dcm).

5. Conformidad (Conformance Statements)

Cada implementación DICOM debe publicar un documento de conformidad que especifica exactamente qué partes del estándar soporta.

4.3. Objetos de Información DICOM (IOD)

Un IOD (Information Object Definition) es una especificación de un tipo de objeto que se puede intercambiar en DICOM. Cada IOD define:

• Qué atributos (tags) contiene.
• Cuáles son obligatorios, opcionales o condicionales.
• Qué valores puede tomar cada atributo.

Ejemplos de IODs:

• CT Image IOD: Imagen de Tomografía Computarizada.
• MR Image IOD: Imagen de Resonancia Magnética.
• US Image IOD: Imagen de Ultrasonido (ecografía).
• CR Image IOD: Radiología Computarizada (radiografía digital).
• Structured Report (SR) IOD: Informe estructurado (texto + mediciones).
• Presentation State IOD: Estado de presentación (anotaciones, ventanas, zoom…).

Estructura de un objeto DICOM: Data Set

Un objeto DICOM contiene un Data Set: conjunto de elementos de datos (Data Elements), cada uno identificado por un tag.

Ejemplo de tags DICOM:

UID (Unique Identifier)

Los objetos DICOM se identifican mediante UIDs (cadenas numéricas únicas globalmente, similares a UUIDs). Hay UIDs para:

• Study: Un estudio completo (ej: «TAC tórax del paciente Juan García del 15/10/2024»).
• Series: Una serie dentro de un estudio (ej: «Serie axial con contraste»).
• Image (SOP Instance): Una imagen individual (ej: «Corte 25 de la serie axial»).

Paciente (Patient)
  └─ Estudio (Study) [UID único]
       └─ Serie (Series) [UID único]
            └─ Imagen (Instance/SOP) [UID único]
            └─ Imagen
            └─ ...
       └─ Serie
            └─ Imagen
            └─ ...
  └─ Estudio
       └─ ...
    

4.4. Servicios DICOM (DIMSE)

DIMSE (DICOM Message Service Element) define las operaciones que se pueden realizar entre sistemas DICOM. Son análogos a operaciones CRUD (Create, Read, Update, Delete) en bases de datos.

Servicios DIMSE principales:

Roles DICOM:

• SCU (Service Class User): Cliente que INICIA una operación (ej: un TAC que envía imágenes es SCU de C-STORE).
• SCP (Service Class Provider): Servidor que RESPONDE a la operación (ej: el PACS que recibe imágenes es SCP de C-STORE).

Ejemplo de flujo C-STORE:

1. TAC (SCU) establece conexión TCP/IP con PACS (SCP) en puerto 104 (puerto estándar DICOM).
2. TAC envía solicitud C-STORE con imagen DICOM.
3. PACS valida la imagen, la almacena en su base de datos.
4. PACS responde: "C-STORE exitoso" (status 0x0000 = Success).
5. TAC cierra conexión.

4.5. Modalidades de Imagen y DICOM

DICOM soporta prácticamente TODAS las modalidades de imagen médica. Cada modalidad tiene códigos específicos:

4.6. PACS (Picture Archiving and Communication System)

Un PACS es un sistema informático que:

• Almacena imágenes médicas en formato DICOM.
• Gestiona la base de datos de estudios (indexación por paciente, fecha, modalidad…).
• Distribuye las imágenes a estaciones de trabajo, visores web, sistemas clínicos (Diraya).
• Archiva a largo plazo (almacenamiento masivo, copias de seguridad).

Componentes de un PACS:

1. Servidor DICOM:
   • Recibe imágenes de modalidades (C-STORE SCP).
   • Gestiona base de datos (metadatos: paciente, estudio, serie…).
   • Sirve imágenes a clientes (C-FIND, C-GET, C-MOVE SCP).
2. Almacenamiento:
   • Primario (online): Discos SSD/HDD de alta velocidad para estudios recientes (últimos 3-6 meses). Acceso inmediato.
   • Secundario (nearline): Discos de menor coste para estudios antiguos (6 meses – 5 años). Acceso en segundos/minutos.
   • Archivo (offline): Cintas LTO, almacenamiento en cloud para estudios muy antiguos (>5 años). Acceso en horas/días. Obligatorio legalmente conservar imágenes durante años (historial clínico).
3. Estaciones de Diagnóstico (Diagnostic Workstations):
   • PCs de alto rendimiento con monitores médicos calibrados (alta resolución, luminancia certificada).
   • Software visor DICOM avanzado: ventanas, zoom, mediciones, reconstrucciones 3D, fusión de imágenes…
   • Usadas por radiólogos para emitir informes.
4. Estaciones de Visualización (Review Workstations):
   • PCs estándar para consulta de imágenes por clínicos no radiólogos (médicos de urgencias, cirujanos…).
   • Funcionalidad básica de visualización.
5. Visores Web:
   • Acceso a imágenes desde navegador web (no requiere instalación de software).
   • Usan DICOMweb (WADO-RS) para recuperar imágenes del PACS vía HTTP.
   • Integrados en Diraya: los médicos ven imágenes sin salir de la historia clínica.
6. Interfaz con RIS/HIS:
   • RIS (Radiology Information System): Sistema de gestión de radiología (agenda, pedidos, informes).
   • HIS (Hospital Information System): Sistema de información hospitalario (Diraya en el SAS).
   • Comunicación mediante HL7 (órdenes de radiología, resultados) + DICOM (imágenes).

4.7. DICOMweb: DICOM en la Era Web

DICOM clásico (DIMSE sobre TCP/IP puerto 104) funciona perfectamente en redes de hospital, pero tiene limitaciones en la era web/cloud:

• Requiere abrir puertos específicos (problemas con firewalls).
• Protocolo binario complejo (difícil de implementar en aplicaciones web/móviles).
• No se integra fácilmente con arquitecturas REST/microservicios.

DICOMweb es un conjunto de servicios RESTful sobre HTTP/HTTPS que moderniza el acceso a PACS:

Ventajas de DICOMweb:

• Usa protocolo estándar HTTP/HTTPS (puerto 80/443, compatible con firewalls).
• Fácil de implementar en aplicaciones web (JavaScript), móviles, cloud.
• Soporta autenticación estándar (OAuth 2.0, OpenID Connect).
• Compatible con APIs REST modernas.
• El SAS está migrando gradualmente a DICOMweb para integración de Diraya con PACS.

4.8. Aplicación de DICOM en el SAS

Sistema RIS-PACS Corporativo del SAS

• El SAS tiene un PACS corporativo que gestiona TODAS las imágenes médicas de Andalucía.
• Fabricante principal: GE Healthcare (Centricity PACS).
• Almacena millones de estudios radiológicos de todos los hospitales y centros del SAS.
• Volumen: varios petabytes de imágenes DICOM.

Integración Diraya-PACS

1. Médico en Diraya solicita una radiografía → Diraya envía mensaje HL7 ORM (orden) al RIS.
2. RIS registra la petición, genera Worklist DICOM (lista de trabajo para técnicos de radiología).
3. Técnico en la sala de radiología ve la petición en el worklist del equipo (modalidad DICOM).
4. Técnico realiza la radiografía → equipo envía imágenes DICOM al PACS mediante C-STORE.
5. PACS almacena imágenes, indexa por paciente (NUHSA).
6. RIS notifica a Diraya que el estudio está disponible mediante mensaje HL7 ORU.
7. Médico en Diraya hace clic en «Ver imágenes» → visor web embebido en Diraya obtiene imágenes del PACS mediante DICOMweb WADO-RS.
8. Imágenes se visualizan en el navegador (visor JavaScript DICOM, ej: Cornerstone.js, OHIF Viewer).

5. HL7 (Health Level Seven)

5.1. Historia y Organización de HL7

Creación y Nombre

• HL7 fue fundado en 1987 en Estados Unidos.
• «Health Level 7» hace referencia a la capa 7 (aplicación) del modelo OSI de redes. HL7 se centra en el nivel de aplicación: intercambio de datos entre aplicaciones sanitarias, no en capas inferiores (transporte, red…).
• Organización sin ánimo de lucro con sede en Ann Arbor, Michigan (EE.UU.).

HL7 International

• Organismo internacional con más de 1.600 miembros de 50+ países.
• Incluye: fabricantes de software sanitario, hospitales, administraciones sanitarias, consultores, investigadores.
• Estructura: comités técnicos especializados (Patient Administration, Orders & Observations, Clinical Decision Support, FHIR Infrastructure…).
• Proceso de desarrollo abierto: cualquier miembro puede proponer cambios, extensiones, nuevas funcionalidades.

HL7 España

• Afiliado oficial de HL7 International desde 2001.
• Asociación sin ánimo de lucro que promueve HL7 en España.
• Miembros: SAS, otros servicios sanitarios autonómicos, empresas TIC sanitarias (Everis, Indra, Atos…), hospitales, universidades.
• Organiza eventos, formación, traduce documentación HL7 al español.

Misión de HL7

«Proporcionar un marco de trabajo completo y estándares relacionados para el intercambio, integración, compartición y recuperación de información sanitaria electrónica que apoye la práctica clínica y la gestión, entrega y evaluación de servicios de salud»

5.2. Versiones de HL7: Evolución Histórica

HL7 ha evolucionado a través de múltiples versiones con enfoques diferentes:

5.3. HL7 v2.x: La Mensajería Clásica

Estructura de un Mensaje HL7 v2

Un mensaje HL7 v2 es un texto plano estructurado con delimitadores específicos:

• Segmentos: Líneas de información (paciente, pedido, resultado…). Cada segmento empieza con un código de 3 letras.
• Campos: Separados por | (pipe).
• Componentes: Dentro de un campo, separados por ^ (caret).
• Subcomponentes: Dentro de un componente, separados por & (ampersand).
• Repeticiones: Separadas por ~ (tilde).
• Escape: \ (backslash) para caracteres especiales.

Ejemplo de Mensaje HL7 v2.5 (Admisión de Paciente):

MSH|^~\&|DIRAYA|SAS|LAB|H_VIRGEN_ROCIO|20241024143000||ADT^A01^ADT_A01|MSG001234|P|2.5|||NE|NE|ES
EVN||20241024143000|||^GARCIA_LOPEZ_JUAN^^^^^^^CURRENT
PID|1||12345678A^^^SAS^MR||García López^Juan^Antonio^^Sr.||19850315|M|||Calle Sierpes 123^^Sevilla^Sevilla^41001^ES||(955)123456|(955)789012||S||123456789|||||||||||||||||
PV1|1|I|UCI^201^A|ER|||^RODRIGUEZ^MARIA^CARMEN^^^Dra.|CARD||||19|V|A0||^RODRIGUEZ^MARIA^CARMEN^^^Dra.|INP|NHS|||||||||V||||||||20241024143000

Explicación del ejemplo:

• MSH (Message Header): Cabecera con metadatos del mensaje (sistemas origen/destino, timestamp, tipo mensaje…).
• EVN (Event Type): Información sobre el evento que generó el mensaje.
• PID (Patient Identification): Datos demográficos del paciente (nombre, DNI, fecha nacimiento, dirección…).
• PV1 (Patient Visit): Información sobre la visita/ingreso (ubicación, médico responsable, tipo asistencia…).

Tipos de Mensajes HL7 v2 más Comunes:

Segmentos HL7 v2 Fundamentales:

• MSH (Message Header): Obligatorio en todos los mensajes. Metadatos.
• PID (Patient Identification): Datos demográficos del paciente.
• PV1 (Patient Visit): Información sobre la visita/encuentro clínico.
• OBR (Observation Request): Petición de observación (analítica, radiografía…).
• OBX (Observation/Result): Resultado de observación (valor analítica, medición…).
• EVN (Event Type): Contexto del evento que generó el mensaje.
• NK1 (Next of Kin): Contactos familiares/personas relacionadas.
• AL1 (Allergy Information): Información sobre alergias del paciente.

5.4. HL7 v3 y CDA (Clinical Document Architecture)

HL7 v3: La Revolución que no Triunfó

• Desarrollo iniciado en 1998 para superar limitaciones de v2.
• Basada en un modelo de referencia (RIM – Reference Information Model) muy complejo y formal.
• Formato XML en lugar del texto delimitado de v2.
• Problemas:
  • Extremadamente compleja de implementar.
  • Curva de aprendizaje muy alta.
  • Incompatibilidad total con v2 (no migración gradual).
  • Rendimiento inferior (XML más pesado que texto delimitado).
• Resultado: Adopción muy limitada. La mayoría de implementaciones siguieron con v2.

CDA (Clinical Document Architecture): El Éxito de v3

• CDA es una parte específica de HL7 v3 que SÍ ha tenido éxito.
• Define estructura XML para documentos clínicos (informes, altas, resúmenes…).
• Características:
  • Persistencia: El documento debe mantenerse íntegro en el tiempo.
  • Administración: Metadatos sobre autor, fecha, destinatario…
  • Autenticidad: Firma digital, integridad.
  • Completitud: Documento completo, no fragmentado.
  • Legibilidad humana: Debe ser legible sin software específico (HTML embebido).

Estructura de un Documento CDA:

<ClinicalDocument>
  <realmCode code="ES"/>
  <typeId root="2.16.840.1.113883.1.3"/>
  <templateId root="1.3.6.1.4.1.19376.1.5.3.1.1.1"/>
  <id root="2.16.724.4.8.10.200.10" extension="DOC001234"/>
  <code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of episode note"/>
  <title>Informe de Alta Hospitalaria</title>
  <effectiveTime value="20241024143000"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <recordTarget>
    <patientRole>
      <id root="2.16.724.4.8.10.200.10" extension="12345678A"/>
      <patient>
        <name>García López, Juan Antonio</name>
        <birthTime value="19850315"/>
        <administrativeGenderCode code="M"/>
      </patient>
    </patientRole>
  </recordTarget>
  <author>...</author>
  <component>
    <structuredBody>
      <component>
        <section>
          <title>Diagnóstico Principal</title>
          <text>Infarto agudo de miocardio</text>
          <entry>
            <observation>...</observation>
          </entry>
        </section>
      </component>
    </structuredBody>
  </component>
</ClinicalDocument>

Uso de CDA en España:

• HC-SNS (Historia Clínica Digital del Sistema Nacional de Salud) usa HL7 CDA.
• Cuando un paciente andaluz es atendido en Madrid, el SAS puede compartir un resumen de su historia clínica en formato CDA.
• Diraya exporta documentos CDA para intercambio con otras CCAA.
• Documentos típicos en CDA: informes de alta, resúmenes de episodio, informes de urgencias.

5.5. HL7 FHIR: El Futuro de la Interoperabilidad Sanitaria

FHIR (Fast Healthcare Interoperability Resources)

• Desarrollo iniciado en 2012 por Grahame Grieve (HL7 Australia).
• Primera release estable: FHIR R4 (2019), actualmente FHIR R5 (2023).
• Diseñado para resolver problemas de v2 (complejidad) y v3 (sobrecarga de XML).

Principios de Diseño de FHIR:

1. Simplicidad: Fácil de entender e implementar.
2. Implementabilidad: Enfoque práctico, no académico.
3. Interoperabilidad: Compatible con sistemas existentes.
4. Evolución: Permite actualizaciones sin romper compatibilidad.
5. Estándares web: Usa HTTP, REST, JSON, OAuth 2.0…

Arquitectura FHIR:

1. Recursos (Resources)

En FHIR, toda la información sanitaria se modela como recursos (objetos JSON/XML con estructura definida):

2. RESTful API

FHIR define una API REST estándar para operaciones CRUD sobre recursos:

3. Referencias entre Recursos

Los recursos FHIR se relacionan mediante referencias (similar a claves foráneas en bases de datos):

{
  "resourceType": "Observation",
  "id": "glucose-001",
  "status": "final",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "33747-0",
      "display": "Glucose [Mass/volume] in Serum"
    }]
  },
  "subject": {
    "reference": "Patient/12345"  ← Referencia al paciente
  },
  "encounter": {
    "reference": "Encounter/visit-001"  ← Referencia al encuentro clínico
  },
  "valueQuantity": {
    "value": 95,
    "unit": "mg/dl",
    "system": "http://unitsofmeasure.org",
    "code": "mg/dL"
  }
}

4. Terminologías y Ontologías

FHIR integra terminologías médicas estándar:

• LOINC: Códigos de laboratorio y observaciones clínicas.
• SNOMED CT: Terminología clínica completa.
• CIE-10: Clasificación de enfermedades.
• RxNorm: Medicamentos (EEUU) / ATC: Anatómico Terapéutico Químico (Europa).

5.6. Comparación HL7 v2 vs FHIR

5.7. Implementación de HL7 en el SAS

Motor de Integración HL7 del SAS

• El SAS utiliza un motor de integración centralizado basado en Mirth Connect (plataforma open source de integración sanitaria).
• Gestiona miles de mensajes HL7 v2 diarios entre:
  • Diraya ↔ Sistemas de laboratorio (petición analíticas, resultados).
  • Diraya ↔ RIS-PACS (órdenes radiología, notificación disponibilidad imágenes).
  • Diraya ↔ Sistemas de farmacia (prescripciones, dispensación).
  • Diraya ↔ Sistemas de cita previa (programación, modificación, cancelación citas).
  • Diraya ↔ Sistemas de gestión de camas (ADT – admit/discharge/transfer).

Casos de Uso HL7 v2 en el SAS:

1. Flujo Analítica (ORM → ORU):

1. Médico en Diraya solicita analítica bioquímica.
2. Diraya genera mensaje HL7 ORM^O01 con petición.
3. Motor integración enruta mensaje al LIS (Laboratory Information System).
4. LIS registra petición, genera etiquetas, programa extracción.
5. Tras analizar muestra, LIS envía resultados con HL7 ORU^R01.
6. Motor integración recibe resultado, lo enruta a Diraya.
7. Diraya almacena resultados, notifica al médico (alerta si valores críticos).

2. Intercambio con otras CCAA (CDA):

• Paciente andaluz atendido en Madrid en urgencias.
• Hospital madrileño solicita historia clínica al SAS.
• Diraya exporta resumen de historia en formato HL7 CDA.
• Hospital madrileño importa CDA, médicos consultan antecedentes.

Migración hacia FHIR en el SAS:

• El SAS está iniciando proyectos piloto con FHIR R4.
• Casos de uso prioritarios:
  • Apps móviles: ClicSalud+ consulta datos Diraya mediante API FHIR.
  • Investigación: Extracción de datos anonimizados para estudios clínicos.
  • Interoperabilidad europea: Preparación para EHDS (European Health Data Space).
  • Integración IoMT: Dispositivos de telemonitorización envían datos vía FHIR.
• Estrategia: coexistencia HL7 v2 + FHIR. Los sistemas legacy seguirán con v2, nuevos desarrollos usarán FHIR.

6. IHE (Integrating the Healthcare Enterprise)

6.1. ¿Qué es IHE? Concepto y Misión

Definición

IHE NO es un estándar en sí mismo. Es una iniciativa internacional que define perfiles de integración: especificaciones de CÓMO combinar estándares existentes (HL7, DICOM, SNOMED CT…) para resolver problemas concretos de interoperabilidad sanitaria.

Analogía:

• HL7 y DICOM son como piezas de LEGO individuales (estándares).
• IHE son los manuales de instrucciones que te explican cómo combinar esas piezas para construir estructuras específicas (soluciones de integración).

Fundación y Organización

• Fundada en 1998 por HIMSS (Healthcare Information and Management Systems Society) y RSNA (Radiological Society of North America).
• Colaboración entre proveedores TIC sanitarias (fabricantes) y usuarios (hospitales, clínicas).
• Organización internacional con comités regionales: IHE USA, IHE Europa, IHE Asia-Pacífico…
• IHE Europa incluye participación activa de España (SAS, otros servicios sanitarios, fabricantes como Everis, Indra…).

Misión de IHE

«Mejorar la forma en que los sistemas informáticos sanitarios comparten información. IHE promueve el uso coordinado de estándares establecidos como DICOM y HL7 para abordar necesidades clínicas específicas de compartición de información entre sistemas y para soportar prácticas clínicas óptimas»

Lo que IHE NO hace:

• NO crea estándares nuevos (usa HL7, DICOM, etc.).
• NO certifica productos (los fabricantes pueden auto-declarar conformidad IHE).
• NO es obligatorio legalmente (es voluntario, pero muy recomendado).

Lo que IHE SÍ hace:

• Define perfiles de integración: recetas paso a paso de cómo integrar sistemas.
• Especifica actores: roles que asumen los sistemas en una integración.
• Define transacciones: mensajes específicos (HL7, DICOM…) que se intercambian.
• Organiza Connectathons: eventos donde fabricantes prueban interoperabilidad de sus productos en vivo.

6.2. Arquitectura IHE: Perfiles, Actores y Transacciones

1. Perfiles de Integración (Integration Profiles)

Un perfil IHE define una solución completa a un problema de interoperabilidad clínica específico. Especifica:

• Qué actores intervienen.
• Qué transacciones se ejecutan entre ellos.
• Qué estándares se usan (HL7, DICOM, HTTP…).
• Qué opciones son obligatorias u opcionales.

2. Actores (Actors)

Un actor es un rol funcional que un sistema puede asumir en una integración. Un mismo sistema puede implementar múltiples actores.

Ejemplo de Actores:

• Image Manager/Archive: Sistema que almacena y gestiona imágenes (típicamente un PACS).
• Image Display: Sistema que visualiza imágenes (visor DICOM).
• Order Placer: Sistema que genera peticiones de estudios (Diraya).
• Order Filler: Sistema que recibe y gestiona peticiones (RIS).
• Document Source: Sistema que genera documentos clínicos (Diraya).
• Document Consumer: Sistema que consulta documentos (portal médico de atención primaria).

3. Transacciones (Transactions)

Una transacción es un intercambio específico de información entre dos actores usando un estándar concreto.

Ejemplo de Transacciones:

• RAD-8: Patient Identity Feed → Sincronizar datos demográficos de pacientes (usa HL7 ADT).
• RAD-16: Radiology Order → Enviar orden de radiología (usa HL7 ORM).
• RAD-55: WADO Retrieve → Recuperar imagen vía HTTP (usa DICOM WADO).
• ITI-18: Registry Stored Query → Buscar documentos en repositorio (usa HL7 v3 / ebXML).

6.3. Dominios IHE

IHE está organizado en dominios clínicos, cada uno con sus propios perfiles:

6.4. Perfiles IHE más Relevantes para el SAS

Dominio ITI (IT Infrastructure) – Infraestructura Transversal

1. XDS (Cross-Enterprise Document Sharing)

• Perfil para compartir documentos clínicos entre organizaciones sanitarias.
• Arquitectura:
  • Document Source: Sistema que publica documentos (Diraya).
  • Document Repository: Almacén de documentos.
  • Document Registry: Índice de metadatos de documentos (búsqueda).
  • Document Consumer: Sistema que consulta documentos (portal médico).
• Usa: HL7 v3 CDA para documentos, ebXML para transacciones.
• Uso en España: La HC-SNS usa XDS para compartir documentos entre CCAA.

2. XCA (Cross-Community Access)

• Extensión de XDS para compartir documentos entre comunidades (ej: Andalucía ↔ Madrid).
• Permite búsquedas y recuperación federada.
• Base de la interoperabilidad autonómica en España.

3. PIX (Patient Identifier Cross-Referencing)

• Sincronizar identificadores de pacientes entre sistemas.
• Problema: Un paciente tiene NUHSA en Diraya, pero otro ID en el laboratorio.
• PIX mantiene un mapa de correspondencias (cross-reference) para resolver identidades.

4. PDQ (Patient Demographics Query)

• Buscar pacientes por datos demográficos (nombre, fecha nacimiento…).
• Útil cuando NO se conoce el ID del paciente.

5. ATNA (Audit Trail and Node Authentication)

• Seguridad: auditoría de accesos y autenticación de nodos.
• Registra quién accedió a qué datos, cuándo, desde dónde.
• Obligatorio para cumplir RGPD (trazabilidad de accesos a datos de salud).

Dominio RAD (Radiology) – Radiología

1. SWF (Scheduled Workflow)

• Flujo completo de trabajo de radiología: orden → worklist → adquisición → almacenamiento → informe.
• Actores: Order Placer (Diraya), Order Filler (RIS), Image Manager (PACS), Acquisition Modality (TAC, RM…).
• Transacciones: HL7 para órdenes, DICOM Worklist, DICOM C-STORE para imágenes.
• El perfil más implementado en hospitales del mundo. El SAS lo usa masivamente.

2. PIR (Portable Data for Imaging)

• Exportar imágenes DICOM + informe a CD/DVD/USB para el paciente.
• Incluye visor DICOM autoejecutables (el paciente puede ver sus imágenes en cualquier PC).

3. SINR (Standardized Operational Data of Radiology)

• Informes operativos de radiología (estadísticas, tiempos de espera, volumen de estudios…).
• Para gestión y análisis de rendimiento del servicio de radiología.

Dominio PCC (Patient Care Coordination)

1. XPHR (Exchange of Personal Health Record Content)

• Compartir contenido de historia clínica personal con el paciente.
• Base de apps como ClicSalud+ donde pacientes acceden a su información clínica.

6.5. Ejemplo Práctico: Perfil IHE SWF (Scheduled Workflow) en el SAS

Escenario: Un médico en Diraya solicita una radiografía de tórax. Veamos cómo funciona con IHE SWF:

Actores involucrados:

• Order Placer (OP): Diraya
• Order Filler (OF): RIS de radiología
• Image Manager/Archive (IM): PACS
• Acquisition Modality (AM): Equipo de radiografía digital
• Image Display (ID): Visor DICOM del radiólogo

Flujo de transacciones IHE SWF:

Ventajas de usar IHE SWF:

• Proceso completamente automático (sin intervención manual para copiar datos).
• Todos los sistemas hablan el mismo idioma (especificado por IHE).
• Trazabilidad completa (cada paso queda registrado).
• Interoperabilidad garantizada (cualquier sistema que cumpla IHE SWF se integra).

6.6. IHE Connectathon: Probando la Interoperabilidad

¿Qué es un Connectathon?

• Evento anual organizado por IHE donde fabricantes prueban sus productos en vivo.
• Duración: típicamente 1 semana.
• Lugar: IHE Europa Connectathon (varios países europeos, rotativo).
• Participantes: GE Healthcare, Siemens, Philips, Everis, Indra, Atos, Sectra, Agfa…

Dinámica del Connectathon:

1. Cada fabricante trae sus sistemas (PACS, RIS, HIS, visores, modalidades…).
2. Se configuran escenarios de integración basados en perfiles IHE.
3. Los sistemas de diferentes fabricantes se conectan entre sí.
4. Se ejecutan casos de prueba predefinidos (ej: enviar orden, almacenar imagen, compartir documento…).
5. Monitores IHE verifican que las transacciones cumplen especificaciones.
6. Se detectan errores, se corrigen en vivo, se re-testea.

Beneficios del Connectathon:

• Certificación informal: Los sistemas que pasan Connectathon demuestran interoperabilidad real.
• Detección temprana de problemas: Mejor encontrar incompatibilidades en Connectathon que en producción en un hospital.
• Networking: Fabricantes y compradores (hospitales, CCAA) se conocen, comparten experiencias.
• Aceleración de la interoperabilidad: Productos probados en Connectathon se integran más fácilmente en hospitales.

El SAS y los Connectathons:

• El SAS (a través de equipos TIC) ha participado como observador en Connectathons europeos.
• En pliegos de contratación TIC, el SAS puede exigir conformidad IHE y participación en Connectathon como requisito técnico.
• Ejemplo: «El PACS ofertado debe cumplir perfiles IHE SWF, XDS-I y haber participado exitosamente en IHE Connectathon 2024».

6.7. IHE y la Estrategia de Interoperabilidad del SAS

Adopción de IHE en el SAS:

• El SAS recomienda (y en algunos casos exige) cumplimiento de perfiles IHE en contratos TIC.
• Perfiles priorizados:
  • IHE SWF (Scheduled Workflow): Obligatorio en integración RIS-PACS-Diraya.
  • IHE XDS/XCA: Para compartir documentos con HC-SNS y otras CCAA.
  • IHE PIX/PDQ: Gestión de identidades de pacientes entre sistemas.
  • IHE ATNA: Auditoría de accesos (cumplimiento RGPD).

Beneficios para el SAS:

• Reducción vendor lock-in: Si todos los sistemas cumplen IHE, cambiar de proveedor es más fácil.
• Integración más rápida: Nuevos sistemas que cumplan IHE se integran «out of the box».
• Menor coste de interfaces: No hay que desarrollar interfaces propietarias específicas.
• Calidad garantizada: Productos probados en Connectathon tienen menos errores de integración.

Desafíos:

• Conformidad parcial: Algunos fabricantes dicen «cumplimos IHE» pero solo implementan parte del perfil.
• Versiones: IHE actualiza perfiles regularmente. Hay que vigilar versiones compatibles.
• Opcionales: Los perfiles IHE tienen opciones. Dos sistemas «conformes IHE» pueden no ser 100% interoperables si implementan opciones diferentes.
• Testing: El SAS debe hacer pruebas de integración exhaustivas antes de poner en producción, incluso con sistemas «certificados IHE».

7. Otros Estándares Sanitarios Complementarios

7.1. SNOMED CT (Systematized Nomenclature of Medicine – Clinical Terms)

¿Qué es SNOMED CT?

• La terminología clínica más completa y multilingüe del mundo.
• Contiene más de 350.000 conceptos clínicos activos (síntomas, diagnósticos, procedimientos, fármacos, anatomía…).
• Desarrollada y mantenida por SNOMED International (organización sin ánimo de lucro, 40+ países miembros).
• España es miembro desde 2015, representada por el Ministerio de Sanidad.

Estructura de SNOMED CT

• Conceptos: Cada concepto tiene un ID numérico único (ej: 73211009 = Diabetes mellitus).
• Descripciones: Nombres del concepto (sinónimos, traducciones).
• Relaciones: Jerarquías (diabetes es un tipo de enfermedad endocrina) y relaciones semánticas.

Uso en el SAS

• Codificación de diagnósticos, problemas activos, antecedentes en Diraya.
• Búsqueda inteligente: escribir «infarto» encuentra «infarto agudo de miocardio», «IAM», «STEMI»…
• Interoperabilidad: sistemas que usan SNOMED CT se entienden semánticamente.
• Analítica de datos: agregación y análisis de información clínica codificada.

7.2. CIE-10 (Clasificación Internacional de Enfermedades, 10ª revisión)

¿Qué es CIE-10?

• Clasificación de enfermedades publicada por la OMS (Organización Mundial de la Salud).
• Códigos alfanuméricos para diagnósticos (ej: E11.9 = Diabetes mellitus tipo 2 sin complicaciones).
• Uso principal: estadísticas sanitarias, codificación de mortalidad y morbilidad.
• Versión actual: CIE-11 (publicada 2018, adoptándose gradualmente).

Diferencia CIE-10 vs SNOMED CT

• CIE-10: Clasificación estadística (agrupación), menos granular, obligatoria para codificación de altas hospitalarias (CMBD).
• SNOMED CT: Terminología clínica (detalle), muy granular, para documentación clínica en historia.
• Son complementarias: Diraya puede usar SNOMED CT en la historia clínica y mapear automáticamente a CIE-10 para informes estadísticos.

7.3. LOINC (Logical Observation Identifiers Names and Codes)

¿Qué es LOINC?

• Sistema universal de códigos para pruebas de laboratorio y observaciones clínicas.
• Desarrollado por el Regenstrief Institute (EEUU).
• Más de 95.000 códigos para: analíticas, constantes vitales, escalas clínicas, cuestionarios…

Uso en el SAS

• Codificación de resultados de laboratorio enviados en mensajes HL7 ORU.
• Ejemplo: Glucosa en suero = LOINC 2339-0.
• Permite comparabilidad entre laboratorios (mismo código LOINC, mismo concepto).

7.4. Otros Estándares Relevantes

• ATC (Anatomical Therapeutic Chemical): Clasificación de medicamentos de la OMS.
• openEHR: Especificaciones para arquitecturas de historias clínicas electrónicas.
• CMBD (Conjunto Mínimo Básico de Datos): Datos obligatorios en informes de alta hospitalaria en España (usa CIE-10).

8. Aplicación Práctica: Arquitectura de Interoperabilidad del SAS

Visión Integral

Todos los estándares vistos se combinan en la arquitectura TIC del SAS:

                        DIRAYA (HIS Central)
                               |
            ┌──────────────────┼──────────────────┐
            |                  |                  |
       HL7 v2.x          HL7 v2.x          HL7 CDA (XDS)
            |                  |                  |
    ┌───────▼───────┐  ┌───────▼───────┐  ┌──────▼──────┐
    │   RIS-PACS    │  │  Laboratorio  │  │   HC-SNS    │
    │  (Radiología) │  │      (LIS)    │  │  (Otras     │
    └───────┬───────┘  └───────┬───────┘  │   CCAA)     │
            │                  │          └─────────────┘
     DICOM 3.0          HL7 v2.x
            │                  │
    ┌───────▼───────┐  ┌───────▼───────┐
    │  Modalidades  │  │  Analizadores │
    │  (TAC, RM...) │  │  Laboratorio  │
    └───────────────┘  └───────────────┘

Terminologías: SNOMED CT, CIE-10, LOINC (en mensajes HL7 y CDA)
Seguridad: IHE ATNA (auditoría accesos), ENS, RGPD

Tu rol como TFA-STI en este ecosistema:

• Mantener y optimizar el motor de integración HL7 (Mirth Connect).
• Resolver incidencias de comunicación DICOM entre modalidades y PACS.
• Validar conformidad de nuevos sistemas con estándares (HL7, DICOM, IHE).
• Participar en proyectos de migración a FHIR.
• Colaborar en implementación de terminologías (SNOMED CT, LOINC).
• Generar informes de interoperabilidad y rendimiento de interfaces.

9. Cuestionario de Autoevaluación – 25 Preguntas Tipo Test

10. Mapa Conceptual y Referencias

                    NORMALIZACIÓN TIC SANITARIA
                              |
        ┌─────────────────────┼─────────────────────┐
        |                     |                     |
  ORGANIZACIONES       ESTÁNDARES GENERALES   ESTÁNDARES SANITARIOS
        |                     |                     |
  ┌─────┴─────┐         ┌────┴────┐          ┌─────┴─────┐
  |           |         |         |          |           |
Internacional Nacional  Internet Web     Imágenes  Mensajería  Terminología
  |           |         |         |          |           |           |
ISO,IEC,ITU AENOR,UNE  IETF,W3C IEEE     DICOM      HL7      SNOMED CT
IEEE,W3C               TCP/IP   802.11      |           |      CIE-10
                       HTTP     Ethernet    |      ┌────┴────┐  LOINC
                       JSON     Wi-Fi       |      |         |
                                           PACS   v2.x    FHIR
                                            |      |         |
                                          RIS-PACS  |     APIs REST
                                          SWF(IHE) ORM/ORU  JSON
                                                    |
                                              Mirth Connect
                                              (Motor HL7 SAS)
    

11. Referencias Normativas y Bibliográficas