Publishing & launch

The assembled design needs to be taken through review and publication, and then the study needs to be launched: enable sites and open subject enrollment. All of this lives on the Study Design screen (/studies/{studyId}/design) and on the lifecycle card of the Overview screen.

The Study Design screen is organized around three zones: the Design in effect (what all sites work against), the Design draft (what you are currently assembling) and a collapsed History of past versions.

0:000:00

The version path: Draft → Review → Approved → Published with segregation of duties.

Draft and effective design

The design has two fundamentally different roles:

• The draft — the working version: its content (visits, forms, fields, code lists, rules) can be freely changed. It is assembled visually — the Open builder, SoA matrix and Preview buttons in the draft zone lead to the CRF Builder; importing a ready-made JSON remains as the way to move a design as a whole.
• The effective (published) design — the version data is actually collected against. It is immutable — the builder opens it for viewing only.

A published design cannot be changed

After publication the version becomes immutable — neither a field nor a rule can be corrected in it. Any change is a new version (an amendment): you create a new draft, take it through the same path and, if data has already been collected against the old version, migrate the subjects. This guarantees reproducibility: it is always clear exactly what the user saw at a given moment.

The version path: review → approval → publication

The draft goes through four steps. On the screen this is shown as a “stepper” with one main action at each step:

Draft → In review → Approved → Published

1. Draftsubmit for review
2. In review
   • return to draftDraft
   approve
3. Approvedpublish
4. Published
   • next version publishesSuperseded

Branches

• Draft · In review · ApprovedretireRetired

The design version lifecycle: assemble → review → approve → publish, with a return to draft and supersession on amendment.

1. Draft — you assemble the design. When it is ready, click Submit for review (requires the studyversion.submit_review permission). Built-in validation here will not let a broken design through: dangling references to code lists, non-compilable rules, fields without types.

2. In review — a participant with the studyversion.approve permission checks the version and clicks Approve. Found problems? Return to draft: the version goes back to editing and is submitted for review again after rework (the author can also take their own version back after submitting it too early).

3. Approved — the version can be published: Publish (the studyversion.publish permission).

4. Published — the version becomes effective and immutable; the previously published version automatically moves to the “Superseded” status.

Above the main action button a checklist of “gates” — conditions that must be met — is always visible. For example, “The draft has no CRFs yet — assemble the design in the builder or import JSON”. When everything is ready, “All checks passed — ready for the next step” is shown.

Segregation of duties (SoD)

By default the author may approve their own version — the system simply records the fact of self-approval in the audit trail. If your organization’s rules require that the approver is not the author, enable the “Strict separation of duties on approvals” setting (core.sod.strict_approvals) — for the whole tenant or for a single study (Admin → Settings).

Strict mode: approver ≠ author

In strict mode, if the author tries to approve their own version, the system will refuse: “Approval requires a different user with the studyversion.approve permission”. If you are the author and at the same time an access administrator, a Set up access link will be next to it, so you can grant the permission to a colleague; otherwise ask an administrator. For organizations without a second pair of hands there is a documented exception.

Publication also has its own gates on the server side: all edit checks must be valid and, for a multilingual design, the translations of the declared languages must be approved (a single-language design is not subject to this gate).

JSON import and export: moving a design

The primary way to assemble is the builder, but a design can be moved as a whole file: Export JSON downloads the assembled design (for example, to hand it to another system or use it as the basis of a new study), Import JSON loads a ready one — instead of building from scratch.

Paste JSON

In the draft, click Import design (JSON) and paste the design JSON object.

Pick a file

In the same dialog you can pick a .json file — its contents are placed into the input field.

Before the import a preview is shown: “Events: M · Forms: N” — how many visits and forms will be in the design. After confirmation the draft content is replaced entirely, and you can keep refining it in the builder.

Import replaces the draft

The import wipes the current draft content completely. You can only import into a draft: a published version or one submitted for review is immutable.

Checking before hand-off

Before submitting the version for review, three short rituals are worth the time:

• The builder’s Problems panel — a live list of design open items: forms without fields, a form not linked to any visit, a “code” field without a codelist, a minimum greater than a maximum, and so on (see CRF Builder). The same checks run at submission for review — better to see them early.
• The preview — “live” every form: skip logic, derivations and checks work as during real entry, but nothing is saved. The recommended step before hand-off — see the form preview.
• Diff against a version — a comparison with another version, with changes classified as “safe / caution / breaking” and a list of forms that did not change (which do not need a repeat UAT).

A separate publication gate is translations, but only for a multilingual design: the core requires approved dictionaries of the declared languages. A single-language design (by default no CRF languages are declared) passes this gate automatically. Languages are declared in the builder: the More (⋯) menu → CRF languages (see CRF Builder).

Site activation

Subjects can only be enrolled in an active site, and a site is activated on top of a published design version. This is the Sites screen (/studies/{studyId}/sites).

1. Click Activate site (the site.activate permission; the button is unavailable until there is a published design).

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

3. The site appears with the Active status. Later it can be Closed (with a mandatory reason) — a closed site stops enrolling subjects, but entry and cleaning for already-enrolled ones continue; and it can be Reopened again.

UAT and go-live

Launching the study is done through transitions on the lifecycle card of the Overview screen. Two paths are possible.

With a test run (UAT)

From the draft, click Start UAT (gate: a published design). The UAT status is a test contour: all clinical flows work as in production, but every subject created is automatically marked as a test subject and excluded from “production” exports. So that nobody mistakes the run for real collection, a banner hangs above every study screen: “Test contour — all data is test data”.

The run is guided by the “UAT run” card on the Overview screen — a checklist of the end-to-end scenario, where each item links to the relevant screen and ticks itself off as you go:

1. A test subject exists — enroll a subject (it is marked as test right away).

2. Data entered — complete at least one form.

3. At least one query fired and was closed — trigger a check and resolve the query.

4. At least one SDV verification performed — verify a value as the monitor would.

5. At least one electronic signature applied — sign a form.

When the scenario is complete, click Go-live (gates: at least one active site, zero test subjects). If test subjects still remain, a separate dialog opens: to continue, you must explicitly confirm the irreversible deletion of all test subjects and their data and give a reason — the cleanup of the test contour is recorded in the audit trail.

Without UAT

You can launch straight away: from the draft — Launch without UAT. This is a deliberate decision, so the system will require a reason — it will be recorded in the audit trail. The gates are the same: a published design and an active site.

After go-live the study is in the Active status — enrollment and data entry are open, and no test subjects exist anymore. Onward through the lifecycle: Close enrollment → Close study → (at the closeout stage) archiving. The full status machines are in the Status reference.

Edits after publication: amendments

Since a published version cannot be changed, any protocol change is a new version. You create a new draft from the published one, take it through the same path and publish it. If data has already been collected against the old version, subjects need to be migrated to the new version — through a wizard with a diff, change classification and a preliminary run (dry-run) that shows the consequences (which signatures are invalidated, which SDV is reset) without side effects.

The migration console is the Amendments item in the study navigation (the “Closeout” group); it can also be reached from the collapsed History zone on the design screen. In detail — in the Amendments section.

What’s next

Creating a studyStudy statuses and the launch checklist.

CRF BuilderAssembling the draft visually: forms, fields, preview.

AmendmentsA new design version and subject migration.

Enrolling subjectsSubject enrollment after go-live.

Status referenceThe full lifecycles of the study and design versions.