Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

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.

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 [email protected]); 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
Proveniência de dados médicos explicada: quem escreveu o quê e como registar
Modelo de consentimento e acesso
Autenticação e OAuth
Limites e limites de taxa
Fiabilidade, estado e incidentes: monitorização, cópias de segurança, comunicação de incidentes
Arquitetura
O Espaço Europeu de Dados de Saúde (EHDS) para programadores

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card