科学 Agent 技能库 clinical-reports：以 ACR、CAP 与 42 CFR 493.1291 为准绳构建放射、病理与检验诊断报告草稿框架

诊断报告是直接进入病历、面向临床决策的高风险文书，绝不能由 AI 自由"生成"内容。本篇文章聚焦 scientific-agent-skills 仓库中 diagnostic_reports_standards.md 这一关联文档，系统讲解它在放射、病理与检验三个场景下为 AI Agent 划定的"安全操作边界"：Agent 只能依据 ACR 影像判读沟通实践参数、CAP 癌症方案模板、CLIA 法规 42 CFR 493.1291，把已核实的结构化字段映射成"默认阻断（fail-closed）"的 JSON 草稿骨架，再交给具备资质的人员完成撰写、复核与签署。读完本文，你将掌握三类诊断报告草稿的可用字段、禁止行为、隐私底线，以及仓库内配套模板与确定性校验脚本的用法。

文档定位：一份"结构化字段地图"，而非诊断生成系统

原文在开头就给出了一句话总纲：这些资产（assets）是经授权的临床服务使用的结构化字段地图（structured field maps），它们不解读数据，也不产出适用于患者诊疗的报告。

这一点对应到技能本身，见 SKILL.md 中对诊断报告草稿的定义：radiology_report_template.json、pathology_report_template.json、lab_report_template.json 只是字段映射，不是诊断撰写系统。任何一次 AI 调用都必须遵守若干不可协商边界（Non-Negotiable Boundary），包括：不做诊断、不推荐治疗方案、不解释影像/标本/原始检验结果、不推断或"补全"任何缺失的观察与数据、不签署/存档/提交/修改任何源记录、不使用真实 PHI、不调用外部 LLM 或图片服务。

从实现上看，这一边界是"写死"在模板里的：三类 JSON 资产的 draft_status 字段默认都是 BLOCKED_INCOMPLETE_DRAFT_NOT_FOR_CLINICAL_USE_...（阻塞且不完整，不可用于临床或签署），并带有明确的 safety_notice。可结合 tests/clinical-reports/test_scripts.py 中 test_generator_copies_blocked_template_without_interpolation 测试验证：即使由脚本生成的模板拷贝，draft_status 也必然包含 BLOCKED，且 authorization_verified 恒为 false。

放射科报告草稿：对齐 ACR 影像判读沟通实践参数

所依据的标准基线

文档指出，影像诊断报告、最终报告原则、初步报告、非常规沟通（nonroutine communication）、非正式沟通以及机构层面的沟通政策，均以 ACR《影像诊断判读结果沟通实践参数》（Practice Parameter for Communication of Diagnostic Imaging Findings）2025 年修订版（Resolution 9） 为依据。版本与日期细节可以在 sources.md 的 "Diagnostic reporting" 小节找到对应的官方来源记录（该账本核对日期为 2026-07-23），使用前应再次核验当前官方版本与本地机构政策。

可以映射哪些已验证事实

radiology_report_template.json 仅允许把已核实的事实填入以下字段：

• 检查项目身份与状态（examination）；
• 按提交方提供的临床适应证（clinical_indication）；
• 技术参数与已记录的局限性（technique_and_limitations）；
• 对比资料来源引用（comparison）；
• 由具备资质的判读专业人员撰写的所见与印象（findings / impression）；
• 非常规沟通记录引用（nonroutine_communication_record）；
• 修订/更正及其报告版本（correction_or_addendum_linkage）。

模板中的 guidance 区块专门记录了所采用的基准来源：base 固定为 ACR Practice Parameter，revision 为 "2025"，而 modality_specific_source 与 local_policy_version 默认为 null，等待人工填写。fields 中的每一项都形如 {"status": "missing", "source_fact_ids": []}——在未获得可追溯的事实 ID 前一律保持 missing。

严格禁止的行为

对应到同一文档，放射科草稿中 AI 不得：

• 检查或解读影像；
• 生成"正常所见"、相关阴性、鉴别诊断、紧急程度、随访或处置建议；
• 选择 BI-RADS、LI-RADS、Lung-RADS、PI-RADS 或其他任何分类；
• 推断初步报告（preliminary report）即为最终报告；
• 发起、模拟或记录一次并未真实发生的沟通。

报告内容、沟通、更正与签署的控制权始终归责任放射科医生及其所在机构。

生成一份放射科草稿

在 clinical-reports 技能目录下，可以用模板生成脚本拉取默认阻断的 JSON 骨架：

PYTHONDONTWRITEBYTECODE=1 python3 scripts/generate_report_template.py --list
PYTHONDONTWRITEBYTECODE=1 python3 scripts/generate_report_template.py \
  --type radiology-scaffold \
  --output ./radiology-report-scaffold.json

脚本实现见 generate_report_template.py：它只做"原样拷贝"（output.write_bytes(validated_source.read_bytes())），不做任何插值、不填充临床内容、默认不覆盖已存在文件（需显式 --overwrite），并限制输入输出均为后缀匹配的本地普通文件。

病理报告草稿：以当前精确的 CAP 癌症方案为准

方案与版本是动态的

CAP（美国病理学家学会）持续发布并更新按器官/标本划分的癌症方案（Cancer Protocols）。文档提示：CAP 模板页面在核对时显示 2026-06-17 有方案更新、2026-06-24 有 Breast DCIS 更正，因此方案版本与 required/core 或 conditional 元素都可能变化，绝不能维护一套固定的通用模板。

pathology_report_template.json 的 protocol_selection 区块完整记录了这一前提：cap_protocol_title、cap_protocol_version、specimen_and_procedure_scope_verified、biomarker_protocol_title_and_version、staging_system_and_edition、local_policy_version 在方案被选择前一律为 null/false。

使用前提：先由合格的病理医生选择

只有在具备资质的病理医生完成以下选择后，Agent 才可使用该模板映射字段：

• 精确的器官/部位与标本/操作类型；
• 当前适用的 CAP 方案标题与版本（如有）；
• 适用的生物标志物方案与分期（staging）版本；
• 本地实验室/报告要求。

在 CAP 概要式报告（synoptic reporting）范围内，核心与条件必需数据元素被表示为"数据元素/应答"成对结构（data-element/response pairs）；其适用性取决于当时的精确方案版本。

严格禁止的行为

病理场景下不得：

• 生成大体（gross）或镜下（microscopic）观察描述；
• 判定诊断、分级、分期、切缘状态、生物标志物解读或标本充分性；
• 用一份通用癌症检查表代替当前的精确方案；
• 把 cannot be determined（无法确定）或 not applicable（不适用）强行转成确定值；
• 生成签名或最终诊断。

草稿模板中的 fields（如 gross_observations_authored_by_pathologist、diagnosis_authored_by_pathologist、synoptic_data_element_response_pairs）刻意用 _authored_by_pathologist 后缀强调：这些内容只能由病理医生本人撰写。

检验报告草稿：符合 CLIA 框架的 42 CFR 493.1291

法规基线

对适用的美国非豁免检测（nonwaived testing），42 CFR 493.1291 规定了准确及时的传输、报告必备信息、转介实验室处理、可及性以及更正报告等内容。文档同时强调：确切的法规文本与实验室政策拥有最终控制权。同样可在 sources.md 的 "Diagnostic reporting" 小节核对 eCFR 版本的注意事项（eCFR 是持续更新的非官方在线版本，正式场合应使用官方年度 CFR 并咨询法律审核）。

lab_report_template.json 中 guidance.base 即固定为 "42 CFR 493.1291"，scope_verified_by_laboratory 默认为 false。

可以映射什么

lab_report_template.json 只允许映射已由执行实验室或已核实源系统发布的结果，并保留：

• 报告状态与版本；
• 执行实验室/源系统引用；
• 授权系统中保留的标本与检测标识（不得复制到示例中）；
• 按发布原样呈现的结果、单位、参考区间、标志、方法与注释；
• 同时指向原始报告与更正报告的更正链接；
• 存在的已记录通知引用（documented notification reference）。

对应模板字段包括 released_result、released_units、released_reference_interval、released_flags_or_comments、original_and_corrected_report_linkage 等，released_ 前缀同样在语义上限定：只能照录实验室已发布的值。

严格禁止的行为

检验场景下不得：

• 计算、标准化、换算、解读、加标志或压制任何患者结果；
• 提供参考区间或"危急值"阈值；
• 推断标本充分性；
• 推荐随访或治疗；
• 改动转介实验室的结果或解读；
• 发布或签署报告。

隐私与记录完整性：只用合成、去标识或汇总数据

诊断报告通常需要标识符来做正向患者匹配（positive patient matching），因此隐私边界尤其关键。本技能不处理生产环境记录，只接受 synthetic（合成）、de-identified（去标识）或 aggregate（汇总） 三类清单；真实临床记录必须放在机构控制的系统内，并遵守适用的访问、留存、更正、审计与披露程序。

这与 SKILL.md 的输入闸门（Input Gate）完全一致——只有同时满足目的明确、数据类别受允许、授权已记录、仅本地处理、最小必要已界定、存在溯源（provenance）、复核负责人已指定这七项条件才允许继续。从源码看，scripts/_common.py 通过 ALLOWED_DATA_CLASSES = {"synthetic", "deidentified", "aggregate"} 在程序层面强制了这一点。

每个生成草稿的 fields 项都必须通过 source_fact_ids 关联到 provenance_manifest_template.json 中的事实 ID；事实清单只记录本地定位符、字段路径、核验状态、核验角色、核验日期与 SHA-256 值哈希，不复制源内容或直接标识符。provenance_validator.py 会校验这一"事实-声明"的完整可追溯链。

DRAFT_NOT_FOR_CLINICAL_USE 是强制出口

文档规定：每一个草稿骨架在责任医疗服务机构在授权系统中完成复核与补全之前，必须保持 DRAFT_NOT_FOR_CLINICAL_USE 标识。这与仓库中所有模板的 draft_status 前缀 BLOCKED_INCOMPLETE_DRAFT_NOT_FOR_CLINICAL_USE... 相呼应——默认阻断是设计目标，而不是可选项。

在技能流程中的落地：从生成骨架到确定性校验

配合整体路由表使用

诊断报告草稿并非独立工作流，而是 SKILL.md 中"先路由、再起草"流程的一部分。起草前应先阅读 report_type_routing.md 并核对 sources.md 中的官方来源账本：

• 放射科草稿 → 路由到 ACR 2025 沟通实践参数 + 各模态 ACR 资料，边界是"由合格放射科医生撰写所见/印象并处理非常规沟通"；
• 病理科草稿 → 路由到 当前标本特异的 CAP 癌症方案（如适用），边界是"由合格病理医生选择方案/版本并撰写诊断"；
• 检验科草稿 → 路由到 42 CFR 493.1291 + 实验室政策，边界是"执行实验室控制结果、参考区间、更正与发布"。

三个 JSON 资产的顶层结构也都预设了 review 区块（如 qualified_radiologist_review、qualified_pathologist_review、authorized_laboratory_review 均为 pending，signature_present 为 false），从数据结构上保证"复核待办"不会被遗漏。

生成、填充与校验脚本

对应三类草稿的生成命令（在 clinical-reports 目录下执行）：

PYTHONDONTWRITEBYTECODE=1 python3 scripts/generate_report_template.py \
  --type radiology-scaffold --output ./radiology-scaffold.json
PYTHONDONTWRITEBYTECODE=1 python3 scripts/generate_report_template.py \
  --type pathology-scaffold --output ./pathology-scaffold.json
PYTHONDONTWRITEBYTECODE=1 python3 scripts/generate_report_template.py \
  --type lab-scaffold --output ./lab-scaffold.json

填充原则（与 SKILL.md 第 3 步一致）：draft_status 保持不变；只有当已核验事实 ID 支持时才把 null 替换为值；不确定性按原样保留；not_applicable_with_rationale 仅在合格复核者提供理由时使用；源记录与草稿始终保持分离。

起草完成后的确定性校验工具包括 provenance_validator.py（事实到声明的可追溯性）与 consistency_checker.py（分母/比例等内部一致性）。所有脚本只依赖 Python 标准库，无网络、无动态求值、无序列化代码执行，也不做患者记录抽取。需要特别强调的是：校验只检查结构与内部一致性，成功结果依然提示必须人工复核。_common.py 通过 MAX_JSON_BYTES = 1_000_000、MAX_DEPTH = 24、拒绝 URL/符号链接输入等约束把处理范围牢牢限制在本地小文件之内。

测试 test_scripts.py 中 test_every_json_asset_parses_and_contains_no_obvious_real_phi 还会对所有 JSON 资产做正则扫描，确保不混入邮箱、社保号、电话号码等疑似真实 PHI；test_bundled_path_references_exist 则保证 SKILL.md 与各 references 文档中引用的 assets/、references/、scripts/ 相对路径真实存在。这两点从工程上印证了本文档"只收合成数据、字段地图可引用"的设计初衷。

小结：把"边界"当作功能来设计

诊断报告领域里，AI Agent 真正的价值不在于替医生"写出诊断"，而在于把经过核验的字段稳定、可追溯、可复核地组织成结构化草稿。本文档以 ACR 2025、CAP 癌症方案与 42 CFR 493.1291 为三大锚点，配合 BLOCKED_INCOMPLETE_DRAFT_NOT_FOR_CLINICAL_USE 的默认阻断模板、SHA-256 溯源清单与本地确定性校验，形成一套"宁可缺字段、不可造事实"的工程范式。任何实际使用前，请以 sources.md 为起点核验当前版本，并把内容撰写、沟通、签署全部交还给具备资质的临床专业人员与其授权系统。