What this is, and who it is for
After a UAT cycle passes, the version is Awaiting sign-off. Three different people each sign the design the cycle tested, in three capacities. When all three have signed the version is Approved; a person with the right then takes it Live, and it becomes the design participants are captured under.
| Sign-off | Who gives it | Permission |
|---|---|---|
| Author | The Project Manager | study.version.signoff |
| QA | The Data Manager | study.version.signoff |
| Approver | The Sponsor Manager | study.version.signoff |
Held by: Project Manager, Data Manager, Sponsor Manager (study.version.signoff).
The capacity comes from your role, not from anything you choose: the server derives it. The eCRF Designer, the Organization Admin and everyone else have no Sign off control. One person gives one sign-off per cycle. Go live is for a Project Manager or Organization Admin (study.version.go_live).
Held by: Organization Admin, Project Manager (study.version.go_live).
Where to find it
Study → Versions, the version Awaiting sign-off: a Sign off action, and a Reject action; the same on the UAT dashboard and the Version details page. The Version details page lists the three sign-offs and who gave each. A person who cannot sign is told why where the button would be: You already signed as Author, or Ask the Sponsor ….
What you can do
Sign off
- Choose Sign off. The dialog is titled Author sign-off — 1.0 (or QA, Approver) and says: Recording an attributable e-signature as {you} ({role}). The signature is bound to the snapshot the passed cycle tested — editing the design afterwards invalidates it (21 CFR Part 11).
- Meaning of signature: say what you attest (required).
- Step-up re-authentication: the system e-mails you a 6-digit code. Enter it.
- Type your name to sign. It must match your name.
- Confirm. The signature is recorded with the meaning, your name and the time, and a fingerprint of the snapshot.
When the third signature is recorded, the version moves to Approved.
Reject
Reject returns the version to Build and withdraws the sign-offs given so far. The dialog asks Why it is rejected (required), the same code and your name. A rejection is a signed act too. The design is corrected, resubmitted and a new cycle is tested (Correct a design after UAT).
Go live
- On the Approved version choose Go live. The dialog reads Take 1.0 Live: an atomic move: 1.0 becomes the design subjects are captured under, with no downtime. From the moment it goes Live, subjects are enrolled and data is captured as real data. Every item below must be done first.
- The Before going Live checklist shows each item ticked or not, with what is missing and where to put it right:
| Item | Means |
|---|---|
| UAT cycle N passed | A cycle passed and none is still open |
| Three sign-offs by three people | Author, QA and Approver all signed and are current (Still to sign: … otherwise) |
| The design is the one UAT tested | Every sign-off is bound to the approved snapshot (its hash is shown) |
| The SDV plan carries over | For an amendment: every verification requirement of the version being replaced still has its form, field and visit in this one |
| A live site with an Investigator | For the first go-live: at least one active production site, and an Investigator at every active one. Sites registered in UAT are test sites and do not count |
- Go live stays off until every item has a tick. Type the version number to confirm, then confirm.
- Stays disabled until the version number typed matches.
- Disabled until the exact version number is typed.
What happens
In one transaction:
- the version becomes Live and the one that was Live (if any) becomes Superseded;
- the study records it as its protocol version and takes the study settings of the version;
- at the first go-live the study moves from Setup to Active;
- the test assignments of people who now hold a Live assignment are retired;
- and it is written to the audit trail.
Going Live changes the configuration only: participants already in the study keep following the version they were created under until they are moved to the new one, one by one, after re-consent where the amendment asks for it (Amend a live study, Record consent and re-consent).
Every option
What can refuse a go-live
- The checklist above is not complete (it is checked again inside the transaction).
- The version is no longer Approved (a sign-off was withdrawn, or it was withdrawn).
- A change in an amendment would no longer fit data the Live version already holds (breaking): the dialog lists each change and what to do instead.
Sign-off safeguards
- A signature is bound to the snapshot the passed cycle tested; if the design changes, it is resubmitted and signed again.
- Three different people in three capacities, enforced by the application and the database.
- A fresh code for each signature, valid for that act only.
- You cannot sign for someone else; your name is typed.
What the system records
study.version.signoff_recorded (capacity, meaning, signer, fingerprint, time), study.version.signoff_rejected, study.version.approved, study.version.went_live, study.version.superseded, team.validation_roster_retired, and a study state change study.state.changed for the first go-live. Each e-signature is an auth.stepup.verified code check and a signature.applied entry. See Audit events.
What you cannot do, and why
- Sign twice for one cycle, or sign as a role you do not hold.
- Sign a design that was not tested. The signature binds to the cycle's snapshot.
- Go live with no active site and investigator (first release) or without three sign-offs.
- Undo going Live. A later version replaces it; the superseded one is kept.
- Edit a Live design. Start an amendment.
Compliance Q&A
Yes. Each sign-off records the signer's name, the time, the meaning they typed and a fingerprint of the snapshot; it requires a code sent to the signer's address and their typed name; and it is invalidated if the design changes.
Limits: the second factor is a code e-mailed to the signer's address, so it is as strong as that mailbox; there is no authenticator application or hardware key (Settings).
Evidence: server/src/modules/study/versions/application/commands/signoff.tsstep-up code (auth.stepup.verified)signature.appliedsnapshot hash binding
No. Author, QA and Approver must be three different people, each holding the role that gives that capacity, so one person cannot give two of them.
Evidence: server version sign-off rules (three different peoplecapacity derived from role)database constraint
Related
Review and release a study · Test a version in UAT · Amend a live study · Sign records · Who can and cannot