Audit trail review, protocol amendments and the help desk

YouEDC Capture

• A new study and its copy are made as one record, the QA environment, without production. Production appears only when “Sign and release in production” is pressed in QA: the settings, sites and team go there, never the test patients, and the candidate becomes version 1. The person who pressed the button is recorded as the creator. Until the first release the Production tab on the card is grey and says “after the release”. An empty production the wizard had made next to QA, where nobody worked, was moved to the admin's trash at the update. QA environment of a study
• Audit trail review (study menu → Audit trail review). ICH E6(R3) expects a periodic, risk-based review of the audit trail of critical data; until now there was only a box to tick in the lock readiness checklist. Now the portal turns the study's audit trail into signals worth a look: a change after SDV, after the investigator's signature, after the data manager's approval or after a form was unlocked; the first entry of a form long after the visit; many changes of one value; entries at night or at the weekend in the site's time; many forms within a few minutes; a change by someone other than who entered the value or by an unusual role. Critical data first (critical fields, forms with 100% SDV in the SDV plan), each signal with its evidence: who, when, old → new, the reason, a link to the form. The data manager marks a signal reviewed with a comment or raises a query on the field from it; a new change of the same value opens it again. Progress, filters by site, signal and period, an Excel download, thresholds in the settings. The project administrator, data managers and monitors see it, each for their own sites, blinded members without the forms for the unblinded team. Every mark and query is in the audit trail. The lock readiness item “Audit trail of critical data reviewed” is done by itself once every signal on critical data is reviewed. The demo study already has signals, some of them reviewed. Audit trail review · Préparation au gel
• Central statistical monitoring (site risk, stage 2; Site risk → Central monitoring). The data of each site is compared with the other sites together by fixed statistical tests, no AI: values far from the others (the median, robust z), data too smooth (a small spread, F test; the same value in many patients), digit preference in measurements (the last digit of blood pressure, weight, heart rate against equal shares, chi-square), the trend of the first value by the date of enrolment, rates of adverse events, withdrawals, queries and missing values. Each finding says in words by which method, on how many patients and at which threshold it was found, with a small chart: the site against the other sites together. The threshold counts the tests (0.05 divided by their number); a site with little data gets “not enough data”, not a verdict. The randomisation arm is never used, forms for the unblinded team are not read, a member sees only their sites. A monitor or data manager marks a finding reviewed with a comment or turns it into an action of the site's risk review; both are kept as written and go to the audit trail. If the study wants, the findings not yet reviewed count in the risk level as a separate indicator (off by default). In the hypertension demo study one site rounds blood pressure to 0 and 5 and another enters values that are too even. Central statistical monitoring · Risque des centres (monitoring basé sur les risques)
• Data migration from CDISC ODM 1.3.2 (Import → Data migration from CDISC ODM). The file is checked against the official schema; a file with a DOCTYPE or external entities is refused. In a study whose eCRF has never been released the draft is built from the MetaDataVersion: visits, forms, fields with units and ranges, answer lists and tables, then reviewed and released as usual. Events, forms and items are matched by OID, then by name; sites are chosen or added. The dry run writes nothing and gives an Excel report with every rejected value. The load saves each form with the source Migration, the old audit records in the reason for change, and never turns the old system's users into portal users; loading again updates only the values that changed. Names and initials are never imported. The migration report in Excel and PDF (counts per form and site, rejected values, the file's SHA-256, who and when) goes to the Trial Master File. An example with invented data is there to try. Data migration from CDISC ODM
• Recruitment page and pre-screening (Recruitment in the study menu). A public page of the study at a random address: the plain-language text the ethics committee approved, the sites (by name or by city only) and a short questionnaire of yes-or-no questions, a number in a range (the age) and a choice of answers, each answer marked as fitting or not. The page is off by default and is switched on only after the approval is recorded (the date, the decision number, the version of the text); the approved text is fixed by its SHA-256 and never changes, a new text needs a new approval. A note on the ban on advertising prescription drugs (38-FZ, art. 24). Before sending, the consent to the processing of health data (152-FZ art. 9 and 10, GDPR art. 9, a HIPAA note for the US) names the controller, the retention (6 months by default) and the contact to withdraw. A first name or initials and an e-mail or a phone only, encrypted with the study's key when the study has it on. The person sees only “may fit” or “does not fit”, never the criteria or a diagnosis, and gets a link to withdraw the consent. The leads are seen by the team of the chosen site and the study managers: statuses, notes, “Make a patient” (only the site is copied from the lead), deletion on request and a job that deletes the data after the retention period; all in the audit trail. The study overview shows the funnel and the leads by site and status without personal data. Bots are stopped without outside services; no outside scripts or counters. The diabetes demo study has the page switched on. Recruitment page and pre-screening
• Queries without noise. A confirmed value stays confirmed: once the site confirmed a value and the monitor or data manager closed the automatic query, saving the form again, an import or an ePRO answer with the same values do not open it again; when any value the check reads changes, it checks afresh. The study's library of standard query texts in Russian and English with the placeholders {field}, {value}, {visit}, {form}: the data manager and the project administrator keep it (with a default set, every change in the audit trail), and a monitor picks a text when raising a query and can still edit it. On the query list, tick several queries or all on the page and close them with one required reason after a confirmation: each one is closed and audited on its own, only at your sites and on the forms you may see. Queries
• A data management plan (DMP) from the portal's data (DM documents → Data management plan). A Word document in Russian or English: the profile and design, the team's roles, the sites, the eCRF versions and their history, the counts, a summary of the checks with a reference to the DVP, query management and deadlines, the SDV plan, the coding dictionaries (only names and versions), the reconciliations of SAEs, lab data and vendors, ePRO and consent, randomisation and blinding, imports and API, data review and audit trail review, the database lock with a readiness checklist, the archive and data protection (152-FZ on a Russian installation). What the portal cannot know the team writes right on the screen. A version is issued with a reason and keeps its snapshot and SHA-256; the document lists its version history, and when the eCRF changes the screen says “The eCRF changed since DMP version”. The signature table is signed on paper, and until then the document is marked as the portal's draft. Issuing and text edits are in the audit trail; the data manager and the project administrator write and issue, the monitor reads. The demo study has versions 1.0 and 2.0 after an eCRF amendment. DM documents: the DVP and the DMP
• Study status report on a schedule (Capture → Status report). Recruitment by site against target (registered, randomised, screening failures, withdrawals), visits done and overdue, form completion and missing pages, queries by status, age and site with the site's average answer time, SDV progress, coding backlog, lock readiness with its forecast and ePRO compliance, when the study has them. The data manager chooses the sections, the period, the schedule (weekly on a weekday, monthly or off), the Excel and PDF files and the recipients, only from the study team. A recipient gets a letter without personal data: only numbers and a link to the portal, no attachment. Each reader sees only their own sites, a blinded one nothing that reveals the arms, and lists by patient code only on the portal and only if they see patients. Every report is kept with its date, period and SHA-256 and never changes; making it, the letters and changes of the settings are in the audit trail. Download now works without a schedule. Study status report on a schedule
• A protocol amendment in a running study (eCRF versions → Protocol amendment). Upload the amended protocol or pick it from the Trial Master File: it is read with the same model as the set-up from the protocol and compared with the previous one (or with the eCRF version in force when the study was built by hand). Each change is a row with the protocol's old and new words and pages: a new visit, a visit removed, moved or with a new window, a form added to a visit or taken off, a new form from the library, planned patients and sites into the profile; eligibility criteria, randomisation, the SAE deadline and a form with data already collected are rows to do by hand, with the reason. The data manager accepts or rejects each row with a comment, the project administrator writes the accepted ones into the eCRF draft only (in the QA environment when there is one): the version in force does not change and nothing is deleted. The reason of the release is filled in with the amendment's number and date; when the study keeps consent versions, the page reminds you of re-consent. Everything is in the audit trail, and the rows download as Excel. The demo study has amendment 2, the training protocol its version 2.0. A study set up from its protocol
• The form library is twice as large and easier to use. 163 standard forms instead of 69 and 13 packs instead of 4: study conduct under GCP (protocol deviations, re-consent, the 24-hour SAE report, unblinding, contacts with the patient), family history, surgery, allergies, vaccinations, alcohol, laboratory (liver, inflammation, iron, cardiac markers, insulin, OGTT), infections, oncology by RECIST 1.1, cardiology (CHA2DS2-VASc, HAS-BLED, MACE), neurology (Glasgow coma scale, Rankin, CGI), spirometry, MELD and Child-Pugh, DAS28, PASI, dermatology and cosmetics, pregnancy, medical devices, health economics, registries. The core forms get CDASH fields: the reason for an unplanned visit, the route and batch of the study drug, the time and fasting for laboratory samples. The library page: tabs, groups on the left, search without a reload, the form's preview beside the list, several forms with one button. The WHO-5, AUDIT and EPDS questionnaires are templates without text: paste the official text from its licence or permission. The demo studies show the new forms in the draft of the next eCRF version. Form library, copying and eCRF from Excel
• The talk with the doctor in remote consent (eConsent). The page of a remote signing request has a new block, Talk with the doctor: the site plans a talk in answer to the patient's request or on its own, with the date and time in its own time zone, the length and the way: a video call by a link of the organisation's own video service, a phone call from the doctor or a meeting at the site, and a note for the patient. A talk can be changed and cancelled with a reason; a new link to the patient keeps it, the patient's refusal or a cancelled link cancels it. The patient sees the talk on the consent page behind the same link and code: the time in their own time zone, “Join the video call” (it opens in a new tab; YouEDC hosts and records no call and loads no script of a video service), “The doctor will call you” or “Come to the site”, and an .ics file for the calendar. When the patient's e-mail is known and the letters are on, the patient gets letters when the talk is planned, changed or cancelled and a reminder the day before, without the study's name and without the link to the call. Links are taken only from the domains the installation (VIDEO_LINK_DOMAINS) or the study allows, such as the organisation's Jitsi or TrueConf server or Yandex Telemost; any other is refused with a message. After the talk the investigator records when it took place, how long, who explained, who took part, the questions discussed and the outcome: Ready to sign now, Needs time to think or Declined to take part (the link closes); the record never changes and the patient's copy shows it (FDA eConsent guidance, ICH E6(R3) 2.8). A new study setting, A talk with the doctor is required before signing (off by default), opens the signature only after such a talk. Every step (planned, changed, cancelled, the letters, the link opened by the patient, the talk held and its outcome) is in the audit trail. Remote electronic consent · Consentement éclairé
• The form library has two free validated questionnaires: the PHQ-9 (depression) and the GAD-7 (anxiety). The instructions, questions and answers are word for word from the official English version, with Pfizer's credit line under the questions; the item codes are CDISC (PHQ0101…, GAD0101…). The form comes in scale mode: the passport filled in (Pfizer Inc., free, no permission required), the texts locked, and no single question taken into another form. The total (0–27 and 0–21) and the severity band are counted on save when every item is answered; the patient sees neither. An answer above 0 to PHQ-9 item 9 opens a query to the site: “PHQ-9 item 9 positive: the investigator assesses suicide risk”. The library has no official Russian translation yet: in a study in Russian the builder marks the forms “English only” and the questions stay in English. In the migraine demo study the patients answer both on the phone. Form library, copying and eCRF from Excel · Questionnaires patient (ePRO)
• ePRO, stage 3: answers by a representative and the interview. In the settings of a form completed by the patient the builder chooses who answers: the patient only, the patient or a representative, or a representative only (a child, a patient who cannot answer), and whether the questionnaire allows an interview. In the patient’s card the site records the representatives: who they are to the patient and how they got access, a name only if wanted and never in the audit trail. A representative gets their own link, the leaflet with the QR code and their own PIN; their page shows only the questionnaires open to a representative, and the audit actor is “Representative of patient … (mother)”. A team member opens a questionnaire in the “Interview” section, gives the mode (by phone or at the visit), the date, the time and who answers, enters the answers and confirms the questions were read as written; the answers are saved as the patient’s own with the source “interview”, the audit actor is “team member on behalf of patient …”. Who answered shows in the form, the card, the casebook (PDF and JSON) and the export: the source interview and a new “Respondents” sheet. Questionnaires patient (ePRO)
• SMS to patients. The Portal Owner sets up the SMS gateway in Administration › SMS: the provider (SMS.RU, or “Log only” for development), the API key kept encrypted and never shown again, a neutral sender name, the portal's daily limit, the sending hours in the installation's time zone, a test SMS and a key check. In the patient card the site records the consent to SMS with the number, the date and the language (Russian or English); the number is kept encrypted and shown only masked. “Send the link by SMS” and the hourly reminder job send the invitation and the reminders: the text holds only the personal link and a hint about the PIN, never the PIN itself. Quiet hours, at most 3 SMS per patient a day, retries on a temporary error of the provider, a delivery log in the patient card and audit records with the number masked. “Stop SMS” (STOP) deletes the number, and the patient can switch SMS off on the questionnaire page. In QA, the training environment and demo the provider checks the messages in test mode and sends nothing to the phone. Messengers are deliberately not supported: the patient's data do not go to foreign platforms. SMS to patients · Questionnaires patient (ePRO) · Administration
• Data from a patient's health record in HL7 FHIR R4. On the patient's card, “From the health record (FHIR)” takes the hospital system's export: a Bundle, a single resource or NDJSON. The hospital system can also post the record through the write API (POST /fhir) with its key. Lab results and vital signs go into fields by their LOINC codes (units are converted, an unknown unit is never guessed); conditions and medications become new records of the medical history and concomitant medication logs, with ICD-10, SNOMED CT, ATC or RxNorm codes kept as given. Nothing is saved unchecked: the preview shows for every value its resource, id and date, the form, visit and field, and what is not imported and why. A value that would change a saved one is unticked and needs a reason. After the confirmation the value's history names its FHIR source, and the form shows it above the fields. Of the Patient resource only the sex and the year of birth are read; neither the file nor its name is kept. The mapping is set in the eCRF builder, with a default LOINC map. The CKD demo cohort already holds a confirmed import and a corrected result from the hospital system waiting for review. Data from a health record (HL7 FHIR R4) · API for hospital, laboratory and sponsor systems
• A condition on a form in a visit. The form's page has a new card “In visits”: for every visit where the form is ticked you can set “Expected in this visit only if” with the same AND / OR condition editor (fields of other forms, the patient's card), and the box under it tries the condition at once on values you type. On the eCRF matrix such a cell shows “only if”. While the condition does not hold the form is not shown in the visit and is not counted as missing in completeness, lock readiness, the counts, the expected-forms widgets, the patient card, the casebook and the visit signature. Data entered before is kept and marked “not expected, data kept”, as with a hidden field. Every change is written to the design audit trail and shows in the comparison of eCRF versions, in the DVP and in words in the investigator guide. The patient's card gets PATIENT.ARM, the code of the randomisation arm: any condition may use it in an open-label study; in a blinded study only the rules of forms for the unblinded team may, and saving anything else is refused with an explanation; for blinded members the arm always reads as empty. AND / OR conditions and checks across forms