PCI Registered Reports (PCI RR)
A peer-review route in which the study plan, measurement methods, and analysis approach are reviewed and granted in-principle acceptance (IPA) before outcome data are examined. It is the planned publication safeguard for the Speech Gap / BPD study, alongside ClinicalTrials.gov registration.
Registration, ethics approval, and Stage 1 in-principle acceptance are three separate processes, none of them yet completed.
Why it fits this study
A within-person longitudinal design with an exploratory prediction question is exactly the kind of work where post-hoc flexibility would quietly destroy credibility: choosing which of many temporal parameters to report, or which threshold to use, after seeing outcomes. Freezing the specification first removes that degree of freedom. → Longitudinal within-person measurement
The decisive distinction: access, not timing
Starting data collection before IPA does not automatically make PCI RR impossible. PCI RR can accommodate studies in which data exist before IPA. What matters is whether the data are accessible or have been observed.
The critical rule: accumulating study data must not be used to decide how the software, features, thresholds, exclusions, statistical model, or evaluation procedure should work. Development and validation should instead use synthetic data, external data, or a clearly separated pilot dataset.
Bias-control levels
| Level | Condition |
|---|---|
| 6 | Data do not yet exist at submission — maximum prospective protection |
| 5 | Data exist but are inaccessible to the authors before IPA |
| 4 | Data are accessible in principle, but the authors certify they have not accessed them |
| 3 | Data have been accessed, but no part relevant to the planned analyses has been observed |
| 2–1 | Increasing amounts of relevant data observed; additional or stringent safeguards required |
Beginning collection before IPA need not end the RR route, but it reduces the strength of the prospective design and may limit which PCI RR-friendly journals are eligible. The handling recommender should be informed immediately about any inflexible start date and the data-access safeguards in place.
What a Day-30 review decision would mean
| Criticism | Status | Response |
|---|---|---|
| Analysis or evaluation plan insufficient | Usually repairable | Lock accumulated data, revise the plan before inspecting outcomes |
| Evaluation code not yet developed | Usually repairable | Implement and test on synthetic, external, or pilot data |
| Software testing or validation inadequate | Usually repairable | Add tests, validation datasets, prospective acceptance criteria |
| Feature definitions or algorithm need clarification | Often repairable | Freeze the revised specification prospectively, document the change |
| Acquisition software produced unreliable recordings | Potentially fatal for early data | The first 30 days may be unusable; missing information cannot be reconstructed |
| Review requires changing what or how data are recorded | Major difficulty | Pre- and post-change observations may not be comparable |
| The therapy procedure itself must change | Major difficulty | The study may no longer implement one consistent protocol |
| Outcome-related variables already inspected | Serious threat | Prospective bias protection falls substantially; safeguards or redesign may be required |
Recommended safe timeline
- Day 1 — Submit a detailed measurement and analysis specification: the software’s intended inputs, outputs, feature definitions, quality-control rules, exclusions, validation criteria, and planned statistics.
- Day 2 onward — Collect recordings and clinical data, but encrypt or sequester outcome-relevant information from the software-development and analysis teams.
- During Stage 1 review — Develop and test the software only with synthetic, external, or explicitly separated pilot data.
- After Day-30 feedback — Revise the methods, document exactly what changed and why, and obtain the recommender’s and reviewers’ approval before examining study outcomes.
- Before unblinding — Freeze the source-code commit, container image, dependencies, feature definitions, QC criteria, exclusions, statistical analysis plan, and evaluation scripts.
- After the 12-week collection — Unlock the data and run the frozen pipeline. Label any additional analyses clearly as exploratory.
When repair is insufficient
If a Day-30 review finds the original acquisition method was incapable of producing valid measurements, improved downstream software cannot reconstruct information that was never captured. The defensible options are to exclude pre-correction participants prospectively, treat early observations as pilot data and restart the confirmatory cohort, or redesign and resubmit the Stage 1 proposal.
The bottom line
Software implementation, testing, and evaluation may be completed during the 12-week collection period if the raw data are collected reliably, outcome-relevant information remains unseen, and all revised methods are approved and frozen before evaluation.
What cannot safely be postponed is the prospective definition of the measurement, its validity criteria, and the safeguards preventing accumulating data from influencing development decisions.
Source: PCI Registered Reports, “Guide for Authors”.
Related pages
Speech Gap · Semmelweis / VIKOTE · Longitudinal within-person measurement · Respiratory signal extension · Data governance and annotation