Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
API de salud con consentimiento del paciente
Cómo el paciente otorga acceso a un registro a través de ámbitos y duraciones de OAuth 2.1, registrado y revocable, qué cambia en el diseño de una aplicación y cómo las IDs emparejadas mantienen las aplicaciones separadas.
Una API de salud con consentimiento del paciente es aquella en la que el acceso a un registro es concedido por el paciente, para un propósito, por un tiempo, y puede ser visto y retirado por el paciente, en lugar de ser decidido una vez por la organización que posee los datos. En Anpheros, el consentimiento no es un campo que se establece; es el mecanismo a través del cual una aplicación accede a un registro. Esta guía explica cómo funciona para un desarrollador y qué cambios implica en el diseño de una aplicación.
Dos formas de acceder a un registro
| Acceso de la organización | Acceso concedido por el paciente | |
|---|---|---|
| Quién autoriza | su organización, a través de una clave API | el paciente, a través de una pantalla de consentimiento OAuth 2.1 |
| Uso típico | una clínica o laboratorio que escribe resultados, su propia aplicación que escribe en nombre de sus usuarios | una aplicación de terceros, un asistente de IA, una herramienta para médicos, un familiar |
| Alcance | los pacientes que su organización creó o que se compartieron con ella | los alcances que el paciente aceptó (patient/Observation.read, …) |
| Duración | mientras la clave sea válida | la duración que el paciente eligió; renovable, revocable |
| Visible para el paciente | sí, en el registro de acceso | sí, con la capacidad de revocar |
Ambas vías pasan por la misma API y el mismo registro FHIR. La diferencia es quién tiene la llave de la puerta.
El flujo de consentimiento, paso a paso
- Su aplicación envía al paciente al endpoint de autorización de Anpheros con los ámbitos (scopes) que necesita y una razón en lenguaje claro.
- El paciente ve lo que solicita, elige una duración y acepta o rechaza. La pantalla está en el idioma del paciente.
- Recibe un token de acceso limitado a esos ámbitos y a ese paciente. Los tokens tienen una vida útil corta; los tokens de actualización duran tanto como el consentimiento.
- Cada lectura y escritura con ese token se registra con el nombre de su aplicación. El paciente ve el registro en su aplicación.
- Si el paciente retira el consentimiento, la siguiente solicitud falla con un error claro. Recibe una webhook para que pueda realizar la limpieza.
El flujo es OAuth 2.1 estándar con PKCE y ámbitos SMART on FHIR, por lo que las bibliotecas existentes funcionan. La guía Authentication and OAuth tiene los parámetros exactos y el Consent and access model las reglas detrás de él.
Qué cambia en tu aplicación
- Pides menos. Los alcances son por tipo de recurso y por dirección. Una aplicación que registra el peso solicita
Observation.read, no el registro completo. - Diseñas para la retirada. El acceso puede terminar en cualquier momento. Guarda en caché poco, relee cuando sea necesario y maneja el error de revocación como un estado normal.
- Obtienes confianza gratis. Los pacientes ven el nombre de tu aplicación, a qué puede acceder y cuándo leyó algo por última vez. Las aplicaciones que se comportan bien son más fáciles de aceptar.
- Escribes con procedencia. Todo lo que escribes lleva tu aplicación como autor y, cuando sea relevante, la persona en cuyo nombre. El paciente y otras aplicaciones pueden distinguir tus datos de los suyos.
Identificadores que no filtran información
Cada aplicación ve a un paciente bajo un identificador por pares: la misma persona tiene un ID diferente en tu aplicación y en otra. Dos aplicaciones no pueden unir sus datos sobre una persona sin el consentimiento del paciente, incluso si ambas están construidas sobre Anpheros. Para tu código esto es invisible; para el paciente es la diferencia entre consentimiento y una formalidad.
Familias y cuidadores
El consentimiento se extiende a las personas que gestionan registros para otros: un padre para un hijo, un hijo adulto para un padre anciano. El registro permanece con la cuenta que lo creó; otras cuentas reciben acceso, que puede ser revocado. Su aplicación ve el mismo mecanismo de consentimiento, con el cuidador como la persona que acepta.
Relacionado
- Modelo de consentimiento y acceso
- Autenticación y OAuth
- Backend de SMART on FHIR
- API de Salud
- Seguridad, privacidad y residencia de datos
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card