DocumentaçãoSuporteCosta Rica · Contato
ESENPT
Fale conosco
  • Técnica
  • Organizacional

IHE XDS.bCross-Enterprise Document Sharing

Em poucas palavras

O XDS.b é um perfil da IHE para que hospitais, clínicas e consultórios compartilhem documentos clínicos de um paciente, como resumos de alta, laudos ou resultados, sem centralizá-los em um único sistema. Cada instituição guarda seus documentos e um registro comum permite encontrá-los. Programas nacionais como a ELGA na Áustria e o prontuário eletrônico do paciente da Suíça o usam.

Tipo
Guia de implementação
Responsável
IHE International
Versão vigente
ITI TF Rev. 20.2
Revisado
25 de outubro de 2026

Explicação

O que é

O Cross-Enterprise Document Sharing (XDS.b) é um perfil de integração do framework técnico de Infraestrutura de TI (ITI) da IHE. Ele facilita registrar, distribuir e consultar documentos clínicos entre instituições, de um consultório particular a um hospital. Em outubro de 2026, a revisão vigente do framework técnico ITI é a 20.2, de novembro de 2025. A IHE esclarece que hoje o termo XDS se refere apenas ao XDS.b.

Domínio de afinidade

O XDS.b supõe que as instituições pertencem a um domínio de afinidade XDS: um grupo que concordou em trabalhar com políticas comuns e uma infraestrutura compartilhada, como uma rede regional, um programa nacional ou uma rede de oncologia. O perfil não define essas políticas: cada domínio decide como identificar os pacientes, como obter o consentimento, como controlar o acesso e quais formatos de documento usar.

Atores e transações

AtorFunção
Document SourceProduz e publica documentos (ITI-41)
Document RepositoryGuarda os documentos e os entrega (ITI-43)
Document RegistryIndexa os metadados e responde a consultas (ITI-18)
Document ConsumerBusca e recupera documentos
Patient Identity SourceInforma ao registro as identidades dos pacientes (ITI-8 ou ITI-44)

Os metadados usam o modelo de registro do ebXML. Um único registro pode indexar documentos de muitos repositórios.

Requisitos que costumam passar despercebidos

Todos os atores do XDS.b devem ser agrupados com Consistent Time (CT) e com um ator Secure Node ou Secure Application do ATNA, o perfil de auditoria e autenticação de nós. Sem ATNA, uma implementação não é conforme.

Equívocos comuns

  • O XDS.b é neutro quanto ao conteúdo: compartilha texto, PDF, documentos CDA ou imagens DICOM, mas não garante que o receptor entenda o conteúdo. Isso é definido pelos perfis de conteúdo e pelo domínio.
  • Funciona dentro de um domínio de afinidade. Para consultar outras comunidades, usa-se o XCA.
  • Exige um identificador de paciente comum no domínio, que costuma ser resolvido com PIX ou um identificador nacional.
  • As transações são serviços web SOAP; para clientes leves ou móveis, a IHE oferece o MHD, uma interface FHIR que pode ficar na frente do XDS.b.

Exemplos de uso

  1. Na Áustria, a ELGA registra documentos CDA por meio do IHE XDS, e seu guia de implementação «XDS Metadaten» (versão 3.0.2, de julho de 2024) define como derivar os metadados.

  2. Na Suíça, o suplemento 1 do anexo 5 da portaria EPDV-EDI (edição 8, em vigor desde 1º de junho de 2025) fixa as adaptações nacionais do XDS, do XCA e do ATNA para o prontuário eletrônico do paciente.

  3. O perfil XDS-I.b da IHE estende o XDS.b à imagem: compartilha manifestos DICOM Key Object Selection que apontam para os estudos.

  4. O perfil XCA da IHE permite consultar e recuperar documentos de outras comunidades, que podem ser elas mesmas domínios de afinidade XDS.

  5. A opção «XDS on FHIR» do perfil MHD converte uma publicação FHIR em uma transação XDS.b Provide and Register Document Set-b.

  6. O sistema de uma clínica publica um resumo de alta no repositório regional, e o médico de família o encontra ao consultar o registro com o identificador do paciente.

Relação com outros termos

Apoia-se em4

  • IHE ATNAObrigatória

    Todos os atores do XDS.b devem ser agrupados com um ator Secure Node ou Secure Application do ATNA.

  • Índice mestre de pacientes (MPI)Média

    O XDS.b exige um identificador de paciente comum no domínio de afinidade; pode ser resolvido com um MPI (por exemplo, via PIX) ou com um identificador nacional.

  • CDABaixa

    O XDS.b é neutro quanto ao conteúdo; muitos domínios compartilham documentos CDA, mas o perfil não exige isso.

  • HL7 v2Baixa

    O registro deve implementar o Patient Identity Feed em HL7 v2 (ITI-8) ou HL7 v3 (ITI-44), então pode funcionar sem HL7 v2.

Dependem deste2

  • IHE MHDMédia

    O MHD reutiliza os metadados do XDS e pode ser a API de uma rede XDS.b (opção XDS on FHIR), mas também funciona sem ela.

  • Troca de informações de saúde (HIE)Média

    Um HIE baseado em documentos pode usar XDS.b; outros usam mensagens HL7 v2 ou APIs FHIR.

Fontes

  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
Glossário de interoperabilidade em saúde