eCRF specification from a protocol
What the specification contains, how versions work and how to read it back.
The eCRF specification is the document the database is built from and signed off before the study starts. The portal writes it from the draft read from the protocol: you review and edit instead of typing it from scratch.
How to get it
- Upload the protocol on the “Protocol to study build” page and correct the draft: visits, forms, fields.
- Click “Specification” at the top of the draft. Give the protocol version, the status and the document language. The language changes titles and query texts; questions stay in the protocol’s language.
- Download Excel or Word, or click “Print or save as PDF” and choose “Save as PDF”.
- When the version is ready for review, click “Issue this version”. An issued version never changes and downloads the same way later.
To see it at once, click “Specification” next to the training protocol YE-ONC-201. “Specification, version 2” next to its amendment first issues version 1.0 from the original protocol, then shows version 2.0 with the list of changes.
What is in it
- Cover: protocol number and title, the file and its SHA-256, protocol and specification versions, status, the signature table (data manager, reviewer, sponsor) and conventions: day 0, field codes, date format.
- Revision history and changes since the previous version: what the amendment changed in visits, procedures and eCRF forms.
- Visits with codes V01, V02…, days, windows, contact type and the event a visit is counted from. The visit × form matrix.
- Forms with their CDASH domain and conditions from footnotes. The fields of each form: code (CDASH variable), question, type, codelist, units, required, ranges, “not done allowed”, show-if condition.
- Codelists (code and decode). Identical answer lists are merged; yes/no is the NY codelist.
- Edit checks: possible and expected ranges, dates not in the future, library rules (end not before start, systolic above diastolic), visit not before consent, visit windows from the day 0 visit, conditions from footnotes (pregnancy test for a male participant). Logic is written as FORM.FIELD; hard checks stop the value from being saved, soft checks open a query.
- Open questions: what the portal does not decide for you. Forms not in the library, questionnaire licences, visits after an event and repeating visits, footnotes such as “pre-dose”, “fasting”, “some participants only”.
- From the protocol: where each procedure came from (page, table, row, footnotes), and the log of your edits to the proposal.
Editing in Excel and reading it back
You can edit the Excel file and upload it back on the “Protocol to study build” page, like a protocol. The portal recognises its own specification and makes a draft from it: visits, forms, fields, codelists and field rules. The study is built from that draft. Visit-window checks and footnote conditions are not read back: the mini-EDC has no such checks yet, they are instructions for the build.
The same file is read by “Specification check” in the DM workspace. Run the specification through it before review.