Arion · eCRF platform

Study Builder Guide

A practical, step-by-step guide to configuring a study in Arion — translating a clinical protocol into a working, operational data-collection model.

Audience
Study Builder · Study Manager
Scope
The Study Design area
Revision
August 2026

This guide is written for the Study Builder role (study_builder) — the person who translates a clinical protocol into a working study in Arion. It walks through everything you configure in the Study Design area, in roughly the order you'll build it, and explains the choices that shape how sites later capture and review data. Study Managers and admins who also configure studies will find it equally useful.

01 What the Study Builder does (and why it matters)

Study setup and design is the foundation for everything else in Arion. This is where you define how the study will operate in practice: what information is captured, when it's collected, how it's validated, and what review controls apply.

The goal of the design area is to give you a structured way to translate a protocol into an operational data-collection model. Rather than building forms in isolation, Arion links your study definition directly to the later patient, visit, review, and analytics workflows.

Design time binds to capture time

Protocol design binds to operational data A protocol row of Study, Event, Page and Field sits above an operational row of Patient and Enrollment, Occurrence, Form instance and Field value, with dashed lines binding Event to Occurrence, Page to Form instance, and Field to Field value, showing that captured data always traces back to the design object that defines it. PROTOCOL · DESIGN TIME Study Event Page Field OPERATIONAL · CAPTURE TIME Patient Enrollment Occurrence Form instance Field value every captured value traces back to its field definition
A field isn't just a label — it is the definition that produces every value collected for it.

The decisions you make here become the operational rules that drive patient registration, casebook data entry, completion tracking, SDV review, query generation, protocol-deviation monitoring, and downstream analytics. Getting the design right is what lets the rest of the platform run consistently.

02 Your role and what you can do

The Study Builder is the most focused study-configuration role — its job is study design. You work in the Study Builder to define and maintain the study structure, but it is not intended for operational patient workflows.

RoleRelationship to study design
study_builderYou. Design the study.
Study managerCan also configure studies while supervising operations.
Platform / tenant adminBroad configuration authority.
Data manager, statisticianMay have visibility into the study structure without being primary configuration owners.
Site PI, site coordinatorConsumers of the workflow you design, not designers of it.
One important limit

The publication actions (Publish for Testing, Publish to Production) are reserved for study_manager, tenant_admin, and platform_admin. You design and iterate; a manager or admin performs the go-live steps (see sections 12–14).

03 The big picture: what you'll configure

The Study Design area lets you configure the operational structure of a study before any patient activity begins.

The builder at a glance

What each Study Builder tab configures A tab bar of eight tabs — General, Planning, Forms, Safety rules, Events, Lifecycle, Queries and Data review — colour-grouped into three concerns shown below: Structure (Forms and Events), Rules (Safety rules, Queries and Data review), and Lifecycle (General, Planning and Lifecycle). A note records that publish actions belong to manager and admin roles. General Planning Forms Safety rules Events Lifecycle Queries Data review Structure Forms · Events pages, fields, field types visits and linked forms visit-specific form order Rules Safety · Queries · Data review validation and completion automatic query generation SDV strategy, prohibited meds Lifecycle General · Planning · Lifecycle identity, codes, sample size screening, criteria, enrolment rescreening, waivers Publish for Testing and Publish to Production are performed by study_manager, tenant_admin or platform_admin — not by the study_builder role directly.
Eight tabs, three concerns: the structure you capture, the rules that govern it, and the participation lifecycle around it.

Across the builder you'll define:

  • core study metadata (identity and planning)
  • study timelines and planning information
  • visit and event structure
  • pages and forms
  • field definitions and validation rules
  • eligibility (inclusion/exclusion) criteria
  • review rules such as SDV settings
  • study-specific safety controls such as prohibited medications

Together these create a controlled study blueprint that produces consistent data capture across users, patients, and centers.

04 Study-level configuration (identity & planning)

Start at the study level, where you define the main identifying and planning information:

  • study name
  • short study code
  • protocol code
  • lifecycle status
  • sample size
  • planning dates and timeline expectations

These settings establish the identity and operational context of the study, and they feed downstream visibility in dashboards, operational summaries, and study administration. Planning fields (sample size, dates) are especially valuable when the platform is used for ongoing monitoring, because they let teams compare actual activity against intended timelines and recruitment expectations.

The Study Builder open on the General tab, with the tab bar across the top — General, Planning, Forms, Safety Rules, Events, Lifecycle, Queries, Data Review — and fields for study name, study code, protocol code, description, and an optional sample size alongside per-center goals.
Capture to be providedStudy-level configuration on the General tabassets/screens/builder-general-tab.png
Study-level configuration on the General tab. The tab bar across the top — General, Planning, Forms, Safety Rules, Events, Lifecycle, Queries, Data Review — is the map of everything in section 3; sample size can also be broken down into per-center goals.

05 Pages, forms, and fields

Arion structures study forms around pages and fields, with visit-specific ordering controlled from the event definition (see section 8). Building with pages instead of one long form makes the data-collection experience easier to navigate and closer to how visits actually work.

Each study can include multiple pages, and each page can contain multiple fields. You manage all of this from the Forms tab, where you create, rename, delete, and configure pages and their fields.

Field types you can define

  • text and long-text fields
  • numeric fields
  • date and time fields
  • enum and selectable-value fields
  • checkbox-style fields
  • repeatable sections for grouped entries
  • derived fields calculated from other data points
A key detail about ordering

Pages are not globally sortable in the Forms tab. When you need to control the order in which forms/pages appear for a given visit, you set that order inside the Events tab for the specific event. This lets the same page sit in different positions depending on the visit.

The Forms tab: a Pages column on the left, each page card showing its field count and a Full SDV / No SDV toggle, beside a Fields column for the selected page listing each field with its type, key, Required badge and position number.
Capture to be providedThe Forms tab / form builderassets/screens/builder-forms-tab.png
The Forms tab: pages on the left, the selected page's fields on the right. Each field shows its type, key, whether it is required, and its position. Note that fields carry drag handles but pages do not — page order is set per event, not here.

06 Field requirements and value validation (the non-blocking model)

This is one of the most important concepts to understand, because Arion deliberately keeps data entry non-blocking. Nothing you configure at the field level will stop a site from saving.

The non-blocking model

How validation behaves without blocking the save A value entered by the site is always saved — the save is never blocked. From there the flow branches: a value within the rules is simply fine, while a value outside range or format shows an amber warning and is still saved. On form completion, the out-of-range value can become a query if automatic query generation is configured. Value entered Saved never blocked Within the rules nothing further happens Outside range or format non-blocking warning — the value is still saved On form completion → query only if you enabled it in Queries settings
Clinical data entry stays fluid; quality issues are surfaced visually and, where you configure it, captured formally as queries.

Required fields

You can mark a field as required. In the current version, leaving a required field empty does not block saving the form — the site can save partial data and come back later. Instead, required fields do two things: they drive form completion, and they can (optionally) drive automatic queries.

Range and format rules (soft validation)

Fields can carry range and format rules — minimum/maximum values, minimum/maximum length, and pattern checks. These are treated as soft validation: when an entered value falls outside the configured range or format, Arion shows a non-blocking warning indicator on the field, but the user can still save.

Removed behaviour

There is no longer any per-field “strict” flag that hard-blocks saving — that behavior has been removed in favor of the warning-plus-query model.

Defining field validation rules in the form builder.
Capture to be providedDefining field validation rules in the form builderassets/screens/builder-field-validation.jpg
Defining field validation rules in the form builder

Form completion

A form is considered complete when all of its required fields are filled (or when it's explicitly marked complete). Reaching completion is the moment any configured automatic queries for that form are generated. The net effect: clinical data entry stays fluid — sites are never stopped mid-entry — while quality issues are surfaced visually and, where you configure it, captured formally as queries.

A non-blocking out-of-range warning during data entry.
Capture to be providedA non-blocking out-of-range warning during data entryassets/screens/builder-range-warning.jpg
A non-blocking out-of-range warning during data entry

07 Query generation settings

The Study Design area includes a dedicated Queries configuration section where you decide whether Arion should automatically raise queries for common data situations, and what initial status those queries get.

Automatic query generation

The four automatic query generation settings Four settings, all defaulting to off: out-of-range or invalid values, empty required fields, and every SDV discrepancy each raise a query with a configurable initial status of candidate or open; auto-closing resolved auto-generated queries is optional and off by default. All four default to OFF — automatic query generation is always an explicit choice. Out-of-range or invalid values raises a query once the form reaches completion candidate or open Empty required fields required fields still empty at form completion candidate or open Every SDV discrepancy always linked — the per-discrepancy checkbox is hidden while on candidate or open Auto-close resolved auto-queries closes once the value is corrected or the field completed off by default Candidate = held for a reviewer to promote before the site sees it. Open = immediately visible to the site.
These tune how strictly data-quality issues become formal queries — without changing the non-blocking entry experience.

The available settings are:

  • Automatically generate queries for out-of-range or invalid values. When on, values outside a field's configured range or format produce a query once the form reaches completion. You choose the initial status: candidate (held for a reviewer to promote before the site sees it) or open (immediately visible to the site).
  • Automatically generate queries for empty required fields. When on, required fields still empty at form completion produce a query, again with a configurable candidate or open initial status.
  • Automatically generate a query for every SDV discrepancy. When on, flagging any SDV discrepancy always raises a linked query with the configured status — even if the person flagging it can't otherwise create queries. Because the outcome is fixed, the per-discrepancy “also create a query” checkbox is hidden in the SDV dialog. When off, that optional checkbox remains available.
  • Automatically close auto-generated queries when the underlying issue is resolved. Optional and off by default (a reviewer closes them manually). When on, an auto-generated query closes automatically once the value is corrected or the required field is completed.
The Study Design Queries settings tab.
Capture to be providedThe Study Design Queries settings tabassets/screens/builder-queries-settings.jpg
The Study Design Queries settings tab

08 Visits and events (ordering, and the visit workflow setting)

Study data in Arion is visit-oriented. In the Events tab you define study events that represent planned visits or other structured collection points in the timeline.

Each event is associated with one or more study pages, so the design area isn't only defining fields — it's defining when and where those fields appear in the operational workflow. This is also where you control visit-specific form order: you can sort the linked forms/pages within the event itself, so a page can appear in a different position depending on the visit, without any global reorder from the Forms tab.

Configuring events well supports scheduled visit planning, alignment between the protocol timeline and data capture, patient-level completion tracking by visit, and clearer operational reporting on what has and hasn't been collected. By linking events to pages in advance, you ensure later patient casebooks follow the intended structure instead of relying on ad hoc form access.

The Events tab: an event card with its name, Required and Screening event flags, target day and window in days, an SDV toggle, and a Linked pages list whose entries are numbered and draggable to set the order used in this event, with the remaining pages offered underneath.
Capture to be providedVisit / event structure with linked formsassets/screens/builder-events-structure.png
An event and its linked pages. The numbered entries are dragged to set the order used in this event — the same page can sit in a different position elsewhere. Note the Screening event flag and the target day and window alongside it.

Screening events

If your study uses a screening period (section 9), you also mark which events are screening events here. Only events flagged as screening events are open for normal casebook data entry while a subject is still in screening; the remaining scheduled events materialise once the subject is enrolled.

Visit workflow: can sites enter visits out of order?

At the top of the Events tab there is a Visit workflow card that controls whether data entry is gated on earlier visits being complete. Arion previously enforced a single hard rule — every form in every prior visit had to be complete before any data could be entered in a later visit. That is now a study-design choice with three modes:

Visit order modes

The three visit ordering modes Three panels, each showing visits one to four with visit two incomplete while the site enters visit four. Any order: the save succeeds with no gate, the default for new studies. Warn if out of order: the save succeeds but is flagged, with an optional query on the earlier visit. Require in order: the save is refused until visit two is complete, and the message names the blocking visit. Any order open · default for new studies V1 V2 V3 V4 V2 incomplete · site enters V4 Save succeeds No gate at all. Sites enter visits as the data arrives. Default for new studies. Warn if out of order warn V1 V2 V3 V4 V2 incomplete · site enters V4 Save succeeds — flagged Optionally tick “also raise a query on the incomplete earlier visit” — where the outstanding work actually is. Require in order strict · backfilled for old studies V1 V2 V3 V4 V2 incomplete · site enters V4 Save refused Blocked until V2 is complete. The message names the blocking visit.
The mode becomes read-only in production, like the rest of study design — changing it then requires an amendment.
  • Any order (open) — no gate. Sites enter visits in whatever order the data arrives. This is the default for new studies and matches how most protocols actually run (labs come back late, a monitor finds a missing page from visit 1 while the subject is at visit 5).
  • Warn if out of order (warn) — the save succeeds, but the out-of-order entry is flagged. You can additionally tick Also raise a query on the incomplete earlier visit, which puts the query where the outstanding work actually is, rather than on the visit being entered.
  • Require in order (strict) — the original blocking behaviour. Saving form data in a later visit is refused until earlier scheduled visits are complete, and the message names the specific blocking visit.
The Visit workflow card at the top of the Events tab, offering three mutually exclusive order modes — Any order, Warn if out of order, and Require in order — under the note that visit windows always apply.
Capture to be providedThe Visit workflow card at the top of the Events tabassets/screens/builder-visit-workflow.png
The Visit workflow card at the top of the Events tab: the three order modes, mutually exclusive. The card's own subtitle makes the point above — visit windows always apply, whichever mode you pick.

09 The Lifecycle tab: screening and eligibility

This area has changed significantly. Eligibility criteria are no longer configured on separate Inclusion criteria and Exclusion criteria tabs. Those tabs have been replaced by a single Lifecycle tab that holds one shared inclusion/exclusion criterion editor together with the screening period, enrolment, screen failure, rescreening, and waivers.

The lifecycle you are configuring

Patient screening and enrollment lifecycle Registered leads to Screening with tri-state eligibility answers. Screening branches to Enrolled or Screen failed. Screen failed can loop back to rescreening or exit the study. Enrolled leads to a terminal lifecycle state, Completed, Withdrawn, or Discontinued, each of which still leaves safety follow-up open. Registered Screening tri-state criteria explicit enrolment criteria not met Enrolled Screen failed rescreen (if permitted) study exit Completed Withdrawn Discontinued safety follow-up remains available
The Lifecycle tab configures every transition on this diagram.
The Lifecycle tab with the screening period enabled: checkboxes for allow rescreening and allow eligibility waivers, an eligibility confirmation selector, a rescreen subject code selector with a copy form data option, and a screen-failure reason list of code and label pairs.
Capture to be providedThe Lifecycle tabassets/screens/builder-lifecycle-tab.png
The Lifecycle tab: screening period, rescreening, waivers, eligibility confirmation, and screen-failure reasons. Each failure reason is a code and label pair — the code is what gets stored, the label is what the site sees.

Turning on a screening period

Tick “This study has a screening period”. New subjects then register into a screening status instead of going straight to enrolled, and only the events you flagged as screening events in the Events tab are open for data entry until the subject is enrolled.

Screening options

  • Allow rescreening — a failed screening attempt is kept and a new linked screening record is created rather than overwriting the original assessment. Under Rescreen subject code you choose whether the rescreen creates a new subject code or reuses the screening one, and Copy form data controls whether values already entered are carried onto the new record. Subject codes are unique within a study and appear in patient URLs, so agree with your team which option to standardise on before go-live.
  • Allow eligibility waivers — permits a reviewer to waive a failing criterion. A waiver also requires the individual criterion to be marked waivable and the user to hold reviewer permission; site roles cannot grant one. A granted waiver automatically creates a linked auto_eligibility_waiver protocol deviation.
  • Eligibility confirmation — choose whether enrolment must be confirmed by the Principal investigator or a Site coordinator. Selecting PI requires that PI's password confirmation at the moment of enrolment.
  • Screen-failure reasons — the code/label list sites pick from when recording a screen failure. Define these up front; a screen failure always stores a reason and a clinical date.

Eligibility criteria and evaluation modes

Criteria are defined once in the shared editor, each with a code (e.g. I1, E1), the criterion text, a waivable flag, and — this is new — an evaluation mode.

Criteria: modes and answer states

Criterion evaluation modes and the three answer states On the left, three evaluation modes: Manual, where the site records the answer; Field, bound to a screening field with an operator and comparison value; and Formula, an expression over screening data. On the right, three answer states: yes counts toward eligible, no fails that criterion, and not assessed leaves the assessment pending. A highlighted note states that pending never auto-fails and that a missing source value resolves to Not assessed. EVALUATION MODE Manual the site records the answer directly Field bound to a screening field — age · At least · 18 Formula an expression over screening data — age >= 18 Field pickers only offer fields that exist in screening events. ANSWER STATE yes counts toward eligible no fails that criterion not assessed leaves it pending Pending never auto-fails A missing source value on a computed criterion resolves to Not assessed, not to a failure.
Incomplete screening data produces a subject who cannot be enrolled yet — never one who is wrongly failed.
  • Manual — the site records the answer directly. This is the classic behaviour.
  • Field — the criterion is bound to a screening field and evaluated from the entered data using an operator (equals, not equal, greater than, at least, less than, at most) and a comparison value. For example: age · At least · 18.
  • Formula — an expression evaluated from screening data that must resolve to a boolean, e.g. age >= 18.

Field and formula criteria retain the value and evidence used for the evaluation, so a reviewer can trace a verdict back to the source field. Field pickers only offer fields that exist in screening events, and the study will not save if a criterion points at a field outside screening.

The shared criteria editor, with Inclusion criteria and Exclusion criteria as two sections of one editor. Each criterion carries its text, a code, an evaluation mode and a waivable checkbox; the criterion in Field mode adds a field picker, an operator and a comparison value.
Capture to be providedThe shared inclusion/exclusion criteria editorassets/screens/builder-criteria-editor.png
Inclusion and exclusion criteria now live in one editor. Criterion I3 is in Field mode, so it gains the three-part binding Age · At least · 18; I1 and I3 are marked waivable, I2 is not.

Three answer states — and why nothing auto-fails

Criteria now use three states: yes, no, and not_assessed. An unassessed criterion leaves the assessment pending — it never produces a screen failure on its own. A missing source value on a computed criterion likewise resolves to Not assessed, not to an automatic failure. The assessment can be saved while incomplete, and answers autosave.

The practical consequence for your design

Incomplete screening data results in a subject who simply cannot be enrolled yet, rather than one who is wrongly failed. A screen failure is always an explicit, attributable act by the site.

10 SDV and review configuration

Source Data Verification (SDV) settings are part of study design, so review expectations are defined up front rather than improvised once data arrives. Configure them from Data review → Source Data Verification. The first decision is the study-wide strategy; when it is set to Use configured hierarchy, each field value ultimately resolves to either Full SDV (must be source-verified by a reviewer) or No SDV (no verification required).

First choose the study-wide strategy

ChoiceBehavior
Use configured hierarchyThe default. Uses the field, page, and visit settings below, plus the separate Eligibility SDV choice.
Full SDVConfirmed override that requires SDV for every configured field, form, and visit, and for eligibility decisions. The hierarchy remains saved beneath the override.
No SDVConfirmed override that removes SDV requirements across the study, including eligibility. The hierarchy remains saved so it can be restored by selecting Use configured hierarchy.

Use Full SDV or No SDV for a deliberate study-wide policy. Use the hierarchy when the protocol needs targeted coverage. The builder asks for confirmation before either study-wide override is applied.

Then configure the hierarchy when needed

  • Field level — set on an individual field in the field editor (Forms tab). A field can also be left to inherit, meaning it takes its behavior from the levels above it.
  • Page (form) level — set on each page/form card (Forms tab).
  • Visit (event) level — set on each event using the SDV control on the event card (Events tab).

How the hierarchy resolves (important)

Arion treats SDV as an opt-in to verification. Everything is No SDV by default, and each level can add a Full SDV requirement on top of the others.

SDV resolves additively

How the three SDV levels resolve Field level, page level and visit level each feed an OR gate. If Full SDV is set at any one of them, the value requires Full SDV, resolved per field and visit. A note records that reducing verification means removing Full SDV at whichever level introduced it, because a field left on inherit or No SDV does not cancel a requirement coming from its page or visit. Default: No SDV. Each level can ADD a Full SDV requirement. Field level field editor · Forms tab Page level page card · Forms tab Visit level event card · most targeted OR Value requires Full SDV resolved per field × visit To reduce verification, remove Full SDV at the level that introduced it. A field left on inherit or No SDV does not cancel a Full SDV coming from its page or visit.
Because the requirement is additive rather than a strict override, the visit level is the most targeted control — it can require verification for one visit alone.
  • Marking a field as Full SDV means it must be verified wherever it appears, in every visit.
  • Marking a page as Full SDV applies Full SDV to every field on that page, across all visits.
  • Marking a visit as Full SDV applies Full SDV to every field on the pages linked to that visit — but only for that visit.

Because the requirement is additive, not a strict override, a field “needs verification” if Full SDV is set at the field, at its page, or at the visit where it appears. The visit level is the most targeted control: it can require verification for one visit without forcing that field to be verified in every other visit. Conversely, leaving a field on inherit or No SDV does not cancel a Full SDV coming from its page or visit — to reduce verification you must remove the Full SDV at whichever level introduced it.

When you save the design, Arion resolves these three levels into a concrete verification plan for each field-and-visit combination. That resolved plan drives the SDV workspace, where reviewers see exactly which values require source verification per visit and can mark them verified or flag discrepancies. The payoff: SDV expectations are consistent and predictable, defined as part of the protocol structure rather than decided case by case.

Eligibility SDV and PI signature

The same Source Data Verification section contains Eligibility SDV. It defaults to No SDV and is editable only while Use configured hierarchy is selected. Choose Full SDV to create a dedicated, pending SDV record for each decided eligibility assessment, including a screen-failure decision. A study-wide Full SDV includes eligibility automatically; study-wide No SDV excludes it.

Require SDV before PI signature belongs to the PI Signature section below. It is available only when at least one SDV scenario is active. If the study is changed to No SDV, Arion disables and clears that dependency so a signature cannot be gated on review that the study does not require.

Field-level SDV strategy in the field editor.
Capture to be providedField-level SDV strategy in the field editorassets/screens/builder-sdv-field.jpg
Field-level SDV strategy in the field editor
Page-level SDV strategy in the Forms tab.
Capture to be providedPage-level SDV strategy in the Forms tabassets/screens/builder-sdv-page.jpg
Page-level SDV strategy in the Forms tab
The Events tab, showing the Full SDV / No SDV toggle on the event card itself, to the right of the event's target day and window.
Capture to be providedVisit (event)-level SDV strategy in the Events tabassets/screens/builder-events-structure.png
Visit (event)-level SDV, set by the SDV toggle on the event card. Setting it here requires verification of every field on that event's linked pages — but only for this event.

11 Safety controls: prohibited medications

Arion lets you configure study-specific safety rules at design time. The main example is defining prohibited medications for the study.

This ensures safety rules aren't only documented but actually operationalized: once configured, they can later drive review and protocol-deviation workflows tied to real patient activity (for instance, recording a prohibited medication can automatically raise a protocol deviation). Placing these controls in study setup moves your team from passive configuration to enforceable operational rules.

Prohibited medications configuration.
Capture to be providedProhibited medications configurationassets/screens/builder-prohibited-medications.jpg
Prohibited medications configuration

12 The study lifecycle: draft to testing to production

Arion clearly separates a study that's still being validated from one that's live for real data collection. Three lifecycle stages matter most.

Study lifecycle

Study lifecycle: draft to testing to production Draft publishes forward into Testing, which publishes forward into Production with a typed confirmation. Production cannot roll back to Testing because publishing permanently clears disposable testing data. In production the design is no longer edited directly; authorized builders change it through a reviewed amendment draft that publishes a new version without deleting collected data. no rollback · amend via new version Publish for Testing Publish to Production typed confirmation required Draft protocol fully editable Testing disposable test patients & data Production design changes by amendment patient workflows live
Publishing to production is one-way for the lifecycle state: it permanently clears existing operational data. From then on the design is no longer edited in place — authorized users start a private amendment, review its impact, and publish a new version that never deletes collected data.

Draft

The study is still being configured. This is where you define the protocol structure, form layout, events, criteria, and review settings before any workflow validation. Patient workflows are not available in draft.

Testing

You can still edit the design in the Study Builder, and the study acts as a disposable validation environment. During testing, users can create test patients, register visits, enter values, generate queries, exercise SDV, and validate the end-to-end workflow before go-live.

Treat testing as throwaway space

Not a place to accumulate data you need to keep — publishing to production will clear it (section 14).

Production

The study becomes the live environment for real patient activity. Operational work continues (registration, casebook entry, queries, SDV, signatures, locks, deviations) per each user's permissions. The design is no longer edited in place: saving the Study Builder directly is refused, and the protocol changes only by publishing an amendment, which produces a new design version. See section 14.

Moving between stages

  • Publish for Testing moves the study from draft into the operational validation phase.
  • Publish to Production is the deliberate go-live step.

Remember these publish actions are performed by study_manager, tenant_admin, or platform_admin — not by the study_builder role directly.

Study status with publish actions in the Study Design page.
Capture to be providedStudy status with publish actionsassets/screens/builder-publish-actions.jpg
Study status with publish actions in the Study Design page

13 Editing a study in testing (the impact modal)

Because teams keep iterating during testing, Arion no longer blocks a design change just because registered test patients already have data for the visits, forms, or fields you're changing. This matters most when you change visit definitions, change which forms are linked to a visit, remove a form from an event, remove a field, or change field structure in a way that invalidates existing patient metadata and data.

The controlled decision point

When a design change shows the impact modal A design change in testing is checked: if it does not remove structure existing patients reference, it saves immediately — purely additive changes such as adding a field, a visit or a linked form. If it does, an impact modal lists the affected patients, visits, forms, field values, SDV verifications, signatures and locks, and offers Cancel to adjust the design or Confirm to save and remove the orphaned data. Design change in testing Removes structure that existing patients reference? no yes Saves immediately adding a field, a visit, a linked form Impact modal patients, visits, forms, field values, SDV verifications, signatures, locks Cancel adjust the design Confirm removes orphaned data
Nothing is silently discarded — a destructive change is always an explicit confirmation.

When a change would remove or fundamentally alter structure that existing patients reference, the save does not silently discard anything and does not proceed immediately. Instead, the Study Builder shows a confirmation modal that:

  • lists the affected patients and summarizes the impact,
  • explains that some patient data will be removed and that patient/form/visit statuses may be recalculated,
  • shows exactly what's affected: how many patients, visits, forms, and field values are involved, and how many SDV verifications, PI signatures, and locks would be removed.

This is your controlled decision point. You can cancel, go back to the builder, and adjust the design — or explicitly confirm the destructive change. Only after you confirm does Arion save the new design version, remove the orphaned data that no longer fits the updated structure, preserve data that still matches, and recompute affected form and visit statuses.

Additive changes never show the modal

Adding a field, adding a visit, or linking an additional form without invalidating existing records saves immediately.

Impact confirmation modal for changes affecting existing patients.
Capture to be providedImpact confirmation modalassets/screens/builder-impact-modal.jpg
Impact confirmation modal for changes affecting existing patients

14 Publishing to production

Publishing to production is a deliberate go-live step with a destructive confirmation. When a study is published to production, Arion requires the user to type PUBLISH to confirm, then permanently clears all patient and operational data currently in that study — patients, visits, form instances, field values, queries, deviations, signatures, locks, SDV records, and patient-related audit-trail activity. The study design itself is preserved.

Two practical cautions
  • Because production go-live wipes operational data, the testing study should be treated as disposable validation space, not a data store.
  • Manually flipping a study in the database from production back to testing is not a supported workflow. If that's done and the study is later published to production again, the publish will treat the current patient and operational data as disposable and delete it.
Publish to Production confirmation dialog.
Capture to be providedPublish to Production confirmation dialogassets/screens/builder-publish-actions.jpg
Publish to Production confirmation dialog

After go-live: the design can still change

Going live is not the end of study design. Real protocols are amended constantly, and Arion supports that — a production study is no longer edited, it is amended. Opening the Study Builder on a production study offers a Start amendment action, which unlocks the builder against a private draft. Publishing that draft produces a new design version.

Amendments never delete collected data

A field removed by an amendment is retired, not deleted: values already collected for it are preserved, shown read-only on the forms that collected them, and can be brought back by restoring the field in a later amendment. Publishing is also prospective — it applies to new subjects and visits that have not started, so a site is never left with a form changing underneath them.

Amendments have their own guide covering design versions and version stamps, how each change is classified by its effect on collected data, the review screen, retirement and restoring a retired field, and moving existing subjects onto a new version.

Read the Study Versioning & Amendments Guide →

15 Quick reference

Where things live in the builder

Builder tabs: General · Planning · Forms · Safety rules · Events · Lifecycle · Queries · Data review.

TabWhat you configure there
FormsCreate/rename/delete pages and fields; set field-level and page-level SDV; set field validation rules. (Pages are not globally sortable here.)
EventsDefine visits/events, link pages, set visit-specific form order, set visit-level SDV, flag screening events, and configure the Visit workflow card (order mode).
LifecycleScreening period, rescreening, waivers, eligibility confirmation, screen-failure reasons, and the shared inclusion/exclusion criteria editor. (Replaces the old Inclusion/Exclusion criteria tabs.)
QueriesAutomatic query generation — all default off.
Data reviewStudy-wide SDV strategy, eligibility SDV, PI signature readiness, and lock policy.
Study levelName, codes, status, sample size, planning dates; prohibited medications.

Visit ordering at a glance

Any order (default for new studies) · Warn if out of order (+ optional query on the earlier visit) · Require in order (blocks, names the blocking visit). Existing studies were backfilled to Require in order. Visit windows and the visit date are never gated.

Screening lifecycle at a glance

Register → screening · criteria answered yes/no/not_assessed (pending never auto-fails) → explicit enrolment or screen failure (reason + clinical date) → optional rescreen. Terminal states: withdrawn / completed. Treatment discontinuation is separate and keeps the subject enrolled.

The non-blocking rule

No field setting blocks a save. Required = drives completion + optional queries. Range/format = soft warning only. There is no per-field “strict” hard-block anymore.

Form completion

A form is complete when all required fields are filled (or it's explicitly marked complete). Completion is when automatic queries fire.

SDV hierarchy and overrides

Use configured hierarchy is the default. Within it, a field needs verification if Full SDV is set at the field, its page, OR its visit. Full SDV and No SDV are confirmed study-wide overrides that retain the hierarchy for later reuse.

Lifecycle

Draft (design, no patients) → Testing (editable, disposable, impact modal on destructive edits) → Production (live; the design changes only by publishing an amendment, which never deletes collected data). Publish actions are manager/admin only; Publish to Production wipes operational data and requires typing PUBLISH.

This guide summarizes the Study Setup and Design functionality based on the Arion functionality overview. Exact screens, labels, and available actions depend on your study's configuration and your assigned role.

Arion — eCRF / eCRD platform for clinical trial management.