YouEDC Capture
- UAT of an eCRF candidate in the test environment. The test environment's “UAT” page makes a run for the candidate, its steps made from the candidate's design. The first step is always manual: the eCRF specification and the DVP reconciled with the protocol in force (the protocol version goes into the comment). Then the visits and the schedule if they changed, and a script per form: the form against the specification, and for each new or changed field and check and for every critical field the allowed and expected ranges, the required answer and the check itself. The robot enters the steps' values into the candidate's edit-check engine in memory, saving nothing, and compares the answer with the expected result from the specification (the declared bounds, the message texts). What the robot cannot set up (a check with a condition, a value of another form, a calculated field) becomes a manual step; a calculation is worked out by hand. Fail and n/a need a comment. The executor signs the run (e-mail and password), another person who recorded no step approves it; a run with a failed step is not approved. A new candidate gets a new run, and the passed manual steps of unchanged elements are taken over. The run downloads in Excel. The working study releases a version without a mark only when the UAT of its candidate is approved; otherwise with the tick “Release without an approved UAT” and a reason, and the version shows it. The demo studies have a test environment with the approved UAT of the next version's draft QA environment of a study · eCRF versions
- A study from its protocol: the progress of the set-up. After the upload the page shows the upload of the file, then the steps of the set-up one by one: reading the protocol page by page (“page 12 of 150”), finding the schedule of activities, creating the study and its eCRF draft, the test environment, the log, and opens the log itself when the study is ready. You can leave the page: the set-up runs in the background and the job is under “My background jobs”. If the file cannot be read, the page says why and nothing is created; pressing the button again does not start a second set-up. The training protocol is set up with its progress too. A big PDF is read page by page and takes six times less memory: before, a protocol of over a hundred pages could outlast the server's answer A study set up from its protocol
- Paste from Excel into a table of a form: copied cells fill the table to the right and down, a growing table adds the rows it needs, and lines “test, result” of a lab report go to the rows of the lab table with the same name or code; what the table lacks is named under it Entering data into a form
YouEDC Safety
- A SUSAR in a blinded trial: the unblinded E2B(R3) for the authority. Mark the case's blinded study product, and a member with unblinded access downloads a file where that product is named by the treatment allocation, as the authority receives a SUSAR. The usual E2B and CIOMS I stay blinded for investigators and ethics committees; the blinded team never sees the unblinded file, and the case history records the download without the allocation. A safety physician checks the file before it is sent YouEDC Safety
Portal
- Suggestions: decisions come with a release. Export the suggestions and discuss them with the developer; what was decided (done, planned, not planned, with an answer to the author) goes into the next release. After the install the statuses and answers are set by themselves and the author sees them in “My suggestions”. A decision is applied once, only to its own suggestion, and does not change a status an admin set by hand later Suggest to the developer
- The roadmap shows on top which build the portal runs now, with a link to its release notes; the number comes from the installed archive
- Demo: a real-world data (RWE) study of rheumatoid arthritis from medical charts. Day 1 is the start of the first biologic years ago; the time points up to month 60 take the nearest DAS28 assessment in the window or are marked not done with the reason; a lines-of-therapy log, a consent or the ethics committee's waiver of it, an interim data cut. Real-world data studies carry a green RWE badge next to DEMO in the top bar, the banner and the lists of projects, and the demo page groups them together Demo project
- A quick start guide on four A4 pages: the most important things about every section, a map of the portal, how a screen is organised, five steps to a running study and five rules, with links to the help articles. Print it or save it as PDF. The portal strongly recommends that newcomers read it before the first use: on the desk and in the help. The portal has its own mouse doctor in a white coat: it illustrates the guide and now and then peeks into the home page, leading to the guide. The guide is refreshed every fifth build
- Deleting a study for good: Administration › Projects › the bin on the project's row. The admin types the project code, the project disappears for everybody at once, and in the background everything goes: patients and data, team and sites, queries, signatures, files and DICOM on the disk and in S3, documents, the test environment, the study's audit chain (each study has its own). The portal audit keeps two lines: who queued the deletion and why, and how many records went. The switch in Administration › Settings › “Deleting studies” closes the deletion in the code and in the database itself: switch it off on an installation that runs real studies whose records must be kept for years Administration