Skip to content
YouEDC docs

eCRF versions

Testing and release, the draft, comparing versions, deactivating instead of deleting.

Data entry should not change under the investigators' hands every time someone edits the eCRF. That is why the eCRF of a study is released in numbered, signed versions. Until version 1 the builder works live, for testing; after the release data entry keeps the version in force while the builder prepares the next version in a draft. The page opens from the eCRF builder, button “eCRF versions”, or from the notice at the top of every builder page.

REG-DIAB-01 · versions over time Data entry eCRF builder Testing changes at once v1 in force draft of v2 v2 in force draft of v3 Release v1 go-live Release v2 amendment 2 A release takes a reason and your password: the electronic signature. Data entry never sees the draft: it gets the changes with the next release.
REG-DIAB-01 · versions over time Data entry eCRF builder Testing changes at once Release v1 · go-live Release v2 · amendment 2 v1 in force draft of v2 v2 in force draft of v3 A release takes a reason and your password: the electronic signature. Data entry never sees the draft: it gets the changes with the next release.
REG-DIAB-01: version 1 released at go-live (reason “Go-live: the eCRF was tested with test patients”), version 2 with protocol amendment 2. Here “data entry” also means patient questionnaires (ePRO), import, export and the casebook.

Who does what

  • Project administrator: changes the eCRF in the builder, releases versions and discards the draft.
  • Data manager and monitor: open the versions page, compare versions and download them as JSON.

Testing: before version 1

A new study has no released version yet. The builder changes the design live: data entry uses it at once, so every form can be tried with test patients. A grey notice at the top of the builder says “Testing: the eCRF has not been released yet.”

To try both version 1 and every amendment after the launch on test patients, make the QA environment (a new study is made with it at once): the eCRF is built there, the candidate is tried on test patients who stay from version to version, and it is released into production. There the candidate gets its UAT: scripts made from its design, a robot on the edit checks, the executor's signature and another person's approval. With a QA environment, a version is released without a mark only when the UAT of its candidate is approved.

If the study is already enrolling and version 1 has not been released, the notice turns amber: changes take effect in data entry at once, and every change is written to the audit trail. The notice suggests releasing version 1, so that later changes wait in a draft.

Releasing a version

The left card of the versions page shows what will be released: for version 1 the size of the eCRF (visits, forms, fields, checks), later the changes waiting in the draft. To release:

  1. Write the reason for the release, for example “Protocol amendment 2: a laboratory form at month 6”.
  2. Enter your password again. It is your electronic signature under the release, in the manner of 21 CFR Part 11.
  3. Tick “I have checked the eCRF and sign the release of version 2.”
  4. Press Sign and release version 2.

The release is refused when no form is in any visit, or when a form in a visit has no active fields: the card lists the problems under “Not ready to release”. It is also refused when the draft is the same as the version in force: there is nothing to release.

The eCRF versions page of REG-DIAB-01 with the draft of version 2 and the release form
The versions page of REG-DIAB-01: the six changes waiting in the draft of version 2 and the release form with the reason and the password.

What a released version keeps

  • A snapshot of the whole design: visits, forms, fields, checks and the visit schedule (visits × forms), as JSON with its SHA-256 hash.
  • The reason, who released it and when, and the signature.
  • A released version never changes. JSON in the table of released versions downloads it, for the validation file or for another system.
  • The audit trail gets an “eCRF version released” record with the number of changes and the hash, for version 2 of REG-DIAB-01 “4 added, 1 changed, 1 deactivated · SHA-256 …”.
  • When the Trial Master File function is on, each released version also lands in the TMF inbox as the eCRF specification in CDISC ODM 1.3.2.

After the release: the version in force and the draft

Data entry, patient questionnaires (ePRO), import, export and the casebook use the version in force. The builder now edits the draft of the next version, and a blue notice at the top says so: “Version 1 is in force. You are editing the draft of version 2.”, with the number of changes waiting. Visits, forms and fields that are not in a released version yet are marked new. Each change in the draft is still written to the audit trail as an “eCRF change”.

The versions page lists the changes waiting in the draft:

  • added: a new visit, form, field or check, or a form ticked at a visit in the visit schedule;
  • changed: each property that changed, old → new;
  • deactivated and active again;
  • moved: a new place in its list;
  • removed: a form taken out of a visit in the visit schedule.
REG-DIAB-01 · draft of version 2 added Form LB · Laboratory tests deactivated Field · DM · Demographics and anthropometry EDU · Education changed Field · VS · Vital signs SBP · Systolic BP expected maximum: 180 → 160 added Field · LB · Laboratory tests HBA1C · HbA1c added Field · LB · Laboratory tests GLUC · Fasting glucose added Visit schedule Month 6 visit · LB Reason for the release Protocol amendment 2: a laboratory form at month 6 Audit trail eCRF version released 4 added, 1 changed, 1 deactivated SHA-256 9b41c2…e07a
REG-DIAB-01 · draft of version 2 added Form LB · Laboratory tests deactivated Field · DM EDU · Education changed Field · VS SBP · Systolic BP expected maximum: 180 → 160 added Field · LB HBA1C · HbA1c added Field · LB GLUC · Fasting glucose added Visit schedule Month 6 visit · LB Reason for the release Protocol amendment 2: a laboratory form at month 6 Audit trail eCRF version released 4 added, 1 changed, 1 deactivated SHA-256 9b41c2…e07a
The draft of version 2 of REG-DIAB-01 as the versions page lists it: form LB “Laboratory tests” added; the field EDU “Education” of the form DM deactivated; the expected maximum of SBP “Systolic BP” lowered from 180 to 160; the fields HBA1C and GLUC added to LB; LB ticked at the Month 6 visit.

Discard the changes puts the draft back to the version in force: what was added in the draft is deleted, and what was changed gets its released properties back.

Deactivate instead of delete

A visit, form or field that is in a released version, or that already has data, cannot be deleted. The builder offers Deactivate instead, and Make active again brings it back.

  • A deactivated element collects no new data and disappears from data entry.
  • Its data stays: in the patient card wherever the patient has data, in the export (Excel, CSV and ODM keep the columns) and in the casebook.
  • A released check cannot be deleted either: deleting it switches it off.
Delete or deactivate? A visit, form or field you no longer need Is it in a released version, or does it have data? Yes No Deactivate collects no new data and disappears from data entry; its data stays in the patient card, the export and the casebook e.g. EDU, released in v1 Delete never released and holds no data: it is simply removed e.g. a field added in the draft Checks: a released check is switched off instead of being deleted.
Delete or deactivate? A visit, form or field you no longer need Is it in a released version, or does it have data? Yes No Deactivate collects no new data, disappears from data entry; its data stays in the patient card, export, casebook e.g. EDU, released in v1 Delete never released, holds no data: simply removed e.g. a field added in the draft Checks: a released check is switched off instead of being deleted.
The builder shows the button that applies: Deactivate for EDU, released in version 1; Delete for a field added in the draft and never released.

What stays fixed

  • The code of a released form or field cannot be changed, so exports and analysis programs written for version 1 keep working with version 5.
  • The type of a field with data cannot be changed.
  • Answer options that patients already have cannot be removed from a choice field; their text can still be changed.

When a field really needs another code or type, deactivate it and add a new field: the old data stays under the old code.

Which version a form was saved under

Each saved form remembers the eCRF version it was last saved under. The table of released versions shows how many forms were saved under each version (“Forms saved”); forms saved before version 1 are counted as testing. The casebook shows the version of each form.

Comparing versions

Compare versions shows the differences between any two versions, or between a version and the draft, as the same list of changes, headed by the counts, for example “added: 4 · deactivated: 1 · changed: 1”. What changed in a row of the table compares that version with the one before it.

Comparing version 1 of the REG-DIAB-01 eCRF with the draft
Version 1 compared with the draft of version 2: the counts, then each change, with the old and the new value of what changed.
One amendment, one version. Try the eCRF with test patients before version 1 and release version 1 at go-live. After that, release one version per protocol amendment, with the amendment number in the reason: the table of versions then reads as the history of the protocol.

© 2026 Т.Г. (contact@youedc.com), YouEDC. All rights reserved. Terms of use. Data entered by users belongs to them.
MainEDC™ is a trademark of DM365.