处方工作台里，Agent 给出一句：“可使用，注意监测。”
药师没有点确认，追了三个问题：适应证是哪一个？剂量范围来自哪条证据？患者肾功能落在哪个分层？
用药风险常出现在检索成功之后。说明书、指南、药物知识库原本带有适应证、人群、剂量单位、禁忌证、相互作用、证据等级。生成阶段把这些限定压成一句结论，系统看起来会回答，责任却被推给最后审核的人。
海外已经出现 FDB MedProof MCP 这类面向 Agent workflow 的药物知识库信号，应用场景指向处方审核、用药安全提醒、患者沟通。技术问题很具体：搜到材料后，系统能不能保住限定条件。
图1：处方工作台上的证据卡。Agent 输出被拆成 indication、dose、contraindication、interaction、population、renal_adjustment、evidence_level、knowledge_version
普通 RAG 会把用药证据切碎
企业知识库常见做法是 chunk、向量召回、模型总结。放进用药场景，很快出问题。
药品说明书和指南的语义单位经常跨段落。一个“适用于某疾病”的结论，后面可能跟着年龄限制、妊娠状态、肾功能分层、合并用药风险、疗程和监测项。chunk 切在中间，召回文本仍然相关，生成答案却漏了限制。
剂量字段更容易出事故。mg、mg/kg、每日总量、单次用量、起始剂量、最大剂量，单位和频次只要被改写，下游就可能误认为系统给出了可执行处方。医疗 AI 在这里只能作为证据入口、文献追踪和研究审计工具，不能替代医生诊断、药师审核或医疗机构决策。
| 方案 | 输出形态 | 字段校验失败时的行为 |
|---|---|---|
| 普通 RAG 摘要 | “该药可用于某疾病，注意监测” | 继续生成，缺失条件被自然语言掩盖 |
| 结构化证据包 | indication、dose、population、interaction、renal_adjustment 分字段返回 | 停止给出处方动作，展示缺失字段、冲突来源和复核原因 |
一个最小接口可以把责任分清：Knowledge MCP 返回事实，规则层做 claim_check，LLM 读取证据并生成摘要，不改写剂量单位、证据等级和风险标签。
{
"request": {
"drug_code": "RxNorm_or_ATC",
"task": "medication_evidence_check",
"patient_context": {
"age": "number_or_unknown",
"diagnosis": ["ICD_or_SNOMED"],
"allergy": ["coded_or_text"],
"renal_function": "value_or_unknown",
"hepatic_function": "value_or_unknown",
"pregnancy_status": "unknown",
"current_medications": ["RxNorm_or_ATC"]
}
},
"knowledge_mcp_fact": {
"indication": "scoped_text",
"dose": {"range": "text", "unit": "preserved", "frequency": "text"},
"contraindication": ["scoped_text"],
"interaction": ["scoped_text"],
"population": ["scoped_text"],
"renal_adjustment": "scoped_text",
"evidence_level": "label",
"source_id": "id",
"knowledge_version": "YYYY-MM-DD"
},
"rule_claim_check": {
"missing_context": ["renal_function"],
"risk_level": "pharmacist_review",
"allowed_output": "evidence_summary_only"
},
"llm_policy": {
"read_only_fields": ["dose", "evidence_level", "knowledge_version"],
"forbidden_actions": ["final_prescription", "rewrite_unit"]
}
}
EHR 字段要进检索，也要进校验
同一个药名，落到不同患者身上，回答可能完全不同。年龄、诊断、过敏史、肾功能、肝功能、妊娠状态、当前用药，不能只塞进 prompt 末尾当背景。它们要参与检索前过滤，也要参与检索后校验。
更接近日常工作台的时序是：医生在 EHR 中选择待评估用药；Agent 拉取最小患者上下文；系统生成 query_set，包含药物编码、目标适应证、年龄段、肾功能状态、合并用药类别、过敏史；Drug Knowledge MCP 返回 retrieved_facts；规则层做字段级 claim_check；LLM 输出证据摘要和复核提示。
常见失败样例：patient_context 里的 renal_function 是 unknown，retrieved_fact 里存在 renal_adjustment。系统如果仍允许模型输出“可使用，注意监测”，就把缺失字段包装成了临床判断。处理方式应标记 missing_context，展示命中的肾功能调整条目来源，并升级到药师复核。
图2：EHR patient context、Drug Knowledge MCP、规则层与 LLM Agent 的调用关系。输入为 patient_context 和 query_set，输出为 retrieved_facts、claim_check、audit_log
FHIR 里，MedicationRequest 可对应待评估用药，Observation 承接肾功能、肝功能等实验室指标，Condition 承接诊断，AllergyIntolerance 承接过敏史。编码层面，药物名尽量映射 RxNorm 或 ATC，诊断映射 ICD 或 SNOMED CT，实验室指标映射 LOINC。做不到完全标准化，也要标出“自由文本”“院内码”“国际码”的来源，避免模型把不同粒度字段混成同一事实。
审计从候选证据池开始
药事和合规评审很少关心回答是否顺滑。他们看候选证据池、排除理由、升级规则、责任路径。
例如一个模拟审计题：“用药 Agent 在相互作用提醒中如何减少 alert fatigue”。检索问题可以拆成 drug-drug interaction alert、clinical decision support、override rate、pharmacist review、EHR workflow。保留 PMID/DOI、研究类型、场景、主要终点、局限性，再交给药师判断哪些证据可进入院内规则讨论。
准备这类模拟审计集时，可以用 超能文献 做前期资料搜集：用中文问题检索 drug knowledge base、medication safety、clinical decision support、MCP-like agent workflow、drug-drug interaction alert fatigue 等主题，并整理来源、摘要和候选证据表。它适合文献查找和整理，不提供诊断、处方或用药建议。
图3：审计日志示意。字段包括 request_id、knowledge_version、source_id、patient_context_hash、missing_fields、model_output、risk_level、human_reviewer、final_action
一次回答的 audit_log 至少覆盖知识库版本、命中条目、患者上下文字段、缺失字段、模型输出、风险等级、人工确认人、最终处理结果。回放事故时，团队才能判断问题来自知识库版本、EHR 字段缺失、检索命中错误、模型生成越界，还是人工流程没有接住。
回到开头那句“可使用，注意监测”。药师追问适应证、剂量范围、肾功能分层，暴露的是三个具体断点：证据没有按字段保存，EHR 上下文没有进入校验，高风险缺失项没有触发复核。引用来源只能证明系统看过材料，不能证明它保留了限制条件。
下一步先做 50 条模拟审计集：每条包含患者上下文、药物知识条目、正确应答边界、必须升级的条件、人工确认记录。随后导出候选证据池和排除理由，明确 EHR 写回状态机，再让药师、医生、信息科一起验收错误类型和升级规则。
