企业官网建设流程全解析

基于 CARE 清单的病例报告草稿合规框架：clinical-reports 技能的 13 项结构化核查与发布安全门控

【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000+ scientists worldwide. 165 ready-to-use validated skills plus 100+ scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills

病例报告（Case Report）是医学期刊中最常见但也最容易被忽视质量控制的文体之一。本仓库scientific-agent-skills中的 clinical-reports 技能，为 AI Agent 提供了一套以CARE 2013 检查清单（CARE 2013 Checklist）为骨架、2017 版解释与说明（Explanation & Elaboration）为补充的病例报告草稿编制规范与本地确定性校验工具。本文以skills/clinical-reports/references/case_report_guidelines.md为绝对主体，逐条解析 CARE 的 13 个标题结构、草稿安全边界、知情同意与去标识化约束、fail-closed（故障关闭）状态机以及"结构完整不等于可投稿"的评审门控，并结合技能内置的 case_report_template.json、validate_case_report.py 与 test_scripts.py 源码，讲清"如何把一份可验证的病源事实清单安全转成符合 CARE 骨架的投稿前草稿"。

CARE 指南在病例报告中的定位与边界

版本现状：2013 清单 + 2017 解释

依据该技能官方来源台账 sources.md，CARE 官方网站当前仍将2013 CARE Checklist认定为核心检查清单，2017 年的解释与说明文档则提供条目理由（rationale）与写作范例（examples）。技能文档明确指出：CARE 是病例报告的"报告指南"（reporting guidance），它并不授权任何人访问病案记录、不建立同意、不证明去标识化成立，也不替代目标期刊的投稿须知。

这一点被模板中的guidance字段固化为强制约束——见 case_report_template.json：

"guidance": { "name": "CARE", "checklist_version": "2013", "explanation_version": "2017", "target_journal_instructions_checked": false }

对应地，validate_case_report.py 中guidance.name必须是CARE、checklist_version必须是2013、explanation_version必须是2017，三者任一不匹配都会把清单判定为BLOCKED；而target_journal_instructions_checked若不为true，只会产生 warning（"目标期刊须知仍未核对"），而非阻断——因为期刊规则本就不属于脚本能自动判定的事项，只能由人核对。

权威性声明的边界

原文档特意强调一条容易误用的原则：CARE 是"报告时应遵循的写作指引"，不是临床行为授权，也不构成合规证明。因此，任何把"通过了 CARE 校验"误解为"可以投稿/发表"的表述都是越界的。校验器能做的仅有两件事：确认全部标题具备一个允许的状态、以及每个条目都挂接了已核验的事实引用（fact references）。它不评判临床准确性，也不评判 CARE 遵循程度——这一点在工具自述 limitations 中被写死："Structure and provenance metadata only; no clinical-content validation."（仅结构溯源元数据，不做临床内容验证）。

CARE 十三项标题结构：从论文标题到知情同意

编写病例报告草稿时，必须保留官方结构的十三项标题，顺序不可随意调换。原文档给出如下权威顺序：

1. title（标题）
2. key words（关键词）
3. abstract（摘要）
4. introduction（引言）
5. patient information（患者信息）
6. clinical findings（临床发现）
7. timeline（时间线）
8. diagnostic assessment（诊断评估）
9. therapeutic intervention（治疗干预）
10. follow-up and outcomes（随访与结局）
11. discussion（讨论）
12. patient perspective（患者视角）
13. informed consent（知情同意）

这些标题在源码中被原样固化为CARE_ITEMS元组。见 validate_case_report.py：

CARE_ITEMS = ( "title", "key_words", "abstract", "introduction", "patient_information", "clinical_findings", "timeline", "diagnostic_assessment", "therapeutic_intervention", "follow_up_and_outcomes", "discussion", "patient_perspective", "informed_consent", )

校验逻辑同时执行key 级白名单：缺少任一CARE_ITEMS键、或出现任何不在该元组内的多余键，都会被报为 error 并整体BLOCKED（见校验器中missing_keys/extra_keys判断），其效果是从数据结构上杜绝"漏写章节"或"擅自增章"两类漂移。子条目层面的细节则需以官方 2013 清单与 2017 解释为准（技能引用台账 sources.md 已给出官方出处，使用前应核对实时版本）。

安全使用：草稿编制的硬性红线

原文档"Safe use"一节列出了草稿编制阶段不可妥协的操作纪律。结合技能整体边界（见 SKILL.md），可归纳为以下可执行规则：

• 从模板起步：所有病例报告草稿必须以 assets/case_report_template.json 为起点，它天然以BLOCKED_INCOMPLETE_DRAFT_NOT_FOR_CLINICAL_USE_OR_SUBMISSION状态打开，13 个 care_items 全部为missing、source_fact_ids为空数组。推荐用模板生成器产出本地副本而非手工建文件。
• 只使用去标识化的源事实：绝不复制原始图表或自由文本病案。对模板或脚本，不得写入原始自由文本病历；当存在结构化 source-fact manifest 时优先使用它。
• 直接标识符与联系方式不得进入草稿 manifest。
• 时间线用相对偏移表达：在获得授权且科学上充分的前提下，以"研究/病例相对偏移量"表示时间先后；不得为了掩盖冲突而篡改时间顺序。
• 诊断与治疗表述保持"属性化事实"：仅作为来自授权记录的归属陈述保留，脚本与 Agent 不得独立诊断、不得为治疗"合理化"、不得推荐诊疗方案。
• 患者视角必须归属授权来源，严禁编造引语。
• 不确定性要留在明处：缺失的随访、不良结局、局限性必须可见，不得用流畅文字"补全"。
• 不得抢先声称新颖性：在责任作者完成文献审阅之前，不得声称 novel。
• 禁止由单病例推导因果或普适性治疗结论。

这些红线在 SKILL.md 中被列为"Non-Negotiable Boundary"（不可谈判边界），例如"不得从患者级叙述生成个例安全报告""不得签名、背书、归档、报送、提交或修改源记录""不得调用外部 LLM、图像服务、API 或另一技能"。若请求越过边界，正确的做法是中止不安全部分，转而提供空白结构化模板、源事实清单或确定性结构校验，并把临床/监管决策交给合格的负责人。

知情同意与隐私：两个独立问题，一个共同红线

CARE 把知情同意列为清单条目之一，但模板本身无法取得或核实同意。原文档对同意与隐私的处理给出四条必须遵守的约束：

1. 只记录由责任人工评审者核实过的同意状态。校验器对应地要求privacy.publication_consent_record必须是一个非空字符串引用（指向本地同意状态记录），没有值即为 error。
2. 不得创建一段千篇一律的"已取得同意"标准陈述——也就是说，不得用模板脚本自动生成"本研究已获得患者书面知情同意"之类的固定句，因为同意是否真的取得只能由人核实。
3. "发表同意"与"HIPAA 去标识化"是两个独立问题：同意发表不等于满足 HIPAA 去标识化，反之亦然。在模板的privacy块中二者被拆成两个独立字段（publication_consent_record与deidentification_process_record），正是为了在数据层面防止混为一谈。
4. 去标识化并不必然消除全部再识别风险：罕见病、小社区、图像、异常时间线、独特组合都可能残留再识别风险，因此privacy.reidentification_risk_reviewed必须为true，否则报 error。

此外，涉及期刊政策、机构政策、法律法规、伦理委员会政策，以及未成年人、死者或无法同意者的情形，都需要具备相应资质的评审介入——这类判断属于技能明示不做的范围（"does not establish legal, regulatory, ethical, journal, accreditation, or institutional compliance"）。

模板privacy块的完整骨架如下：

"privacy": { "deidentification_process_record": null, "publication_consent_record": null, "image_or_media_included": false, "reidentification_risk_reviewed": false }

校验器（validate_case_report.py）会强制：deidentification_process_record与publication_consent_record必须是非空字符串；reidentification_risk_reviewed必须为true；image_or_media_included必须为布尔值。

Fail-closed 状态机：四个允许状态与它们的语义

原文档规定，每个 CARE 条目必须且只能使用以下四种状态之一。这四种状态构成了一套"默认阻断、逐步解锁"的 fail-closed（故障关闭）语义，其源码定义见 validate_case_report.py：

ALLOWED_ITEM_STATUSES = { "verified_present", "not_applicable_with_rationale", "missing", "conflict", }

状态机的几处关键约束值得单独强调：

• not_applicable_with_rationale是白名单受限状态。源码中NA_ALLOWED = {"patient_perspective"}（validate_case_report.py），意味着全表 13 项里只有"患者视角"允许被标记为不适用，其余任何条目想用"不适用"都会被拒——这防止了用 N/A 把难以补齐的章节"洗白"。
• verified_present必须有事实背书。仅填状态而不给source_fact_ids，等同于missing。
• 知情同意条目不可被脚本豁免。原文档原话："The consent item cannot be waived by the script." consent 条目处于missing或未解决状态（含conflict）时，将阻断发表交接（publication handoff）。

测试用例 test_scripts.py 直接验证了这套门控：把timeline条目改成missing后，validate_case_manifest返回BLOCKED，且错误信息中包含该条目名；把patient_name之类的未知顶层字段塞入 manifest，同样返回BLOCKED。

合格评审清单：结构通过 ≠ 允许投稿

原文档在最后给出投递前必须完成的合格评审范围。在提交任何期刊之前，责任作者与相应的临床、隐私/法律、机构评审者必须逐项核验：

• 源记录准确性与时间线（source accuracy and chronology）；
• 同意与授权（consent and authorization）；
• 隐私与图像/元数据处理（privacy and image/metadata handling）；
• 术语与临床解读（terminology and clinical interpretation）；
• 讨论部分的论断与引文（discussion claims and citations）；
• 冲突、局限性、不良结局（conflicts, limitations, and adverse outcomes）；
• 目标期刊的现行投稿须知（the target journal's current instructions）。

之所以要"逐项人工核验"，是因为校验器的结构判读边界清晰：STRUCTURE_COMPLETE_REVIEW_REQUIRED不是允许提交的许可。这一语义在源码中贯穿始终——validate_case_report.py 中，只要无 error 就返回STRUCTURE_COMPLETE_REVIEW_REQUIRED，同时固定输出"review_required": True与"authorizes_clinical_use_or_submission": False；反之只要存在任一 error 便返回BLOCKED。与此同时，模板review块的三个评审字段（qualified_clinical_review、privacy_legal_review、accountable_author_review）若不为completed会产生 warning，而submission_authorized若不为false则直接报 error——在草稿 manifest 内，投稿授权字段必须保持 false。

测试 test_scripts.py 也验证了这一点：即便一个 13 项全部verified_present、评审全completed的"完美" manifest，其状态仍是STRUCTURE_COMPLETE_REVIEW_REQUIRED，且authorizes_clinical_use_or_submission恒为False。

实操闭环：从模板生成到校验运行

将上述规范落到命令行，是整套框架最具实战价值的部分。以下命令来自 SKILL.md 的安全编制工作流（Safe Drafting Workflow），全部为纯 Python 标准库、本地有界文件、无网络依赖：

第一步，查看可用模板并生成病例报告草稿副本：

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

生成器（generate_report_template.py）只做"复制 + 本地路径白名单校验"，不做任何插值、不填充临床内容、默认不覆盖已存在文件（覆盖需显式--overwrite），也不宣告就绪。从源码看，它还通过_common.py中的local_output_path拒绝了符号链接、URI scheme 与网络路径，保证纯本地闭环。

第二步，逐字段填充已核验事实：保持draft_status原封不动；只有存在支持性 fact ID 时才把null替换为值；不确定性、"not assessed" 必须原样保留；不得把原始观察"翻译"成诊断、编码、分级、分期、严重性、因果性、预期性或推荐意见；not_applicable_with_rationale仅在合格评审者提供了 rationale 时使用；源记录与草稿始终分离（详见 SKILL.md）。

第三步，运行本地确定性校验：

PYTHONDONTWRITEBYTECODE=1 python3 scripts/validate_case_report.py \ ./case-report-draft.json

输入文件经由 _common.py 的load_json_object检查：必须是.json、≤1 MB、UTF-8、无重复键、节点数与深度有上限、字符串无非法控制字符——其目的在于即使输入是恶意或病态结构，脚本也保持 fail-closed，不进入任何网络或动态求值路径。校验通过时的退出码为 0，BLOCKED时退出码为 1，并可用-o输出结构化 JSON 报告。

当其他报告类型需要时，技能还提供对应的结构校验器，例如临床试验结果（CONSORT/SPIRIT 2025 与 ICH E3 结构用 validate_trial_report.py）、不良事件聚合表、术语 schema、去标识化流程文档、溯源一致性与算术一致性校验，命令参考 SKILL.md。每一类工具输出的成功状态同样带review_required: True语义。

结语：草稿允许失败关闭，发布只允许人门开启

将 case_report_guidelines.md 与技能源码对照可以得出整条使用哲学：结构问题用确定性脚本"fail closed"，临床与伦理判断留给人。CARE 2013 的 13 项标题、四个 fail-closed 状态、知情同意不可脚本豁免、去标识化不等于零再识别风险、STRUCTURE_COMPLETE_REVIEW_REQUIRED不等于可投稿——这一连串规则在 JSON 模板、Python 校验器与单元测试三层被同一套常量与断言固化。因此实践者获得的是一条清晰可复核的路径：以本地模板起步 → 仅填挂接事实 ID 的字段 → 用无依赖脚本验证结构 → 交由临床、隐私/法律、作者与期刊四方评审 → 在submission_authorized由人置为 true 之前，所有草稿都停留在"BLOCKED / REVIEW_REQUIRED"状态。这正是此类安全受限 Agent 技能应当具备的形态：它可以帮你把结构砌得严丝合缝，却永远不会替你说"可以投稿"。

【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000+ scientists worldwide. 165 ready-to-use validated skills plus 100+ scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills