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

诊所访问请求（患者批准，CIBA）

Q: 请求流程是标准化的吗？

是的。它是 OpenID Connect CIBA，因此可以使用现有的 OAuth 库。有关更广泛的模型，请参阅 带有患者同意的医疗保健 API 指南。

诊所访问请求背后的 OpenID CIBA 流程：接待人员输入患者的电子邮件，患者在应用程序或通过电子邮件批准 30、90 或 365 天的访问权限，诊所的应用程序将收到令牌。

诊所只有在患者批准后才能访问 Anpheros 上的患者记录。 诊所的应用程序会发送一个请求，其中包含患者的电子邮件地址和所需的访问权限。患者会在 Anpheros 应用程序和电子邮件中收到该请求，可以看到谁在请求以及请求什么，选择允许的时间长度，然后批准或拒绝。如果患者批准，诊所的应用程序将收到令牌，并且可以在访问过期或患者撤销访问权限之前读取记录。

该流程是标准的 OpenID Connect Client-Initiated Backchannel Authentication (CIBA) 流程，采用轮询模式。它的存在是为了让接待人员无需将手机或链接交给患者：请求会发送给患者，而不是通过诊所的屏幕。

逐步指南

前台录入患者邮箱。 诊所的应用程序使用其客户端凭据调用 POST /oauth/bc-authorize，将患者邮箱作为 login_hint，所需的 scope 以及患者将看到的简短 binding_message。
平台对每个地址的响应方式相同。 响应包含一个 auth_req_id、一个有效期和一个轮询间隔，无论该邮箱是否拥有 Anpheros 账户。它不会透露谁拥有记录。对没有账户的个人的请求将简单地过期。
患者决定。 患者会在 Anpheros 应用和电子邮件中收到通知。请求会显示组织、范围和消息。他们选择 30、90 或 365 天的期限，然后按“允许”或“拒绝”。电子邮件中的链接在打开时不会批准任何内容，因为邮件扫描程序会打开链接；患者必须按下按钮。
诊所进行轮询。 应用程序调用 POST /oauth/token，并提供 grant type urn:openid:params:grant-type:ciba 和 auth_req_id。当患者尚未决定时，响应为 authorization_pending。批准后，令牌将返回一次。拒绝将返回 access_denied，未答复的请求将返回 expired_token。
诊所根据授予的范围进行读取和写入。 每次读取都会被记录并对患者可见。诊所只能更改或删除自己写入的内容。

患者受何保护

仅限已验证的电子邮件。 请求仅匹配已验证电子邮件的账户，因此没有人可以通过创建他人地址的账户来接收他人的请求。
作用域和时间限制。 访问权限按资源类型和操作进行，并在规定时间内有效。默认情况下，无人响应的请求会在一天内过期，最长不超过七天。
可随时撤销。 撤销在下次请求时生效。诊所无法通过刷新方式重新获得访问权限。
可见。 患者在应用程序中可以看到每一次连接和每一次访问。请参阅同意和访问模型。

诊所需要构建的内容

在平台上注册一个机密的 OAuth 客户端，其密钥保存在服务器上。
一个尊重间隔并处理四种结果的轮询循环。
一种向接待处显示患者决定的方式（“等待患者”、“批准至……”、“拒绝”）。
处理返回的令牌作为短期凭证：访问令牌有效期为 30 分钟，刷新令牌在每次使用时都会轮换。请参阅身份验证和 OAuth。

对于倾向于在患者面前打开同意页面的诊所（例如在前台），也支持使用 PKCE 和 SMART on FHIR 单独启动的标准授权码流程。

常见问题解答

患者是否必须在诊所？

否。他们可以在任何地方通过自己的手机或电子邮件链接进行批准。因此，可以在预约前发送请求，即使患者在国外也可以批准。

如果患者没有 Anpheros 账户怎么办？

请求将被接受，然后无决定地过期，诊所无法得知账户是否存在。患者可以创建一个账户，诊所可以发送新的请求。

访问权限持续多久？

患者在批准时选择 30、90 或 365 天。他们可以提前撤销。

诊所可以看到记录中的所有内容吗？

仅限于患者批准的范围。范围是按资源类型和操作设置的，并且可以按类别进行过滤。

请求流程是标准化的吗？

是的。它是 OpenID Connect CIBA，因此可以使用现有的 OAuth 库。有关更广泛的模型，请参阅带有患者同意的医疗保健 API 指南。

这是实时运行的吗？

是的，在私有 Beta 版的平台上。生产环境访问需要经过验证的组织和已签署的数据处理协议。