Publish a version and launch the study

A built design has to go through review, approval and publication, and then the study is launched: sites are added and subject enrollment is opened. The version is driven on the study’s Design page — a six-stage pipeline with one main button per stage; the launch happens in the Path to launch guide on the Overview screen.

Who and when

The task is split between people — that is how segregation of duties (SoD) works:

• Data manager the study designer (Study Builder) builds the version and hands it over for review — the “submit a version for review” permission (studyversion.submit_review);
• Data manager the data manager reviews and approves — the “approve a version” permission (studyversion.approve);
• Administrator the administrator publishes the version (studyversion.publish), adds sites (site.activate) and moves the study through its statuses (study.lifecycle.change).

This is how the role templates distribute the permissions; your organisation may distribute them differently.

The task comes up when the first design is built, and with every protocol amendment.

Before you start

• The version is a Draft, it has forms and visits, and the builder’s Problems panel shows no errors.
• Every form has been walked through in the preview.
• If the design declares CRF languages, the translations are approved. A single-language design is not affected.
• Another person will approve — agree with them in advance.

Steps

0:000:00

The version path: draft → review → approval → publication, with segregation of duties.

Take the version through the pipeline

1. Basis. Open the Design section. While the version has no forms, the stage offers a start: Open builder or Import design — from a file following the template.

2. Build (author). Build the visits, forms and checks. When the stage checklist says “No build errors”, click Hand over for review. The version gets the In review status.

3. Review and sign-off (approver). Click Open comments, look through the design and leave comments on elements. Documents for sponsor sign-off are in the Version pack side panel (the For sign-off group). If rework is needed — Return to draft; the author can return the version too.

4. Testing. If configuration testing is required for the version and there is no evidence for the current design, the stage offers Open testing (the eCRF configuration testing module). Without it, approval is only possible with Approve with a reason — the reason stays in the audit trail.

5. Approval (approver). Check the What changed since version … block, click Approve and confirm. The version gets the Approved status.

6. Publication (publisher). When the checklist says “Nothing blocks publication”, click Publish and confirm. The version gets the Published status.

Add a site

1. Open the Sites section and click Add site… (the button is unavailable while there is no published design).

2. Enter the Site code, Site name and Design version (by default the newest published one) and click Activate.

The site appears in the Active status. Later it can be closed with Close site (a reason is mandatory) — enrollment there stops, but entry and cleaning for subjects already enrolled continue — and opened again with Reopen.

Launch the study

Open the study’s Overview: in the Path to launch guide, the Open enrollment zone shows the available transitions and their gates.

With a test run (UAT)

1. Click Start UAT (gate: Published design) and confirm. The study moves to the UAT status.

2. Work through the Test run checklist — items tick themselves as you go: A test participant was created · At least one form was completed · At least one query was opened and closed · Source data verification (SDV) was performed · An electronic signature was applied.

3. Click Go-live (gates: Active site, No test subjects). If test subjects remain, explicitly confirm in the dialog the irreversible deletion of all test subjects and their data, and enter a reason.

Without UAT

1. In the Draft status, click Launch without UAT.

2. Enter a reason — launching without a test run is recorded in the audit trail as a deliberate decision. The gates are the same: Published design and Active site.

Release an amendment

A published version cannot be changed. On the Design page click Start an amendment — a draft copy of the version in effect appears; take it through the same pipeline. If there are already subjects on the previous version, the last stage is called Publish and migrate, and the button reads Publish and migrate N subjects: after publication the Amendments screen opens, where you review the consequences and start the migration (see Run a protocol amendment).

What happens

• Every pipeline step — hand-over for review, return, approval, publication — is written to the audit trail and the design change log. An author’s self-approval is flagged in the audit trail as self_approved.
• After publication the version Published becomes the one in effect and is immutable; the previously published version automatically becomes Superseded. Toast: “Design published — site activation is now open”.
• The Version pack gains the deployment report.
• In the UAT status a banner “Test contour — all data is test data” hangs above every study screen; every new subject is flagged as a test subject and excluded from production exports.
• After go-live the study is Active: enrollment and entry are open, no test subjects remain, and the Path to launch guide disappears.

If it doesn’t work

• “Design validation found N errors. The version cannot go to review while they remain.” — click Open the problems and fix the errors in the builder.
• “The draft has no CRFs yet” — build the design in the builder or import a file.
• “You don’t have permission to submit the design for review” / “Approved by a member with design approval rights” / “You don’t have permission to publish the design” — you lack the corresponding permission; a colleague takes the next step.
• “The design must be approved by someone other than its author” — strict segregation of duties is on and you are the author. Hand approval to a colleague; if you administer access, there is a Set up access link next to it, otherwise ask an administrator to grant the permission.
• “No approved translation for the required locale(s) … Publication is blocked without it.” — Go to translations and approve the translation.
• “Publish a design version first — a site is only activated on a published version” — finish the publication.
• “Go-live” or “Start UAT” is disabled — a gate is not met (it is marked in the Open enrollment zone); “Only a study administrator can open enrollment.” — you don’t hold study.lifecycle.change.

Next

Enrol a subjectSubject enrollment after go-live.

Run a protocol amendmentA new design version and subject migration.

Segregation of dutiesWhy the author doesn't approve, and how the exception works.

Status referenceThe full lifecycles of the study and design versions.

More details

Draft and the design in effect

• A draft is the working version: its content (visits, forms, fields, codelists, rules) can be changed freely in the CRF builder or replaced by importing a design from a file.
• The design in effect (published) is the version data is actually collected against. The Design page header reads “Version … in effect since …”. It is immutable: the builder opens it read-only (View design).

A published design cannot be changed

After publication the version is immutable — not a single field or rule can be fixed in it. Any change is a new version (an amendment) taken through the same path; if data was already collected on the old version, subjects are migrated to the new one. This way it is always clear what exactly a user saw at a given moment.

The version lifecycle

The pipeline has six stages, while a version has four main statuses: the “Review and sign-off”, “Testing” and “Approval” stages all happen while the version is In review.

1. Drafthand over for review
2. In review
   • return to draftDraft
   approve
3. Approvedpublish
4. Published
   • the next one is publishedSuperseded

Branches

• Draft · In review · Approvedwithdraw from useRetired

The design version lifecycle: build → review → approval → publication, with return to draft and replacement by an amendment.

A version can be taken out with Withdraw from use in the More actions menu (permission studyversion.retire): a retired version cannot be edited or published. The full status machines are in the Status reference.

Segregation of duties (SoD)

By default the author may approve their own version — the system warns “You are the author of this version” and records the self-approval in the audit trail. If your organisation’s rules require that the approver is not the author, turn on the “Strict separation of duties on approvals” setting (core.sod.strict_approvals) — for the whole tenant or for a single study. In strict mode the approve button is blocked for the author. For organisations without a second pair of hands there is a documented exception — the personal studyversion.self_approve permission.

Unresolved review comments do not forbid approval — the approver sees the warning “There are unresolved review comments” and decides.

What to check before hand-over

• The Problems panel — a live list of gaps; the same checks run when the version is handed over for review.
• Preview — skip logic, derivations and checks work as in real entry, but nothing is saved.
• What changed — for an amendment the page shows a human-readable list of changes against the version in effect, with an assessment: “data not affected”, “new rules for entered data” or “affects collected data”. Any two versions can be compared with Compare versions.

Publication also has its own server-side gates: all edit checks must be valid and the design integrity check passed, and for a multilingual design the translations of the declared languages must be approved.

The version pack

The Version pack button opens a side panel with the version’s documents by stage: For sign-off (blank CRF, annotated CRF, specification; Download all), Testing, Approval and publication (the deployment report — appears after publication) and Transfer and import (the version design and the template for preparing a design). The system does not store the sponsor sign-off mark yet.

After launch

Further along the lifecycle: Close enrollment → Close study → archive. These transitions are performed on the Locks screen (the closing pipeline), not on the Overview. Closed enrollment can be reopened with Reopen enrollment (with a reason), a closed study with Reopen for late data.

UAT is a test contour

In UAT every clinical flow works as in production, but every subject is a test subject. Removing the test subjects before go-live is irreversible and is recorded in the audit trail together with the reason.