What this is, and who it is for
A design returns to Build from UAT in two ways: the testers fail the cycle, or a signer rejects at sign-off. In both the design is editable again, every earlier sign-off is withdrawn, and the next submission opens a new cycle on a new snapshot. When a cycle failed, the issues that were still open are the corrections the next round owes: the UAT corrections page lists them so the designer can say what was done about each.
| You need | To |
|---|---|
form.design | Mark a correction resolved, or take that back |
study.read / study.version.read | See the page |
Held by: Organization Admin, Project Manager, eCRF Designer (form.design).
Where to find it
Study → Build → UAT corrections, which appears only when a UAT cycle has sent the design back. The Build home shows a callout (Back from UAT cycle 1: 3 corrections are still open) and the menu item carries the number open.
What you can do
- Open UAT corrections. Filter All rounds or the Current round, or Open corrections only. The summary shows Rounds, UAT cycles failed and Open corrections.
- For each round, Requirements · what came in lists the findings: Finding, Linked to (the form, visit or participant it was seen on), Severity and Status. The first round is The initial design, built from the protocol. A round carries a RE-CONSENT REQUIRED tag when its version is an amendment that asks for it. View the saves of this round opens the save history for that round.
- Make the change in Forms, Visits or the Mapping.
- Back on the page, choose Mark resolved for the finding and say What was done? (optional). Take back reopens a correction marked resolved by mistake. The callout turns green when every correction is resolved.
- A Project Manager submits the version to UAT again when it is ready (Review and release a study).
Every option
What a correction is
A failed cycle's issue log is closed evidence and is never changed. What the design side says about a finding is a correction, a row of its own. Only a finding that was still open when the cycle failed needs one; a finding UAT had resolved or accepted does not. A correction can be made only for the version's latest failed cycle, and only while the version is in Build: once the version is submitted again the round is over and its corrections are frozen with it. The database holds those rules for every writer.
Ways back to Build
| How | Effect |
|---|---|
| Fail the cycle (a reason is required) | The version returns to Build; the cycle and its test data stay, read-only. Sign-offs still standing are withdrawn |
| Reject at sign-off (a reason and a signature) | The version returns to Build and the sign-offs given so far are withdrawn. There are no corrections to mark, because the cycle passed; the reason is on the sign-off |
What the system records
uat.cycle.failed with the reason, study.version.signoff_rejected, study.version.returned_to_build, and for each correction uat.correction.resolved or uat.correction.reopened with the person and the note. The failed cycle's issues stay as they were.
What you cannot do, and why
- Change or delete an issue of a failed cycle. It is evidence.
- Correct a finding the cycle had already resolved or accepted.
- Mark a correction after resubmitting. The round is closed.
- Skip the retest. A corrected design is a new submission, snapshot and cycle; nothing carries over a pass.
Compliance Q&A
Yes. A failed cycle is never overwritten: it keeps its issues, its test data and its reason. What the designer did about each open finding is recorded separately, with the person and the time, and the next round starts on a new snapshot.
Evidence: server/src/modules/study/versions (failed cycle kept with its reason and test datacorrections as separate rowsaudit events uat.cycle.failed, uat.correction.resolved)
Related
Test a version in UAT · Build a study · Review and release a study · eCRF Designer