Resposta curta: a segurança numa aplicação de saúde responde a quatro perguntas, por ordem. Quem é esta pessoa? Identidade: um utilizador verificado (doente, médico, sistema) através do OpenID Connect e, para médicos, a identidade profissional nacional; o nível de verificação importa mais do que a força da palavra-passe. O que pode fazer? Autorização: tokens OAuth 2.0 (a evoluir para 2.1) com âmbito (scopes) na sintaxe SMART on FHIR, derivados do consentimento do doente para um propósito e duração, aplicados na camada de dados. O que fez? Responsabilização: um registo de acesso que o doente pode ler e um rasto de AuditEvent FHIR para a organização. Os dados estão seguros em repouso, em trânsito e em cópias de segurança? Proteção: encriptação, gestão de chaves, segregação, restauros testados. À volta deles: a base da ISO 27001 e 27799, NIS2 e a Regra de Segurança da HIPAA, e as ameaças específicas dos dados de saúde (navegação interna, registo incorreto, ransomware).
O mapa
A segurança e a identidade numa aplicação de saúde formam sete camadas: identidade através de OpenID Connect e IDs nacionais ou profissionais, autorização através de OAuth 2.0 e âmbitos SMART on FHIR, consentimento como a origem de cada concessão, responsabilização através de registos de acesso e FHIR AuditEvent, proteção através de encriptação e cópias de segurança, uma base de ISO 27001, ISO 27799, NIS2 e HIPAA, e partilha iniciada pelo doente.
| Camada | Norma ou prática | O que lhe dá | Página |
|---|---|---|---|
| Identidade | OpenID Connect; identidades nacionais (eIDAS, NHS login, GesundheitsID); identidades profissionais (eHBA, CPS, UZI) | Um sujeito verificado com um nível de garantia | SMART App Launch explicado |
| Autorização | OAuth 2.0 e 2.1 (PKCE obrigatório, sem concessões implícitas ou de palavra-passe); âmbitos SMART on FHIR (patient/Observation.rs); serviços de backend com autenticação de cliente assimétrica | Tokens ligados a um utilizador, um contexto de doente e um âmbito | SMART App Launch explicado, SMART on FHIR backend |
| Consentimento | FHIR Consent; concessões baseadas em propósito e tempo; revogação; "break-the-glass" com justificação e alerta | O doente como a fonte de toda a autorização | Plataforma de consentimento do doente, Pedidos de acesso de clínica |
| Responsabilização | Registos de acesso por registo visíveis para o doente; FHIR AuditEvent; armazenamento à prova de adulteração; retenção | Quem viu o quê, quando, porquê | Quem viu o meu registo médico? |
| Proteção | TLS 1.2+, encriptação em repouso com chaves geridas, encriptação a nível de campo para identificadores, ambientes segregados, cópias de segurança com restauro testado | Confidencialidade e disponibilidade | ISO 27001 vs ISO 27799 |
| Base | ISMS ISO 27001, controlos de saúde 27799, medidas NIS2, Regra de Segurança HIPAA, esquemas nacionais (HDS, DSPT, C5) | O que hospitais, auditores e reguladores esperam | NIS2 para hospitais e fornecedores, HIPAA vs GDPR |
| Partilha | SMART Health Links e Cards; credenciais verificáveis | Partilha iniciada pelo doente com um link ou QR, revogável | SMART Health Links explicados |
Identidade: garantia em vez de palavras-passe
A identidade numa aplicação de saúde depende da garantia em vez da força da palavra-passe: níveis de garantia de identidade como NIST IAL, eIDAS substancial e alto, ou NHS login P9 descrevem a força com que uma pessoa foi verificada no registo, enquanto a autenticação multifator e as passkeys descrevem cada início de sessão. Os clínicos são identificados através de identidades profissionais que são revogadas quando saem.
Uma aplicação para doentes que mostre um registo completo tem de saber que está a falar com esse doente. Os níveis de garantia de identidade (IAL da NIST, eIDAS substancial e alto, NHS login P9) descrevem quão fortemente a identidade foi verificada na inscrição; a força da autenticação (multi-fator, passkeys) descreve cada início de sessão. Hospitais e sistemas nacionais exigem cada vez mais identidades verificadas de esquemas reconhecidos em vez de registos auto-declarados, e a Carteira de Identidade Digital da UE tornar-se-á um meio aceite. Para médicos, a identidade profissional (e a sua revogação quando alguém sai) é o sistema de registo para quem pode atuar como médico.
Autorização: o consentimento torna-se âmbitos
A autorização num registo controlado pelo doente traduz o consentimento do doente, como permitir que uma clínica leia resultados de laboratório e condições durante 90 dias, em âmbitos OAuth e contexto do doente no token, na sintaxe SMART on FHIR como patient/Observation.rs, aplicada na camada de dados em cada pedido e revogada quando o doente retira. O "break-the-glass" é um caminho separado e auditado.
Num registo controlado pelo doente, o consentimento do doente é a política: esta clínica pode ler os meus resultados de laboratório e condições durante 90 dias. O sistema traduz isto em âmbitos OAuth e contexto (qual doente, quais recursos, quais operações) no token que o sistema da clínica recebe, aplica-os em cada pedido na camada de dados e revoga-os quando o doente retira. A sintaxe de âmbito do SMART on FHIR (patient/Observation.rs, patient/Condition.rs) é a língua franca para isto; âmbitos granulares (por categoria ou código) existem no SMART v2 para um controlo mais fino. O "break-the-glass" (acesso de emergência sem consentimento) é um caminho separado e auditado com justificação obrigatória e um alerta ao doente, nunca um padrão. Ver Plataforma de consentimento do doente.
Responsabilização: o registo que o doente lê
A responsabilização numa aplicação de saúde significa que cada acesso a um registo, por quem, quando, o quê e sob qual consentimento, é escrito num registo "append-only" que o doente pode ler na sua aplicação e numa trilha de auditoria organizacional em FHIR AuditEvent. A ISO 27799 trata isto como obrigatório, e um registo visível é o dissuasor mais forte contra a navegação interna.
Cada acesso a um registo, por quem, quando, o quê, sob qual consentimento, escrito num registo apenas de adição que o doente pode ler na sua aplicação, e num rasto de auditoria organizacional (FHIR AuditEvent) para as equipas de segurança. A ISO 27799 trata isto como obrigatório para informações de saúde; o princípio da transparência do GDPR e os direitos do doente do EHDS apontam na mesma direção; o maior dissuasor do mundo real para a navegação interna é um registo visível. Ver Quem viu o meu registo médico?.
Proteção: a base de engenharia
A base de engenharia para a proteção de dados de saúde é TLS em todo o lado, encriptação em repouso com chaves geridas e rotacionadas, encriptação ou tokenização separada para identificadores diretos, ambientes segregados com dados sintéticos fora da produção, acesso de privilégio mínimo com autenticação multifator para administradores, gestão de segredos e vulnerabilidades, cópias de segurança encriptadas testadas por restauração contra ransomware, e resposta a incidentes dentro dos prazos do GDPR e NIS2.
TLS em todo o lado, com cifras modernas e fixação de certificados em aplicações onde apropriado; encriptação em repouso com chaves num serviço de gestão de chaves e rotação; encriptação ou tokenização separada para identificadores diretos; segregação de produção de desenvolvimento, com dados sintéticos fora da produção; acesso de privilégio mínimo para o pessoal, sem contas partilhadas, multi-fator para todo o acesso administrativo; gestão de segredos; gestão de dependências e vulnerabilidades com divulgação; cópias de segurança encriptadas, testadas por restauro e protegidas contra o ransomware que atingiu hospitais e laboratórios repetidamente (WannaCry em 2017, o hospital de Düsseldorf em 2020, Change Healthcare e Synnovis em 2024). Resposta a incidentes com os relógios de 72 horas do GDPR e 24 horas da NIS2 num único plano de ação.
Ameaças específicas aos dados de saúde
As ameaças específicas aos dados de saúde são a navegação interna de registos de conhecidos, o arquivamento incorreto entre doentes, a partilha excessivamente ampla concedida por demasiado tempo, SDKs de publicidade dentro de aplicações que lidam com dados de saúde, injeção de documentos em funcionalidades de IA, e retenção longa ao longo de décadas durante as quais as chaves, formatos e regras de acesso devem sobreviver a pessoal e fornecedores.
- Navegação interna de registos de conhecidos ou figuras públicas: acesso baseado em relações e registos visíveis.
- Registo incorreto entre doentes: reconciliação de identidade e proveniência, não apenas controlo de acesso.
- Partilha excessivamente ampla: uma clínica que recebeu "tudo" por um ano; âmbitos e durações com padrões sensatos.
- Aplicações com SDKs de publicidade: sem rastreadores de terceiros em nada que manipule dados de saúde.
- Injeção em documentos em funcionalidades de IA: o conteúdo é dados, nunca instruções (RAG em registos médicos).
- Retenção longa: os registos vivem décadas; chaves, formatos e regras de acesso devem sobreviver ao pessoal e aos fornecedores.
Em Anpheros
A Anpheros aplica o mapa de segurança a si própria com OAuth 2.0 com PKCE para aplicações e autenticação de cliente assimétrica para backends, consentimento por propósito e duração como a origem do acesso de cada clínica, um registo de acesso por registo na aplicação da pessoa, encriptação em repouso e em trânsito, alojamento na UE, sem SDKs de publicidade, e um ISMS ao abrigo da ISO 27001 e 27799.
Anpheros aplica este mapa a si próprio: OAuth 2.0 com PKCE para aplicações e autenticação de cliente assimétrica para backends; consentimento por propósito e duração como a fonte de acesso de cada clínica, com revogação e sem "break-the-glass" silencioso; um registo de acesso por registo na aplicação da pessoa; encriptação em repouso e em trânsito, alojamento na UE, sem SDKs de publicidade; um ISMS segundo a ISO 27001 com os controlos de saúde 27799. O site do programador documenta autenticação, consentimento e segurança.
Páginas relacionadas
- SMART App Launch explicado
- Plataforma de consentimento do doente
- Quem viu o meu registo médico?
- SMART Health Links explicados
- ISO 27001 vs ISO 27799
- NIS2 para hospitais e fornecedores de tecnologia de saúde
- Segurança da plataforma (site do programador)
- Autenticação (site do programador)
Fontes
- HL7 SMART App Launch
- IETF: OAuth 2.1 (rascunho)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Recomendações de aquisição para cibersegurança em hospitais
Perguntas frequentes
O OAuth 2.1 é diferente do 2.0?
O OAuth 2.1 consolida o 2.0 com as suas melhores práticas de segurança: PKCE é obrigatório para todos os clientes, as concessões implícitas e de palavra-passe são removidas, os URIs de redirecionamento devem corresponder exatamente, e os tokens de atualização para clientes públicos devem ser vinculados ou rotacionados. O SMART on FHIR v2 já exige a maioria disto.
O que é "break-the-glass"?
Acesso de emergência a um registo sem o consentimento prévio do doente, por um médico que declara uma justificação. Deve ser raro, registado, revisto e comunicado ao doente; nunca é o caminho de acesso padrão.
Porque é que os doentes devem ver o registo de acesso?
Porque é o dissuasor mais forte de acesso inadequado e a expressão mais clara de controlo: a pessoa vê qual clínica leu o quê e quando, e pode revogar. A ISO 27799 e o EHDS apontam na mesma direção.
Preciso de um sistema de auditoria separado?
Precisa de um rasto de auditoria apenas de adição (FHIR AuditEvent ou equivalente) que a aplicação não possa alterar, retido de acordo com a política, e uma vista para o doente derivada dele. Se é um sistema separado ou um armazenamento protegido dentro da plataforma é uma escolha de implementação.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →