Manage queries

A query is a managed question about data: a discrepancy with the source, a clarification, a remark. Queries are the main data-cleaning tool; they look and behave the same everywhere: in the form, in the study queue and in your personal task queue.

Who and when

Monitor Data manager Medical monitor — the people who raise questions about data and accept the answers. Permissions:

• open a query — query.open; close — query.close; reopen — query.reopen; cancel — query.cancel; assign an owner — query.assign;
• closing a medical query also requires the medical review permission (data.review.medical).

You open a query when a value differs from the source document (often right during SDV), when a value is missing, or when it raises a question no rule can check. The site coordinator usually answers — that is a separate task: Answer a query.

Before you start

• You hold a role with the right permission on the site (or study) that holds the data.
• For a field query, the field already has a value. A missing (empty) value is raised as a form query.
• The area is not under a hard lock.
• If the field is blinded, plan wording that does not quote the value.

Steps

1. Open the subject’s form and find the field you have a question about.

2. Open the query dialog:

   • on a field — choose Open query… in the field menu;
   • on the form — the Query on the form… button at the top of the form (a missing value, a cross-field inconsistency, a question about the whole form).

3. Fill in the Query text. Optionally pick an assignee (or leave “Do not assign (shared queue)”) and a Response deadline (optional) — without it the area’s SLA applies. The Query type field (manual or medical) is shown only to holders of the medical review permission.

4. Click Open query. You see “Query N opened”; the query gets status Open and joins the site’s queue.

0:000:00

Query console: auto, manual and medical queries of the whole study in one queue, with filters and ageing

Accept or reject an answer

Once the site has answered, the query is Answered and waits for you. Open it in Queries — the thread, context and current value open on the right.

• Close (accepted) — the answer is accepted. Enter a Resolution (required: it goes into the thread as a message and stays in the audit trail). The query becomes Closed. You can undo the close right from the notification.
• Reject answer… — the answer is not accepted. Give a reason; the query returns to the site as Open in a new round.

Reopen a closed query

In a closed query’s thread click Reopen and give a reason. The query is back in work:

Reopened. An automatic query cannot be reopened manually — it reopens by itself if the check is violated again.

Cancel a query opened in error

Click Cancel query and give a reason. Cancellation is terminal: a Cancelled query cannot be reopened. Only manual and system queries can be cancelled; a medical query follows its own medical-resolution path.

Work the queue in bulk

1. Open Queries in the study menu and narrow the list with filters (status, type, site, Overdue only, assignee).

2. Tick several queries.

3. Choose an action — Close, Reopen or Cancel — and confirm.

4. Read the result “applied N, skipped M”; expand Skipped items to see the reasons.

The action is applied to each selected query separately and audited separately — it is not all-or-nothing.

Assign an owner

In the query thread, on the Assignee line, choose Assign (a candidate from the list), Take it or Unassign. This takes the query.assign permission (by default held by the data manager and the monitor).

Export the query register

Above the list are Export (XLSX) and Print (PDF). Both build the register on the server with exactly the filters selected on screen; the row search is on-screen only and is not included in the file. This takes export.run. File contents are under Query register.

What happens

• Every transition — open, answer, close, reject, reopen, cancel, assign — is written to the audit trail with the author, time (UTC) and reason or resolution. A bulk operation writes an event per query plus a summary event for the operation.
• The query status moves along its own axis: Open → Answered → Closed; branches — Reopened and Cancelled. A query does not change the field’s value or its other axes.
• Notifications are targeted: an answer → whoever opened the query; a reopen → the author of the last answer; a close → both; an assignment → the assignee. Opening a query notifies no one — it appears in the Tasks of those entitled to work on it. A notification carries only a label and a link, never a clinical value.
• A register export lands in the Exports journal with a checksum; the download goes to the audit trail.

If it doesn’t work

• “Open query…” is disabled: “Available once the item has data” — the field is empty. Use Query on the form….
• No query buttons or menu items — you lack the matching permission (query.open, query.close, query.reopen, query.cancel) in that area.
• You cannot close a medical query — it requires data.review.medical.
• No Reopen on an automatic query — by design: it reopens with a new rule violation.
• “Only an answer can be rejected — this query has none yet” — the query is not answered yet; there is nothing to reject.
• A bulk operation skipped some queries — the reasons are under Skipped items: “no permission”, “hard-locked”, “invalid state transition”, “not found”.
• No candidates to assign — no one holds the right to answer or close in the query’s area; assignment does not grant rights, contact your access administrator.
• No export buttons — you do not hold export.run.

Next

Answer a queryHow the site answers: an explanation or a value correction with a reason.

Verify source data (SDV)Checking against source; a discrepancy → a manual query.

Perform a medical reviewMedical queries and safety data review.

Your task queueWhy these queries are in your Tasks and how assignment differs from a permission.

More detail

Query types

Type	Who opens it	When
Auto	The system	An edit check with a query action fired on save
Manual	Monitor, data manager, PI	A remark on a value that a rule cannot check
System	The system	A process inconsistency (e.g. a conflict after randomization)
Medical	Medical monitor	A clinical question about safety data

Query lifecycle

A query has one main path and three additional transitions:

1. Open
   • cancelCancelled
   answer
2. Answered
   • rejectOpen · new round
   accept
3. Closed
   • reopenReopened

The main path of a query and the additional transitions.

Query statuses: Open, Answered, Closed, Reopened and the terminal Cancelled. Full status tables for all axes are in the status reference.

Closing is not cancelling

Closing means the discrepancy has been resolved; cancelling means the query should not have been opened. They are deliberately kept apart for data-quality metrics.

Automatic queries

An automatic query (type Auto) is managed by the rules engine: it opens when an edit check with a query action fires on save, and closes by itself as soon as the data is fixed and the check stops firing (reconciliation). An auto query cannot be reopened manually — it “reopens” through a new violation of the same rule. It can be closed manually, but that is a deliberate acceptance of the deviation: a resolution is required.

The site’s answer

The site coordinator usually answers. They either explain the value in text or correct the data (the edit goes through a reason for change) — and the query moves Open → Answered. After the answer the query waits to be closed by the monitor or the data manager. Step by step — Answer a query.

Blinded values in query text

If the field is blinded, the system warns you: do not quote the value in the query text — query text is not masked. Describe the problem without revealing the value itself.

Discussion thread

All messages on a query live in one thread: comments, answers and resolutions. The thread counts rounds (how many times the query was sent back for rework) and reopens. A single thread keeps the discussion history and the audit trail together — instead of spawning new queries for the same issue.

The work queue

Queries are easier to work through in a queue than casebook by casebook. It exists at three levels:

• the study queue — all queries (the Queries section);
• the subject queue — the Queries tab in the casebook;
• Tasks — the queries waiting for you specifically.

The queue is built from your permissions: it contains exactly the queries you are allowed to answer or close within their areas. How Tasks queues work, and why assigning an owner is a label rather than a permission, is covered in Your task queue. A queue row leads to the form with the focus on the field — editing always happens in its original context.

Assigning an owner

A live query can have an assignee — the person who took it (or was asked) to see it through. The assignee gets a notification, the query rises to the top of their Tasks with an “assigned to me” label, and the queues gain an assignee column and filter.

Assignment is a label, not a permission

The system computes the candidates from grants: you can assign only someone who is already allowed to answer or close the query within its area. How assignment differs from a permission — see Your task queue.

Query register

• XLSX — the full set of columns for working in Excel. The first sheet is “About this export”: filters, who built the register and when, the cut. Printing is pre-configured — landscape orientation, the table header repeats on every page.
• PDF — the same picture as a printable PDF/A copy with the key columns — to take to a monitoring visit or hand over without Excel.

The file contains what a person needs rather than machine codes: query number, site, subject, visit, form and field, type and status in words, query text, the last message with its author and date, who opened it and when, assignee, age and overdue flag. Dates are in UTC (the columns say so): the file is read where the site’s time zone is unknown.

Messages on blinded fields are masked in the file exactly as on screen. Every build lands in the Exports journal with a SHA-256 checksum, and every download is recorded in the audit trail: who, when, with which filters and how many rows.

Deadlines and ageing (SLA)

Every query shows its age — how many days it has been open. The deadline threshold (SLA) is configured at study or site level; queues highlight overdue queries, and the ageing of unclosed queries by age bucket is computed on the Monitoring screen.

The system never closes queries on a timeout

SLA is a metric and a highlight, not a status transition. An overdue query stays open until a person resolves it. The system never “closes on time”.