1. INTRODUCCIÓN Y DELIMITACIÓN DEL TEMA

El intercambio electrónico de datos no consiste simplemente en enviar información por una red. Su rasgo definitorio es que dos o más sistemas, pertenecientes normalmente a organizaciones distintas, intercambian datos con una estructura, semántica y reglas de tratamiento previamente acordadas, de modo que el receptor puede incorporarlos a sus procesos sin volver a teclearlos. Esta precisión permite diferenciar el EDI de un correo con un PDF adjunto, de una copia de un fichero en una carpeta compartida o de una consulta manual a una página web. En esos tres casos existe transmisión electrónica, pero no necesariamente integración automática ni un contrato de datos común.

El epígrafe oficial reúne dos tradiciones que hoy convergen. La primera es el EDI empresarial, nacido para automatizar pedidos, avisos de expedición, recepciones y facturas mediante mensajes normalizados como UN/EDIFACT. La segunda es la interoperabilidad administrativa, cuyo objetivo es que los órganos públicos intercambien datos, documentos, asientos registrales y evidencias con garantías jurídicas, técnicas y de seguridad. XML, los servicios web, las API, la mensajería segura, las plataformas de intermediación y los modelos semánticos actúan como piezas comunes entre ambas tradiciones.

En la Administración, el intercambio de datos tiene además una consecuencia jurídica directa: hace efectivo el derecho de las personas interesadas a no aportar documentos que ya obren en poder de una Administración o hayan sido elaborados por otra. La supresión de certificados en soporte papel no significa eliminar la información acreditativa, sino sustituir el documento que transportaba el ciudadano por una transmisión electrónica trazable entre el órgano cedente y el órgano cesionario. El dato sigue necesitando una fuente competente, una finalidad legítima, control de acceso, registro de auditoría y posibilidad de acreditar qué se consultó, para quién, cuándo y dentro de qué procedimiento.

Para preparar el tema conviene separar cuatro niveles. El nivel sintáctico determina cómo se representa el mensaje: EDIFACT, XML, JSON o una sintaxis binaria. El nivel semántico fija qué significa cada elemento, qué catálogos y códigos se utilizan y qué reglas de negocio deben cumplirse. El nivel técnico establece transporte, interfaces, seguridad, confirmaciones y tratamiento de errores. El nivel organizativo y jurídico identifica responsables, finalidades, acuerdos, procedimientos, base legitimadora, conservación y auditoría.

El tema se desarrolla desde los fundamentos del EDI hasta los proyectos actuales. Se estudian UN/EDIFACT, ANSI X12, GS1 EANCOM, XML, XSD, XPath y XSLT; los protocolos AS2 y AS4; el principio de «solo una vez»; SCSP y las plataformas de intermediación; @ries, SIR y SICRES 4; el uso de EDI en SIGLO; Diraya, Receta XXI, HCDSNS y RESNS; y las iniciativas europeas de identidad, eDelivery, facturación, intercambio transfronterizo de evidencias y datos de salud.

2. CONCEPTO, EVOLUCIÓN Y VALOR DEL EDI

El Intercambio Electrónico de Datos, conocido universalmente por sus siglas en inglés EDI (Electronic Data Interchange), constituye un conjunto de metodologías, tecnologías y estándares que permiten la transmisión de información estructurada entre sistemas informáticos de diferentes organizaciones de manera automática, sin intervención manual. A diferencia del simple envío de documentos digitales como archivos adjuntos de correo electrónico, el EDI implica la transferencia de datos en formatos estandarizados y estructurados que pueden ser procesados directamente por los sistemas de información receptores sin necesidad de reintroducción manual de datos.

El concepto fundamental del EDI radica en la sustitución de documentos en papel o procesos manuales por flujos de información digitales estructurados. Cuando pensamos en cómo tradicionalmente las organizaciones intercambiaban información, imaginemos una empresa que necesita enviar una orden de compra a un proveedor. En el modelo tradicional, este proceso implicaba generar un documento en papel, enviarlo por correo postal o fax, y luego el proveedor debía introducir manualmente toda esa información en su sistema informático. Este proceso era lento, propenso a errores de transcripción, y generaba costes significativos tanto en tiempo como en recursos.

Con el EDI, este mismo proceso se transforma radicalmente. El sistema informático de la empresa compradora genera automáticamente un mensaje EDI que contiene todos los datos de la orden de compra en un formato estructurado y estandarizado. Este mensaje se transmite electrónicamente al sistema del proveedor, donde es recibido, validado y procesado automáticamente, actualizando inmediatamente sus sistemas de gestión de pedidos, inventario y producción sin intervención humana. Esta automatización extremo a extremo reduce drásticamente los tiempos de proceso, elimina errores de transcripción, disminuye costes operativos, y permite respuestas más rápidas a las necesidades del negocio.

2.1. Evolución Histórica del EDI

La historia del EDI se remonta a finales de la década de 1960, cuando la industria del transporte en Estados Unidos comenzó a buscar formas de agilizar el intercambio de información entre transportistas, cargadores y destinatarios. Las primeras implementaciones eran propietarias, con cada par de empresas desarrollando sus propios formatos y protocolos de comunicación, lo que resultaba en soluciones incompatibles y costosas de mantener.

Durante los años setenta y ochenta, diferentes industrias comenzaron a desarrollar sus propios estándares sectoriales de EDI. La industria del transporte creó el estándar TDCC (Transportation Data Coordinating Committee), el sector minorista desarrolló UCS (Uniform Communications Standard), y la industria química estableció CIDX (Chemical Industry Data Exchange). Sin embargo, esta proliferación de estándares verticales presentaba problemas cuando las empresas necesitaban intercambiar datos entre diferentes sectores industriales.

El punto de inflexión llegó en 1987 con la publicación del estándar ANSI X12 en Estados Unidos, seguido por el desarrollo de EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) por parte de las Naciones Unidas en 1988. EDIFACT se convirtió en el estándar internacional dominante, proporcionando un marco común que podía utilizarse globalmente y entre diferentes industrias. Este período marcó la maduración del EDI como tecnología empresarial crítica.

2.2. Beneficios y Limitaciones del EDI Tradicional

Los beneficios del EDI tradicional son sustanciales y han sido ampliamente documentados a lo largo de décadas de implementaciones exitosas. La reducción de costes operativos es quizás el beneficio más inmediato y tangible, ya que elimina los gastos de impresión, envío postal, almacenamiento físico de documentos y re-introducción manual de datos. Las organizaciones que implementan EDI típicamente reportan ahorros del cincuenta al setenta por ciento en los costes de procesamiento de documentos comerciales.

La mejora en la precisión de los datos es otro beneficio crítico. Los estudios han demostrado que la introducción manual de datos tiene tasas de error que oscilan entre el uno y el cinco por ciento, dependiendo de la complejidad de la información. El EDI prácticamente elimina estos errores de transcripción, mejorando significativamente la calidad de los datos en los sistemas empresariales. Esta mayor precisión se traduce en menos disputas comerciales, menos devoluciones de productos, y relaciones más sólidas con socios comerciales.

Sin embargo, el EDI tradicional también presenta limitaciones significativas que han motivado la búsqueda de alternativas modernas. La complejidad técnica es considerable, requiriendo software especializado, conocimiento experto de los estándares EDI, y infraestructura de comunicaciones dedicada como redes de valor añadido o VPNs. Esta complejidad se traduce en altos costes iniciales de implementación que pueden ser prohibitivos para pequeñas y medianas empresas.

3. ARQUITECTURA, CICLO DE VIDA Y MODELOS DE INTEGRACIÓN

3.1. Arquitectura Técnica del EDI

Para comprender cómo funciona el EDI a nivel técnico, es útil visualizar su arquitectura en capas. En la base encontramos la capa de aplicación, que consiste en los sistemas empresariales que generan y consumen los datos, como sistemas ERP, aplicaciones de gestión de la cadena de suministro, o plataformas de comercio electrónico. Estos sistemas contienen la información que necesita ser intercambiada, por ejemplo, órdenes de compra, facturas, avisos de envío o catálogos de productos.

Por encima de esta capa de aplicación se sitúa el software de traducción EDI, que es el componente crítico que convierte los datos internos de la organización al formato EDI estandarizado y viceversa. Este software mapea los campos de las bases de datos internas a los segmentos y elementos de datos correspondientes en el estándar EDI elegido. Por ejemplo, cuando un sistema ERP genera una orden de compra, el traductor EDI extrae información como el número de orden, fecha, identificación del proveedor, líneas de producto con cantidades y precios, y condiciones de entrega, y los estructura según el formato del mensaje ORDERS de EDIFACT o el documento 850 de ANSI X12.

La capa de comunicaciones gestiona la transmisión física de los mensajes EDI entre organizaciones. Históricamente, esto se realizaba a través de Redes de Valor Añadido o VANs (Value Added Networks), que son redes privadas operadas por terceros que proporcionan servicios de enrutamiento, almacenamiento temporal, conversión de protocolos y auditoría. Las VANs funcionan como oficinas de correos electrónicas, recibiendo mensajes de los remitentes, almacenándolos en buzones electrónicos, y entregándolos a los destinatarios cuando se conectan a la red.

3.2. Protocolos de Comunicación en EDI

La transmisión de mensajes EDI puede realizarse mediante diversos protocolos de comunicación, cada uno con características específicas que los hacen más adecuados para diferentes escenarios. El protocolo AS2 (Applicability Statement 2) se ha convertido en el estándar de facto para transmisión EDI sobre Internet en los últimos quince años. AS2 utiliza HTTP o HTTPS como protocolo de transporte, incorporando cifrado mediante SSL o TLS, firma digital de mensajes para autenticación y no repudio, compresión de datos para reducir ancho de banda, y MDN (Message Disposition Notification) para confirmaciones de recepción.

El funcionamiento de AS2 es relativamente directo pero robusto. El remitente comprime el documento EDI, lo firma digitalmente usando su clave privada, cifra el documento firmado usando la clave pública del destinatario, y envía el paquete resultante mediante una petición HTTP POST. El receptor recibe el mensaje, lo descifra usando su clave privada, verifica la firma digital del remitente usando su clave pública, descomprime el documento, y envía un MDN firmado al remitente confirmando la recepción y validación correcta. Este proceso garantiza confidencialidad, integridad, autenticación y no repudio de las transacciones EDI.

Otros protocolos importantes incluyen FTP y SFTP para transferencia de archivos batch, especialmente útiles cuando se procesan grandes volúmenes de transacciones en lotes programados. El protocolo OFTP2 (Odette File Transfer Protocol) es ampliamente utilizado en la industria automotriz europea para intercambio de datos entre fabricantes de automóviles y su red de proveedores. X.400 es un estándar de mensajería de la ITU-T que fue popular en los años noventa pero ha sido ampliamente reemplazado por soluciones basadas en Internet.

3.3. Redes de Valor Añadido (VANs)

Las Redes de Valor Añadido merecen una explicación más profunda debido a su papel histórico en la evolución del EDI. Una VAN funciona como intermediario entre socios comerciales, proporcionando varios servicios que simplifican la implementación y gestión del EDI. El servicio más básico es el enrutamiento y entrega de mensajes, donde la VAN recibe mensajes de un remitente, los almacena en un buzón, y los entrega cuando el destinatario se conecta, similar a cómo funciona el correo electrónico pero con garantías adicionales de entrega.

Las VANs también proporcionan conversión de protocolos, permitiendo que un remitente envíe usando un protocolo específico mientras el destinatario recibe usando un protocolo diferente, todo transparente para ambas partes. La conversión de formatos permite incluso traducir entre diferentes estándares EDI, por ejemplo, recibiendo un mensaje en formato ANSI X12 y entregándolo convertido a EDIFACT. Los servicios de auditoría mantienen registros detallados de todas las transacciones para cumplimiento regulatorio y resolución de disputas.

Sin embargo, las VANs tradicionales presentan inconvenientes significativos. El coste es sustancial, típicamente basado en el volumen de datos intercambiados o el número de transacciones, lo que puede resultar prohibitivo para pequeñas empresas. La dependencia de un único proveedor de VAN crea un punto único de fallo y puede generar preocupaciones sobre vendor lock-in. Por estas razones, muchas organizaciones están migrando desde VANs tradicionales hacia soluciones basadas en Internet utilizando protocolos como AS2, que proporcionan capacidades similares a costes significativamente menores.

3.4. Del intercambio por lotes a la integración casi en tiempo real

El EDI clásico suele operar por lotes: una aplicación genera mensajes, un traductor los deposita en una cola y el canal los entrega al socio. El procesamiento puede ser inmediato, pero el diseño no presupone una conversación interactiva. En arquitecturas modernas aparecen API síncronas, eventos y flujos de mensajería. Una API REST puede devolver una respuesta en la misma conexión; un broker puede distribuir un evento a varios consumidores; una cola garantiza desacoplamiento y reintentos. Ningún patrón es universalmente mejor: la elección depende de latencia, volumen, criticidad, necesidad de confirmación, consistencia y capacidad de recuperación.

Un intercambio robusto distingue la entrega técnica de la aceptación funcional. Que el receptor confirme que recibió bytes no significa que acepte la factura o el pedido. Puede haber una confirmación de transporte, otra de validación sintáctica y una respuesta de negocio. Esta separación evita que se confundan errores de red, errores de formato y rechazos por reglas del procedimiento.

4. NORMAS EDI: UN/EDIFACT, ANSI X12, GS1 Y MENSAJES DE NEGOCIO

4.1. EDIFACT – El Estándar Internacional

EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport), desarrollado bajo los auspicios de las Naciones Unidas, representa el estándar EDI internacional más ampliamente adoptado fuera de Norteamérica. Para comprender EDIFACT, es útil examinar su estructura jerárquica de mensajes, que se organiza en varios niveles de granularidad que van desde elementos individuales de datos hasta documentos completos.

En el nivel más básico encontramos los elementos de datos, que son los bloques constructores fundamentales. Un elemento de dato representa una única pieza de información, como un número de orden, una fecha, o un código de producto. Cada elemento de dato tiene un identificador numérico único dentro del estándar EDIFACT. Por ejemplo, el elemento 1004 representa el número de referencia de documento, mientras que el elemento 2005 representa la fecha de emisión. Los elementos de datos pueden ser numéricos, alfabéticos, alfanuméricos o de formato especial como fechas y horas.

Los segmentos son conjuntos de elementos de datos relacionados que representan una unidad lógica de información. Por ejemplo, el segmento NAD (Name and Address) contiene elementos de datos para el nombre de una entidad, su dirección postal, ciudad, código postal y país. Los segmentos siempre comienzan con un identificador de tres letras seguido de los elementos de datos separados por un carácter delimitador, típicamente el símbolo más. Un ejemplo de segmento NAD completo podría verse así: NAD+BY+5412345000013::9++Empresa ABC+Calle Principal 123+Madrid++28001+ES, donde BY indica que es la parte compradora, seguido del código de identificación de la empresa y los detalles de su dirección.

Los mensajes EDIFACT completos se construyen combinando múltiples segmentos en un orden específico definido por el estándar para cada tipo de documento de negocio. Por ejemplo, el mensaje ORDERS para órdenes de compra tiene una estructura que comienza con segmentos de cabecera como UNH (Message Header) y BGM (Beginning of Message), seguidos por segmentos que identifican a las partes involucradas con NAD, fechas relevantes con DTM, condiciones de entrega con TOD, y luego los detalles de línea de producto usando segmentos LIN y QTY, culminando con segmentos de resumen y el segmento UNT (Message Trailer) que cierra el mensaje.

4.2. ANSI X12 – El Estándar Norteamericano

ANSI X12 es el estándar EDI dominante en Estados Unidos, Canadá y México, desarrollado por el Accredited Standards Committee X12 bajo la American National Standards Institute. Aunque ANSI X12 y EDIFACT cumplen propósitos similares y comparten filosofías de diseño, utilizan sintaxis y terminología diferentes. Comprender las diferencias es importante para organizaciones que operan globalmente y necesitan soportar ambos estándares.

La estructura de ANSI X12 es conceptualmente similar a EDIFACT pero utiliza diferentes identificadores y convenciones de nomenclatura. Los documentos de negocio en ANSI X12 se denominan conjuntos de transacciones (transaction sets) en lugar de mensajes, y se identifican mediante códigos numéricos de tres dígitos. Por ejemplo, el conjunto de transacciones 850 es equivalente al mensaje ORDERS de EDIFACT para órdenes de compra, el 810 corresponde a facturas como INVOIC, y el 856 es el aviso de envío equivalente a DESADV.

Los segmentos en ANSI X12 utilizan identificadores de dos o tres caracteres, y la sintaxis emplea el asterisco como delimitador de elementos de datos en lugar del símbolo más de EDIFACT, y la tilde como terminador de segmento. Un ejemplo de segmento de dirección en ANSI X12 podría verse así: N1*ST*EMPRESA ABC*92*123456~N3*CALLE PRINCIPAL 123~N4*MADRID**28001*ES~, donde cada segmento termina con tilde y los elementos dentro de cada segmento se separan con asteriscos.

4.3. Estándares Sectoriales Específicos

Además de los estándares horizontales como EDIFACT y ANSI X12 que pueden aplicarse a cualquier industria, existen numerosos estándares verticales desarrollados para sectores específicos que tienen requisitos particulares de intercambio de datos. Estos estándares sectoriales son especialmente importantes en industrias altamente reguladas o con procesos de negocio muy especializados.

En el sector sanitario, HL7 (Health Level Seven) es el estándar internacional para intercambio de información clínica y administrativa entre sistemas de información hospitalarios. HL7 define mensajes para admisiones de pacientes, resultados de laboratorio, informes de diagnóstico por imagen, prescripciones médicas y facturación. La versión HL7 FHIR (Fast Healthcare Interoperability Resources), que representa la evolución moderna del estándar aprovechando tecnologías web como REST y JSON, está ganando adopción rápida por su mayor simplicidad comparada con las versiones anteriores basadas en sintaxis propietaria.

La industria del transporte aéreo utiliza ampliamente IATA Cargo-IMP (Interchange Message Procedures) para comunicaciones relacionadas con el transporte de carga aérea, y IATA Passenger Services Messages para reservas, emisión de billetes y operaciones aeroportuarias. El sector financiero emplea SWIFT para transferencias interbancarias internacionales, con sus mensajes altamente estructurados y validados que garantizan la precisión de las transacciones financieras globales.

4.4. EDIFACT en el Servicio Andaluz de Salud

El SAS dispone de guías históricas de integración EDI para su cadena logística. La Guía EDI de la Factura documenta la recepción de facturas de proveedores conforme al mensaje EDIFACT INVOIC D.93A UN EAN007. La guía de pedido utiliza ORDERS D.96A UN EAN008. En ambos casos la especificación general se especializa mediante una guía de implementación: se seleccionan segmentos, calificadores, cardinalidades y reglas de negocio aplicables al proceso del SAS.

Este ejemplo es especialmente didáctico. EDIFACT define una sintaxis y directorios generales, pero la interoperabilidad real requiere acordar un subconjunto implementable. Un elemento condicional en el estándar puede ser obligatorio en el contexto SAS; un código admitido globalmente puede restringirse a unos valores; y una relación de negocio puede imponer que una factura se vincule a una confirmación de recepción. Por eso no basta con afirmar que dos sistemas «usan EDIFACT»: deben coincidir en mensaje, directorio, asociación, guía y reglas.

UNH+1+INVOIC:D:93A:UN:EAN007'
BGM+380+F2026-000123+9'
DTM+137:20260804:102'
NAD+BY+8435226700007::9'
NAD+SU+8437000000000::9'
RFF+ON:PEDIDO-45678'
MOA+39:1210.00'
UNT+8+1'

El ejemplo es únicamente pedagógico: muestra una cabecera INVOIC, fecha, comprador, proveedor, referencia de pedido e importe. Una implementación productiva debe seguir la guía completa, calcular el número real de segmentos, aplicar los calificadores admitidos, firmar o proteger el intercambio según el canal y validar las reglas tributarias y contables vigentes.

5. XML Y SU ECOSISTEMA DE TECNOLOGÍAS

5.1. XML como Alternativa al EDI Tradicional

XML (eXtensible Markup Language) representa un cambio paradigmático en el intercambio electrónico de datos, ofreciendo una alternativa más flexible y accesible al EDI tradicional. Para comprender por qué XML ha ganado tanta tracción, es importante explorar sus características fundamentales y ventajas sobre los formatos EDI clásicos.

XML es un lenguaje de marcado que permite definir estructuras de datos jerárquicas utilizando etiquetas descriptivas encerradas entre corchetes angulares. A diferencia de los mensajes EDI que utilizan notaciones crípticas y posiciones fijas, XML permite que los datos sean autoexplicativos. Por ejemplo, mientras que en EDIFACT podríamos encontrar algo como «BGM+220+ORD12345+9», que requiere consultar la especificación del estándar para entender que significa tipo de documento 220 (orden de compra), número ORD12345, función 9 (original), en XML el mismo contenido se expresaría como:

<OrdenCompra>
    <TipoDocumento>Original</TipoDocumento>
    <NumeroOrden>ORD12345</NumeroOrden>
    <Fecha>2025-01-15</Fecha>
</OrdenCompra>

Esta legibilidad humana de XML facilita enormemente el desarrollo, depuración y mantenimiento de integraciones. Los desarrolladores pueden comprender la estructura y contenido de un documento XML sin necesidad de consultar constantemente especificaciones complejas. Además, las herramientas modernas de desarrollo incluyen soporte nativo para XML, con editores que proporcionan validación sintáctica en tiempo real, formateo automático y asistencia en la edición mediante autocompletado basado en esquemas.

La extensibilidad es otra ventaja fundamental de XML. Mientras que los estándares EDI tradicionales requieren procesos formales de cambio que pueden llevar años, con XML es relativamente sencillo añadir nuevos elementos de datos a un documento sin romper la compatibilidad con sistemas existentes que simplemente ignorarán las etiquetas que no reconocen. Esta flexibilidad es particularmente valiosa en entornos que evolucionan rápidamente o cuando se integran aplicaciones que tienen requisitos únicos no contemplados en estándares predefinidos.

5.2. ebXML – Electronic Business XML

ebXML (Electronic Business using eXtensible Markup Language) representa un esfuerzo ambicioso de crear un marco global para comercio electrónico basado en XML, desarrollado conjuntamente por UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) y OASIS (Organization for the Advancement of Structured Information Standards). El objetivo de ebXML era proporcionar una infraestructura abierta que permitiese a empresas de cualquier tamaño y ubicación geográfica conducir negocios electrónicamente.

La arquitectura de ebXML es modular y comprende varios componentes que trabajan juntos. El registro ebXML funciona como un directorio donde las organizaciones publican sus capacidades de negocio, los procesos que soportan, y los documentos que pueden intercambiar. Pensemos en el registro como páginas amarillas electrónicas donde las empresas pueden descubrir potenciales socios comerciales y sus capacidades. Los perfiles de colaboración o CPPs (Collaboration Protocol Profiles) describen las capacidades técnicas y de negocio de una organización, especificando qué protocolos de comunicación soporta, qué niveles de seguridad implementa, y qué tipos de documentos puede procesar.

Cuando dos organizaciones deciden establecer una relación comercial usando ebXML, negocian un Acuerdo de Protocolo de Colaboración o CPA (Collaboration Protocol Agreement) que especifica exactamente cómo intercambiarán información. El CPA se deriva de los CPPs de ambas partes y define aspectos técnicos como el protocolo de transporte que usarán, los requisitos de seguridad incluyendo cifrado y firma digital, los tiempos de respuesta esperados, y los procedimientos de manejo de errores. Una vez establecido el CPA, las aplicaciones de negocio de ambas organizaciones pueden intercambiar documentos XML según los procesos definidos sin intervención manual adicional.

5.3. UBL – Universal Business Language

UBL (Universal Business Language) es una biblioteca de documentos XML para procesos de negocio comunes como compras, transporte y logística. Desarrollado por OASIS y adoptado como estándar ISO 19845, UBL proporciona definiciones de documentos listos para usar que cubren los casos de uso más frecuentes en comercio electrónico y cadenas de suministro. La ventaja de UBL radica en que ofrece un conjunto coherente de esquemas XML bien diseñados que las organizaciones pueden adoptar directamente sin necesidad de crear sus propias definiciones desde cero.

Los documentos UBL más utilizados incluyen Order para órdenes de compra, Invoice para facturas, Despatch Advice para avisos de expedición, y Catalogue para catálogos de productos. Cada documento UBL se define mediante un esquema XML que especifica todos los elementos de datos posibles, sus tipos, cardinalidades (si son obligatorios u opcionales, y cuántas veces pueden aparecer), y las relaciones entre ellos. Por ejemplo, una factura UBL puede contener información sobre el emisor y receptor, fechas relevantes, condiciones de pago, referencias a documentos relacionados como la orden de compra original, líneas de factura con descripciones de productos, cantidades, precios unitarios y totales, impuestos aplicables, y el importe total a pagar.

La adopción de UBL ha sido particularmente significativa en administraciones públicas europeas en el contexto de la facturación electrónica. La Directiva 2014/55/UE de la Unión Europea estableció la obligación de que las entidades del sector público acepten y procesen facturas electrónicas que cumplan con el estándar europeo EN 16931, que a su vez se puede implementar usando UBL o CII (Cross Industry Invoice). Esta estandarización a nivel europeo ha impulsado significativamente la adopción de UBL como formato común para facturación electrónica entre proveedores y administraciones públicas.

5.4. Documento bien formado, documento válido y contrato de datos

Un documento XML es bien formado cuando respeta las reglas sintácticas: un único elemento raíz, etiquetas correctamente anidadas, atributos entrecomillados y caracteres especiales escapados. Es válido cuando, además, cumple una DTD o un esquema XSD determinado. La distinción es esencial: un documento puede ser XML correcto y, sin embargo, no ser aceptable para el proceso porque falte un campo obligatorio, aparezca un código no permitido o una fecha no tenga el tipo exigido.

<Factura xmlns="urn:ejemplo:sas:factura:v1">
  <Numero>F2026-000123</Numero>
  <Fecha>2026-08-04</Fecha>
  <Proveedor/>
  <Importe moneda="EUR">1210.00</Importe>
</Factura>

Los espacios de nombres evitan colisiones entre vocabularios. La URI del espacio de nombres identifica el vocabulario, pero no tiene por qué ser una página descargable. El prefijo es local al documento: dos mensajes pueden usar prefijos distintos y pertenecer al mismo espacio. Esta es una trampa habitual cuando se compara XML por texto en vez de hacerlo por nombres expandidos.

5.5. XSD, XPath, XSLT y validación de reglas

XSD define elementos, atributos, tipos simples y complejos, secuencias, alternativas y cardinalidades. XPath selecciona nodos y calcula expresiones sobre el árbol XML. XSLT transforma un documento XML en otro XML, HTML o texto. Para reglas de negocio que exceden la capacidad de XSD pueden utilizarse validaciones adicionales, por ejemplo Schematron, controles de catálogo o código de aplicación.

Una estrategia madura versiona conjuntamente el esquema, la documentación, los ejemplos, los catálogos y las pruebas. La compatibilidad no debe inferirse por el número de versión. Añadir un elemento opcional suele ser compatible para consumidores tolerantes; cambiar un tipo, reinterpretar un código o hacer obligatorio un elemento puede romper integraciones aunque el XML siga siendo bien formado.

6. SERVICIOS WEB, API, JSON Y MENSAJERÍA ASÍNCRONA

La expansión de Internet convirtió el intercambio de datos en una capacidad transversal de las arquitecturas de aplicaciones. Los servicios web basados en SOAP formalizaron contratos mediante WSDL y utilizaron XML tanto para el sobre como para los datos. SOAP no es simplemente «XML por HTTP»: define un modelo de mensajes, cabeceras, fallos y extensiones. En entornos administrativos ha sido habitual combinarlo con perfiles WS-* para firma, cifrado, direccionamiento y entrega fiable.

Las API REST usan los conceptos de recurso, representación, identificador y operación uniforme de HTTP. Normalmente intercambian JSON, aunque también pueden emplear XML. REST no es un estándar de formato, sino un estilo arquitectónico; una API concreta necesita documentar rutas, métodos, parámetros, códigos de estado, esquemas y reglas. OpenAPI facilita ese contrato, permite generar clientes y habilita pruebas automáticas, pero no sustituye el gobierno del servicio.

JSON reduce verbosidad y encaja bien con JavaScript y las API modernas. Sin embargo, carece de algunas construcciones nativas de XML, como espacios de nombres, y su ecosistema de firma o transformación es distinto. JSON Schema permite describir estructuras y validar tipos, pero de nuevo no convierte por sí solo un mensaje en interoperable. La decisión XML frente a JSON debe basarse en contratos existentes, herramientas, requisitos de firma, volumen, necesidad de transformación y ecosistema receptor.

En integración administrativa conviene separar la API de negocio de los mecanismos transversales. Un gateway puede autenticar, aplicar cuotas, validar tokens, registrar trazas y publicar versiones; un bus o plataforma puede transformar y enrutar; el servicio propietario del dato conserva la decisión sobre qué se puede consultar y con qué finalidad. Concentrar toda la lógica en el middleware crea un «bus inteligente y extremos tontos» difícil de evolucionar.

6.1. Contratos, versionado y compatibilidad

Un contrato debe indicar identificadores, cardinalidades, tipos, catálogos, obligatoriedad, reglas condicionales, errores, límites de tamaño, protección, disponibilidad y política de versiones. En una API, devolver 200 OK con un error dentro del cuerpo dificulta la observabilidad; en mensajería, confirmar antes de persistir el mensaje puede causar pérdidas; en intercambio por fichero, renombrar el archivo antes de completar la escritura puede provocar lecturas parciales. Son fallos de diseño, no del formato elegido.

La compatibilidad hacia atrás exige que un consumidor antiguo pueda seguir procesando mensajes nuevos dentro de los límites acordados. Una técnica es la evolución aditiva: nuevos campos opcionales y valores de catálogo gestionados. Otra es publicar una nueva versión mayor con período de convivencia. La retirada debe incluir inventario de consumidores, métricas de uso, comunicación, entorno de pruebas y fecha de fin de servicio.

7. TRANSPORTE, SEGURIDAD Y EVIDENCIAS DEL INTERCAMBIO

Los mensajes pueden viajar por redes de valor añadido, SFTP, HTTPS, AS2, AS4, colas, VPN o redes corporativas. El canal debe elegirse según criticidad, volumen, relación entre las partes y requisitos de evidencia. TLS protege la conexión en tránsito y autentica normalmente al servidor; con autenticación mutua puede identificar también al cliente. No obstante, la protección termina en cada extremo TLS. Si el mensaje atraviesa intermediarios y debe conservar su integridad extremo a extremo, puede necesitar firma a nivel de mensaje.

AS2, definido para intercambio B2B sobre HTTP, combina firma, cifrado y confirmaciones MDN. Su éxito se explica por permitir EDI seguro sobre Internet sin depender exclusivamente de VAN privadas. AS4 es un perfil de ebMS 3.0 alineado con servicios web y se usa como base del bloque europeo eDelivery. Puede operar con entrega push o pull, recibos, seguridad de mensajes y acuerdos de procesamiento.

La seguridad exige autenticación del sistema, autorización por servicio y finalidad, mínimos privilegios, protección de secretos, trazabilidad, detección de anomalías y gestión de certificados. Un certificado caducado, revocado o emitido para otro nombre invalida la confianza aunque el algoritmo sea fuerte. La rotación debe planificarse y probarse antes de la expiración, especialmente cuando intervienen terceros que mantienen almacenes de confianza propios.

La evidencia debe vincular el mensaje, el emisor, el receptor, el instante, el identificador de transacción y los acuses. En procedimientos administrativos o facturación puede ser necesario conservar además el formato original, firmas, validaciones, sellos y metadatos durante el plazo aplicable. Convertir un XML firmado a PDF para archivarlo puede destruir la capacidad de validar la firma original, aunque mejore la legibilidad humana.

8. INTEROPERABILIDAD SEMÁNTICA, IDENTIFICADORES Y GOBIERNO DEL DATO

La mayor parte de los fallos de interoperabilidad no se debe a que falte conectividad, sino a diferencias de significado. Dos sistemas pueden intercambiar el campo centro y referirse uno al centro sanitario, otro al centro de consumo y otro al órgano gestor. La solución requiere un modelo canónico o contratos explícitos, definiciones, dominios, catálogos, responsables y reglas de calidad.

Los identificadores son fundamentales. En el intercambio administrativo aparecen códigos DIR3 para órganos y oficinas; en logística, GLN, GTIN u otros identificadores GS1; en salud, identificadores de paciente, profesional, centro y episodio. Debe conocerse quién emite el identificador, su ámbito de unicidad, su ciclo de vida y si puede reasignarse. Usar el nombre visible de una unidad como clave técnica produce errores cuando cambia la denominación.

Los catálogos deben publicarse y versionarse. Una lista de provincias, estados de expediente, tipos de documento o motivos de rechazo puede evolucionar. El consumidor necesita saber si debe rechazar un valor desconocido, tratarlo como «otro» o almacenarlo para revisión. El emisor no debe reutilizar un código histórico con un significado nuevo, porque rompería la interpretación de datos conservados.

8.1. Modelo canónico y traducciones

Un modelo canónico reduce el número de transformaciones en integraciones complejas: cada sistema traduce entre su modelo y el canónico, en lugar de mantener mapeos bilaterales con todos los demás. Sin embargo, un modelo canónico demasiado ambicioso se vuelve rígido. Debe centrarse en conceptos compartidos y permitir extensiones controladas. En salud, estándares como HL7 FHIR proporcionan recursos y reglas, pero una implantación interoperable sigue necesitando perfiles, terminologías y guías de implementación.

8.2. Calidad y procedencia

El receptor debe conocer la procedencia del dato: organismo cedente, momento de obtención, versión y condiciones. Un dato correcto ayer puede no serlo hoy. Por eso algunas consultas devuelven la situación actual y otras una certificación relativa a una fecha. La calidad se evalúa mediante completitud, validez, consistencia, unicidad, actualidad y exactitud. La plataforma no debe «corregir» silenciosamente un dato del cedente sin conservar la trazabilidad.

El gobierno asigna propietarios funcionales, custodios técnicos y responsables de seguridad y protección de datos. También establece alta de consumidores, finalidad autorizada, niveles de servicio, gestión de incidencias, cambios de esquema y retirada. Una integración sin propietario termina acumulando cuentas técnicas, certificados olvidados y consumidores que nadie reconoce.

9. SUPRESIÓN DE CERTIFICADOS EN SOPORTE PAPEL: FUNDAMENTO Y MARCO JURÍDICO

La iniciativa de Supresión de Certificados en Soporte Papel, conocida como SCSP, nació para evitar que la ciudadanía actuara como mensajera entre organismos. En el modelo tradicional, una persona solicitaba un certificado a la Administración A y lo presentaba ante la Administración B. El dato ya existía en el sector público, pero el procedimiento trasladaba al interesado el coste de obtención, desplazamiento, custodia y actualización.

Los Reales Decretos 522/2006 y 523/2006 impulsaron la supresión, en la Administración General del Estado, de fotocopias de documentos de identidad y certificados de empadronamiento. Las órdenes de desarrollo regularon los servicios de verificación de identidad y residencia. La Ley 11/2007 generalizó el derecho a no aportar datos ya disponibles y, posteriormente, la Ley 39/2015 consolidó el régimen actual.

El artículo 28 dispone que la Administración actuante podrá consultar o recabar los documentos salvo oposición de la persona interesada, con las excepciones legales, y que deberá hacerlo electrónicamente mediante redes corporativas, plataformas de intermediación u otros sistemas habilitados. También prohíbe exigir datos no previstos por la norma reguladora y documentos ya aportados anteriormente, salvo imposibilidad de recuperación o circunstancias excepcionales.

El Real Decreto 203/2021 completa el modelo. Las transmisiones realizadas mediante redes corporativas, plataformas de intermediación u otros sistemas tienen la consideración de certificados administrativos necesarios para el procedimiento. La petición identifica los datos, sus titulares y la finalidad; si interviene una persona empleada pública, también debe identificarse. El órgano cesionario responde del acceso y uso correctos, especialmente cuando los datos tienen protección reforzada.

9.1. Oposición, consentimiento y base jurídica

No debe confundirse oposición con consentimiento. La regla del artículo 28 permite la consulta salvo oposición en muchos procedimientos, pero existen ámbitos en los que una ley especial exige consentimiento expreso o impone un régimen propio. La aplicación tramitadora debe mostrar la información adecuada, recoger la oposición o el consentimiento cuando proceda y bloquear consultas incompatibles con lo declarado.

La finalidad no puede formularse de manera genérica como «gestión administrativa». Debe vincularse a un procedimiento, trámite o actuación concreta y a los requisitos establecidos en su normativa. La consulta masiva «por si acaso» vulnera minimización y proporcionalidad. Tampoco es lícito reutilizar un resultado obtenido para un expediente en otro distinto sin comprobar la habilitación correspondiente.

9.2. Del certificado documental a la respuesta estructurada

SCSP puede devolver una respuesta positiva o negativa, datos estructurados o una certificación electrónica según el servicio. El valor probatorio no depende de que exista una imagen de un certificado tradicional, sino de la competencia del cedente, la integridad de la transmisión, la identificación de la finalidad y la trazabilidad. Esta transición permite automatizar decisiones, pero obliga a modelar cuidadosamente estados como «no consta», «servicio no disponible», «titular no identificado» o «resultado negativo». Un fallo técnico nunca debe interpretarse como incumplimiento del requisito.

10. PROTOCOLO SCSP Y PLATAFORMAS DE INTERMEDIACIÓN

SCSP es simultáneamente un conjunto de especificaciones y un patrón organizativo. En el intercambio intervienen el cedente, propietario o competente sobre el dato; el cesionario, órgano que lo necesita para tramitar; y la plataforma de intermediación, que proporciona conectividad, normalización, control y auditoría. La plataforma no se convierte por ello en propietaria funcional de todos los datos.

El protocolo admite modalidades síncronas y asíncronas. En una consulta síncrona, el tramitador espera la respuesta dentro de la interacción. Es apropiada para datos pequeños y servicios con respuesta rápida. En una consulta asíncrona, la petición se registra y la respuesta se recupera posteriormente; resulta útil para lotes, procesos costosos o dependencias externas. En ambos casos deben existir identificadores únicos, control de duplicados y estados inequívocos.

10.1. Controles obligatorios

Antes de una consulta deben comprobarse el procedimiento habilitado, la finalidad, los datos estrictamente necesarios y el régimen de oposición o consentimiento. La identidad técnica del consumidor debe estar asociada a permisos concretos; no debe usarse un certificado compartido por múltiples aplicaciones sin trazabilidad interna. Tras la consulta, se registra fecha, hora, titular, servicio, resultado, finalidad y actor.

La auditoría protege tanto a la ciudadanía como al empleado público. Permite investigar accesos indebidos, demostrar la legalidad de una consulta y detectar patrones anómalos. Los registros deben protegerse contra alteración y conservarse según la política aplicable. No deben incluir más datos personales de los necesarios: registrar el resultado completo en varios logs puede multiplicar la exposición.

10.2. Tratamiento de errores

Conviene clasificar errores en cuatro grupos: autenticación o autorización; validación del mensaje; indisponibilidad técnica; y resultado de negocio. Un código HTTP, un SOAP Fault o un estado SCSP debe mapearse a una acción. Algunos errores son reintentables; otros requieren corregir datos; otros indican que el consumidor no está habilitado. Los reintentos deben aplicar espera progresiva y límite, evitando sobrecargar un cedente caído.

La aplicación tramitadora debe conservar evidencia de la imposibilidad cuando, excepcionalmente, solicita al interesado el documento porque no pudo recuperarlo. Esta excepción no puede convertirse en práctica ordinaria por falta de integración. La mejora debe medir tasa de consultas automáticas, disponibilidad, tiempos, rechazos, incidencias y documentos evitados.

11. INICIATIVAS DE LA JUNTA DE ANDALUCÍA

La Junta de Andalucía articula su administración electrónica mediante un conjunto de plataformas especializadas. El marco autonómico se encuentra en el Decreto 622/2019, de administración electrónica, simplificación de procedimientos y racionalización organizativa, junto con las leyes estatales, el ENI y el ENS. La arquitectura no debe imaginarse como una única aplicación universal, sino como servicios de registro, intermediación, firma, notificación, tramitación, archivo y directorios que se integran con los sistemas sectoriales.

11.1. Plataforma SCSP de la Junta de Andalucía

La Junta dispone de su propia Plataforma SCSP, integrada con servicios internos y con la Plataforma de Intermediación estatal. Ofrece servicios web para integración automática y una herramienta de usuario final, SCSP-Web, como solución facilitadora en servicios autorizados. La integración automática es el escenario preferente porque reduce errores, vincula la consulta al expediente y permite aplicar controles desde la aplicación tramitadora.

Las altas se realizan por finalidad y procedimiento. El sistema registra qué dato se solicita, quién es su titular, cuándo se pide, para qué finalidad y qué actor realiza la consulta. Los sistemas consumidores deben impedir consultas fuera de procedimientos habilitados, comprobar oposición o consentimiento y registrar al gestor concreto. Esta configuración traduce principios jurídicos a controles técnicos verificables.

11.2. @ries, Registro Electrónico Único e intercambio registral

@ries establece un registro de entrada y salida unificado para la Junta. Gestiona asientos y documentos y se integra con el Sistema de Interconexión de Registros. Cuando la documentación se presenta en papel, la oficina puede digitalizarla y generar una copia electrónica auténtica para su remisión. El destino se identifica mediante directorios comunes y el intercambio registra estados, rechazos y aceptación.

@ries no debe presentarse como plataforma genérica de intercambio de cualquier dato. Su dominio es el registro administrativo. Para consultas de datos se usa SCSP; para intercambio registral, @ries con SIR y SICRES; para expedientes, servicios de tramitación y nodos de interoperabilidad; para notificaciones, la plataforma correspondiente. Distinguir dominios evita respuestas de examen aparentemente plausibles pero incorrectas.

11.3. Red NEREA y conexión con Red SARA

La Red NEREA conecta administraciones locales andaluzas y facilita el acceso a servicios de la comunidad autónoma y de la Administración General del Estado a través de Red SARA. La red proporciona el plano de comunicaciones; no define por sí sola el significado de los mensajes. Sobre ella pueden operar SIR, consultas de datos y otros servicios compartidos. La seguridad requiere segmentación, autenticación, control de acceso, monitorización y cumplimiento del ENS.

11.4. Directorios y plataformas habilitantes

El intercambio necesita directorios de unidades y oficinas actualizados, especialmente DIR3. Un asiento dirigido a un código incorrecto puede ser técnicamente válido y, sin embargo, no llegar a la unidad competente. También intervienen servicios de firma y validación, sellado de tiempo, portafirmas, notificación y archivo. El valor está en su integración coherente dentro del procedimiento.

12. INICIATIVAS DEL SERVICIO ANDALUZ DE SALUD

El SAS intercambia datos en dos grandes ámbitos: el económico-logístico, donde los mensajes conectan al organismo con proveedores y sistemas contables, y el asistencial, donde la continuidad clínica exige compartir información sanitaria con controles reforzados. Ambos ámbitos necesitan interoperabilidad, pero sus modelos, finalidades, bases jurídicas y riesgos son diferentes.

12.1. SIGLO, EDI y EDISAS

SIGLO soporta la gestión corporativa de compras, logística, almacenamiento, distribución, facturación y contabilización. Sus guías EDI documentan mensajes como ORDERS, DESADV, RECADV e INVOIC. Esta cadena permite relacionar pedido, expedición, recepción y factura, reduciendo tecleo y facilitando conciliación. La identificación GS1 y las guías AECOC aportan códigos y reglas compartidas con los proveedores.

La documentación de 2025 describe EDISAS, una utilidad de SIGLO que permite a proveedores sin integración EDI simular el envío electrónico de albaranes DESADV y facturas INVOIC desde una interfaz. No ofrece toda la cobertura de una integración EDI completa, pero reutiliza conceptos y servicios de SIGLO para registrar comunicaciones. Es un ejemplo de estrategia gradual: mantener el modelo de mensajes y ofrecer un canal accesible a organizaciones con menor capacidad técnica.

12.2. Diraya e Historia de Salud Digital de Andalucía

Diraya es el sistema corporativo que da soporte a la historia clínica electrónica en el SAS e integra información para que esté disponible cuando sea necesaria en la atención. La interoperabilidad interna conecta módulos asistenciales y sistemas departamentales. No debe afirmarse sin evidencia que toda Diraya use un único estándar o que cualquier integración se realice directamente contra su base de datos. La práctica correcta es utilizar servicios e interfaces corporativas autorizadas, contratos de integración, identificadores maestros y terminologías acordadas.

En salud, un dato no es solo un valor: necesita paciente, autor, organización, instante, contexto asistencial, estado, unidades, método y procedencia. Una analítica sin unidades o un diagnóstico sin sistema de codificación puede ser técnicamente transmitido y clínicamente peligroso. La interoperabilidad clínica combina estándares como HL7, perfiles IHE, DICOM y terminologías, con guías corporativas y controles de seguridad.

12.3. Receta XXI y Receta Electrónica del SNS

La receta electrónica andaluza se denomina Receta XXI. Integra prescripción, dispensación y seguimiento mediante Diraya y la red de oficinas de farmacia. A nivel nacional, la Receta Electrónica interoperable del SNS permite dispensar en una comunidad autónoma medicamentos prescritos en otra presentando la tarjeta sanitaria individual. Esto requiere identificar al paciente, recuperar prescripciones activas, registrar la dispensación y devolver la información a la comunidad de origen.

La diferencia entre Receta XXI y RESNS es de ámbito: la primera es la solución andaluza; la segunda es el servicio nacional que interopera entre comunidades. Un sistema autonómico participa mediante nodos y servicios acordados, sin perder la responsabilidad sobre su fuente de datos.

12.4. HCDSNS y servicios transfronterizos

La Historia Clínica Digital del SNS permite compartir una selección de documentos clínicos relevantes entre servicios de salud, con acceso profesional autorizado y acceso de la ciudadanía. No replica necesariamente la historia completa en un repositorio central; opera mediante servicios, índices y acceso a documentos definidos. La identificación única en el SNS se apoya en la Base de Datos de Tarjeta Sanitaria Individual.

En el plano europeo, los servicios de MyHealth@EU permiten el intercambio de resumen de paciente y receta electrónica entre países participantes. España y las comunidades autónomas contribuyen a estos servicios mediante la infraestructura nacional. El software libre OpenNCP implementa capacidades del punto de contacto nacional para eSalud y ha sido objeto de preguntas oficiales del SAS.

13. PROYECTOS NACIONALES DE INTERCAMBIO DE DATOS

13.1. Plataforma de Intermediación de Datos y servicios de verificación

La Plataforma de Intermediación de la Administración General del Estado actúa como punto común para consultar datos y documentos asociados a procedimientos. Integra organismos cedentes y facilita que comunidades autónomas y entidades locales consuman servicios mediante Red SARA. Entre los servicios históricamente más representativos se encuentran verificación de identidad y residencia, titulaciones, datos tributarios, Seguridad Social, desempleo, discapacidad y familia numerosa, aunque el catálogo evoluciona.

El valor de la plataforma es reducir integraciones punto a punto y aplicar un marco uniforme de alta, seguridad y auditoría. El órgano consumidor sigue siendo responsable de justificar la finalidad, limitar los datos y tratar correctamente el resultado. La interoperabilidad entre plataformas autonómicas y la estatal evita que cada sistema sectorial deba conectarse directamente con todos los cedentes.

13.2. Red SARA

Red SARA es la red de comunicaciones que interconecta las Administraciones Públicas españolas y proporciona acceso a servicios comunes. Es infraestructura, no una base de datos ni una aplicación de firma. Puede transportar consultas de intermediación, intercambio registral, validaciones y otros servicios. La separación entre red y aplicación es una pregunta típica: SARA proporciona conectividad segura y servicios asociados, mientras cada plataforma mantiene su función.

13.3. SIR, SICRES 4 y DIR3

El Sistema de Interconexión de Registros permite intercambiar asientos electrónicos y documentación entre registros. El Real Decreto 203/2021 establece que las interconexiones se realicen a través de SIR. La NTI SICRES 4, aprobada en 2021, define el modelo de datos, mensajes de control, estados, identificadores, seguridad, tratamiento de errores y uso de directorios. DIR3 aporta códigos de unidades y oficinas.

El intercambio registral no es una consulta SCSP. En SIR se remite un asiento y su documentación a un destino administrativo. En SCSP se solicita un dato o certificación a un cedente para incorporarlo a un procedimiento. Pueden coincidir dentro de un expediente, pero resuelven necesidades diferentes.

13.4. Cl@ve, @firma y servicios de confianza

Cl@ve facilita identificación electrónica común; @firma valida firmas y certificados y ofrece servicios relacionados. Identificar a una persona no equivale siempre a obtener su firma. Muchos trámites requieren autenticación para acceder, pero solo determinadas actuaciones exigen firma conforme a la Ley 39/2015. Separar identificación, firma, sello y autenticación de sistemas evita sobredimensionar los controles.

13.5. FACe, Facturae y contratación electrónica

La Ley 25/2013 impulsó la factura electrónica y el registro contable de facturas. FACe es el punto general de entrada estatal y Facturae es el formato estructurado nacional, actualmente con versión 3.2.2 publicada. Facturae utiliza XML y firma XAdES en los supuestos aplicables. No debe confundirse con la factura EDI INVOIC del SAS: pueden coexistir como canales y modelos distintos dentro de procesos de facturación pública.

13.6. HCDSNS y RESNS

En el Sistema Nacional de Salud, la HCDSNS y la RESNS son proyectos sectoriales de intercambio. Se apoyan en acuerdos de gobernanza, identificación de pacientes y profesionales, conjuntos documentales, trazabilidad y seguridad. Su especialización demuestra que la interoperabilidad horizontal necesita adaptarse al dominio: un asiento registral, una prescripción y una factura no pueden modelarse con el mismo esquema genérico.

14. PROYECTOS Y MARCOS EUROPEOS

La Unión Europea ha evolucionado desde proyectos piloto hacia infraestructuras y reglamentos de aplicación general. El objetivo es que una persona o empresa pueda usar su identidad, aportar evidencias, facturar o recibir asistencia sanitaria en otro Estado miembro sin que las diferencias nacionales impidan el servicio.

14.1. eIDAS revisado y Cartera Europea de Identidad Digital

El Reglamento (UE) 2024/1183 modificó eIDAS y creó el marco de identidad digital europea. Los Estados miembros deben ofrecer al menos una Cartera Europea de Identidad Digital conforme al calendario de implantación. La cartera permitirá presentar atributos y credenciales con control por la persona usuaria y divulgación selectiva. Este marco amplía eIDAS más allá del reconocimiento de medios de identificación y servicios de confianza.

La firma electrónica cualificada mantiene el efecto jurídico equivalente a la firma manuscrita. Sin embargo, no toda autenticación con cartera implica firma cualificada. La cartera puede identificar, presentar una titulación o demostrar un atributo sin firmar un documento. De nuevo, deben distinguirse finalidad y nivel de garantía.

14.2. Pasarela Digital Única y Once-Only Technical System

El Reglamento (UE) 2018/1724 creó la Single Digital Gateway. Su Once-Only Technical System permite intercambiar evidencias entre autoridades de distintos Estados miembros para procedimientos transfronterizos. El sistema localiza proveedores de evidencias, solicita datos, permite controles y los entrega al procedimiento de destino. Traslada al ámbito europeo el principio de «solo una vez», con retos de traducción semántica, identificación de autoridades y protección de datos.

14.3. Interoperable Europe Act

El Reglamento (UE) 2024/903 establece medidas para un alto nivel de interoperabilidad del sector público en la Unión. Refuerza evaluaciones de interoperabilidad, reutilización de soluciones, gobernanza y cooperación. Su importancia para un TFA-STI es conceptual: la interoperabilidad pasa de ser una recomendación técnica a un elemento estructural de los servicios públicos digitales transeuropeos.

14.4. eDelivery, AS4 y bloques digitales

El bloque eDelivery proporciona especificaciones, software y servicios para intercambiar datos y documentos mediante puntos de acceso, utilizando AS4. El modelo de cuatro esquinas permite que emisor y receptor contraten proveedores distintos y se comuniquen mediante reglas comunes. Separar red de entrega, descubrimiento, identidad y semántica facilita reutilización en justicia, contratación, salud y otros sectores.

14.5. eInvoicing, EN 16931 y Peppol

La Directiva 2014/55/UE impulsó una norma semántica europea de factura electrónica, EN 16931. Las administraciones deben poder recibir y procesar facturas conformes en las sintaxis admitidas. Peppol combina especificaciones de proceso, documentos BIS y una red de puntos de acceso. UBL y UN/CEFACT CII son sintaxis utilizadas para representar el modelo semántico europeo.

Peppol no es únicamente un formato ni una aplicación central. Es un marco de gobernanza e intercambio. Un documento UBL no se convierte en Peppol por usar XML: debe cumplir el perfil BIS, reglas de validación, identificadores y transporte de la red.

14.6. MyHealth@EU y Espacio Europeo de Datos de Salud

MyHealth@EU soporta servicios sanitarios transfronterizos, inicialmente resumen de paciente y receta/dispensación electrónicas, y amplía progresivamente categorías como resultados de laboratorio, imágenes e informes de alta. Los puntos de contacto nacionales traducen y transmiten información conforme a guías comunes.

El Reglamento (UE) 2025/327 creó el Espacio Europeo de Datos de Salud. Distingue uso primario para asistencia y uso secundario para investigación, innovación, políticas y regulación. Entró en vigor en marzo de 2025, pero su aplicación es gradual: las obligaciones principales sobre resumen de paciente y receta se proyectan para 2029, y otras categorías para 2031. Es incorrecto presentarlo como plenamente operativo desde su entrada en vigor.

15. PROTECCIÓN DE DATOS, SEGURIDAD, AUDITORÍA Y RESPONSABILIDAD

El intercambio administrativo y sanitario trata datos personales y, en salud, categorías especiales. La interoperabilidad no reduce las obligaciones del RGPD y la LOPDGDD; las hace más exigentes porque aumenta el número de sistemas, actores y flujos. Cada consulta debe tener base jurídica, finalidad determinada, minimización, exactitud, limitación temporal y medidas de seguridad.

El órgano cedente asegura la calidad y legitimidad de la fuente; el cesionario justifica la necesidad y usa el dato para la finalidad autorizada; la plataforma aplica controles y deja trazas. Las responsabilidades concretas dependen del diseño jurídico y técnico, pero no deben diluirse en expresiones como «lo hace la plataforma». Los acuerdos y condiciones de uso deben definir incidencias, derechos, auditorías, conservación y subencargados cuando proceda.

15.1. Control de acceso y mínimo privilegio

La autorización debe combinar identidad del sistema, servicio, procedimiento, finalidad y rol del usuario. Una cuenta genérica compartida impide atribuir consultas. Los permisos deben revisarse cuando cambian funciones o finaliza un proyecto. En servicios automáticos, la identidad de máquina se complementa con el identificador del expediente y, cuando sea posible, del empleado que desencadena la acción.

15.2. Trazabilidad sin sobreexposición

Registrar todo el mensaje en logs puede revelar datos sensibles. Es preferible almacenar identificadores, códigos de resultado y huellas, y proteger los repositorios de auditoría. El acceso a las trazas también debe auditarse. Para resolver incidencias puede existir un mecanismo excepcional de acceso al detalle, con autorización y justificación.

15.3. Disponibilidad y continuidad

La dependencia de servicios externos exige acuerdos de nivel de servicio, timeouts, reintentos, circuit breakers, colas y procedimientos degradados. Un servicio cedente indisponible no debe bloquear indefinidamente la aplicación. El modo degradado debe respetar la ley: puede permitir continuar y recuperar el dato después, o justificar la solicitud al interesado cuando proceda, pero no inventar un resultado.

15.4. Integridad y no repudio

Las firmas, sellos y sellos de tiempo aportan evidencias. La validación debe contemplar cadena de confianza, revocación, instante de firma y política. Para conservación a largo plazo pueden requerirse formatos avanzados y renovación de evidencias. El archivo debe preservar el original y sus metadatos, no solo una representación visual.

15.5. Evaluación de impacto y seguridad desde el diseño

Cuando el tratamiento pueda generar alto riesgo, especialmente por escala, sensibilidad o combinación de fuentes, procede analizar una evaluación de impacto. La arquitectura debe aplicar privacidad por diseño: limitar campos, separar entornos, seudonimizar cuando sea posible, evitar datos reales en pruebas y controlar exportaciones. El ENS proporciona el marco de seguridad para los sistemas del sector público y sus proveedores.

16. ESTRATEGIA DE IMPLANTACIÓN Y OPERACIÓN

Implantar un intercambio comienza por el proceso, no por elegir XML o una API. Debe definirse qué problema se resuelve, quién es fuente auténtica, qué datos son necesarios, qué evento inicia el intercambio, qué evidencia necesita el expediente y cómo se gestionan excepciones. Después se modelan mensajes e interfaces.

16.1. Fases recomendadas

1. Inventario y análisis jurídico: procedimientos, cedentes, consumidores, base jurídica, oposición o consentimiento, plazos y evidencias.
2. Modelo semántico: conceptos, identificadores, catálogos, reglas, unidades y procedencia.
3. Contrato técnico: esquemas, API, mensajes, seguridad, errores, idempotencia, límites y versiones.
4. Entorno de pruebas: datos sintéticos, simuladores, certificados de prueba, casos positivos y negativos.
5. Piloto: alcance acotado, métricas, soporte reforzado y plan de reversión.
6. Despliegue: incorporación progresiva de consumidores y seguimiento de calidad y rendimiento.
7. Operación: monitorización, auditoría, gestión de certificados, cambios y continuidad.

16.2. Pruebas

Las pruebas deben cubrir sintaxis, esquema, reglas de negocio, catálogos, autenticación, autorización, rendimiento, duplicados, orden, reintentos, caídas, expiración de certificados y versiones. Las pruebas de contrato detectan cambios incompatibles. Las pruebas de seguridad verifican que un consumidor no puede consultar finalidades ajenas ni modificar el titular.

En intercambio sanitario deben incluirse casos de homonimia, cambios de identificador, datos ausentes, unidades, anulaciones y correcciones. En facturación, duplicados, abonos, impuestos, referencias a pedidos y conciliación. En registro, destinos inexistentes, documentos demasiado grandes, rechazos y subsanaciones.

16.3. Métricas

Las métricas útiles son tasa de éxito, latencia por percentiles, disponibilidad, errores por causa, reintentos, duplicados, antigüedad de colas, consultas por procedimiento, documentos evitados y tiempos de tramitación. También deben medirse calidad semántica y accesos anómalos. Un promedio puede ocultar colas largas; por eso se emplean percentiles y distribución.

16.4. Antipatrones

• Integrar directamente contra tablas de otro sistema sin contrato ni propietario.
• Usar producción para pruebas o consultar personas reales sin finalidad.
• Compartir cuentas técnicas entre aplicaciones.
• Interpretar error técnico como respuesta negativa.
• No versionar esquemas ni catálogos.
• Confirmar el mensaje antes de persistirlo.
• Duplicar datos sensibles en logs.
• Depender de nombres descriptivos como identificadores.
• Diseñar sin idempotencia ni reconciliación.

17. MAPA CONCEPTUAL Y REPASO DE EXAMEN