Partilha de Registos Clínicos Eletrónicos: Guia de Interoperabilidade

Partilhar registos clínicos eletrónicos entre sistemas significa reconciliar pelo menos quatro normas: HL7 FHIR R4 para troca baseada em API, C-CDA R2.1 para transferência baseada em documentos, HL7 v2.x para mensagens legadas, e DICOM para imagiologia. Em Portugal, o RGPD classifica os dados de saúde como categoria especial ao abrigo do Artigo 9.º, e a CNPD tem emitido orientações claras sobre as salvaguardas técnicas obrigatórias — o que significa que o "como" da transferência é tão regulado quanto o "o quê". Quando um registo circula entre um hospital público e uma clínica privada, passa tipicamente por adaptadores FHIR ou documentos CDA encapsulados nos perfis IHE XCA.

A Pilha de Normas com que Está Efetivamente a Trabalhar

A interoperabilidade de registos clínicos parece uma salada de normas porque o é mesmo. Eis o que cada camada faz:

• HL7 v2.x — mensagens delimitadas por pipe dos anos 90, ainda o cavalo de batalha para pedidos laboratoriais, feeds ADT (admissão/alta/transferência) e gestão de ordens dentro de um hospital; não adequado para partilha entre organizações
• C-CDA R2.1 — documentos XML estruturados que representam um resumo de doente, nota de alta ou nota de referenciação; a espinha dorsal das mensagens Direct e da maioria da troca via HIE
• HL7 FHIR R4 — recursos RESTful (Doente, Observação, Condição, PedidoDeMedicamento) trocados sobre HTTPS com JSON ou XML; a camada moderna, exigida pelas regras de certificação de sistemas clínicos eletrónicos
• DICOM — norma de imagiologia, circula pelos seus próprios canais (DIMSE, DICOMweb)
• IHE XDS.b — perfil de partilha de documentos entre empresas, usado por HIEs para indexação e recuperação de documentos clínicos

Quando "partilha um registo clínico eletrónico", está na realidade a partilhar fragmentos de cada camada, montados no formato certo para o recetor.

APIs FHIR e a Interoperabilidade Obrigatória

A legislação europeia e as normas nacionais empurram progressivamente para a exposição de APIs FHIR. Para um programador a integrar com um sistema hospitalar português, isso significa tipicamente:

1. Registar uma aplicação no portal do fornecedor do sistema clínico
2. Usar o fluxo de lançamento SMART on FHIR com OAuth 2.0 e PKCE
3. Solicitar âmbitos como patient/*.read ou recursos específicos
4. Receber bundles JSON sobre HTTPS

O problema prático: os âmbitos de API, os limites de velocidade e o acesso à produção variam muito entre fornecedores e entre implementações hospitalares. O acesso de produção requer frequentemente acordos assinados e avaliações de segurança — o que faz todo o sentido dado que estão em causa dados de categoria especial ao abrigo do RGPD.

C-CDA: Ainda o Padrão para Resumos Entre Organizações

Apesar do crescimento do FHIR, a maioria da troca de registos entre organizações ainda envia documentos C-CDA. Um Documento de Continuidade de Cuidados (CCD) ao abrigo do C-CDA R2.1 tem tipicamente 200 KB-2 MB de XML com HTML incorporado para legibilidade humana. Modelos-chave:

• CCD (Documento de Continuidade de Cuidados)
• Resumo de Alta
• Nota de Referenciação
• Nota de Consulta
• Nota de Evolução

Estes documentos circulam por mensagens Direct (S/MIME sobre SMTP) ou troca HIE baseada em consulta. O sistema clínico recetor analisa o XML e integra os elementos estruturados no registo local. A qualidade da análise varia — alguns sistemas integram listas de problemas corretamente mas perdem a história social. A reconciliação de dados continua a ser um passo manual na maioria das clínicas.

Quando as APIs Falham e é Necessária uma Transferência de Ficheiros

Apesar de todas as normas, os clínicos precisam regularmente de mover um ficheiro que não cabe em nenhuma API. Exemplos:

• Um bundle PDF de 300 MB de registos em papel digitalizados de antes de a clínica ir para o digital
• Um conjunto de dados de investigação em formato SAS ou Stata para uma revisão retrospectiva
• Um conjunto de fotografias de feridas dos cuidados domiciliários que não precisam de sobrecarregar o servidor de imagens
• Registos de retenção legal para um processo de responsabilidade civil pendente

Para estes casos, recorre-se a transferência encriptada de ficheiros. Os requisitos: DPA assinado com o fornecedor, encriptação AES-256-GCM em repouso, TLS 1.3 em trânsito, registo de auditoria e expiração do link. Se a ferramenta é uma funcionalidade integrada do sistema clínico, um serviço empresarial aprovado pelo hospital ou uma transferência ad-hoc baseada no navegador depende da sua governação interna.

O HexaTransfer oferece o percurso ad-hoc com encriptação do lado do cliente antes do carregamento. Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB. Registe a transferência no seu registo de auditoria padrão para prestação de contas posterior.

Correspondência de Doentes e o Problema de Identidade

Partilhar um registo requer saber que é o doente certo. Portugal não tem um identificador nacional único de saúde amplamente implementado para troca interoperável — o Número de Utente do SNS existe, mas a sua exposição em APIs varia. A resolução de identidade baseia-se em correspondência probabilística de nome, data de nascimento, sexo e código postal.

As taxas de correspondência em redes de produção variam entre 70-95% dependendo da qualidade dos dados. As taxas de não correspondência traduzem-se em registos em falta no ponto de cuidados e registos duplicados que enchem o processo. Muitas redes adicionam agora correspondência referencial por bases de dados de terceiros para melhorar a precisão.

Para transferências ao nível de ficheiro, inclua sempre identificadores do doente no nome do ficheiro ou numa folha de rosto — Número de Utente, data de nascimento e pelo menos um identificador adicional. Não dependa do clínico para saber a que doente pertence "jsc-rm-20261002.dcm".

Consentimento, Segmentação e Dados Sensíveis

Nem todos os registos se partilham da mesma forma. Os dados de saúde mental, de consumo de substâncias, genéticos e de saúde reprodutiva têm frequentemente regras de partilha específicas ao abrigo do direito nacional. Em Portugal, as normas da DGS e as orientações da CNPD sobre dados de saúde mental impõem requisitos de consentimento mais exigentes.

Se a sua ferramenta de transferência não consegue respeitar a segmentação — não consegue sinalizar quais as partes de um documento que requerem consentimento adicional —, não a use para registos de saúde mental. Use-a para o pacote de seguimento de ortopedia.

O RGPD Artigo 9.º, n.º 2, alínea h), permite o tratamento de dados de saúde para fins de cuidados médicos, mas exige salvaguardas adequadas. A partilha sem estas salvaguardas é uma violação, não apenas uma irregularidade técnica.

Auditoria e Registo de Divulgações

O RGPD Artigo 15.º dá aos titulares de dados o direito de saber quem acedeu aos seus dados. O registo de auditoria do seu sistema de transferência alimenta este registo de divulgações. Capture:

• Marca temporal em UTC
• Organizações remetente e destinatária
• Código de finalidade (TRATAMENTO, PAGAMENTO, OPERAÇÕES, AUTORIZAÇÃO)
• Categorias de dados transferidos
• ID do doente

Se depender de uma ferramenta genérica de partilha de ficheiros que apenas regista "o utilizador X carregou o ficheiro Y", terá dificuldades quando um doente solicitar uma prestação de contas das suas divulgações — ou quando a CNPD iniciar uma investigação.

Pequenas Práticas e a Lacuna de Recursos

Uma clínica de 3 profissionais de saúde não tem um diretor de informática. Tem um gestor administrativo que trata de TI a par da faturação. Ainda assim tem de produzir registos clínicos eletrónicos em formato interoperável a pedido, assinar DPAs com cada fornecedor, e gerir pedidos de acesso dos titulares de dados.

A abordagem prática:

• Use um sistema clínico eletrónico que trate de Direct, FHIR e acesso de doentes nativamente
• Escolha uma ferramenta de transferência encriptada ad-hoc com DPA para tudo o que o sistema clínico não consegue enviar
• Documente o fluxo de trabalho num POS de uma página
• Forme cada membro do pessoal nas duas ferramentas que usará semanalmente

A partilha de registos clínicos eletrónicos não é um problema de fornecedor único a resolver. É um fluxo de trabalho por camadas a manter. Acerte nas normas onde puder, e tenha uma alternativa encriptada limpa para os casos que as normas não cobrem.