QA environment of a study
Test patients for every eCRF amendment: publish the draft to QA, try it, release the same snapshot.
The QA environment is the base of a study. A new study is made as its QA environment alone, without production: the team builds the eCRF and tries it on test patients in QA, and sometimes lets a demo doctor in. The eCRF reaches production, where the sites' doctors work, only from QA: a tested candidate is released there as a signed version, like a protocol amendment. So no change reaches real patients untried.
What the QA environment is
- It is a study of its own with a code like REG-DIAB-01-QA. It has its own sites, team, patients, queries and audit trail.
- Test patients never reach the working study: not its lists, exports, YouEDC Biostat, counts or letters.
- Every page of the QA environment has an orange frame and the QA badge. Test patients' codes start with the letter T.
- There is one eCRF builder, in the QA environment. In production the eCRF is read-only: every change comes there from QA as a released version.
Making it
The New study wizard makes the study as its QA environment and opens it: a study with the code REG-DIAB-01 appears as one record, REG-DIAB-01-QA. There is no production yet: the Production tab on the card is grey and says “after the release”. A study made as a copy is made the same way. The person who pressed the button is recorded as the creator and the manager. For a study made earlier without a QA environment, the manager presses eCRF builder → eCRF versions → Make the QA environment: the eCRF moves to QA, and the production's builder becomes read-only. The portal takes over the sites, the manager and the data managers of the team. The manager invites investigators and monitors if they take part in the testing. If production already has a released version, the draft becomes candidate 1 at once.
While the study is being set up and has a QA environment, patients are enrolled only in the QA environment: the working study's Enrol button, import and API send there. So the working study starts with no test patient, and nothing has to be deleted at the launch.
A candidate for the UAT
Change the eCRF in the QA environment's builder as usual. While there is no candidate, changes reach the test patients at once. When the eCRF is ready for testing, press Make the draft candidate N on the QA environment's eCRF versions page. No signature is needed: it is not a release. From then on the builder changes only the draft, and the test patients work on the candidate. The card shows whether the candidate is the same as the draft or the draft has changed since.
What cannot be released cannot become a candidate either: for example, when no form is in any visit.
Test patients stay from version to version
Each publication updates the same visits, forms and fields of the QA environment, so the test patients' data stay: new fields are empty for them, changed checks work the new way, deactivated fields are hidden and their data kept. The test patients become a regression set for every next amendment.
A field added in the draft and deleted before its release leaves the QA environment with its test values. A form or visit with test data is not deleted but deactivated.
UAT of the candidate
Before its release a candidate goes through UAT (user acceptance testing): scripts with expected results, an executor who runs and signs them, and an approver who approves them. In the QA environment the eCRF versions page has the card UAT of candidate N: press Open the UAT, then Make the UAT run of candidate N. The run tests the candidate in force in the QA environment and is bound to its number and SHA-256. The manager, the data manager and the monitor of the QA environment make and execute runs.
Nobody writes the steps of a run by hand: the portal makes them from the candidate's design.
- The first step is always manual: reconcile the eCRF specification and the DVP (the edit checks) with the protocol in force. Write the protocol version and its date in the comment.
- Then the visits and the visit schedule, when they changed.
- Then a script per form: the form against the specification when anything in it changed, and steps for every new or changed field and edit check (all of them before version 1 is released). A field is tested for its allowed range, its expected range and its required answer; an edit check for firing where it should and keeping quiet where it should not.
- The critical fields and their checks are in every run as regression, even when they did not change.
The robot does most of the steps: press Run the robot steps. The robot enters each step's values into the candidate's edit-check engine in memory: nothing is saved and no test patient is needed. The expected results come from the specification (the declared bounds, the message texts) and are never computed by the system, so a wrong field setting shows up as a failed step. What the robot cannot set up by itself (a check with a condition, a value of another form, a field shown by a complex condition, a calculated value) becomes a manual step. The executor works a calculated value out by hand and writes both numbers in the comment: their own and the one the form showed.
Manual steps are done on test patients: choose pass, fail or n/a and press Record the outcome. Fail and n/a need a comment: what you saw.
Signatures and a new run
When every step is recorded, the executor writes the conclusion, ticks “I executed these steps and the recorded results are true and complete.”, enters the password (and the e-mail at the first signature of a session) and presses Sign as executor. Then another person approves the run: a member of the QA environment who did not execute it and recorded none of its steps. They review the steps and results and press Sign the approval. So the QA environment needs two people at least: the portal takes the manager and the data managers over to it, and the manager invites the monitor.
A run with a failed step is not approved. Correct the eCRF in the QA environment's builder, make the draft the next candidate and make a new run. Passed manual steps whose element did not change go to the new run marked “taken over from run N”; the robot steps run again. An unfinished run of the earlier candidate becomes “superseded by a newer run” and stays in the list as a record.
The Excel button on the run's page downloads the whole run: the header has the candidate, its SHA-256, the version it was compared with, the result and the signatures; then a row per step with the expected and the actual result and who recorded it when. Making the run, each pass of the robot, every recorded step and both signatures go to the QA environment's audit trail.
To run the steps on paper, press Scripts PDF or Scripts Excel on the UAT page: a blank sheet where the outcome, the actual result, the initials and the date are written by hand. After the release, the validation kit of the version gathers the scripts, the results, the signatures and the release record into one ZIP: see Validation kit and study archive.
Release in production
Release in production is on the study card in My studies when QA is chosen, and in the orange bar on every page of the QA environment. It opens the Release in production card on the QA environment's eCRF versions page: give the reason and the password, tick the statement and press Sign and release in production. The portal takes the candidate into production and releases the next version there with your signature. The version records “tried as candidate N” and “UAT run N approved”. The doctors' data in production stay where they are: a released visit, form or field with data is switched off, never deleted. The project manager and the data manager see the button, that is, those who release versions.
The study build is validated in the QA environment: the UAT of the candidate and the study's validation package are made and approved there, before the release. Production gets the validated candidate as a version that works at once; nothing is validated in production. The study's validation package is in the QA environment's menu. A working study made before the QA environments is not changed in production either: its builder is read-only and no version is released there until the project administrator makes the QA environment with “Make the QA environment” on the eCRF versions page; the eCRF moves there, and from then on everything goes through QA.
The first release makes the production REG-DIAB-01: the study's settings, sites, manager and data managers go there, never the test patients or their data. The candidate becomes version 1 there with your signature. Production starts in set-up: the doctors begin once the manager launches the study. The person who pressed “Sign and release in production” is recorded as the creator of production.
Studies made before this order were turned round by the portal at the update: the production's draft went to the QA environment without loss, and the eCRF has been built there since. The audit trails of both studies have the line “eCRF moved to the QA environment”. Where the wizard had made an empty production next to the QA environment and nobody worked in it, the portal moved it to the admin's trash at the update, and the study stayed one QA environment. Its audit trail has the line “Empty production put aside: the study lives in its QA environment”. The first release makes production again under the same code.
Without an approved UAT the release form shows the tick “Release without an approved UAT (say why in the reason)”: this is how an urgent fix is released. Without the tick the portal does not sign such a release. When the draft has changed since the candidate, with the tick it becomes a new candidate first. A version released this way is marked “without an approved UAT” in the list of versions and in the audit trail.
Running the draft over the working data
Test patients show how the amendment works on new records. But the working study already has hundreds of completed forms, and you need to know beforehand what the amendment does to them. The draft card on the versions page has the button Run the draft over the working data for this. The manager, the data manager and the monitor see it.
The portal takes every saved page of the forms whose fields or checks the draft changes and checks it twice: with the version in force and with the draft, the same way a save does. The result, by site:
- New errors: values the draft would refuse (a narrower range, a removed option, a new error check). The value stays, but the site meets the error the next time it saves the page.
- To add: completed forms that lack a field that became required.
- New automatic queries: warnings that do not fire today. The query opens when the page is next saved.
- Automatic queries the draft no longer raises: an open automatic query is closed when the page is next saved.
The run only reads: it writes nothing to the data, opens no query and leaves one line in the audit trail. Everyone sees their own sites, without the patients who withdrew the use of their data. Patient IDs are shown to those who may see patients.
To add after an amendment
When an amendment makes a field required, forms already completed stay completed: nothing is reopened and the SDV mark stays. Such forms go to the list To add after an amendment: the Patients page shows a yellow notice with a link to it. A site sees only its own forms.
For each form the list names the field needed and the version since which it is required. The form itself shows a hint too. Open the form, fill the field in or mark it “no data”, and save: the form leaves the list. A field hidden by its show condition (a question for smokers only, say) is not required.
The training environment for investigators
The training environment is a second linked copy of the study. Investigators and coordinators learn data entry there on invented patients without spoiling anything in the working study. Make it on the eCRF versions page (Make the training environment) or from the ⋯ menu on the study's card in My studies. Its code is the study's own ending in -TRN; its badge and top stripe are purple.
- The eCRF is the version in force, not the draft. The QA environment is for trying what is about to change; the training environment shows what the sites will really fill. After every release in the working study it gets the new version by itself. While the draft has unreleased changes, it waits for the next release.
- The whole team with the same roles and sites. The people who will enter data are the ones who practise. The eCRF builder is read-only there.
- Apart from the working study. Its own patients, queries and audit trail. Nothing reaches the exports, Biostat or counts. ePRO letters go only to the addresses of its team, marked “[Training]” in the subject.
In My studies the working study, its QA environment and its training environment are one card with a Production | QA | Training switch. An environment whose team you are not in is greyed out with a lock. Before a study's first release its Production tab is grey and says “after the release”.
A new study on the basis of another one
In the new study wizard, at the Template step, choose Copy of my study and the study to copy. The item “New study on the basis of this one” in the ⋯ menu of a card opens the same. You may copy the studies where you are the manager or a data manager.
The eCRF draft is copied: forms, fields, code lists, edit checks, visits and actions on event. It becomes the new study's draft, not yet released. If you tick them, the sites are copied too (numbers, names, cities, without people) and a QA environment is made at once. Patients, data, queries, signatures, versions, the team and the audit trail are never copied. The two studies are not linked afterwards; the audit trail of both says where the copy came from.
What is not taken over yet
The QA environment gets the eCRF, the answer lists, the sites and part of the team. The settings of the modules (randomisation, ePRO, consent, signatures) are set in the QA environment separately. Letters to patients from the QA environment go only to the addresses of its team members, with “[QA]” in the subject.
© 2026 Т.Г. (contact@youedc.com), YouEDC. Tous droits réservés. Conditions d’utilisation. Les données saisies par les utilisateurs leur appartiennent.
MainEDC™ est une marque de DM365.