Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
Solicitudes de acceso de clínicas con aprobación del paciente (CIBA)
El flujo OpenID CIBA detrás de las solicitudes de acceso de clínicas: la recepción introduce el correo electrónico del paciente, el paciente aprueba en la aplicación o por correo electrónico durante 30, 90 o 365 días, y la aplicación de la clínica recibe tokens.
Una clínica accede al registro de un paciente en Anpheros solo cuando el paciente lo aprueba. La aplicación de la clínica envía una solicitud nombrando la dirección de correo electrónico del paciente y el acceso que necesita. El paciente la recibe en la aplicación Anpheros y por correo electrónico, ve quién está solicitando y para qué, elige cuánto tiempo permitirlo y aprueba o rechaza. Si aprueba, la aplicación de la clínica recibe tokens y puede leer el registro hasta que expire el acceso o el paciente lo retire.
El flujo es el flujo estándar de OpenID Connect Client-Initiated Backchannel Authentication (CIBA), en modo de sondeo (poll mode). Existe para que un recepcionista no necesite entregarle al paciente un teléfono o un enlace: la solicitud va al paciente, no a través de la pantalla de la clínica.
Paso a paso
- Recepción introduce el correo electrónico del paciente. La aplicación de la clínica llama a
POST /oauth/bc-authorizecon sus credenciales de cliente, el correo electrónico del paciente comologin_hint, elscopeque necesita y un brevebinding_messageque verá el paciente. - La plataforma responde de la misma manera para cada dirección. La respuesta contiene un
auth_req_id, una fecha de caducidad y un intervalo de sondeo, independientemente de si ese correo electrónico tiene una cuenta de Anpheros. No revela quién tiene un registro. Una solicitud para una persona sin cuenta simplemente caduca. - El paciente decide. Recibe una notificación en la aplicación Anpheros y un correo electrónico. La solicitud muestra la organización, el alcance y el mensaje. Eligen un período de 30, 90 o 365 días y pulsan permitir o rechazar. El enlace en el correo electrónico no aprueba nada cuando se abre, porque los escáneres de correo abren enlaces; el paciente tiene que pulsar el botón.
- La clínica sondea. La aplicación llama a
POST /oauth/tokencon el tipo de concesiónurn:openid:params:grant-type:cibay elauth_req_id. Mientras el paciente no haya decidido, la respuesta esauthorization_pending. Después de la aprobación, los tokens se devuelven una vez. Un rechazo devuelveaccess_deniedy una solicitud sin respuesta devuelveexpired_token. - La clínica lee y escribe dentro del alcance concedido. Cada lectura se registra y es visible para el paciente. Una clínica solo puede modificar o eliminar lo que ella misma escribió.
Qué protege al paciente
- Solo correo electrónico verificado. Una solicitud solo coincide con una cuenta cuyo correo electrónico está verificado, por lo que nadie puede recibir solicitudes de otra persona creando una cuenta con su dirección.
- Con alcance y tiempo limitado. El acceso es por tipo de recurso y acción, durante un período establecido. Una solicitud a la que nadie responde caduca en un día por defecto y en un máximo de siete días.
- Revocable en cualquier momento. La revocación surte efecto en la siguiente solicitud. La clínica no puede volver a acceder.
- Visible. El paciente ve cada conexión y cada acceso en la aplicación. Consulte modelo de consentimiento y acceso.
Lo que una clínica necesita para construir
- Un cliente OAuth confidencial registrado en la plataforma, con su secreto guardado en el servidor.
- Un bucle de sondeo que respete el intervalo y maneje los cuatro resultados.
- Una forma de mostrar la decisión del paciente a recepción ("esperando al paciente", "aprobado hasta el …", "rechazado").
- Manejo de los tokens devueltos como credenciales de corta duración: los tokens de acceso duran 30 minutos y los tokens de actualización rotan en cada uso. Ver autenticación y OAuth.
Para una clínica que prefiere abrir una página de consentimiento delante del paciente, por ejemplo en el mostrador, también se admite el flujo estándar de código de autorización con PKCE y lanzamiento independiente de SMART on FHIR.
Preguntas frecuentes
¿Tiene que estar el paciente en la clínica?
No. Pueden aprobar desde su propio teléfono o desde el enlace del correo electrónico, dondequiera que estén. Por lo tanto, se puede enviar una solicitud antes de la cita, y un paciente que esté en el extranjero aún puede aprobarla.
¿Qué pasa si el paciente no tiene cuenta de Anpheros?
La solicitud se acepta y luego expira sin una decisión, y la clínica no puede saber si existe una cuenta. El paciente puede crear una cuenta y la clínica puede enviar una nueva solicitud.
¿Cuánto dura el acceso?
El paciente elige 30, 90 o 365 días cuando aprueba. Pueden retirarlo antes.
¿Puede la clínica ver todo en el registro?
Solo el alcance que el paciente aprobó. Los alcances se establecen por tipo de recurso y acción, y se pueden filtrar por categoría.
¿Es el flujo de solicitud un estándar?
Sí. Es OpenID Connect CIBA, por lo que se pueden utilizar bibliotecas OAuth existentes. Consulte la guía API de salud con consentimiento del paciente para obtener el modelo más amplio.
¿Está esto en producción?
Sí, en la plataforma en beta privada. El acceso a producción requiere una organización verificada y un acuerdo de procesamiento de datos firmado.
Relacionado
- Una plataforma de datos de pacientes para clínicas y hospitales
- Plataforma de consentimiento del paciente para aplicaciones de salud
- Cómo implementar el consentimiento del paciente con SMART on FHIR
- Seguridad, privacidad y residencia de datos
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card