医疗保健 AI 治理框架：HIPAA、FDA SaMD 与临床监督要求
面向医疗保健组织的实用 AI 治理框架。涵盖 HIPAA 合规、FDA 软件作为医疗器械要求、临床人在回路设计和审计追踪规范。
医疗保健中的 AI 不是一 个理论上的治理挑战。它是一个有具体标准、审计预期和责任影响的监管合规要求。部署 AI 的医疗保健组织面临多层监管环境：HIPAA 管辖数据处理，FDA 监管符合医疗器械定义的软件，而 EU AI Act 的高风险分类涵盖了在欧洲运营中使用的临床决策支持系统。
本框架涵盖医疗保健 AI 部署所需的治理结构、监督机制和文档实践。
监管环境：哪些法规适用于你的 AI 系统
在设计治理之前，确定哪些法规适用。
HIPAA 适用于 你的 AI 系统处理、存储或传输受保护健康信息（PHI）的情况。这包括接收患者数据作为输入（临床记录、影像元数据、实验室值）或产出包含 PHI 的输出的系统。HIPAA 的安全、隐私和违规通知规则都延伸到接触 PHI 的 AI 系统。
FDA 的软件作为医疗器械（SaMD）框架适用于 你的 AI 系统满足 21 USC 321(h) 下医疗器械定义的情况：旨在诊断、治愈、减轻、治疗或预防疾病，或影响身体结构或功能的软件。基于患者数据提供患者特定建议的临床决策支持软件通常符合条件。行政 AI（调度、计费、不含临床建议的文档摘要）通常不符合。
EU AI Act 的高风险分类适用于 旨在用于 EU 医疗器械法规覆盖的医疗器械和临床决策支持系统中的 AI 系统，部署在 EU 或面向 EU 患者。高风险分类要求风险管理系统、数据治理文档、对部署者的透明度、人工监督能力和在 EU 数据库中注册。
联合委员会和 CMS 标准 越来越多地在认证和认证标准中涉及 AI，特别是围绕临床决策支持治理和临床人员培训要求。
在构建治理结构之前，确定这些法规中哪些适用于你环境中的每个 AI 系统。这些框架的合规负担差异很大。
临床人在回路设计
对于为临床决策提供信息的 AI 系统，人在回路架构不是可选的治理——它是设计基线。每个临床 AI 部署必须回答三个结构性问题：
AI 为哪些决策提供信息？ 精确定义决策范围。"协助脓毒症风险分层「足够具体来设计治理。」协助临床决策制定"则太宽泛，在没有清晰性的情况下创造了责任。
谁在 AI 的输出影响患者护理之前审查它？ 确定负责审查的具体角色（主治医师、护士、药剂师）。审查者必须有临床权限来接受、修改或拒绝 AI 建议。如果审查输出的唯一人员就是输入数据的同一人，那不是有意义的监督。
当 AI 和临床医生意见不一致时会怎样？ 覆盖工作流与默认工作流同样重要。记录覆盖机制，要求在不遵循 AI 建议时记录临床理由，并跟踪覆盖模式作为质量信号。
置信度阈值和升级
设计良好的临床 AI 系统不会以相同方式呈现所有输出。在展示层构建置信度阈值：
- 高置信度输出（模型在其验证范围内运行）：呈现给负责临床医生，附带明确的建议行动
- 中等置信度输出（模型在其验证范围的边缘）：标记为需要临床医生明确审查后再行动
- 低置信度输出（分布外输入）：升级给高级临床医生或标记为仅人工评估，不将 AI 建议作为指导呈现
阈值校准应针对你的临床群体进行验证，而不仅仅是针对基准数据集。分布偏移是真实现象——在一家医院群体上训练的模型在另一家可能有不同的置信度特征。
AI 系统的 HIPAA 合规
AI 系统的 HIPAA 合规有几个标准数据处理框架未完全覆盖的组成部分。
最小必要标准
HIPAA 的最小必要标准（45 CFR §164.514）要求将 PHI 访问限制在完成预期目的所需的最小范围。对于 AI，这意味着：
- AI 系统应仅接收其实际需要执行功能的数据元素。脓毒症预测模型不需要患者的保险信息或计费代码。设计数据流水线只传递必要的字段。
- AI 系统本身的基于角色的访问控制：计费编码员应该能够查询 AI 获取编码协助，但不应该能够查询临床 AI 获取患者特定的临床评估。
- 查询级审计：每个包含 PHI 的 AI 查询必须用用户身份和允许查询的角色授权进行记录。
审计控制要求
HIPAA 的审计控制标准（45 CFR §164.312(b)）要求记录和检查包含 PHI 的系统中活动的机制。包含或处理 PHI 的 AI 系统必须产生审计级日志，包括：
- 查询时的用户身份和角色
- UTC 时间戳
- 查询中存在的数据元素（不一定是高容量系统的完整查询内容，但足以识别涉及的 PHI）
- 查询的模型版本
- 交付的输出
- 输出是否用于临床决策（如果你的系统捕获了这一点）
这些日志必须按你的 HIPAA 保留时间表保留，并且必须在违规调查或 OCR 审计中可提供。
商业伙伴协议
如果你的 AI 供应商代表你处理 PHI，HIPAA 要求签订商业伙伴协议（BAA）。这适用于：
- 接收含 PHI 的提示的云 AI API 提供商
- 在包含 PHI 的数据集上训练的微调平台
- 你的 AI 模型运行的推理托管提供商
如果你在 PHI 上微调并在本地部署，推理层不需要 BAA（你是自己的商业伙伴）。如果涉及第三方计算提供商，训练步骤需要。
FDA SaMD 治理要求
如果你的 AI 系统符合软件作为医疗器械的定义，FDA 治理要求在 HIPAA 之外还需要满足。
预定变更控制计划
FDA 的 AI/ML SaMD 指导强调预定变更控制计划（PCCP）——记录你将如何在初始批准后管理模型更新、再训练和性能变化。PCCP 应描述：
- 触发模型审查的性能指标和阈值
- 评估模型变更是否构成需要新监管提交的修改的流程
- 部署再训练模型前的临床验证要求
- 如何向临床用户传达变更
对于你拥有的微调模型：你控制再训练流程，记录它。对于基于云 API 的系统：你的 PCCP 必须考虑供应商的模型更新实践，这可能超出你的控制——这是许多 SaMD 开发者倾向于自有模型基础设施的原因之一。
算法透明度
FDA 关于 AI/ML-based SaMD 的指导包含透明度要求。临床用户和临床决策者必须能够访问：
- AI 在做什么（其临床功能）
- 它在什么数据上训练（在类别层面）
- 其已知的性能特征（按相关子组的准确率、灵敏度、特异度）
- 其已知的局限性（性能较低的患者群体、模型可能表现不佳的输入条件）
这些信息应记录在模型卡中，并让使用系统的临床人员可以访问。
上市后监测
SaMD 要求上市后监测计划。对于 AI 系统，这意味着跟踪：
- 模型性能与真实世界临床结果的对比（而不仅仅是在保留数据上的预测与观察对比）
- AI 可能导致临床错误的不良事件报告
- 覆盖模式作为性能信号
- 人口统计性能监控用于偏见检测
医疗保健 AI 审计追踪规范
医疗保健 AI 审计追踪必须捕获足够的信息来重建每个 AI 影响的临床决策。每次查询的最少记录：
| 字段 | 值 |
|---|---|
| 事件 ID | 每次查询的唯一标识符 |
| 时间戳 | UTC，毫秒精度 |
| 用户 ID | 链接到 HR/资质认证系统 |
| 用户角色 | 查询时的授权角色 |
| 患者 ID | 按日志策略去标识化或假名化 |
| 包含的数据元素 | 类别（实验室、生命体征、记录），日志中不含完整 PHI |
| 模型 ID | 具体模型版本和适配器版本 |
| 交付的输出 | 呈现给临床医生的建议 |
| 临床医生行动 | 接受 / 修改 / 拒绝（如已捕获） |
| 覆盖原因 | 自由文本（如已拒绝并捕获） |
保留期限：HIPAA 对覆盖实体的最低要求是 6 年。各州法律可能延长。EU AI Act 高风险系统要求 10 年日志保留。
治理委员会结构
医疗保健 AI 治理需要跨职能问责。最小可行治理委员会包括：
临床倡导者：能够评估 AI 建议临床有效性的医生或高级实践提供者，并作为治理与使用系统的临床人员之间的联络人。
合规官或隐私官：负责每个 AI 部署的 HIPAA 和监管合规审查。
信息安全：负责 AI 基础设施的访问控制、审计日志完整性和数据安全。
法律顾问：审查 FDA 监管状态、供应商合同（BAA、赔偿条款）和责任影响。
IT/工程：负责基础设施、模型部署和日志实施。
该委员会应至少每季度召开会议，并在每次新 AI 部署、模型更新或 AI 范围发生重大变更之前召开。
医疗保健 AI 的本地基础设施
对 PHI 处理有严格要求的医疗保健组织有结构性原因倾向于本地 AI 推理。当 AI 模型在你的基础设施上运行时：
- PHI 永远不会离开你的网络到达云 API 端点
- 你现有的网络访问控制适用于 AI 系统
- 你的审计日志基础设施以与捕获任何其他临床系统查询相同的方式捕获 AI 查询
- 你不依赖与第三方推理提供商的 BAA 来处理每个生产查询
部署模式：使用去标识化或合成训练数据在云 GPU 上微调，导出为 GGUF 格式，通过 Ollama 或 llama.cpp 在你的临床网络上本地部署推理。云用于训练，本地用于推理。
Ertas Data Suite 完全在 你的基础设施上运行——操作期间无数据外泄、无云推理调用，并记录每个处理步骤及操作员身份。对于 PHI 处理不可妥协的医疗保健组织，本地架构是使 AI 治理可行的基础。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $25/mo USD.
