跳到正文

医疗报告结构与来源检查

整理病例、诊断、试验和研究报告的文档结构,使用本地检查工具核对来源事实与报告字段,结果供专业人员审阅。

开源精选医疗业务39 个文件50,135 Stars浏览次数 2K-Dense-AI/scientific-agent-skills MIT版本 a1043ef
开始使用

适用环境:Requires Python 3.11+ for optional dependency-free local scripts. No credentials or network needed for data processing; network access is needed only to review current public guidance.

输入资料
获准使用且符合原文范围的资料 经过核查的来源事实与报告类型 阅读本节完整说明
交付内容
结构化报告草稿 来源与文档检查记录 阅读本节完整说明
  1. 获取完整包,保留配套文件的目录结构。
  2. 按照原文准备所需工具、依赖与输入资料。
  3. 阅读对应使用步骤与输入输出说明,在自己的环境中验证结果。

使用提示摘自原文,配套文件保留来源版本;实际运行条件以各包说明为准。

正文

获取原文件

references/safety_reporting.md

Safety reporting is role-, product-, phase-, source-, jurisdiction-, and time-dependent. This skill formats verified aggregate counts only. It does not determine seriousness, severity, causality, expectedness, reportability, clock start, destination, format, or follow-up.

Core distinctions

  • Adverse event (AE): an untoward medical occurrence temporally associated with a medicinal product; causality is not required.
  • Adverse reaction / suspected adverse reaction: a causal relationship is at least reasonably possible or otherwise meets the applicable regional definition.
  • Seriousness: outcome or regulatory criterion such as death, life-threatening experience at the time, hospitalization, disability/incapacity, congenital anomaly, or another medically important event.
  • Severity: intensity. A severe event is not automatically serious; a serious event need not be severe in intensity.
  • Expectedness: comparison with the applicable reference safety information under the governing procedure.

Only an authorized qualified safety professional may make or approve these assessments.

ICH routes

E2A — pre-approval expedited reporting

ICH E2A (Step 4, 27 October 1994) defines standards for expedited reporting during clinical development. It describes minimum information for an initial report and the distinction among serious, unexpected, and suspected reactions.

Do not apply E2A as a universal post-approval rule or encode its timelines without the current regional requirement and sponsor procedure.

E2B(R3) — ICSR electronic data and message specification

E2B(R3) defines data elements and electronic transmission for individual case safety reports. It covers pre- and post-approval ICSRs within scope. It does not:

  • decide whether a case is reportable;
  • define an aggregate safety table;
  • replace E2A, E2D(R1), or regional rules;
  • validate clinical coding or narrative accuracy.

Use the current implementation guide, Q&As, code lists, regional implementation guide, and receiving-system rules. The ICH catalogue did not expose a readable current file list during this review; the FDA implementation page independently confirms the E2B(R3) message specification and regional additions. No local script implements or validates E2B messages.

E2D(R1) — post-approval individual cases

ICH adopted E2D(R1), Post-Approval Safety Data: Definitions and Standards for Management and Reporting of Individual Case Safety Reports, on 15 September 2025.

It addresses post-approval ICSR sources and case management, including organized data collection systems, literature, digital platforms, and patient-support programs. It explicitly directs users to:

  • E2B for ICSR structure/format/data elements;
  • E2C for periodic aggregate safety reporting;
  • regional/local requirements where they differ.

Do not use the aggregate formatter for an ICSR or use E2D(R1) to invent missing case data.

E2C(R2) — periodic aggregate reporting

Where applicable, E2C(R2) addresses periodic benefit-risk evaluation reporting. Applicability and regional format require qualified review. Aggregate tables in this skill are display aids, not periodic reports.

FDA IND safety reporting

For applicable US IND studies, 21 CFR 312.32 controls sponsor IND safety reporting. FDA issued final sponsor and investigator safety-reporting guidances in December 2025. The sponsor guidance includes aggregate-data assessment considerations; the investigator guidance clarifies investigator-to-sponsor and IRB responsibilities.

FDA’s IND safety-reporting page, checked 30 September 2026, states:

  • sponsors report qualifying potential serious risks under 21 CFR 312.32;
  • unexpected fatal or life-threatening suspected adverse reactions must be reported to FDA as soon as possible and within 7 calendar days after the sponsor’s initial receipt of the information;
  • other qualifying potential serious risks must be reported to FDA and participating investigators as soon as possible and within 15 calendar days after the sponsor determines the information qualifies;
  • as of 1 April 2026, commercial IND reports under 21 CFR 312.32(c)(1)(i) use FDA AEMS with E2B(R3), with stated exemptions for noncommercial INDs;
  • other categories described on the page use the applicable eCTD route.

This summary is not a reporting clock or filing instruction. The responsible sponsor, investigator, IRB/IEC, and regulatory professionals must consult the current regulation, guidance, protocol, and procedures for each event.

US postmarketing electronic transition

FDA’s AEMS electronic-submissions page permits E2B(R2) postmarketing ICSRs through 30 September 2026 and requires E2B(R3) for all ICSRs submitted through ESG NextGen beginning 1 October 2026. This transition is distinct from the commercial IND requirement above. FDA states that Safety Reporting Portal users need take no action for this transition. These are US receiving-system requirements, not worldwide ICH effective dates. The responsible regulatory professional must verify the applicable route; this skill never transmits.

Aggregate formatter input

format_adverse_events.py accepts only aggregate rows:

  • analysis set;
  • treatment group;
  • MedDRA version;
  • system organ class;
  • preferred term;
  • subjects affected;
  • event count;
  • denominator.

It also requires a populated clinical_trial_safety_aggregate_template.json sidecar that records authorization, protocol/SAP/data-cut references, analysis set, counting and threshold rules, MedDRA version/language, provenance, and pending human reviews.

It rejects row-level identifiers, verbatim narratives, case IDs, and onset dates. It checks arithmetic and group consistency but does not verify:

  • MedDRA term/code validity;
  • coding quality or hierarchy placement;
  • treatment relatedness;
  • seriousness or fatality;
  • analysis-set correctness;
  • deduplication;
  • whether a subject appears in multiple terms or SOCs;
  • statistical inference.

MedDRA caveats

MedDRA 29.1 (September 2026) is the released version documented by the official English Introductory Guide at this review. A report must use the study/sponsor-authorized dictionary version, not automatically the newest version.

State the exact version and language. Terms can change currency, names, or hierarchy across releases; codes can persist through renames. Use licensed official files and MedDRA Points to Consider. A syntax checker cannot validate coding.

Required handoff

Every aggregate table must disclose:

  • analysis set and denominator per group;
  • whether values are subjects, events, or both;
  • MedDRA version and language;
  • counting rules and threshold supplied by the protocol/SAP;
  • missing or suppressed cells;
  • no inferential claim unless separately verified;
  • qualified safety and statistical review required;
  • not suitable for individual-case submission.

CONTACT HAONAN

联系haonan

医疗 AI · 产品与独立开发

刘浩南

关注医疗 AI 从 demo 到真实落地,聚焦产品化、商业化与院内工作流效率提升。

12年医疗产研经验,大湾区头部医疗AI公司前产品总监,独立开发者

医疗 AI 产品化医疗 AI 商业化院内工作流效率
刘浩南的微信联系二维码
微信扫一扫,联系 haonan