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

API de saúde com consentimento do paciente

Como o acesso a um registo é concedido pelo paciente através de âmbitos e durações OAuth 2.1, registado e revogável, o que muda no design de uma aplicação e como os IDs par a par mantêm as aplicações separadas.

Uma API de saúde com consentimento do paciente é aquela em que o acesso a um registo é concedido pelo paciente, para um propósito, por um tempo, e pode ser visto e retirado pelo paciente, em vez de ser decidido uma vez pela organização que detém os dados. Na Anpheros, o consentimento não é um campo que se define; é o mecanismo através do qual uma aplicação acede a um registo. Este guia explica como isso funciona para um programador e o que muda no design de uma aplicação.

Duas formas de aceder a um registo

Ambos os caminhos passam pela mesma API e pelo mesmo registo FHIR. A diferença reside em quem detém a chave da porta.

O fluxo de consentimento, passo a passo

1. A sua aplicação envia o paciente para o endpoint de autorização Anpheros com os escopos de que necessita e um motivo em linguagem clara.
2. O paciente vê o que solicita, escolhe uma duração e aceita ou recusa. O ecrã está no idioma do paciente.
3. Recebe um token de acesso limitado a esses escopos e a esse paciente. Os tokens têm curta duração; os tokens de atualização duram tanto quanto o consentimento.
4. Cada leitura e escrita com esse token é registada com o nome da sua aplicação. O paciente vê o registo na sua aplicação.
5. Se o paciente retirar o consentimento, o próximo pedido falha com um erro claro. Recebe um webhook para que possa efetuar a limpeza.

O fluxo é OAuth 2.1 padrão com PKCE e escopos SMART on FHIR, pelo que as bibliotecas existentes funcionam. O guia Autenticação e OAuth tem os parâmetros exatos e o Modelo de consentimento e acesso as regras subjacentes.

O que muda na sua aplicação

• Pede menos. Os escopos são por tipo de recurso e por direção. Uma aplicação que regista o peso pede Observation.read, não o registo completo.
• Projeta para a revogação. O acesso pode terminar a qualquer momento. Armazene em cache o mínimo possível, releia quando necessário e trate o erro de revogação como um estado normal.
• Obtém confiança gratuitamente. Os pacientes veem o nome da sua aplicação, o que ela pode aceder e quando leu algo pela última vez. As aplicações que se comportam bem são mais fáceis de aceitar.
• Escreve com proveniência. Tudo o que escreve carrega a sua aplicação como autor e, quando relevante, a pessoa em nome de quem. O paciente e outras aplicações podem distinguir os seus dados dos deles.

Identificadores que não vazam

Cada aplicação vê um paciente sob um identificador par: a mesma pessoa tem um ID diferente na sua aplicação e noutra. Duas aplicações não podem juntar os seus dados sobre uma pessoa sem o consentimento do paciente, mesmo que ambas sejam construídas sobre Anpheros. Para o seu código isto é invisível; para o paciente é a diferença entre consentimento e uma formalidade.

Famílias e cuidadores

O consentimento estende-se a pessoas que gerem registos para terceiros: um progenitor para um filho, um filho adulto para um pai idoso. O registo permanece com a conta que o criou; outras contas recebem acesso, que pode ser revogado. A sua aplicação vê o mesmo mecanismo de consentimento, com o cuidador como a pessoa que aceita.

Relacionado

• Modelo de consentimento e acesso
• Autenticação e OAuth
• Backend SMART on FHIR
• API de Saúde
• Segurança, privacidade e residência de dados

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