Study Wizard User Guide

Study Wizard — User Guide

Describes the functionality currently available in Study Designer. Part of the EarlyBird / MyRBQM platform.

About this guide

Study Wizard (also called here Study Designer - SD) is Cyntegrity's self-service study-setup product. It lets a study team configure the risk-monitoring setup for a clinical study — a reusable study template, its Key Risk Indicators (KRIs), Quality Tolerance Limits (QTLs) and underlying metrics — and then export it into EarlyBird/MyRBQM for live monitoring. SD also runs AI-assisted authoring and AI-based Protocol Deviation detection.

This guide explains how each function actually works: where it lives, the step-by-step flow, the fields and options you see, the validation rules, and how the objects depend on one another. It documents only functionality that is available today.

> [Screenshot: SD landing screen inside the MyRBQM portal]

1. Overview & key concepts

SD is a module embedded inside MyRBQM. You open it from the MyRBQM Settings menu — no second login — and it reuses MyRBQM's authentication, header/footer, date formatting and calculation catalog, so it looks and behaves like the rest of the platform.

A study is built from these building blocks, which are interdependent — a KRI/QTL always sits on top of one or more metrics:

Statuses you'll see everywhere. Each object (KRI, QTL, Metric) carries a Draft → Approved status; approving locks editing, moving back to Draft re-enables it and increments the object's version. The template itself has the same Draft ↔ Approved flag.

Dates display consistently: MMM dd, yyyy  for dates and MMM dd, yyyy at hh:mm tt (UTC)  for timestamps.

2. Quick-start workflow

1. Create a study template with the Study Wizard; on General Info choose which functionality to use (KRIs / QTLs). → §3
2. Design risk management — build KRIs and QTLs (metrics are auto-created), set thresholds, optionally use the AI Assistant. → §4, §5
3. Define the metrics — after the KRIs/QTLs are created, open each auto-created metric and complete its definition (input data, parameters, unit, levels, calculation & mapping notes). → §4.1
4. Set up Protocol Deviation Detection — upload the protocol, data specification and test data, define the deviation types, and run AI analysis / detection. → §6
5. Review & collaborate — comment and resolve, run the consistency check. → §8
6. Approve & export — promote to Approved and export as Excel or JSON. → §3.6, §7

> Note — Programmable vs. Observable protocol deviations. Each deviation type is classified by a Creation Type: Programmable ones are detected automatically by SD (AI analysis and PD detection), while Observable ones cannot be programmed and are entered manually by CROs in the MyRBQM Compliance Module. For Observable types, detection is not run — see §6.

> [Screenshot: Study Wizard stepper]

The Study Wizard's step sequence is dynamic — steps appear or disappear based on the functionality you tick on General Info.

3. Study Template Management

Purpose: Create, organize, version and export the study templates that drive every setup.

3.1 The Company Study Template list

The SD landing screen is the Company Study Template list — a paged, name-sorted table of every template for your company. Columns: Name (links to the template Overview), Description, Latest Version, Last Change (date + user), Status. A search field filters by Name and Description; Create New Template launches the Study Wizard. The Actions column also offers Create Copy and Export.

> [Screenshot: Company Study Template list with search and Create New Template]

3.2 Creating a template with the Study Wizard

Create New Template opens the Study Wizard ("Create New Study Type Template"). On the General Info step you enter:

• Name — mandatory, unique per company.
• Description — mandatory.
• Functionality to be used — checkboxes Use KRIs, Use QTLs, Use Subject Profile (all default off). At least one must be ticked or Continue is blocked; ticking a box immediately shows/hides the matching wizard step.
• Therapeutic Area — multi-select from a fixed list (Cardiology, Oncology, Neurology, …).
• Planned Release Date — optional date picker.
• Planned Number of Studies — mandatory integer ≥ 1 (default 1).
• Data upload frequency in days — mandatory integer (default 1).
• Study Protocol and Annotated eCRF — optional PDF uploads.

An Exit Study Wizard control returns to the template list after a "You are about to leave this page" confirmation.

> [Screenshot: Study Wizard — General Info step]

3.3 Template Overview & lifecycle

Clicking a template name opens the Overview page, a tile layout. The General Information tile repeats the wizard fields plus Created/Last-Change stamps and download links for the uploaded Protocol and eCRF. Additional tiles — KRIs, QTLs, Metric — appear only when their option was enabled, each showing status-grouped counts and a list (ID, Title, Status) linking to the respective list page.

Lifecycle: a two-state flag Draft ↔ Approved. Draft → Approved keeps the version; Approved → Draft increments the template version. Any change requires a mandatory rationale (multi-line, ≤ 250 characters); the last change date, user and reason are shown.

Because each version has a distinct ID, editing an outdated version shows a version-mismatch warning: "You are currently working on template version X. The latest available version is Y."

3.4 Create Copy

Create Copy shows a confirmation dialog; the duplicate is named _Copy_  (the number guaranteeing uniqueness), Version 1, Status Draft.

3.5 Consistency check on approval

Promoting a template from Draft to Approved triggers a metric consistency check: every metric's mandatory fields must be filled or a validation error blocks approval. This catches metrics that were auto-created during KRI/QTL setup but never completed — such metrics cannot be approved via KRI/QTL approval and keep their status unchanged.

3.6 Export

Two export paths (details in §7):

• JSON/ZIP — a machine-readable bundle of the template configuration.
• Excel — a human-readable spec for stakeholders without a MyRBQM account.

4. Risk Management Design (Metrics, KRIs, QTLs)

Purpose: the core of SD. You configure the metrics that read data, the KRIs/QTLs that evaluate them against thresholds, and drive everything through Draft → Approved with versioning. Key dependency: a KRI/QTL always sits on top of one or more metrics, and approving or deleting a KRI cascades to those metrics.

4.1 Metrics

Metrics live on Manage Metrics — a table grouped by category, with ID/Name search, showing ID, Name (+ an info icon with the Calculation & Mapping Notes), Levels, Status {Draft, In Review, Approved}, Type {Standard, Custom}, and Input (linked metrics or data sources). Metrics are usually created implicitly while building a KRI, then refined here.

The Metric Details page fields:

• Display ID — mandatory; auto-generated M_  or user-entered with a uniqueness check.
• Display Name — mandatory. Internal Name — auto-generated, unique, hidden.
• Metric Parameters — optional; each has Name (unique per metric), Value Type {int, bool, decimal}, Value (validated against the type), Description, and Level (kept in sync with metric levels).
• Is Standard Metric — read-only; automatically true when a metric with the same Internal Name exists in the shared study library.
• Calculation & Mapping Notes — mandatory, multi-line; holds the calculation hints/suggestions for the metric, is included in the Excel export, and is not shown in MyRBQM.
• Input Data — Study Input Data (optional dimensions from the entity/dimension tree) and Metric Input Data (mandatory — from the shared metrics list or a new named metric).
• Category — mandatory dropdown (standard categories + create-new).
• Levels — mandatory multi-select of {Study, Country, Site, Subject, Visit}, derived as the superset of the levels of the KRIs using the metric.
• Unit of Measure — mandatory single-select (AEs, SAEs, PDs, visits, subjects, %, dropouts, days, pages, queries) + create-new.
• Display on Dashboard — Dashboard Heartbeat (checkbox + optional order > 0) and Dashboard Predictions (assigns a prediction ID and the AutoArima prediction method).

Standard metrics are locked down: Display Name, Unit, Calculation & Mapping Notes, Input Data and the Parameter list are read-only (only a parameter's value is editable), because those fields would change the standard calculation. One exception: the unit of an auto-created "Rate" metric is editable, because the unit is still unknown at KRI-creation time.

> [Screenshot: Metric Details page with Parameters and Input Data]

4.2 Comparison logic (threshold, lag, direction)

A KRI's Threshold Comparison decides how current data is judged:

• Compare with Threshold — direct comparison to the threshold.
• Compare with Threshold after Lag — adds a lag condition for data stabilization; selecting it reveals mandatory Lag Value, Lag Metric and Lag Metric Level fields.
• Lag Direction {Higher (default), Lower} — Higher triggers when the value exceeds the lag value, Lower when it is below.

The Threshold Direction {Higher, Lower} governs alert direction: Higher alerts when the value is ≥ the threshold, Lower when the value is ≤ the threshold. A Percentage-of-Difference type is also available — the relative difference between denominator and numerator as a percentage (e.g. under/over-recruitment indicators).

4.3 KRIs

KRIs live on Manage Key Risk Indicators: a table grouped/sorted by category then ID, with ID/Name search, showing the High and Medium threshold + unit, the underlying metric(s), and Status.

Creation captures:

• Display ID (RI_  auto or user-entered unique), Display Name, a hidden Dimension Name (upper-camel-cased from the display name on save), Description.
• Category (standard categories + create-new).
• Levels — mandatory multi-select {Study, Country, Site, Subject}, each usable once.
• Threshold Direction, and Type {Percentage, Ratio, Number}:
• Number → one metric.
• Percentage/Ratio → either a single Percentage/Ratio metric or separate Numerator + Denominator metrics (default), each chosen from the shared list or created new.
• Threshold Comparison (§4.2), Thresholds per level (High mandatory, Medium optional, plus lag fields when applicable), and optional Planned Value per level.
• Level defaults, edited per level in an accordion: TicketAutoClose (default on), AlertsMuted (default off), ResultsMuted (default off), TicketCreateTimeout (default two weeks; options none / day / week / two weeks / month / quarter / half-year / year).

Auto-created underlying metrics: creating a KRI generates its metrics automatically — for custom metrics, ID/Name/Levels/Category come from the KRI (unit %  for percentage, per  for ratio); for standard metrics, values come from the shared study library.

> [Screenshot: KRI creation form with per-level thresholds]

4.4 QTLs

A QTL is a KRI flagged Is QTL. Enabling it opens a management page identical to KRIs except: the ID prefix becomes QTL_ , the category is fixed to "QTL" (system-reserved, not manually creatable), and the level is restricted to Study. QTLs share the higher/lower direction and threshold mechanics of KRIs.

4.5 Comments, approval, unsaved changes & versioning

• Comments — add to KRIs, QTLs and metrics on their management pages, independently of Save. Each is ≤ 1000 characters and shows the creation datetime (UTC) and author. Edited comments show an "Edited" marker; only the author may edit or delete (deletion is a soft-delete, excluded from export). All comments are included in the Excel export.
• Approval cascade — approving a KRI/QTL prompts "…Do you also want to approve these metrics?" with Yes, approve all / No, only KRI/QTL / Cancel. Approved objects can no longer be edited and hide the AI Assistant.
• Deletion cascade — deleting a KRI/QTL that uses underlying metrics prompts to also delete metrics "no longer used elsewhere" (not referenced by any other KRI, QTL, Metric or Prediction). Deleting a KRI requires confirmation.
• Unsaved changes — leaving an edit page with unsaved changes raises Discard / Cancel / Save Changes (Save runs the same validation as a normal save).
• Versioning — each KRI, QTL and metric has an integer version that increments when its status is moved back to Draft; the current version appears as a column in the Excel export.

5. AI Assistant (KRI creation)

Purpose: speed up KRI authoring by turning a guided conversation into a filled-in KRI form.

The AI Assistant is a chat panel on the Create KRI form (reached via the KRI list → + Create → Show AI Assistant). It is visible by default and can be hidden/unhidden. AI messages are left-aligned, your messages right-aligned; the conversation is ephemeral and not stored — it is gone once you leave the page.

How it works:

1. The assistant conducts a guided interview, asking questions to collect the information needed for a new KRI.
2. When it has enough, it produces a summary of the KRI it will create.
3. Once you agree, click Apply All Suggestions. A pop-up lists every field the AI identified (**Cancel / Continue**).
4. On Continue, the KRI form fields are populated from the summary — and you can still edit any field before finalizing.

The AI Assistant is hidden once a KRI is Approved.

> [Screenshot: KRI form with AI Assistant panel and "Apply All Suggestions"]

6. Protocol Deviation Detection

Purpose: define the study's protocol-deviation rules and run AI-based detection against test data. This is a distinct capability — it is configured and executed in its own area, not through the KRI AI Assistant.

Setup. Under General Information you upload three inputs:

• Protocol (Markdown, .md )
• Data Specification (Markdown, .md )
• Test Data (.zip )

Protocol Deviation Types. SD manages a list of deviation types. Each type carries a structured set of fields:

• Creation Type (mandatory) — see below
• ID, Name, Category, Sub-Category, Severity
• Definition / Trigger Criteria
• Data Source / Schema Reference
• Data-Handling & Consistency Rules
• Exceptions
• Integration / Dependency Notes
• Reporting / Output Specification
• Amendments, Notes
• the list of data-source filenames used

Creation Type — Programmable vs. Observable. Every deviation type has a mandatory Creation Type of Programmable or Observable, set in the General Information section (you can toggle it at any time):

• Programmable (the default) — the deviation can be detected automatically. AI Analysis and PD Detection can be run, the Results section is shown, and the type can be Enabled.
• Observable — the deviation cannot be programmed and is instead entered manually by CROs in the MyRBQM Compliance Module. For an Observable type, Execute AI Analysis and Execute PD Detection are disabled, the Results section is hidden, and Enabled is locked off.

Creation Type appears as a column (after Name) and as the first filter on the deviation-types list, and is included in the Excel export/import and the JSON export. Existing deviation types default to Programmable.

Per-type actions. For each deviation type you can:

• Enable / disable the type (Programmable only),
• Execute AI Analysis — the AI reviews the configuration against the uploaded protocol and data specification (Programmable only), and
• Execute PD Detection — run detection against the uploaded test data (Programmable only).

> [Screenshot: Protocol Deviation Types list with Execute AI Analysis / Execute PD Detection]

7. Export

• JSON/ZIP export — bundles the General Info (excluding the uploaded files), the KRI configuration and all associated metric configurations into a single ZIP named ___SD.zip . This is the machine-readable form used to move a configuration downstream.
• Excel export — a workbook for stakeholders without a MyRBQM account, with these tabs:
• General Information — template/company, environment, therapeutic area, description, planned release date, upload frequency, planned number of studies.
• Version History — one row per version: Version, Status, Author, Changes, Date.
• KRI Spec / QTL Spec — ID, Title, Description, Category, Calculation Type {Percentage, Ratio, Number}, numerator/denominator details, Levels & Thresholds, Comments.
• Metric Spec — ID, Title, used-for-KRIs/QTLs, used-for-predictions, show-on-dashboard, standard vs. custom, calculation & mapping notes, unit, levels, parameters, comments.

Both export buttons carry explanatory tooltips.

> [Screenshot: Export dialog — Excel vs JSON]

8. Review & Collaboration

Purpose: collaborative review of a configuration before it is finalized.

• Threaded comments can be added to tables and resolved. An unresolved comment shows a Resolve button; a resolved comment shows a tick (✓), and hovering reveals the resolver's name and date/time.
• The total and unresolved comment counts appear in the KRI, QTL, Metric and PDP lists; any record with unresolved comments shows a warning indicator with the count on its Comments button.
• Comment status (open / resolved) is included in the Excel export.

> [Screenshot: Comment thread with Resolve and unresolved-count badge]

9. Access & permissions

You open SD from the MyRBQM Settings menu; it uses your existing MyRBQM login (if your session has expired you are sent to the portal to sign in and then returned to SD).

Access is governed by a permission check. Study Designer pages require the company-level permission "Manage Study Type Templates (Study Wizard)", held by company administrators. A user without that permission who opens a Study Wizard page sees a full-page message — "You do not have permission to access the requested page" — with a link back to the previous page and a prompt to contact the company administrator.

Document generated 2026-07-31 based on version  SD r1007 (v1.6.0)