Patient Consent for Case Reports: Journal Rules

Patient Consent for Case Report Publication

The written authorization a patient (or parent/guardian/legally authorized representative) gives before a clinical case report describing their presentation, treatment, images, or outcome is submitted to a journal -- required whenever the report contains identifiable information, per ICMJE's patient-privacy recommendations and CARE Guidelines checklist item 13, independent of any separate IRB determination about the underlying case.

ByCASRAI Editorial Board

· Last updated 15 Aug 2026

Ask about Patient Consent for Case Report Publication

Answers are drawn from this dictionary entry and the rest of the CASRAI corpus, with a link to every source.

Answers are AI-generated from CASRAI’s own published pages and can be wrong, so check the linked sources before relying on one; your question is logged without personal data — never sold, never used to train a third-party model — to show us what CASRAI is missing, so please do not type personal or confidential details. How we use this

Worked examples

Is an instance

A case report including a patient photograph with the eyes masked still requires a signed consent form authorizing the identifiable image, since ICMJE explicitly treats eye-masking alone as inadequate anonymization.

Is an instance

A journal (e.g. BMJ Case Reports) requires authors to upload a completed patient consent form -- the journal's own template or an ICMJE-aligned model form -- as a supplementary file before manuscript review can proceed.

Looks similar, but isn't

Not an instance

A fully de-identified retrospective case series drawn from a chart review, with no detail specific enough to permit re-identification, may not require individual publication consent -- but genuine de-identification, not just omission of the patient's name, is the test.

Not an instance

Obtaining IRB approval or exemption for a case report does not substitute for patient consent to publish; the two serve different purposes -- research-ethics oversight versus publication authorization -- and ICMJE/CARE requires both to be considered separately.

Why the SAP exists as a document separate from the protocol

A clinical trial protocol establishes the trial’s design, eligibility criteria, interventions, and endpoints, and typically includes a summary of the planned statistical approach. The Statistical Analysis Plan (SAP) exists as a separate, more granular document because ICH E9 (“Statistical Principles for Clinical Trials”) requires that the full technical details of the planned analysis be specified and documented before anyone with access to the data can see results that might reveal treatment effects — a level of detail (exact model specifications, handling of missing data, multiplicity strategy, definitions of analysis populations) that would make a protocol unwieldy if embedded directly, and that in practice is often finalized somewhat later than the protocol itself, closer to database lock. FDA’s Guidance for Industry on E9 and ICH E9(R1)’s estimands addendum both describe the SAP as the vehicle for this pre-specification.

Timing: why finalization before database lock and unblinding is the whole point

The SAP’s methodological value depends entirely on when it is finalized relative to two events: database lock (the point after which the trial dataset is frozen and can no longer be modified) and unblinding (the point at which treatment-arm assignment becomes visible to those analyzing the data). A SAP finalized and version-locked before both events documents analytic decisions made in ignorance of outcome data. A SAP written, or materially revised, after unblinding — even if it accurately describes reasonable statistical choices — cannot rule out that those choices were influenced by seeing which analysis produced a more favorable result. This is the direct mechanism by which SAP pre-specification prevents outcome-driven p-hacking and selective subgroup reporting: it removes the opportunity, not just the intent. For trials with a Data Safety Monitoring Board (DSMB) conducting interim looks, the SAP additionally pre-specifies the interim-analysis schedule and any statistical stopping boundaries, since the DSMB’s unblinded access to comparative data makes this the same integrity concern at an earlier stage.

What a SAP typically specifies

Analysis populations — how the Full Analysis Set / intent-to-treat population and, where relevant, a per-protocol population are defined; see Intent-to-Treat vs. Per-Protocol Analysis for how these populations differ and why the choice affects estimated treatment effect.
Endpoint definitions and statistical models — the exact test or model for each primary, secondary, and exploratory endpoint, not just which endpoints exist.
Missing-data handling — the imputation or sensitivity-analysis approach for dropouts and missing assessments, specified in advance rather than chosen once the pattern of missingness in the actual data is known.
Multiplicity control — how Type I error is protected when there are multiple endpoints, comparisons, or interim looks.
Subgroup and sensitivity analyses — which subgroups will be examined and how, distinguishing pre-specified (confirmatory-adjacent) subgroup analyses from any later exploratory ones, which must be reported as exploratory.
Mock shells/tables — many SAPs are accompanied by table, listing, and figure (TLF) shells showing the exact output format the analysis will populate, reinforcing that the analysis was planned in structure, not just described in prose after the fact.

Relationship to the protocol, to registration, and to results reporting

The SAP is downstream of, and must be consistent with, the protocol’s stated objectives and endpoints — a SAP that introduces a new primary endpoint not named in the protocol, or changes the primary analysis population, is a protocol-inconsistency finding that reviewers and journal editors are trained to flag. Prospective trial registration on ClinicalTrials.gov (see also Prospective Clinical Trial Registration) is the public record against which a completed SAP can later be checked: because the registry captures the primary and secondary outcome measures before the trial completes, any mismatch between the registered endpoints and what the SAP (or the eventual publication) actually analyzes is detectable by any reader, which is precisely the accountability mechanism prospective registration is designed to create. Under ClinicalTrials.gov’s results-reporting requirements (FDAAA 801 / the Final Rule, 42 CFR Part 11), sponsors of applicable clinical trials frequently upload the SAP itself as a study document, and many registrations track SAP version history so the timing of finalization relative to enrollment completion and database lock is independently verifiable rather than taken on trust. For the broader design choices the SAP builds on — endpoint selection, sample-size and power calculation, and randomization scheme — see Designing a Clinical Trial: Endpoints, Sample Size, Randomization, SAP.

Frequently Asked Questions

What is a Statistical Analysis Plan (SAP) in a clinical trial?

A Statistical Analysis Plan (SAP) is the document that specifies, in full technical detail, how a clinical trial’s data will be analyzed — exact model specifications, handling of missing data, multiplicity strategy, and definitions of analysis populations — separately from the protocol’s higher-level summary of the statistical approach. ICH E9 requires this level of pre-specification before anyone with access to the data can see results that might reveal treatment effects.

How is a SAP different from the trial protocol?

The protocol establishes the trial’s design, eligibility criteria, interventions, and endpoints, and typically includes only a summary of the planned statistical approach. The SAP is the separate, more granular document that spells out the full technical detail, because that level of specification would make a protocol unwieldy if embedded directly and is often finalized closer to database lock than the protocol itself.

When should a SAP be finalized relative to a clinical trial?

A SAP should be finalized and version-locked before both database lock (when the trial dataset is frozen) and unblinding (when treatment-arm assignment becomes visible to those analyzing the data). A SAP written or materially revised after unblinding cannot rule out that its analytic choices were influenced by seeing which approach produced a more favorable result, which is why timing — not just content — is what gives the SAP its methodological value.

What does a Statistical Analysis Plan typically include?

A SAP typically specifies the analysis populations (such as the full analysis set versus a per-protocol population), the exact statistical model for each primary, secondary, and exploratory endpoint, the missing-data handling approach, the multiplicity-control strategy, and which subgroup or sensitivity analyses are pre-specified versus exploratory. Many SAPs are also accompanied by mock table, listing, and figure (TLF) shells showing the exact output format the analysis will populate.

Does the SAP need to match the trial’s registration on ClinicalTrials.gov?

Yes. Prospective registration on ClinicalTrials.gov captures the primary and secondary outcome measures before the trial completes, so any mismatch between the registered endpoints and what the SAP or the eventual publication actually analyzes is detectable by any reader. Under ClinicalTrials.gov’s results-reporting requirements (FDAAA 801 / the Final Rule), sponsors of applicable trials frequently upload the SAP itself as a study document.

Does a Data Safety Monitoring Board (DSMB) affect what goes in the SAP?

Yes. For trials with a Data Safety Monitoring Board (DSMB) conducting interim looks, the SAP additionally pre-specifies the interim-analysis schedule and any statistical stopping boundaries, since the DSMB’s unblinded access to comparative data raises the same integrity concern at an earlier stage in the trial.

Use in your systems

JATS XML <role> element

xml

<role vocab="credit"
      vocab-identifier="https://casrai.org/dictionary/"
      vocab-term="Patient Consent for Case Report Publication"
      vocab-term-identifier="https://casrai.org/dictionary/term/patient-consent-case-report-publication" />

Schema.org DefinedTerm (JSON-LD)

json

{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "@id": "https://casrai.org/dictionary/term/patient-consent-case-report-publication",
  "name": "Patient Consent for Case Report Publication",
  "identifier": "https://casrai.org/dictionary/term/patient-consent-case-report-publication",
  "description": "The written authorization a patient (or parent/guardian/legally authorized representative) gives before a clinical case report describing their presentation, treatment, images, or outcome is submitted to a journal -- required whenever the report contains identifiable information, per ICMJE's patient-privacy recommendations and CARE Guidelines checklist item 13, independent of any separate IRB determination about the underlying case.",
  "inDefinedTermSet": "https://casrai.org/dictionary/domain/clinical-research#set",
  "url": "https://casrai.org/dictionary/term/patient-consent-case-report-publication",
  "sameAs": [],
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "publisher": {
    "@id": "https://casrai.org/#organization"
  },
  "dateModified": "2026-08-15T04:27:35",
  "inLanguage": "en"
}