Skip to content

Forms events ui

Below is a simple, implementable set of UI instructions that keeps a clean separation between: (1) global form assets, (2) study-specific configuration, and (3) ODM-aligned event→form scheduling, while respecting your {study_id} routing context.

1) Core UI principle

  • Anything that is reusable across studies lives outside {study_id} (global scope).
  • Anything that is a study configuration (events, schedules, which forms are used, version pinning) lives inside {study_id}.
  • A form’s “definition” (SurveyJS JSON + metadata) is not the same as a form’s “use in a study” (a pinned version with event bindings).

2) Navigation structure

Global (no ****

** in URL)**

  1. Form Library
  2. List/search all library forms
  3. Create/edit/publish library forms
  4. View versions and change log

Routes (example):

  • /library/forms
  • /library/forms/new
  • /library/forms/{form_library_id}
  • /library/forms/{form_library_id}/versions/{version_id}

Study scope (

** in URL)**

  1. Study Setup
  2. Events (visits) definition
  3. Study Forms (forms used by this study; imported or created locally)
  4. Event–Form Schedule (link forms to events, set requiredness, repeating rules)
  5. Export / ODM preview

Routes (example):

  • /studies/{study_id}/setup/events
  • /studies/{study_id}/setup/forms
  • /studies/{study_id}/setup/schedule
  • /studies/{study_id}/setup/odm-preview

3) Data objects the UI should assume (conceptual)

  • LibraryForm (global)
  • library_form_id, name, description, tags
  • versions[] (each with SurveyJS JSON + compiled ODM metadata + status)
  • StudyForm (study-scoped wrapper)
  • study_form_id, study_id
  • source_type = library | local
  • source_library_form_id (if imported)
  • pinned_version_id (critical)
  • local_overrides (optional; discourage in submission-ready mode)
  • StudyEvent (study-scoped)
  • event_id, study_id, name, order, repeatable, window
  • EventFormBinding (study-scoped)
  • event_id, study_form_id
  • required = true/false
  • repeat_policy (none / per-occurrence / repeating group rules)
  • activation_rules (optional; for conditional schedules)

4) UI: Form Creator

A) Library Form Creator (global)

Where:/library/forms/new and /library/forms/{id}

Purpose: Author canonical reusable forms.

UI requirements:

  1. Editor tab
  2. SurveyJS Creator embedded/full-page (prefer full page)
  3. Enforce naming rules for question.name (stable, unique, SDTM-friendly)
  4. Metadata tab
  5. Form-level metadata: domain, intended use, tags, default units, controlled terminology notes
  6. Versions tab
  7. Draft → Publish flow
  8. Immutable published versions
  9. “Clone as new version” for edits
  10. Compile/Preview tab
  11. Show compiled ODM artifacts (FormDef/ItemGroupDef/ItemDef summary)
  12. Validation warnings (missing units, missing codelists, ambiguous datatypes)

Minimum actions:

  • Save draft
  • Publish version (creates immutable version)
  • Deprecate version (cannot be used for new imports, but existing studies remain pinned)

B) Study Local Form Creator (study-scoped)

Where:/studies/{study_id}/setup/forms/new

Purpose: Create forms that are unique to a study.

UI requirements:

  • Same Creator UX as library, but the output is a StudyForm with source_type=local
  • Still enforce versioning: drafts and immutable versions, pinned within the study

5) UI: Form Library (global)

Where:/library/forms

UI requirements:

  • Table with search/filter (tag, domain, status)
  • Show latest published version + last updated
  • Quick actions: View, Create new, Clone, Deprecate, Export ODM snippet

Key UX rule:

  • You do not “attach” a library form to a study from the library screen. You import it inside a study context so the study pins a specific version.

6) UI: Study Forms (study-scoped)

Where:/studies/{study_id}/setup/forms

This is the study’s form inventory (the forms available to schedule).

Page layout:

  • Two primary actions:
  • Import from Library
  • Create Local Form
  • List of existing StudyForms:
  • Name
  • Source (Library vs Local)
  • Pinned Version
  • Status (Active/Deprecated in study)
  • Used in # events

Import flow (modal/wizard):

  1. Search/select LibraryForm
  2. Choose version (default to latest published)
  3. Confirm “Pin version to study”
  4. Create StudyForm entry

Important rule:

  • After import, the StudyForm is independent of future library changes unless the study explicitly upgrades its pinned version via a controlled action.

7) UI: Events Creation (study-scoped)

Where:/studies/{study_id}/setup/events

UI requirements:

  • CRUD events (visits/study events)
  • Fields:
  • Name (e.g., Screening, Baseline, Week 4)
  • Order
  • Repeatable (Y/N)
  • Visit window (optional; academic-friendly)
  • Provide a simple “reorder” control

ODM alignment guidance to the UI:

  • Treat each event as a StudyEventDef candidate; keep stable internal IDs.

Where:/studies/{study_id}/setup/schedule

This is the key “wiring” screen.

Recommended UI pattern: Matrix + Drawer

  • Left axis: Events (rows)
  • Top axis: Study Forms (columns) or use an “Add form to event” button per row
  • Each cell shows binding status:
  • Not linked
  • Linked (Required/Optional)
  • Repeat settings
  • Conditional indicator

Click cell → Binding drawer:

  • Required toggle
  • Repeat policy
  • Activation rule (optional; keep simple at first)
  • Notes (operational only)

Additional view:

  • “Forms view” tab: for each form, show which events use it (helps avoid duplicates)

Validation on this page:

  • Warn if an event has zero forms (if you expect otherwise)
  • Warn if a required form has no required fields (common authoring issue)
  • Warn if a form is scheduled in repeatable events but is not designed for repeats (policy-based)

9) UI: ODM Preview (study-scoped)

Where:/studies/{study_id}/setup/odm-preview

UI requirements:

  • Show generated ODM hierarchy:
  • Events → Forms → ItemGroups → Items
  • Show OID registry
  • Show warnings/errors that block “submission-ready mode”

This page is your “truth surface” that the schedule and forms compile coherently.

10) Simple rules that keep you future-proof

  1. Pin versions at the StudyForm level. Never reference “latest” dynamically in a live study.
  2. Do not allow in-place edits of published versions. Always clone to a new version.
  3. Do not link library forms directly into schedules. Always import into StudyForms first.
  4. Schedule binds Events to StudyForms, not to LibraryForms.
  5. Keep authoring separate from scheduling. Creator edits the form definition; schedule defines where/when it’s used.

ly.