Transferir Registos Médicos com Segurança: Guia Completo

Transferir registos médicos com segurança significa que o ficheiro é encriptado com chaves às quais o fornecedor de transferência não tem acesso, a transmissão usa TLS 1.3, e o fluxo de trabalho produz um registo auditável de transmissão e receção. Do ponto de vista do RGPD, está a respeitar o Artigo 32.º (medidas técnicas e organizativas adequadas) e o Artigo 9.º (dados de categorias especiais). O atalho prático: carregar o estudo DICOM ou os registos em PDF para um serviço via browser que encripta do lado do cliente com AES-256-GCM antes de qualquer byte sair do posto de trabalho clínico.

O que o RGPD exige concretamente para a transmissão de dados de saúde

O Artigo 9.º do RGPD classifica os dados de saúde como categoria especial. O Artigo 32.º exige medidas técnicas e organizativas adequadas, incluindo explicitamente a encriptação. Para clínicas e hospitais na UE, a encriptação ponto a ponto com derivação de chave do lado do cliente satisfaz estes requisitos. O processamento sem conhecimento reduz o âmbito dos contratos de subcontratante de tratamento ao abrigo do Artigo 28.º.

Nos Estados Unidos, a Regra de Segurança HIPAA — Secção 164.312 (Salvaguardas Técnicas) — exige controlo de acesso, controlos de auditoria, integridade e segurança de transmissão. A encriptação AES-256-GCM do lado do browser satisfaz a maioria destas exigências sem que o fornecedor de transferência tenha acesso ao texto simples.

A questão do Acordo de Subcontratante (DPA/BAA)

No contexto do RGPD, um Acordo de Subcontratante (DPA) é obrigatório quando um fornecedor trata dados pessoais por conta do responsável pelo tratamento. Se o serviço de transferência consegue ver dados de saúde em texto simples — mesmo transitoriamente — é necessário um DPA. Se os dados estiverem encriptados ponto a ponto e o serviço tratar apenas texto cifrado, o fornecedor não é um subcontratante relativamente a esses dados, porque nunca tem acesso a dados pessoais como tal.

Este é o argumento de conhecimento zero. Para práticas mais pequenas, a recomendação prática é combinar um serviço que assine um DPA ou um serviço de conhecimento zero com uma análise de risco documentada.

Tipos de ficheiro clínicos comuns

| Ficheiro | Tamanho típico | Conteúdo | | --- | --- | --- | | Estudo CT DICOM | 200 MB – 2 GB | Fatias, metadados (nome do doente, ID, data do estudo) | | Estudo MRI DICOM | 100 MB – 3 GB | Múltiplas séries | | Patologia digital .svs | 500 MB – 5 GB | Imagens de lâmina inteira | | XML Consolidated CDA (C-CDA) | 100 KB – 5 MB | Resumo clínico estruturado | | Resultados laboratoriais PDF | 50 KB – 20 MB | Análises, relatórios de imagiologia | | Estudo DEXA/DXA | 10–50 MB | Imagens de densidade óssea | | Exportação completa de EMR | 10 MB – 2 GB | Exportação identificada ou solicitada pelo doente |

Um único TAC abdominal com contraste pode atingir 1,2 GB. O email não é um canal adequado para estes ficheiros.

Porque o email e o armazenamento cloud padrão ficam aquém

O SMTP padrão usa TLS salto a salto — os servidores de email ao longo do caminho desencriptam e re-encriptam. Uma mensagem que atravessa três retransmissores tem três pontos de desencriptação.
O Gmail, Outlook.com e iCloud Mail armazenam mensagens nos servidores do fornecedor com chaves detidas pelo fornecedor.
O Dropbox, Google Drive e OneDrive oferecem encriptação em repouso, mas o fornecedor detém as chaves. O plano gratuito do Google Drive não é coberto por DPA para dados de saúde.
O fax, o método de reserva perene, ainda é utilizado na área da saúde, mas o fax de linha analógica não encriptada passa pelas operadoras de telecomunicações em texto simples.

Um fluxo de transferência de conhecimento zero para uso clínico

O clínico exporta o estudo DICOM do PACS (GE Centricity, Philips IntelliSpace, Siemens syngo.via, ou dcm4chee de código aberto) para um .zip com ficheiros DICOM anonimizados ou identificados.
O clínico abre o serviço de transferência no browser. A Web Crypto API deriva uma chave de 256 bits a partir de uma frase-senha partilhada via PBKDF2-HMAC-SHA256, 600 000 iterações, sal aleatório de 128 bits.
O browser encripta cada bloco de 5 MB com AES-256-GCM, IV de 96 bits novo por bloco. O texto cifrado é enviado por TLS 1.3.
A ligação é enviada ao clínico receptor via mensagens seguras (DirectTrust, TigerConnect) ou portal do doente.
A frase-senha é transmitida por um segundo canal — um formulário em papel entregue ao doente, um SMS para um número verificado, ou uma chamada telefónica.
O receptor descarrega, desencripta no browser e abre no OsiriX, Horos, RadiAnt ou no PACS local.

O serviço de transferência nunca vê dados do doente. O registo de auditoria regista o carimbo de hora do upload, o tamanho do ficheiro (não o conteúdo), o carimbo de hora do download e os endereços IP.

Riscos de fuga de metadados

Os ficheiros DICOM incorporam um cabeçalho rico: nome do doente, ID, data de nascimento, médico referenciador, instituição. Dois caminhos de fuga:

Nome do ficheiro inclui DOENTE_APELIDO_ID123456.dcm. Um serviço de transferência com nomes de ficheiro visíveis expõe identificadores mesmo com conteúdo encriptado. Renomeie antes de comprimir em zip.
Tags DICOM dentro do ficheiro contêm todos os dados demográficos. Um ficheiro encriptado oculta isto do serviço de transferência, mas o receptor vê-os após desencriptação. Se o caso de utilização não exigir identificadores, anonimize conforme o Suplemento 142 do DICOM ou a anonimização estatística antes de enviar.

Transferências iniciadas pelo doente

Ao abrigo do RGPD (Artigo 20.º — portabilidade de dados) e das regras de bloqueio de informação da UE, os doentes têm o direito de receber os seus registos em formato eletrónico. Uma transferência encriptada via browser é adequada:

O doente solicita os registos ao serviço de informação do prestador.
O pessoal do serviço carrega um pacote zip PDF/C-CDA/DICOM.
O doente recebe a ligação no email verificado, com palavra-passe por telefone.
O doente descarrega, guarda uma cópia, reencaminha para um prestador de segunda opinião.

Este fluxo satisfaz as obrigações de partilha de informação sem exigir que o doente crie uma conta num portal.

Retenção e eliminação

Os registos clínicos têm retenção estatutária: 10 anos em França (Code de la santé publique L.1110-4), 30 anos na Alemanha para registos hospitalares ao abrigo da lei estadual, e períodos variáveis nos outros países europeus. A transferência em si é efémera. O prazo de retenção aplica-se ao sistema de registo do prestador (o EMR), não à ligação de transferência. Configure a validade da transferência para 14 a 30 dias; o PACS ou EMR do receptor assume a custódia a longo prazo.

Encriptação para clínicas suíças ao abrigo da nFADP

As clínicas suíças estão adicionalmente sujeitas à FADP revista (nFADP, em vigor desde setembro de 2023), que se alinha amplamente com o RGPD nas expectativas de encriptação. A encriptação ponto a ponto com derivação de chave do lado do cliente satisfaz o artigo equivalente ao Artigo 32.º do RGPD.

Comparação de opções de transferência adequadas para a área da saúde

| Opção | Encriptação ponto a ponto | Compatível com RGPD | Tamanho máx. (típico) | Acessível ao doente | | --- | --- | --- | --- | --- | | Gmail padrão | Não (apenas TLS) | Não sem DPA | 25 MB | Sim | | Google Workspace com DPA | Não | Sim | Quota de 5 TB | Sim | | Microsoft 365 com DPA | Não | Sim | 250 GB por ficheiro (OneDrive) | Sim | | DirectTrust (Direct Project) | Sim (S/MIME) | Sim, concebido para saúde | Configurado por HISP | Limitado | | Tresorit Send | Sim (assistido pelo servidor) | DPA disponível | 5 GB gratuito | Sim | | HexaTransfer | Sim (AES-256-GCM no browser) | Conhecimento zero por design | 10 GB | Sim, sem conta necessária |

Os registos médicos têm um peso que vai além do seu tamanho em bytes. O mecanismo de transmissão tem de corresponder a essa responsabilidade.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.