What this is, and who it is for
A query is a question about one value in the study data (or about one form), with a thread of replies. It is how a discrepancy is raised, answered by the site and signed off by someone who is not the person who answered. Every step is recorded, so the history of a correction can be shown to an auditor.
There are two kinds:
- Manual queries, raised by a person who reviews the data.
- Auto queries, raised by the study's edit checks when a form is saved, with no person involved.
The two kinds end differently. A manual query is never closed by the system: the site answers it with Send response (a correction on the form needs a reason, and saving the corrected value does not answer the query), and a person who holds the close permission reviews the answer and closes it. An auto query may close itself, but only when its edit check stops failing and nobody has answered it yet; an auto query the site has answered is never closed that way, and waits for a person like a manual one (ADR 0015, decision 8).
Three groups of people take part, and the system keeps them apart:
| Step | Who | Permission |
|---|---|---|
| Raise (and Escalate) | Project Manager, Clinical Research Associate, Data Manager, Medical Officer, Site Monitor | clinical.query.raise |
| Answer | Principal Investigator, Clinical Research Coordinator, Pharmacy, at their own site | clinical.query.answer |
| Close | Data Manager, Medical Officer, Clinical Data Coordinator | clinical.query.close |
| Reopen | Clinical Research Associate, Data Manager, Medical Officer | clinical.query.reopen |
| See the queries | Everyone above, plus Sponsor Manager and Auditor (read only) | clinical.query.read |
The eCRF Designer, Sponsor Supply Manager and Regulatory Manager hold no query permission. The Organization Admin holds no study role and cannot act on a query: all four actions are checked with no administrator override. Roles are defined in Roles and permissions.
Where to find it
Study → Queries in the left menu. It sits under Data management for the study team and under the site's own heading for site staff. The same screen exists in the Live and the UAT workspace; UAT queries are about test data only.
What you can do
Raise a query
You can start a query from four places. In each case you need clinical.query.raise; without it the control is not shown.
- On a field of a form: click the flag next to the value. The panel shows every query on that value and Raise query on this field. For one cell of a table the query is about that cell alone.
- On a form: Form-level query at the top of the form, for an issue that is not about one value. A list lets you attach it to a field if you wish.
- On a participant: Raise query… in the row menu of the Subjects list.
- On the study: Raise query at the top of the Queries screen, for something not tied to a participant or form (an ad hoc query).
The dialog says what you cannot do: you cannot edit the field value. You flag a discrepancy; the site reviews it and answers with an explanation or a corrected value.
- Sends the query to the site.
Answer a query (site staff)
- Open the query in the list and read the thread.
- Type the answer in the reply box and press Send response. If the value must change, correct it on the form (see Correct data); the correction needs a reason, and saving it does not answer the query: you still press Send response. On a form that has been submitted or signed, the open query is what allows that change.
- The query moves to Answered and waits for a reviewer.
You see and answer only the queries of your own site.
- Records the site's answer; the person who raised the query cannot answer it.
Close, reopen or escalate a query (reviewers)
A reviewer reads the answer and chooses one of three actions, with an optional note that is saved on the thread:
- Close, when the answer settles it. Offered on an Answered query.
- Reopen, when it does not. The query goes back to the site as Reopened.
- Escalate, to flag it for elevated review (a safety or protocol concern). The site can still answer an Escalated query; it is then closed like any other answered query.
- Closes the answered query; the person who gave the latest answer cannot close it.
- Reopens it when the answer is not enough.
Auto queries
An auto query is raised when a form is saved and a check whose severity is query fails. That is what every check does unless the designer says otherwise: for each check the designer can set a field to block the save, raise a query, or only warn. The built-in checks are: required value missing, below the minimum, above the maximum, outside the normal range, too many decimal places, too short, too long, not in the expected format (including email, phone and time formats), not one of the choices, too few or too many selections, file type not allowed, and a date in the future, in the past, before the minimum or after the maximum. A rule the designer wrote can also raise a query. See Rules reference.
- Each failing check on a value is its own query; each failing cell of a table is its own query. A check that still fails is not raised a second time.
- An auto query closes itself the next time the form is saved with the problem fixed, but only while it is still Open, so only when nobody has answered it. Once the site has answered, or it has been reopened or escalated, a person decides. This is the one case in which the system closes a query; a manual query never closes itself.
- An auto query has no raiser, so anyone allowed to answer may answer it.
Every option
The Raise a query dialog
| Control | Required | What it does |
|---|---|---|
| Context box (Subject, Form, Field) | filled in for you | Shows what the query is attached to. Reads Ad-hoc query (no subject / form attached) when you start from the Queries screen |
| Attach to field (optional) | no | Shown on a form-level query only. Pick a value, or leave Form-level (no field) |
| Title | yes, 3 to 120 characters | The short name the site sees in its list |
| Description | yes, 10 to 2,000 characters | What is wrong and what you need. A counter shows the length |
| Priority | yes, default Normal | Sets the response time |
| Cancel / Raise query | Raise stays disabled until the title and description are long enough |
Priority and response time
| Priority | Response expected within | Hint in the dialog |
|---|---|---|
| Critical | 24 hours | safety or regulatory blocker |
| High | 48 hours | data quality issue blocking review |
| Normal | 96 hours | standard discrepancy |
| Low | 96 hours | cosmetic, non-blocking |
The built-in edit checks raise their queries at High priority, except outside the normal range, which is Normal. A rule the designer wrote raises at Normal (action raise a query) or High (action flag).
Status
| Status | Meaning | Reached from | Next, by |
|---|---|---|---|
| Open | Raised, waiting for the site | (new) | the site answers, or a reviewer escalates |
| Answered | The site has responded | Open, Reopened, Escalated | a reviewer closes, reopens or escalates |
| Reopened | The answer was not accepted | Answered, Closed | the site answers again, or a reviewer escalates |
| Escalated | Flagged for elevated review | Open, Reopened, Answered | the site answers, or a reviewer closes |
| Closed | Reviewed and settled | Answered, or an auto query that fixed itself (the server also accepts Escalated, but the screen offers Close only on an Answered query) | a reviewer may reopen it |
An Escalated query can only be answered or closed.
The Queries screen
| Control | What it does |
|---|---|
| Tiles Open, Past SLA, Auto-raised, Manual | Counts for the whole study (your site, for site staff), independent of the filters |
| Tabs All, Auto, Manual | Filter by origin, with the counts |
| All status list | Filter by Open, Answered, Escalated, Reopened or Closed |
| Search box | Searches subject, description and raiser |
| List | 25 per page by default, highest priority first; a pager sets the page size |
| Open field / Open subject | Jumps to the value on its form, or to the participant for a query that has no value |
| Reply box | One box for the answer (site) or the note (reviewer) |
| Send response, Close, Reopen, Escalate | Shown only when your role may take that action on that query in its current status |
- Every query raised at this site.
What the system records
- The thread keeps every comment, every status change and every system entry, in order. Database triggers refuse any update, delete or truncate of a thread entry made through the application or its database role.
- Who did what. The query row stores who raised it, who gave the latest answer and who closed it. Reopening clears the closer; the thread still shows who closed it.
- The audit ledger receives an event for each step (raised, answered, closed, reopened, escalated) with the person, the time and, for close, reopen and escalate, the note as the reason. The event is written in the same database transaction as the change, so a query can never change without its ledger entry. The study Audit Trail shows readable lines for raised, answered, closed and reopened.
- No notification. Raising, answering or closing a query sends no email and no in-app notification. People find work on the Queries screen and in Query aging. If your process needs someone told, build that step into your procedure.
What you cannot do, and why
| You cannot | Because |
|---|---|
| Answer a query you raised | The person who raises a query does not answer it. Checked against the signed-in user, by the application and again by the database (409 clinical.separation_of_duties) |
| Close a query you answered | The person who answers does not close. A reopen clears the rule, so the one who closed a query may answer it once it is reopened |
| Edit a value by raising a query | A query is a question. The site changes the value, with a reason, and your query is what authorizes the change. A query you raised yourself authorizes nothing for you |
| Raise, answer, close or reopen without the permission | The four actions are strict: no administrator override. A custom role that holds both sides of a pair is still refused on the same record |
| See or answer another site's queries | A site user is confined to their own site. A delegate answers only where query response was delegated to them |
| Close a query nobody has answered | A query moves Open → Answered → Closed. Only an auto query whose check stopped failing closes itself while Open |
| Work on Live queries while the study is in Setup, Locked or Archived | There is no Live data to clean before Version 1.0 goes Live, and a locked study accepts nothing: The study database is locked; no changes are permitted |
| Lock the study while a query is Open, Reopened or Escalated | The lock is refused, and the dialog says how many queries are in the way. An Answered query that has not been closed does not block the lock |
| Change the data of a Completed, withdrawn or lost-to-follow-up participant, except by answering a query | Such a participant takes no new data. A value is corrected only while a query raised by someone else is on it, and the reason and the earlier value are recorded |
Queries keep working while the study is Active, On hold, Closed to enrolment, and Completed (queries only).
Compliance Q&A
No. Answering is refused to the person who raised the query, and closing is refused to the person who gave the latest answer. The rule is held three times: the screen hides the control and says why, the application checks it against the signed-in user (never a value sent by the browser), and a database trigger enforces it for any writer, so a custom role or a direct database connection cannot get round it. The simulation of 20 Oct 2026 confirmed it with real roles: the coordinator who answered had no Close control, and the Data Manager's page had no reply box.
Evidence: server/src/modules/study/queries/domain/query.tstrigger trg_queries_separation (server/db/schema.sql)ADR 0015, decision 8server/tests/unit/modules/queries/query.test.tsserver/tests/integration/queries-over-cells.integration.test.ts
Each step adds a thread entry and a ledger event naming the person, with the server's time. Thread entries cannot be updated, deleted or truncated through the application or its database role, whoever is signed in. The ledger event is written in the same database transaction as the change. The thread therefore shows the full history of a query, including a reopen.
Evidence: triggers trg_query_thread_no_update and trg_query_thread_no_truncate (server/db/schema.sql)raise-query.ts, answer-query.ts and transition-query.ts (ledger event in the same transaction)
Yes, for tracking. Each query carries a response time from its priority (24, 48 or 96 hours), the Queries screen shows the time left or overdue on every row and a Past SLA count, and the Query aging report shows how long queries have been open.
Limits: the response times are fixed by priority and cannot be set per study or per site. Nothing escalates, reminds or blocks when a query passes its time; it is shown, not enforced.
Evidence: server/src/modules/study/queries/domain/query-lifecycle.ts (slaHoursFor)pg-query-repository.ts (past SLA)Query aging report
Your organization. The software separates the roles and records every step, but it does not know your data management plan. Define in your procedures who reviews answers, how fast open queries must be cleared, when to escalate, and how reviewers are trained. The software supports the evidence of that work; it does not replace the procedure.
No. Raising, answering, closing and passing the response time send no email and no in-app notification: the only notifications in the system today are "added to a study" and "study created". Sites find their work on the Queries screen. If sites must be told, your procedure has to say who tells them and how.
Related
Correct data · Monitor and verify data · Enter visit data · Rules reference · Statuses · Roles and permissions · Notifications · Compliance questions index