DocumentaciónSoporteCosta Rica · Contacto
ESENPT
Hablemos
  • Técnica
  • Organizacional

IHE XDS.bCross-Enterprise Document Sharing

En pocas palabras

XDS.b es un perfil de IHE para que hospitales, clínicas y consultorios compartan documentos clínicos de un paciente, como resúmenes de alta, informes o resultados, sin centralizarlos en un único sistema. Cada institución guarda sus documentos y un registro común permite encontrarlos. Lo usan programas nacionales como ELGA en Austria y la historia clínica electrónica del paciente de Suiza.

Tipo
Guía de implementación
Responsable
IHE International
Versión vigente
ITI TF Rev. 20.2
Revisado
25 de octubre de 2026

Explicación

Qué es

Cross-Enterprise Document Sharing (XDS.b) es un perfil de integración del marco técnico de Infraestructura de TI (ITI) de IHE. Facilita registrar, distribuir y consultar documentos clínicos entre instituciones, desde un consultorio privado hasta un hospital. A octubre de 2026, la revisión vigente del marco técnico ITI es la 20.2, de noviembre de 2025. IHE aclara que hoy el término XDS se refiere solo a XDS.b.

Dominio de afinidad

XDS.b supone que las instituciones pertenecen a un dominio de afinidad XDS: un grupo que acordó trabajar con políticas comunes y una infraestructura compartida, como una red regional, un programa nacional o una red de oncología. El perfil no define esas políticas: cada dominio decide cómo identificar a los pacientes, cómo se obtiene el consentimiento, cómo se controla el acceso y qué formatos de documento usa.

Actores y transacciones

ActorFunción
Document SourceProduce y publica documentos (ITI-41)
Document RepositoryGuarda los documentos y los entrega (ITI-43)
Document RegistryIndexa los metadatos y responde consultas (ITI-18)
Document ConsumerBusca y recupera documentos
Patient Identity SourceInforma al registro las identidades de los pacientes (ITI-8 o ITI-44)

Los metadatos usan el modelo de registro de ebXML. Un solo registro puede indexar documentos de muchos repositorios.

Requisitos que suelen pasarse por alto

Todos los actores de XDS.b deben agruparse con Consistent Time (CT) y con un actor Secure Node o Secure Application de ATNA, el perfil de auditoría y autenticación de nodos. Sin ATNA, una implementación no es conforme.

Errores frecuentes

  • XDS.b es neutral respecto del contenido: comparte texto, PDF, documentos CDA o imágenes DICOM, pero no garantiza que el receptor entienda el contenido. Eso lo definen los perfiles de contenido y el dominio.
  • Sirve dentro de un dominio de afinidad. Para consultar a otras comunidades se usa XCA.
  • Requiere un identificador de paciente común en el dominio, que suele resolverse con PIX o un identificador nacional.
  • Las transacciones son servicios web SOAP; para clientes livianos o móviles, IHE ofrece MHD, una interfaz FHIR que puede ponerse delante de XDS.b.

Ejemplos de uso

  1. En Austria, ELGA registra documentos CDA mediante IHE XDS, y su guía de implementación «XDS Metadaten» (versión 3.0.2, de julio de 2024) define cómo derivar los metadatos.

  2. En Suiza, el suplemento 1 del anexo 5 de la ordenanza EPDV-EDI (edición 8, vigente desde el 1 de junio de 2025) fija las adaptaciones nacionales de XDS, XCA y ATNA para la historia clínica electrónica del paciente.

  3. El perfil XDS-I.b de IHE extiende XDS.b a la imagenología: comparte manifiestos DICOM Key Object Selection que apuntan a los estudios.

  4. El perfil XCA de IHE permite consultar y recuperar documentos de otras comunidades, que pueden ser a su vez dominios de afinidad XDS.

  5. La opción «XDS on FHIR» del perfil MHD convierte una publicación FHIR en una transacción XDS.b Provide and Register Document Set-b.

  6. El sistema de una clínica publica un resumen de alta en el repositorio regional, y el médico de cabecera lo encuentra al consultar el registro con el identificador del paciente.

Relación con otros términos

Se apoya en4

  • IHE ATNAObligatoria

    Todos los actores de XDS.b deben agruparse con un actor Secure Node o Secure Application de ATNA.

  • Índice maestro de pacientes (MPI)Mediana

    XDS.b exige un identificador de paciente común en el dominio de afinidad; puede resolverse con un MPI (por ejemplo, vía PIX) o con un identificador nacional.

  • CDABaja

    XDS.b es neutral respecto del contenido; muchos dominios comparten documentos CDA, pero el perfil no lo exige.

  • HL7 v2Baja

    El registro debe implementar Patient Identity Feed en HL7 v2 (ITI-8) o en HL7 v3 (ITI-44), así que puede funcionar sin HL7 v2.

Dependen de este2

  • IHE MHDMediana

    MHD reutiliza los metadatos de XDS y puede ser la API de una red XDS.b (opción XDS on FHIR), pero también funciona sin ella.

  • Intercambio de información de salud (HIE)Mediana

    Un HIE basado en documentos puede usar XDS.b; otros usan mensajes HL7 v2 o APIs FHIR.

Fuentes

  1. IHE ITI Technical Framework (Revision 20.2)profiles.ihe.net
  2. IHE ITI Technical Framework Vol. 1 — Cross-Enterprise Document Sharing (XDS.b)profiles.ihe.net
  3. IHE ITI Technical Framework Vol. 1 — Cross-Community Access (XCA)profiles.ihe.net
  4. IHE — Mobile access to Health Documents (MHD)profiles.ihe.net
  5. gesundheit.gv.at — ELGA Implementierungsleitfädengesundheit.gv.at
  6. Fedlex — Ergänzung 1 zu Anhang 5 EPDV-EDI (Ausgabe 8, 2025)fedlex.admin.ch
Glosario de interoperabilidad en salud