# Segurança, privacidade e residência de dados

> Como os dados do paciente são protegidos: residência de dados na UE, isolamento de projetos, IDs par a par, credenciais, consentimento, proveniência, uma auditoria visível para o paciente e os limites do beta privado.

Source: https://developers.anpheros.com/pt/guides/security

Os dados médicos são os dados mais sensíveis que uma aplicação pode conter. Esta página lista como a Anpheros Platform os protege hoje — apenas o que está implementado — e o que ainda é limitado durante o beta privado.

## Residência dos dados

- Todos os dados da plataforma são armazenados e processados na União Europeia: o serviço e as suas bases de dados no Google Cloud `europe-west4` (Países Baixos), a fila de entrega de webhooks em `europe-west3` (Frankfurt) e o registo de acesso em modo append-only na localização da UE do BigQuery.
- **Região de dados dos EUA:** disponível mediante solicitação para clientes de produção ao abrigo de um acordo de associado comercial HIPAA (ver abaixo); os dados de pacientes dos EUA nunca sairão então da região dos EUA.
- Os documentos são armazenados num bucket de armazenamento da UE encriptado com uma chave de encriptação gerida pelo cliente (CMEK). Os originais são imutáveis após a finalização; o seu checksum SHA-256 e tamanho são registados.

## Isolamento entre aplicações

- Cada chave de API pertence a um **projeto**. Um projeto vê apenas os pacientes que criou — na sandbox, incluindo a sua própria cópia de pacientes sintéticos, que nenhum outro projeto pode ver.
- **Identificadores por pares:** cada projeto recebe o seu próprio ID para a mesma pessoa; os IDs internos nunca saem da plataforma, pelo que os IDs não podem ser correlacionados entre aplicações.
- Um registo a que não consegue aceder responde com `404`, nunca com `403`, pelo que a existência de um paciente não pode ser sondada.
- **Sandbox e produção são bases de dados separadas.** Uma chave de sandbox (`sk_test_`) fisicamente não consegue aceder a pacientes reais.
- Com o consentimento do paciente, uma organização lê o registo completo, incluindo o que outras organizações escreveram, mas só pode alterar ou eliminar o que escreveu.

## Credenciais

- As chaves de API são mostradas uma vez e armazenadas apenas como um hash SHA-256. As chaves têm `read` / `write` escopos e nunca cruzam o seu ambiente.
- OAuth 2.1 com PKCE obrigatório (S256); o `redirect_uri` deve ser registado exatamente. Os tokens de acesso duram 30 minutos, os tokens de atualização 30 dias e rodam a cada utilização.
- **Deteção de reutilização de refresh token:** apresentar um refresh token que já foi utilizado revoga toda a cadeia de tokens.
- As respostas de token transportam `Cache-Control: no-store`. Os `id_token` do OpenID Connect são assinados com RS256; as chaves públicas são publicadas em `/oauth/jwks`.

## Consentimento, proveniência e auditoria

- Um paciente concede a uma aplicação acesso numa página de consentimento alojada, escolhendo o registo e a duração (30, 90, 180 ou 365 dias). Os escopos são por tipo de recurso e ação, opcionalmente filtrados por categoria. Cada concessão é espelhada como um recurso FHIR `Consent`.
- A revogação tem efeito no próximo pedido; a aplicação não pode voltar a ser atualizada.
- **Cada escrita** produz um recurso `Provenance`: quem a escreveu (paciente, praticante, dispositivo, importação ou IA), para qual organização, de qual sistema de origem.
- **Cada leitura é registada e visível para o paciente**, incluindo leituras feitas com a chave API do próprio projeto, e incluindo o contexto construído para modelos de IA.

## Segurança de transporte e web

- Apenas HTTPS, com HTTP Strict Transport Security. As respostas da API contêm uma Content-Security-Policy restritiva, `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY` e uma política de referenciador rigorosa.
- As entregas de webhooks são assinadas com HMAC-SHA256 sobre o timestamp e o corpo; os recetores devem rejeitar assinaturas com mais de 5 minutos. Os eventos contêm IDs e versões, nunca conteúdo clínico.
- Limites de taxa: 600 pedidos por minuto por credencial e por IP; corpos JSON até 2 MiB; documentos até 25 MiB.

## Motores de busca e rastreadores de IA

Páginas públicas (anpheros.com, a apresentação da plataforma e esta documentação) estão abertas a motores de busca e rastreadores de IA. A API, o dashboard, as páginas de OAuth e consentimento e a aplicação do paciente (`app.anpheros.com`) são excluídas com as regras `noindex` e `robots.txt`; nenhuma delas retorna dados do paciente sem autenticação.

## HIPAA (Clínicas nos EUA)

Para uma clínica nos Estados Unidos, a Anpheros é um **Business Associate**. O que está implementado, mapeado para a HIPAA Security Rule:

| Salvaguarda | Como a Anpheros o faz |
|---|---|
| Responsabilidade atribuída, análise de risco, políticas escritas (§164.308) | Um Oficial de Segurança nomeado; uma análise de risco anual; dez políticas escritas (acesso, encriptação, registo, resposta a incidentes, notificação de violações, retenção e backup, formação, dispositivos, acesso de emergência, fornecedores), mantidas durante seis anos |
| Identificação única do utilizador, controlo de acesso (§164.312(a)) | Cada chave, token e pessoa tem a sua própria identidade; os projetos veem apenas os seus próprios pacientes; âmbitos de consentimento aplicados em cada leitura; MFA ou SSO exigido para organizações com um projeto de produção; logout automático no dashboard |
| Controlos de auditoria (§164.312(b)) | Cada leitura e escrita registada, encadeada por hash, exportada de forma imutável (append-only); visível para o paciente |
| Integridade (§164.312(c)) | Recursos versionados, proveniência em cada escrita, documentos imutáveis com SHA-256 |
| Segurança da transmissão (§164.312(e)) | TLS 1.2+, HSTS, webhooks assinados, entregas apenas via HTTPS |
| Encriptação em repouso | Base de dados e backups encriptados; documentos sob uma chave gerida pelo cliente |
| Plano de contingência (§164.308(a)(7)) | Backups diários, recuperação point-in-time, teste de restauração a cada 90 dias com tempos registados |
| Notificação de violação (§164.410) | A Covered Entity é notificada em 5 dias úteis pelo nosso BAA (60 dias por lei) |
| Cadeia de Business Associate (§164.308(b)) | Google Cloud sob o seu BAA; a lista de subprocessadores está no anexo do BAA |

Um **Business Associate Agreement** e uma **região de dados dos EUA** estão disponíveis mediante pedido para clientes de produção (escreva para platform@anpheros.com); a produção para dados de pacientes dos EUA abre após a assinatura do BAA. A sandbox contém apenas pacientes sintéticos, pelo que os desenvolvedores nos EUA podem construir hoje sem um BAA. A Anpheros não é certificada contra SOC 2 ou HITRUST; uma auditoria SOC 2 Type II está planeada quando um cliente hospitalar o exigir.

## Limites atuais (beta privado)

- Alojamento numa única zona sem failover automático; ainda sem SLA contratual.
- As chaves de produção são emitidas para organizações verificadas com um acordo de processamento de dados assinado; os parceiros beta começam com dados sintéticos.
- O lançamento do SMART EHR e o parâmetro OpenID `nonce` ainda não são suportados.

## Relacionado

- [RGPD e dados de saúde para programadores](https://developers.anpheros.com/pt/guides/gdpr-health-data-developers)
- [Proveniência de dados médicos explicada](https://developers.anpheros.com/pt/guides/medical-data-provenance): quem escreveu o quê e como registar
- [Modelo de consentimento e acesso](https://developers.anpheros.com/pt/guides/consent)
- [Autenticação e OAuth](https://developers.anpheros.com/pt/guides/authentication)
- [Limites e limites de taxa](https://developers.anpheros.com/pt/guides/limits)
- [Fiabilidade, estado e incidentes](https://developers.anpheros.com/pt/guides/reliability): monitorização, cópias de segurança, comunicação de incidentes
- [Arquitetura](https://developers.anpheros.com/pt/guides/architecture)
- [O Espaço Europeu de Dados de Saúde (EHDS) para programadores](https://developers.anpheros.com/pt/guides/ehds-for-developers)