> ## Documentation Index
> Fetch the complete documentation index at: https://docs.carelane.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Query Lifecycle

> Understand the query workflow from creation to resolution

Queries follow a defined lifecycle from creation through resolution. Understanding this lifecycle helps ensure efficient query management.

## Query States

Queries progress through these states:

| State        | Description                     |
| ------------ | ------------------------------- |
| **Open**     | Query raised, awaiting response |
| **Answered** | Site has responded              |
| **Closed**   | Query resolved                  |

## Lifecycle Flow

```
Created → Open → Answered → Closed
                    ↓
              Reopened → Open
```

<Steps>
  <Step title="Query Created">
    Study team raises a query on a data field.
  </Step>

  <Step title="Open">
    Query is open and awaiting site response.
  </Step>

  <Step title="Site Responds">
    Site team provides response or makes corrections.
  </Step>

  <Step title="Review Response">
    Study team reviews the response.
  </Step>

  <Step title="Close or Reopen">
    If satisfactory, close the query. Otherwise, reopen.
  </Step>
</Steps>

## Query Creation

When a query is created:

* Associated with a specific field and record
* Query text describes the issue
* Record status changes to "Queries in Progress"
* Site team is notified

## Open State

While open:

* Appears in site team's query queue
* Blocks record verification
* May indicate if value change is expected

### Value Change Expected

When raising a query, indicate whether a data value change is expected:

| Setting | Meaning                              |
| ------- | ------------------------------------ |
| **Yes** | Site should change the data value    |
| **No**  | Site should clarify without changing |

## Site Response

Site team responds to queries by:

1. Reading the query text
2. Investigating the issue
3. Updating data if needed
4. Providing a response explanation

### Response Content

Responses should include:

* Explanation or clarification
* Reason for any data change
* Reference to source documents if applicable

## Study Team Review

After site responds:

<Steps>
  <Step title="Review Response">
    Examine the site's response and any data changes.
  </Step>

  <Step title="Assess Adequacy">
    Determine if the response resolves the query.
  </Step>

  <Step title="Close or Reopen">
    Close if resolved; reopen if further clarification needed.
  </Step>
</Steps>

## Closing Queries

When closing a query:

* Record status may return to "Completed (Site)"
* Closure is recorded in audit trail
* No further responses accepted

## Reopening Queries

If the response is insufficient:

* Add follow-up comment explaining what's still needed
* Query returns to Open state
* Site receives notification

<Warning>
  Avoid excessive reopens. Write clear initial queries and clear follow-up requests.
</Warning>

## Multiple Queries

A record can have multiple queries:

* Each query tracks independently
* Record stays in "Queries in Progress" until all closed
* Queries can be on different fields

## Query History

Full query history is preserved:

* Original query text
* All responses and comments
* Status changes with timestamps
* User actions

<Accordion title="Viewing Query History">
  Click on a query to see its complete history, including all messages and status changes.
</Accordion>

## Impact on Record Workflow

Queries affect the record workflow:

| Scenario           | Record Status         |
| ------------------ | --------------------- |
| Query opened       | Queries in Progress   |
| All queries closed | Completed (Site)      |
| Ready for sign-off | Verified (Study Team) |

## Finding Participants by Query Activity

The participant list includes a **Query Status** filter so you can jump straight to participants that need attention. Three activity states are tracked:

| Filter                     | Who sees it | Meaning                                                                         |
| -------------------------- | ----------- | ------------------------------------------------------------------------------- |
| **Queries in Progress**    | Everyone    | The participant has at least one open query awaiting a site response            |
| **Queries in Preparation** | Site admins | Study staff have drafted queries on this participant but have not yet sent them |
| **Queries Responded**      | Site admins | The site has responded to one or more queries awaiting study-team review        |

Participant rows display a visual indicator when responses are pending, making it quick to spot participants ready for the next review cycle. Counts are denormalised on the participant record, so filtering stays fast on large studies.

## Notifications

Query events trigger notifications:

| Event             | Notified   |
| ----------------- | ---------- |
| Query created     | Site team  |
| Response provided | Study team |
| Query reopened    | Site team  |
| Query closed      | Site team  |

## Best Practices

<AccordionGroup>
  <Accordion title="Respond Promptly">
    Address queries quickly to maintain data quality timelines.
  </Accordion>

  <Accordion title="Complete Responses">
    Provide thorough responses to avoid reopening.
  </Accordion>

  <Accordion title="Reference Sources">
    Cite source documents when clarifying data.
  </Accordion>

  <Accordion title="Track Open Queries">
    Regularly review open query counts by site.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Creating Queries" icon="plus" href="/data-quality/creating-queries">
    How to raise queries.
  </Card>

  <Card title="Responding to Queries" icon="reply" href="/data-quality/responding-queries">
    How to respond to queries.
  </Card>
</CardGroup>