简短回答： 健康应用中的安全性通过四个问题来回答，按顺序。这是谁？ 身份：通过 OpenID Connect 验证的用户（患者、临床医生、系统），以及针对临床医生，国家专业身份；验证级别比密码强度更重要。他们可以做什么？ 授权：OAuth 2.0（转向 2.1）令牌，带有 SMART on FHIR 语法的 范围，源自 患者的同意，用于特定目的和持续时间，并在数据层强制执行。他们做了什么？ 问责制：患者可以阅读的 访问日志 和组织的 FHIR AuditEvent 记录。数据在存储、传输和备份中是否安全？ 保护：加密、密钥管理、隔离、经过测试的恢复。围绕这些：ISO 27001 和 27799、NIS2 和 HIPAA 安全规则的基线，以及健康数据的特定威胁（内部人员浏览、错误归档、勒索软件）。
路线图
健康应用中的安全和身份包含七个层面：通过 OpenID Connect 和国家/专业身份进行身份验证，通过 OAuth 2.0 和 SMART on FHIR 范围进行授权，同意作为每次授权的来源，通过访问日志和 FHIR AuditEvent 进行问责，通过加密和备份进行保护，以 ISO 27001、ISO 27799、NIS2 和 HIPAA 为基线，以及由患者发起的共享。
| 层级 | 标准或实践 | 作用 | 页面 |
|---|---|---|---|
| 身份 | OpenID Connect；国家身份（eIDAS、NHS 登录、GesundheitsID）；专业身份（eHBA、CPS、UZI） | 提供一个经过验证的主体，并带有保证级别 | SMART App Launch 详解 |
| 授权 | OAuth 2.0 和 2.1（强制要求 PKCE，无隐式或密码授权）；SMART on FHIR 范围（patient/Observation.rs）；带有非对称客户端身份验证的后端服务 | 绑定到用户、患者上下文和范围的令牌 | SMART App Launch 详解, SMART on FHIR 后端 |
| 同意 | FHIR Consent；按目的和时间绑定的授权；撤销；带有理由和警报的紧急访问（break-the-glass） | 患者是所有授权的来源 | 患者同意平台, 诊所访问请求 |
| 问责制 | 患者可见的每条记录访问日志；FHIR AuditEvent；防篡改存储；保留 | 谁在何时、为何查看了什么 | 谁查看了我的病历？ |
| 保护 | TLS 1.2+，静态加密（带托管密钥），标识符的字段级加密，隔离的环境，经过测试恢复的备份 | 机密性和可用性 | ISO 27001 vs ISO 27799 |
| 基线 | ISO 27001 ISMS，27799 健康控制，NIS2 措施，HIPAA 安全规则，国家计划（HDS、DSPT、C5） | 医院、审计员和监管机构的期望 | NIS2 适用于医院和供应商, HIPAA vs GDPR |
| 共享 | SMART Health Links 和 Cards；可验证凭证 | 患者发起的链接或 QR 码共享，可撤销 | SMART Health Links 详解 |
身份：比密码更重要的保证级别
健康应用的身份识别依赖于保证级别而非密码强度：身份保证级别，如 NIST IAL、eIDAS 的 substantial 和 high，或 NHS login P9，描述了在注册时对个人的验证强度，而多因素身份验证和通行密钥则描述了每次登录。临床医生通过专业身份进行识别，并在他们离职时被吊销。
显示完整病历的患者应用程序必须知道它正在与该患者通信。身份保证级别（NIST 的 IAL、eIDAS 的实质性和高级别、NHS 登录的 P9）描述了在注册时身份验证的强度；身份验证强度（多因素、通行密钥）描述了每次登录。医院和国家系统越来越多地要求来自认可计划的经过验证的身份，而不是自行声明的注册，并且欧盟数字身份钱包将成为一种被接受的手段。对于临床医生来说，专业身份（以及在某人离职时撤销该身份）是关于谁可以作为临床医生行事的记录系统。
授权：同意转化为范围
患者控制记录中的授权将患者的同意，例如允许诊所读取 90 天的实验室结果和病史，转化为 OAuth 范围和令牌上的患者上下文，以 SMART on FHIR 语法表示，如 patient/Observation.rs，在数据层对每个请求强制执行，并在患者撤销同意时被吊销。Break-the-glass 是一种单独的、经过审计的路径。
在患者控制的记录中，患者的同意是策略：这家诊所可以在 90 天内读取我的实验室结果和病史。系统将其转换为OAuth 范围和上下文（哪个患者、哪些资源、哪些操作），这些信息包含在诊所系统收到的令牌中，并在数据层强制执行于每个请求，并在患者撤销时撤销。SMART on FHIR 的范围语法（patient/Observation.rs、patient/Condition.rs）是实现这一点的通用语言；SMART v2 中存在（按类别或代码划分的）细粒度范围，以实现更精细控制。紧急访问（break-the-glass）（在未经同意的情况下紧急访问）是一个单独的、经过审计的路径，需要强制提供理由并向患者发出警报，绝不能作为默认选项。请参阅 患者同意平台。
问责制：患者阅读的日志
健康应用中的问责制意味着对记录的每一次访问，包括访问者、时间、内容和依据的同意，都会被记录在一个患者可以在其应用中阅读的不可追加日志中，以及一个 FHIR AuditEvent 中的组织审计跟踪。ISO 27799 将此视为强制性要求，而可见的日志是阻止内部人员浏览的最强有力的威慑。
对记录的每一次访问，由谁、何时、访问了什么、在什么同意下进行的，都将写入一个只能追加的日志，患者可以在其应用程序中阅读，并写入一个供安全团队使用的组织审计跟踪（FHIR AuditEvent）。ISO 27799 将此视为健康信息的强制要求；GDPR 的透明度原则和 EHDS 的患者权利也指向同一方向；内部人员浏览的最大实际威慑力是可见的日志。请参阅 谁查看了我的病历？。
保护：工程基线
保护健康数据的工程基线是：处处使用 TLS，静态加密（使用托管的、轮换的密钥)，对直接标识符进行单独加密或标记化，将生产环境之外的合成数据隔离在独立的环境中，对管理员实施具有多因素身份验证的最小权限访问，进行密钥和漏洞管理，对加密备份进行恢复测试以防范勒索软件，并在 GDPR 和 NIS2 的规定时间内进行事件响应。
处处使用 TLS，带有现代密码和适当的应用程序证书固定；静态加密（使用托管密钥服务和轮换）；直接标识符的单独加密或令牌化；生产环境与开发环境隔离，生产环境外使用合成数据；员工的最小权限访问，无共享账户，所有管理员访问都使用多因素身份验证；秘密管理；依赖项和漏洞管理及披露；加密的备份，通过恢复进行测试，并能抵御反复攻击医院和实验室的勒索软件（2017 年的 WannaCry、2020 年的杜塞尔多夫医院、2024 年的 Change Healthcare 和 Synnovis）。事件响应，将 72 小时的 GDPR 和 24 小时的 NIS2 时钟集成到同一个运行手册中。
健康数据特有的威胁
健康数据特有的威胁包括：内部人员浏览熟人记录，患者之间错填信息，授予时间过长的过度广泛的共享，应用内处理健康数据的广告 SDK，注入到 AI 功能中的文档传播，以及长达数十年的数据保留期，在此期间密钥、格式和访问规则必须比员工和供应商更长久。
- 内部人员浏览熟人或公众人物的记录：基于关系的访问和可见的日志。
- 患者之间的错误归档：身份协调和来源追溯，而不仅仅是访问控制。
- 过度广泛的共享：一家诊所获得了一年的“所有权限”；具有合理默认值的范围和持续时间。
- 带有广告 SDK 的应用程序：任何处理健康数据的应用程序中都不得包含第三方跟踪器。
- 文档中注入到 AI 功能中：内容是数据，不是指令（在病历上使用 RAG）。
- 长期保留：记录保存数十年；密钥、格式和访问规则必须能够经受住员工和供应商的更替。
在 Anpheros 中
Anpheros 将安全地图应用于自身，采用 OAuth 2.0 和 PKCE 用于应用，以及非对称客户端身份验证用于后端，按目的和持续时间进行同意作为每次诊所访问的来源，在个人应用中进行每条记录的访问日志，静态和传输中的加密，欧盟托管，无广告 SDK，以及符合 ISO 27001 和 27799 的 ISMS。
Anpheros 将此路线图应用于自身：OAuth 2.0（用于应用程序的 PKCE 和用于后端的非对称客户端身份验证）；按目的和持续时间进行同意，作为每个诊所访问的来源，并具有撤销功能，且无静默的紧急访问；患者应用程序中的每条记录访问日志；静态和传输中加密，欧盟托管，无广告 SDK；符合 ISO 27001 并包含 27799 健康控制的 ISMS。开发者网站记录了 身份验证、同意 和 安全性。
相关页面
- SMART App Launch 详解
- 患者同意平台
- 谁查看了我的病历？
- SMART Health Links 详解
- ISO 27001 vs ISO 27799
- NIS2 适用于医院和健康科技供应商
- 平台安全性（开发者网站）
- 身份验证（开发者网站）
来源
- HL7 SMART App Launch
- IETF: OAuth 2.1 (草案)
- 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: 医院网络安全采购指南
常见问题
OAuth 2.1 与 2.0 有何不同？
OAuth 2.1 整合了 2.0 及其安全最佳实践：所有客户端都必须使用 PKCE，移除了隐式授权和密码授权，重定向 URI 必须完全匹配，并且公共客户端的刷新令牌必须绑定或轮换。SMART on FHIR v2 已要求其中大部分。
什么是紧急访问（break-the-glass）？
在未经患者事先同意的情况下，由临床医生声明理由后对记录进行的紧急访问。这种访问必须是罕见的，必须记录、审查并报告给患者；它绝不能是默认的访问路径。
为什么患者应该看到访问日志？
因为它能最有效地阻止不当访问，并且是控制权最清晰的体现：患者可以看到哪个诊所何时读取了什么信息，并可以撤销访问。ISO 27799 和 EHDS 也指向同一方向。
我需要一个单独的审计系统吗？
您需要一个应用程序无法修改的、只能追加的审计跟踪（FHIR AuditEvent 或同等功能），该跟踪需要根据策略进行保留，并提供一个从中派生的面向患者的视图。它是一个单独的系统还是平台内受保护的存储库，这是一个实现选择。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →