Skip to content
Tutorial

Your first study: from draft to a published version

This route takes you through building a study from scratch: one form, one edit check, one visit — just enough to walk the whole path of a design version to publication and activate a site. A real study is built the same way, only with more forms and rules.

  • A practice study in Draft with a design version that is Published.
  • The design holds a “Vital signs” form with required fields and a range, an edit check between two fields, and a visit on which the form is collected.
  • The version was approved by another person — not its author.
  • One site is active in the study, and the Overview shows the next step — a test run or launch.
  • You have done Your first 15 minutes in X7 Insight.
  • The Data manager role or the design builder role (Study Builder) with the permissions to create a study (study.create), edit the draft (studyversion.update), submit it for review (studyversion.submit_review) and activate a site (site.activate). Creating studies is usually granted to the tenant administrator — if there is no New study button, ask them to create a practice study and give you a role in it.
  • A colleague with the permission to approve versions (studyversion.approve) — for the review step. Publishing is done by a holder of studyversion.publish: that can be you or them.
  • The practice study can be deleted later while it is still a draft (permission study.delete): its data and audit trail are kept.
  1. Create the study. In Studies, click New study. Fill in Study code (for example, TRAIN-01 — visible to sites and included in exports) and Study title; Phase is optional. Click Create.

    You should see: “Study TRAIN-01 created.” and the study’s Overview in Draft with the “Path to launch” card: “Build the forms and visits” → “Publish the design” → “Add a site” → “Test run” (optional). An empty design draft (v1.0) has already been created.

  2. Open the builder. In the rail pick Design (or “Open the Design section” on the card). In the “Design draft” zone click Open builder.

    You should see: three panels — the list of forms and lists on the left, the form in the centre (tabs Structure and Logic), the property inspector on the right.

  3. Build a form. Click Add form and name it “Vital signs”. On the Structure tab click Add section, then Add field — the composer line opens. Type each line and confirm it with Enter:

    Systolic BP /number (mmHg)
    Diastolic BP /number (mmHg)

    Select the “Systolic BP” field and in the inspector tick Required, set Min value and Max value. Do the same for diastolic.

    You should see: two fields of type “number”; the builder assigned the technical names (OIDs) itself. The “field is required” and “value in range” checks were created by the system from the properties — they are on the Logic tab in the “From field properties” block.

  4. Add an edit check. On the Logic tab click Add check. In the “New check” window build the condition as the row “Diastolic BP — at least — Systolic BP” (the right side can be compared with another field of the form), write a Message for the coordinator, and under “What happens when it fires” pick Open a query: the value is saved and a query is opened on it. Keep Block entry for values that cannot be true. Try the rule in the “Try it on values” block.

    You should see: the rule in the form’s checks block; on matching values the sandbox answers “Fires — a query would open”.

  5. Build the visit schedule. Go back to the Design page and click SoA matrix. Click Add visit, name it “Screening”, set the type to “scheduled” and, if you like, a planned day and window. Click the cell where the form and the visit meet: ● — the form is required at the visit, ○ — collected as indicated, · — not collected.

    You should see: ● in the “Vital signs × Screening” cell. The builder’s Problems panel no longer complains about a form without a visit.

  6. Live through the form. On the Design page click Preview and enter a diastolic pressure higher than the systolic one.

    You should see: the fired rule with your message under the form. Nothing is saved in the preview.

  7. Submit the version for review. On the Design page check the checklist above the main button and click Submit for review. A broken design does not get through: dangling references, uncompilable rules and fields without a type are listed.

    You should see: the version is In review, and the builder opens it read-only.

  8. Get approval from a colleague. A colleague with studyversion.approve opens your study’s Design, reviews the version and clicks Approve — or Return to draft with comments (then fix them and submit for review again). If configuration testing has not been done for this design, the system asks for a reason for approval and keeps it in the audit trail.

    You should see: the version is Approved.

  9. Publish. Click Publish and confirm “Publish the design?”.

    You should see: the version is Published; it is now the active design and no longer changes — any edit is now a new version.

  10. Add a site. In the rail pick Sites and click Add site…. Enter Site code and Site name, check Site timezone, keep the version you just published in Design version and click Activate.

    You should see: the site in the table with status Active; on the Overview the “Path to launch” marks the three required steps as done.

0:000:00
The version path: draft → review → approval → publication with separation of duties.
  • A study is born as a draft with an empty design version, and the Overview guides you along the path to launch.
  • A form is built in the builder; required and range checks come from field properties, cross-field rules you write yourself — choosing between a query and a block.
  • The visit schedule is the SoA matrix: every subject’s casebook is later built from it.
  • A version goes Draft → In review → Approved → Published, and a published version cannot be changed.
  • A site is activated only on a published version.