为什么80%的Healthcare AI试点在试点阶段失败：数据架构问题

Source: Dev.to

概览

医疗数据一团糟。你会看到电子健康记录（EHR）、实验室、药房、付款方以及各种供应商都在使用略有不同的“几乎是 FHIR、类似 HL7、随机 CSV、神秘 XML”方言。除此之外，还有重复数据、缺失字段以及只存在于某人脑中的业务规则。

在这种基础上再套上强大的大语言模型（LLM），并不会产生魔法。相反会出现不稳定行为、不安全的建议，以及永远停留在“酷炫内部演示”模式的项目。

阅读完整的《构建 AI‑ready 医疗数据架构的 6 步实用指南》

为什么大多数医疗 AI 项目停滞

• 数据碎片化、前后不一致，并且由部落知识而非明确规则进行治理。

现代医疗平台的核心层

1. FHIR 运营层 – 近实时临床工作流。
2. 仓库 / 湖仓 – 对去标识化数据进行分析和机器学习。
3. MDM / hMDM – 身份解析与黄金记录。
4. API + 访问控制 – 应用和 AI 如何触及数据。

让技术栈具备 AI‑ready 的六个步骤

1. 使用 FHIR‑first 持久化 作为规范模型。
2. 添加细粒度授权，比普通应用的 RBAC 更严格。
3. 为 LLM 提供工具 / 函数调用，而不是直接的原始 API 访问。
4. 加入检索增强生成（RAG），使答案基于患者数据。
5. ETL 到仓库，用于跨患者分析和机器学习。
6. 内置隐私与合规控制（令牌化、同意、日志、零保留 LLM）。

常见失败模式

1. 团队从模型出发（“把 GPT 集成到我们的 EHR！”）。
2. 快速原型在沙盒数据集上可运行。
3. 一旦触及真实数据和真实权限，所有东西就崩溃。

在近二十年为受监管行业构建软件的经验中，这种模式看起来更像是架构问题，而不是 AI 本身的问题。

典型阻碍因素

• 缺失或不一致的字段 → 风险误分类、错误分诊、“为什么答案这么离谱？”
• 患者和提供者的重复记录 → 病史破碎、不安全的建议。
• 系统之间冲突的业务规则 → AI 行为取决于你访问的来源。
• 相同概念的不同源格式 → 脆弱的 ETL、意外错误。

在电商应用中微不足道的数据小故障，在临床场景下可能导致错误的临床指导。这也是我们从数据基础而非模型开始的原因。

四层结构的详细视图

FHIR‑first 运营数据层

• 近实时临床数据。
• Patient、Observation、MedicationRequest、Encounter、Condition 等资源共享统一语义。
• 系统可以接入已知结构，而不是一次性自定义模式。

仓库 / 湖仓分析层

• Snowflake、BigQuery、Databricks 等。
• 已 ETL、标准化的数据用于人群健康仪表盘、纵向患者旅程、去标识化数据的预测模型、成本与质量分析。

MDM / hMDM（主数据管理）

• 跨患者、提供者、付款方和计划的身份统一。
• 生成“黄金记录”，确保上层不建立在不稳固的身份层之上。

API + 访问控制层

• 以可预测的方式暴露 REST / GraphQL / FHIR API。
• 集中处理权限逻辑、用途检查、脱敏/遮盖、审计以及字段级访问控制。
• 这也是 AI 系统应当进入的入口。

为什么 FHIR 对 AI 很重要

• 消除模式混乱 – 所有临床实体使用已定义的资源结构。
• 降低一次性映射 – 许多供应商已经提供 FHIR，或可以通过稳定管道转换为 FHIR。
• 让互操作性成为默认 – 医院、实验室、药房、付款方都接入同一结构。
• 提供可预测的输出 – 如 get_patient_observations() 函数始终返回 Observation 资源列表。
• 保持适应性 – 新模块或 AI 工具可以直接连接，无需重新设计数据模型。

其他医疗标准（供参考）

我们通常看到 FHIR 与 这些标准并行使用，而不是取代它们。FHIR 处理现代、API 驱动、以患者为中心的工作流；其他标准则负责归档、研究或监管场景。

示例：FHIR‑first 患者参与平台

• 服务器：HAPI FHIR 服务器，管理读写操作。
• 集成：通过 FHIR API 与外部 EHR 与药房系统同步。
• 权限：在资源层面强制（RBAC + 基于关系的规则 + FHIR 安全机制）。

影响

• 核心临床数据无需自定义模式 → 映射工作大幅减少。
• 多个应用（患者、提供者、管理员）可复用同一数据层。
• 访问控制自然与 FHIR 资源对齐。
• 当加入 AI 功能时，数据模型已经对 LLM 友好。

AI 助手的权限模型

让 AI 助手访问临床数据与构建普通 CRUD 应用截然不同。你需要一个考虑以下因素的权限模型：

• 用户特定访问 – 患者只能看到自己的记录；医生只能看到自己负责的在诊患者。
• 用途 – 治疗、研究、计费等不同场景。
• 情境规则 – 时限访问、“破窗”紧急覆盖。
• 完整审计 – 谁访问了哪些字段，为什么。

示例流程

1. 患者提问：“我的最近一次血液检查结果是什么？”
2. AI 识别并验证用户身份。
3. 授权层评估：该用户是患者本人吗？他们是否被允许查看自己的 Observation 资源？
4. 仅检索被授权的 FHIR 资源。
5. AI 用自然语言总结这些观察结果。

细粒度访问控制工具

• Permit.io、Permify – 开发者友好的 API。
• OPA / ABAC – 针对极其特定策略逻辑的自定义方案。

关键点： 所有 AI 查询都必须经过此层。模型永远不会“自由浏览”你的数据存储。

通过函数调用实现安全的 AI 交互

现代 LLM（OpenAI、Claude 等）支持 函数调用。与其让模型直接生成 SQL 或调用任意 URL，你应当暴露一小套工具函数。

可用后端

• FHIR 服务器（运营数据）
• 仓库 / 湖仓（分析）
• MDM（身份）
• API（访问）

示例函数工具箱

def get_patient_observations(patient_id: str, category: str) -> List[Observation]:
    ...

def get_patient_conditions(patient_id: str) -> List[Condition]:
    ...

def get_patient_medications(patient_id: str) -> List[MedicationRequest]:
    ...

def search_encounters(patient_id: str, date_range: Tuple[date, date]) -> List[Encounter]:
    ...

运行时流程

1. 用户提出问题。
2. LLM 从工具箱中选择合适的工具。
3. 工具使用你的授权层检查权限，根据需要查询 FHIR/MDM/仓库，并返回结构化数据。
4. LLM 基于结构化结果生成自然语言答案。

模型永远不会直接与 FHIR 存储或仓库对话；它始终通过你可控的薄层进行。这是你执行输入校验、日志记录和合规审查的地方。