How clean your data is at database lock is decided by choices your study team makes long before then. Datacapt gives you the tools. The plan, the responsibilities and the timelines are yours.
Before you build
Write the monitoring plan first. Who reviews what, at what frequency, and who signs off. Doing this before the eCRF exists means the eCRF gets built to support it, rather than the plan being bent to fit the eCRF.
Decide your data controls while you design the questions. Every check you write as a data validation is a query you never have to raise by hand. Every check you skip becomes a query per subject. See Build automated queries with data validation.
Decide who locks and who signs, and in what order. These are separate permissions and separate actions with different scopes. Working it out under time pressure at database lock is how studies end up with half a database signed by the wrong person.
Decide whether you need eCRF Review. It is off by default. Switching it on adds the review stamp and the SDV controls. A study that decides mid-flight has a period of data that was never reviewed.
đĄ Tip: document your validation of the eCRF at the time you do it. Inspectors ask how the form was validated, and that answer is far easier to produce on the day than to reconstruct two years later.
Set expectations with your sites, explicitly
Train sites on the eCRF, not only on the protocol. Cover data entry, what the validation messages mean, and how a query reaches them and gets answered. A site that has never seen a query will not answer one.
Tell sites how they will find out about queries. This is the one that surprises teams, so it has its own warning below.
Agree a turnaround time for queries in writing. Without a number, "promptly" means whenever the site next opens the study.
Give sites something to refer back to. A short guide and an FAQ for the situations that come up most reduce both the questions that reach you and the wrong entries that become queries.
â ď¸ Warning: Datacapt does not notify a site automatically when a query is raised on their data. There is no email and no push. A site discovers a query when they next open the eCRF, where the top right reads 1 active query. Two ways to close that gap, and you need one of them:
Build an Automation that emails the site when a query is raised on their center. See Create and Configure Automations.
Chase deliberately, on a schedule, using the Queries dashboard.
Doing neither is the most common cause of queries sitting open for months.
While you are collecting data
Work queries in real time. Site staff remember a visit from last week. They do not remember one from last year, and neither do their notes.
Watch the Queries dashboard by center, not in total. One site with three times the query rate of the others usually means the form is unclear to them, or they were trained differently, not that they are careless.
Look at what the queries are about, not just how many. Twenty queries on the same question is a form problem you can fix once. Twenty queries on twenty questions is a training problem.
Review on a schedule rather than in a push at the end. The review stamp is cleared whenever the data underneath it changes, so reviewing a form that is still being filled in is work you will do twice.
Stay inspection-ready
Check the configuration against the standards that apply to your study, for example FDA 21 CFR Part 11 and GDPR. Access is granted by role rather than by user, so review the roles, not the people.
Decide about the reason for change option before go-live. Every entry and edit is recorded automatically, but the reason for change option makes an edit record why, which is the part an inspector asks about. It lives under Settings > Options > Enable GCP.
â ď¸ Warning: the reason for change option cannot be enabled once the study is Live. This is a decision with a deadline, and the deadline is go-live.
When you close the study
Close every query before you try to lock. Datacapt enforces this: a lock on a form with an open query fails outright. Knowing that in advance saves a confusing afternoon at database lock.
Agree the order of operations. Review, then verify, then lock, then sign, is the usual sequence, but your process is yours. Write it down before you start.
Plan the archive at the same time as the lock, before the study moves to Ended and everything becomes read-only.