QA as the base of a study, a training environment and YouEDC Studio

YouEDC Capture

• The QA environment is the base of a study. A new study, a copy too, is made with its QA environment at once and opens there: the team builds the eCRF in the QA builder and tries it on test patients, and production waits for the launch. A tested candidate goes into production with “Release in production” (on the card, in the orange QA bar and on the QA versions page) as the next version, with a signature, a reason and an audit record, like a protocol amendment. The production's builder is read-only, and the doctors' data stay there. The QA environment, in a demo too, is made by the person who pressed the button, never by an invented member. Studies with a QA environment made before were turned round by the portal at the update, without loss. QA environment of a study · eCRF versions
• The data entry deadline after a visit. On the new page “Late data entry” the data manager sets how many working days (Mon–Fri) the protocol gives to enter a visit, for example 5, and if needed a deadline of its own for single visits. The portal finds what is late by itself: a visit that took place whose forms are not entered or still drafts after the deadline, and a planned visit whose window closed with nothing entered; a visit marked “did not take place” with a reason is not late. The page lists the late visits by site (patient code, visit, forms, date, working days late) and the log of letters; the site sees its late patients with the “Late entry” filter of the patient list. The letter to a site is one per site with everything late, every working day or once a week on the chosen day, to the principal investigators, all investigators or the monitors of the site; patient codes and links to the portal only, in the recipient's language, without the forms hidden by blinding; at most once a day and only when something is late. A QA environment, demo studies and studies before the launch or from the soft lock send nothing. The letter can be previewed and sent at once; the settings and every letter are in the audit trail. Everyone can switch the letter off in the profile Data entry deadline and letters to the sites · Patients and the visit matrix
• Consent versions by site. The Informed consent page has a new table, Versions at the sites: for each version and each site, the day the site moved to it (its ethics committee's approval) and the decision's number. A consent recorded by hand or signed remotely cannot be signed before that day; while the site's day is not filled, the version's approval date is checked and the portal reminds to fill it. A version can name its protocol version. The patient's card puts consents and visits on one line: a visit done after the site moved to a version asking for re-consent, before the patient signed it, is marked red. Such visits, and consents signed before the site moved, become deviation candidates in YouEDC Trials. Every change of the sites' days is in the audit trail. Informed consent
• SDV plan by visit and form. On SDV and approval → SDV plan the project manager sets, for each form at each visit, 100% SDV, partial SDV or no SDV. With partial SDV the pages of a sample of each site's patients are verified: the site's 1st patient and then every k-th in the order of registration, with the share from the YouEDC Trials monitoring plan by the site's risk or set for the study. The rule is reproducible, the sample is shown on the page and goes to Excel for the TMF with the plan. The Waiting for SDV tab, the form's SDV panel, the visit states, the patient card, the overview and the YouEDC Trials counts follow the plan. Until the plan is edited everything works as before; every change is in the audit trail. Monitoring, SDV and the data manager's approval
• From QA to production in one click. “Release in production” is on the study card in My studies when QA is chosen, in the orange bar on every page of the QA environment and on the candidate's UAT card (the main button once the UAT is approved). It leads to the release form of the working study, where the tested candidate is signed as the next eCRF version, with the reason and the password. Only those who release versions see it. QA environment of a study
• The study's training environment. A second linked copy of the working study where investigators and coordinators practise on invented patients. It has the eCRF version in force (not the draft) and gets each new version by itself after the release. The whole team is taken over with the same roles and sites. The builder is read-only there, ePRO letters go only to the team, marked “[Training]”, and nothing reaches the working study, its exports or counts. In My studies the card's switch is now Production | QA | Training, and its ⋯ menu makes a QA environment, a training environment or a new study on the basis of this one. QA environment of a study
• A new study on the basis of another one. The wizard's Template step has Copy of my study: the eCRF draft (forms, fields, code lists, edit checks, visits, actions on event) becomes the new study's draft. If ticked, the sites are copied 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 audit trail of both studies says where the copy came from. QA environment of a study
• YouEDC Studio in Capture studies. The study menu has a YouEDC Studio item: the Studio tools work on the study's live data with no export and no upload. Under the upload field of a tool, pick a file of the study: the forms, the patients, queries, visits with dates, page status and the audit trail. A snapshot of the data is kept with one button, and “What changed” compares it with the current data. One sees what the study export would give: one's own sites and blinding. Demo studies already have a snapshot from a week ago. Project data: deliveries and history
• The date of birth given at enrolment for the duplicate check goes straight into the eCRF's date-of-birth field (BRTHDAT and the like) as a draft by the person who enrolled, noted in the audit trail; the site checks and completes the form without typing the date twice Patients and the visit matrix
• Resetting a patient's ePRO PIN. The patient card shows the state of the PIN (chosen, locked, reset), and the investigator or coordinator of the patient's site clicks “Reset the PIN” and chooses the reason. The old PIN and its lock are cleared, the patient's open sessions close, and the card shows once a one-time code of 6 digits, valid for 72 hours. The patient opens the same link, enters the code and chooses a new PIN; wrong codes count as wrong tries. The link, the QR code, the notifications, the reminders and the answers waiting without the internet stay. The audit trail keeps the reset with its reason and the new PIN chosen. Patient questionnaires (ePRO)