ACCORD and CREDES crosswalk
Transparent reporting lets readers judge whether a consensus result is credible and applicable. Delphi Studio preserves much of the evidence needed for that account, but no platform can write the complete methodological justification on behalf of the investigators.
This page maps two complementary sources of guidance to the records available in Delphi Studio:
- ACCORD — a reporting guideline for consensus methods used in biomedicine. It is applicable beyond Delphi and is not a conduct or quality-assessment standard.
- CREDES — Delphi-specific conduct and reporting guidance developed from a methodological review of palliative-care guidance studies.
For most biomedical Delphi manuscripts, use ACCORD as the primary reporting checklist and CREDES as complementary Delphi-specific guidance. Also apply any guideline required by the larger study design—for example, guidance for core outcome sets, clinical practice guidelines, qualitative research, or patient and public involvement.
:::caution Alignment is not compliance An export can supply dates, denominators, rules, and recorded decisions. Investigators must still explain why the method was appropriate, how evidence informed the item set, how the panel represented relevant perspectives, and what the findings can and cannot support. :::
Planning crosswalk
| Reporting topic | ACCORD/CREDES expectation | Delphi Studio evidence | Investigator must still supply |
|---|---|---|---|
| Objective and intended users | Explain the aim, output, and audience | Objective, consensus question, intended output, target audience | Scientific rationale and intended decision context |
| Choice of method | Name and justify the consensus method | Delphi type, anonymity, feedback, rounds, and stopping configuration | Why Delphi—and this modification—fit the question |
| Protocol and registration | Identify a protocol, registration, and planned deviations process where applicable | Protocol version, launch snapshot, amendments, study events | Registry identifier, public protocol citation, and deviations not represented in platform data |
| Steering group | Describe membership, responsibilities, and decision authority | Research-team collaborators and audited actions | Selection process, relevant expertise, conflicts, and off-platform responsibilities |
| Initial topic or item generation | Describe sources, screening, piloting, and transformations | Item citations, provenance, taxonomy, version lineage | Search/review methods, interview or workshop methods, exclusion decisions, pilot findings |
| Panel eligibility | Define expertise and stakeholder criteria before recruitment | Panel rules, stakeholder targets, qualifications, criteria snapshots | Why each criterion and target was appropriate |
| Sample size | Explain the target and its rationale | Target, minimum, maximum, and enrolled counts | Methodological justification, anticipated attrition, and any power or precision reasoning used |
| Scale and response options | Describe constructs, anchors, abstention/unable-to-rate handling | Dimensions, scales, anchors, zones, comment policy | Evidence or rationale supporting the measurement design |
| Consensus and stopping | Pre-specify definitions, thresholds, item handling, and stopping | Frozen rules, stability configuration, maximum rounds | Justification and any rule not implemented directly by the platform |
| Feedback | State format, content, timing, and anonymization | Feedback configuration and locked snapshots | Why the chosen feedback was suitable and how any external feedback was handled |
Conduct and results crosswalk
| Reporting topic | Delphi Studio evidence | Reporting notes |
|---|---|---|
| Recruitment flow | Expert-selection evidence, panelist states, invitations, consent, and recruitment report | Report numbers identified, invited, enrolled, excluded, withdrawn, and completing each round; avoid publishing identities |
| Panel composition | Stakeholder roles, country, qualifications, and configured profile fields | Report only fields collected with an appropriate purpose; explain missing perspectives and small groups |
| Chronology | Round opening/closing timestamps, deadlines, extensions, and study events | Report the start and end date of every step, including material delays |
| Participation and attrition | Per-round denominators, completion counts, response rates, withdrawals, and unavailable states | Explain denominator definitions and how attrition may have changed the result |
| Feedback delivered | Locked group-level packets and panelist-specific feedback snapshots | Describe quantitative and qualitative content and whether feedback was anonymized |
| Item evolution | Parent-item lineage, source comments, revisions, and next-round plan | State what changed or was removed, why, and between which rounds |
| Consensus results | Per-item distributions, median, IQR, zone percentages, classifications, and dispositions | Report every round—not only the final item list—and distinguish consensus from concordance and stability |
| Dissent and subgroup findings | Bimodality flags, stakeholder divergence, approved themes, and unresolved items | Preserve meaningful disagreement; do not describe non-consensus as panel failure |
| Overrides and deviations | Rationale-bearing disposition overrides, amendments, warning acknowledgments, and study events | Explain effects on interpretation rather than merely stating that an audit event exists |
| Stopping | Stability report, response-rate caveats, maximum-round state, and advisory recommendation | State who made the final decision and why the study stopped when it did |
| Harms or unintended consequences | Study-event log and withdrawals where recorded | Add off-platform incidents, burdens, or consequences relevant to interpretation |
Manuscript-section checklist
Title and abstract
- Identify the work as a consensus exercise and name the method used.
- State the objective, participant groups, principal consensus definition, number of rounds, and main result.
- Avoid using “modified Delphi” as the only methodological description.
Introduction
- Explain why consensus was needed and why empirical evidence alone was insufficient.
- Identify the intended users and decisions the result is meant to support.
- State whether the goal was exploration, prioritization, appropriateness, definition, or validation.
Methods
- Describe the steering group and conflicts of interest.
- Describe protocol development, registration, ethics review, and piloting.
- Explain initial item sources and transformations.
- Report panel eligibility, recruitment routes, targets, and compensation.
- Define anonymity, feedback, scales, unable-to-rate handling, consensus, stability, stopping, and item-handling rules.
- Explain qualitative synthesis, AI use, human review gates, and any external tools.
Results
- Give dates for every round and analysis step.
- Provide participant flow and round-specific denominators.
- Report item additions, removals, revisions, and the reasons for them.
- Present distributions and item-level results for every round.
- Report feedback delivered, deviations, overrides, attrition, unresolved items, and meaningful dissent.
Discussion and declarations
- Explain applicability, missing perspectives, attrition, and other limitations.
- Distinguish panel consensus from empirical proof, population prevalence, and universal recommendation.
- Report funding, sponsor roles, conflicts, author contributions, and data/material availability.
The ACCORD explanation and elaboration provides detailed rationales and reporting examples for each checklist item.
Evidence sources in Delphi Studio
| Artifact | What it contributes | Important limitation |
|---|---|---|
| Launch snapshot | Declared protocol configuration at launch | Does not explain why investigators selected each choice |
| Per-round rule snapshot | Exact classification predicates applied to a round | Does not make the rule methodologically appropriate by itself |
| Feedback snapshot | What group information and prior response a panelist was shown | External communications must be reported separately |
| Item lineage | Wording changes and parent-child relationships | Investigators must explain the substantive rationale |
| Audit log | Actor, timestamp, action, target, and structured payload | A system chronology is not a narrative account of conduct |
| Study-event log | Investigator-recorded deviations, evidence changes, outages, and incidents | Completeness depends on the research team recording events |
| Study report and DOCX | Panel composition, round movement, dispositions, themes, and methods text | Requires investigator review and contextual interpretation |
| Results CSV | Analysis-ready item and rating summaries | Data dictionary and manuscript-specific table design may still be needed |
| Trace bundle | Checksummed archive of audit, configuration, rule, event, and rating evidence | Checksums support integrity verification; they are not an external certification |
| AI manuscript runs | Draft Methods, Results, or Supplement prose | Drafts must be reviewed and approved; investigators remain the authors |
Recommended workflow
- Before launch: create an ACCORD checklist working copy and map every applicable item to a platform field, protocol section, or named investigator-owned document.
- At launch: review the snapshot and save the protocol or registration citation outside the platform where appropriate.
- After each round: review denominators, feedback, item changes, deviations, and study events while details are fresh.
- At study close: export the report, results, recruitment report, and trace bundle; verify that unresolved disagreement and attrition are represented.
- During writing: complete the ACCORD checklist against manuscript page or line numbers. Use CREDES to review Delphi-specific conduct details.
- Before submission: have a researcher who did not draft the first version reconcile the manuscript against the frozen rules, round history, and exported evidence.