YouEDC Safety

Serious adverse event cases: intake, Day 0, SUSAR, 7/15-day deadlines, roles.

YouEDC Safety is the third section of the portal, for the pharmacovigilance team and the sponsor. It keeps the serious adverse event (SAE) cases of the studies: where the report came from, Day 0, the assessment, the 7- and 15-day deadlines.

Where reports come from

• YouEDC Capture. The adverse event form of the study templates (form AE, “serious” field AE_SERIOUS) is linked out of the box: every save of the form with “yes” puts a report in intake by itself. For your own form, name its form and field codes in the project's safety settings.
• Another EDC. “Import SAE listing”: a CSV or XLSX from MainEDC, Rave, InForm, Vault and others. Non-serious rows are skipped and rows already taken in are recognised, so the whole listing can be uploaded every week.
• Paper, e-mail, phone, partner, literature. “New case”: the minimum and the source now, the rest on the case card.

The queue and the projects. The YouEDC Safety page shows the cases of all your projects, and above the numbers a row of projects with the number of open cases in each. A project code in that row and in the table opens the project's YouEDC Safety page, a case number the case card. The breadcrumbs of Safety pages stay in the section: “YouEDC Safety / project code / case”, never leading to the study's YouEDC Capture pages.

New case and the source of a case

The New case button is always in sight: first in the section menu, in the header of the case queue and of the project's YouEDC Safety page, and on the deadlines card of the home page. If you keep cases in one study it opens the form at once; with several studies you choose the study first.

• How the report came. By hand: paper SAE form, e-mail from the site, phone call, other. External sources: another EDC's listing, a partner or licensee, the medical literature, a regulatory authority. For an external source, name the system, partner or publication.
• Duplicate check. If the subject already has a case with the same event or onset date, the form shows it and creates the new case only after “This is a different event, not a duplicate” is ticked. New information about an existing case goes there as a follow-up version.
• The source in sight. The source badge is in the queue, the case header and the XLSX line listing. The tiles “From YouEDC Capture”, “By hand” and “External sources” above the queue show how many cases came each way, and filter the queue.
• The patient in YouEDC Capture. When the study has YouEDC Capture and a patient with this code is there, the case header shows “Open the patient in YouEDC Capture” next to the subject code: it leads to the patient’s card with the visits, forms and queries. Only someone whose role and site allow opening that card sees the button.

Intake: a decision for every report

Check the four minimum criteria of a valid case: an identifiable patient, a reporter, a suspect product, an event. Then one of three: a new case, a follow-up of an existing case (the portal suggests candidates by subject, term and date), or reject with a reason. The received date becomes Day 0.

SUSAR and deadlines

• SUSAR: serious, related (by the stronger of the investigator's and the sponsor's assessment) and not listed in the reference safety information (RSI).
• SUSAR?: serious, but causality or expectedness is not assessed yet. The clock runs as for a SUSAR: waiting for an assessment never stops a deadline.
• SAE: not related, or expected. No expedited report.

Day 0 changes only with a reason, which goes to the audit trail. New information on a case opens the next version: the previous one is frozen whole, and the follow-up has its own 15-day deadline.

Priority and step targets

The queue of cases is sorted by priority, and a P1-P4 badge stands before the case number. P1, critical: a fatal or life-threatening SUSAR (or possible SUSAR), a report due within 2 days or overdue, or a case marked urgent. P2, high: another SUSAR or possible SUSAR. P3, normal: another serious event. P4, low: a non-serious one. Why a case has its priority shows in the badge's tooltip and in the Workflow card of the summary.

The authority's deadline says when the report must leave, not when data entry, the medical review and the QC must be done. So the step the case is at has an internal target, counted from the start of the clock: for a 7-day report, data entry by day 2, the medical review by day 4, QC by day 6; for a 15-day report or a follow-up, days 5, 10 and 13; with no expedited report, days 10, 20 and 30 from the receipt of the current version. These are starting values: in the project's Safety settings, card "Step targets of the worklist", write the days of your SOP. The steps must come in order, and QC must end before the day of the report.

When a step is late, the case moves up one priority level, the queue says in red under the status how many days it is late, and the assignee and the safety physicians get one e-mail per step and version (the notification "A safety case is late at a step" in the profile). The escalation goes to the audit trail. The filter "Late at a step" shows only such cases. The button "Mark as urgent" on the case summary moves it to P1 with a reason: an authority's question, a press enquiry, a DMC decision. The same place removes the mark, and both go to the audit trail. Demo projects send no e-mail.

What next on a case and the queue search

The case summary opens with "What next": what the current step still needs, each line linked to its tab. In data entry these are the four minimum criteria of ICH E2D (without them the case cannot move on), the MedDRA code, the onset, the outcome and the narrative. In the medical review they are the sponsor's causality and the expectedness (without them the case cannot be classified as a SUSAR or not) and the medical signature. In QC they are the QC signature, the approval for reporting and the reports still due. At any step the list also shows follow-up requests past their date, questions from authorities and a report an authority refused (ACK CR or AR). The button below moves the case to the next step in one press: "Send to medical review", "Send to the quality check", "Close the case". When something is still missing the button is grey but works: the open items stay listed. The button "Take it myself" in the Workflow card assigns the case to you.

Above the queue there is a search by case number, subject code, site and event term, and a filter by kind of case (SUSAR, possible SUSAR, SAE, not serious). The number found shows next to it, and "Clear" brings the whole queue back.

Questions from authorities and ethics committees

An authority, an ethics committee or a partner may send a question about a particular case with a date for the answer. Record it on the case's Reports tab, card "Questions from authorities and ethics committees": who asked, when the question came, by when the answer is due and the question itself. While the question is open, the case is P1 in the queue, the project page shows a red notice and the case header a reminder. The answer goes out the usual way, outside the portal. When it is sent, record the date and what was answered. When the date of the answer passes, the assignee and the safety physicians get one e-mail and the audit trail records it. Questions can be recorded on a nullified case too.

Narrative and discussion

On the Narrative tab, Draft from the case data builds a text in the CIOMS order: patient, history, products, the event, seriousness criteria, action taken, outcome, both causality assessments, expectedness, Day 0. Gaps stay in [square brackets]. The treatment allocation never goes into the draft.

The Review and signatures tab is the conversation between the safety team and the sponsor about the case. A comment is about the narrative, the assessment, the products or the case as a whole; people reply, then mark it resolved. Every comment goes to the audit trail. An unblinded member can leave a restricted comment about the treatment: only unblinded members see it, and the audit trail records only that it was written.

Electronic signature

A signature means entering your password again and choosing its meaning: quality check (specialist), medical review and approval for reporting (safety physician). It keeps the name, role, date and time and a fingerprint of the version's content, so you can see when the case changed after the signature. A wrong password is recorded in the audit trail.

• Approval is possible only when every comment is resolved.
• An approved version is locked. To correct it, the safety physician withdraws the approval with a reason, or a follow-up opens a new version.
• A case can be closed only when its current version is approved.

Reports, forms and deadlines

The Reports tab has the CIOMS I form to print or save as PDF (English, Russian, French) and the E2B(R3) XML file. It also keeps the log of reports sent: to whom, which report, when, in which format, the reference and the acknowledgement. When a report is recorded as sent to a regulatory authority, its deadline is met, and the queue moves on to the next one, marked “sent on time” or “sent late”. The project's case list has SUSAR line listing and All cases, XLSX.

Every download is recorded in the case history. The files never contain the patient's name; only the unblinded E2B contains the treatment allocation.

A SUSAR in a blinded trial: the unblinded E2B for the authority

In a blinded trial the regulatory authority receives a SUSAR unblinded, while investigators and ethics committees receive it blinded (ICH E2A; in the EU Regulation 536/2014; the same principle in the EAEU). The portal makes both files from the same case:

1. A member with unblinded access records the treatment allocation on the Summary tab (Blinding card).
2. On the Products tab, tick Blinded study product for the product under the blind. Only blinded studies show this tick.
3. On the Reports tab, a member with unblinded access sees E2B(R3) XML, unblinded. In this file the marked product is named by the treatment allocation (G.k.2.2), and its blinded name stays in the additional information (G.k.11). Every other product is unchanged. The file name ends with _unblinded.
4. The usual E2B(R3) XML and the CIOMS I form stay blinded: send them to investigators and ethics committees.

Team members with blinded access never see the unblinded button and get “Forbidden” if they open its link. The case history records each download of the unblinded file, but never the allocation itself. Frozen versions are exported with the allocation and the tick they had at their time.

Reminders

When 5 days or less are left before the next deadline, the case appears in the Safety deadlines card on the home screen (the card lists the three most urgent cases, the rest are behind the “and N more in the queue” link), and the queue shows a red banner when a report is overdue. E-mails go 5 and 2 days before and when overdue: to the assigned specialist, or to the whole team when nobody is assigned; when overdue, also to the safety physician and the manager. The e-mail carries only the case number, the project and the deadline. Each person switches them in the profile.

Case completeness and follow-up requests

The Summary tab of the case card has a Completeness of the case block: 13 items, the first four being the minimum of a valid case by ICH E2D (patient, reporter, suspect product, event), the others what a complete report needs: MedDRA term, onset, seriousness criterion, outcome, both causality assessments, expectedness, sex and age, action taken with the product, narrative. The percentage shows in the case header, and every gap links to its tab.

What the site still owes is turned into the text of a request by Ask the site for the missing information. The Follow-up requests tab records to whom and when the request went and by when the answer is due; send the request itself by e-mail as usual. When the answer comes, record its date and content; if it brings new information, open a follow-up version. Open and overdue requests show in the queue, the indicators and the case header.

Indicators

The Indicators menu item (and a button on the project's YouEDC Safety page) shows the team's work over 3, 6, 12 months or all time, for one project or all of them: how many cases came and from where, month by month; the share of 7/15-day reports sent on time and how many are overdue; the median days from Day 0 to the first report to an authority and to closing; follow-up requests; the kinds of case and the most frequent events. The same figures are under the monthly chart as a table.

Coding helper

On the Events and assessment tab of a case the portal proposes the MedDRA term and the seriousness criteria under each event. These are rules and a dictionary, without AI: the case text never leaves the server.

Terms are looked up only in dictionaries you may read anyway: the study's adverse event dictionary (bound by the MedDRA licence holder in the study's coding), your own uploaded MedDRA subscription and the built-in CTCAE (NCI terms with MedDRA codes). The study coders' earlier decisions and exact matches come first, then similar spellings. For MedDRA the preferred term (PT) is shown, and the lowest level term (LLT) when that is what matched. When the event is coded already, the helper stays quiet unless the study's coding gives another term: then it shows the difference.

Seriousness criteria are proposed from the words of the event and the narrative (the narrative is read for the first, main event), in Russian and English: “hospitalised”, “life-threatening”, “resuscitation”, “died”, “disability”, “congenital anomaly”, and for a medically important event the ICH E2A examples (bronchospasm, agranulocytosis, convulsions, drug dependency), anaphylaxis, Stevens-Johnson syndrome, liver failure. The sentence the criterion came from is shown next to it. Words with a negation (“no hospitalisation”, “seizures were not observed”) do not count. A fatal outcome proposes the criterion Death.

The event changes only by your decision: Take writes the term and the code, Tick sets the criterion. Not this removes the proposal, and it is not offered again for that event. Every decision goes to the audit trail with its source (the dictionary and its version, or the rules); the medical judgement stays with the physician.

Medical assessment: RSI and causality worksheets

The Reference safety information tab of the project keeps the list of expected serious reactions of each product, in versions with the date each comes into force (from the investigator's brochure or the SmPC). A saved version is never edited: a change is a new version, so every assessment can be traced to the RSI it was made against. On the Events and assessment tab each event then shows whether it is listed in the RSI in force on its onset date (Day 0 when the onset is unknown), compared by MedDRA code, preferred term or, while uncoded, the reported term. The physician accepts the proposal with one button; the RSI version goes to the audit trail. After a new version, the RSI tab lists the open cases whose expectedness differs from it.

Under each event, the causality worksheet offers the WHO-UMC criteria and the Naranjo algorithm. Answers the case already gives (the event after the start of the product; the product withdrawn and the event resolved) are filled in and marked “from the case”. The worksheet shows its category and the causality it proposes; the sponsor causality changes only when the physician accepts it. Every worksheet is kept.

Special situations, pregnancy and the case timeline

On the Patient and reporter tab tick the special situations of GVP VI: pregnancy, breastfeeding, overdose, misuse, medication error, occupational exposure, lack of efficacy, off-label use. A pregnancy gets its own follow-up: the last period or the expected date of delivery, the outcome and its date. Thirty days after the expected delivery without an outcome, the case and the project queue remind you to ask for it. A congenital anomaly in the outcome reminds you to tick that seriousness criterion.

The Timeline tab puts the case on one axis: the products from start to stop, the onset of each event with its outcome, the patient's visits in YouEDC Capture, Day 0, follow-ups, requests to the site, reports sent and deadlines. A product stopped before the event resolved is the dechallenge at a glance.

Literature screening

The Literature tab keeps saved searches of the products in PubMed (NCBI E-utilities), Europe PMC and Crossref, each with its query and how often it runs (GVP asks for at least weekly). The portal uses only these official APIs, within their terms; it never scrapes Google or Yandex result pages, whose terms forbid it and which cannot be repeated. The Search now button at the top of the page starts every active search of the study at once; while they run, a bar with a running mouse shows how many are done and which one is running, and the new articles appear when all are done. If a query was too wide and brought hundreds of articles, fix it and press Remove all unscreened articles above the list to screen: only the articles found by the searches and not decided yet go, the reason is required and goes to the audit trail, and decided articles, case reports, articles entered by hand and the run log stay. Each run covers the dates since the last one and goes to the run log: database, exact query, dates, when, how many found and how many new. Articles are merged across databases and runs by PMID, DOI or title. Each is screened once: not relevant, relevant without a case (for signals and the DSUR, with the reason), or a case report, which opens a case with Day 0 the day you saw the four minimum criteria and the reference in the narrative and the E2B. Journals without an API (eLibrary, local journals) are screened by hand and their articles added by hand. The server calls only the databases the administrator lists in LITERATURE_SOURCES; without it, searches wait and nothing leaves the server.

Getting started. Literature opens from the YouEDC Safety menu or as a tab of the study. At the top are the ready-made searches: the portal takes the products from the reference safety information and the suspect products of the cases, drops the dose and the placebo from the name and prepares a query in every connected database. Tick the ones you need and press Start the searches: they are saved, run weekly, and the first run starts at once. With no products yet, type the name in the field beside it. The query of any search can be refined later, with the reason. Demo projects never go online.

Investigators, signals and reports from partners

A SUSAR goes to every investigator of the study, blinded. On the Reports tab of such a case the SUSAR to the investigators block lists the active sites: record the sending to the ticked sites and each site's confirmation of receipt; a site silent for more than 15 days is shown as late.

The Signals tab shows the events of the study's cases by term and month and flags what is worth a physician's look: rising (3 or more in 90 days, at least twice the 90 days before), one site (60% or more of the events), unlisted (2 or more unexpected or not in the RSI), fatal. There is no breakdown by arm: blinded team members read the page.

On Import, an ICH E2B(R3) file from a partner, licensee or CRO becomes intake items, one per report, with the patient, the reactions, seriousness, the products and the narrative; a report taken in before is recognised. The acknowledgement message (ACK) is then ready to send back.

DSUR: the annual safety report

The study's DSUR tab builds the development safety update report by ICH E2F. Give the product, the development international birth date (DIBD), the period and the language of the report, and press Draft the report. The portal takes the data of the period and drafts every section of the report: the executive summary, the marketing approval status, the RSI changes, the inventory of trials, the exposure, the listings and tabulations, the significant findings, the literature, the region-specific information, the late-breaking cases, the overall assessment and the conclusions.

• Cases as of the data lock point. When new information on a case arrived after the DLP, the report takes the frozen version known on the DLP. Cases and follow-ups received after the DLP go to section 17.
• 7.2: the serious adverse reactions of the period: related by the investigator or the sponsor, or not assessed yet. 7.3: every serious event since the start of development, in the period and in total; by system organ class when your MedDRA dictionary is bound to the study's coding (the portal ships no dictionary).
• Exposure comes from YouEDC Capture: patients enrolled and randomised by sex, age and country. The treatment arms are not shown: the report is blinded.
• Section 16: the patients who died, the withdrawals of treatment because of an SAE, and whether the first SUSAR reports went out on time.

What only people can write (the risk evaluation, the conclusions, facts the portal does not have) stands in [square brackets] in the text and is highlighted; the side panel counts the places left. Correct the text under a section opens it for editing; a correction is marked and kept, and Back to the portal's draft takes the text from the data again. When the study's data change, the page offers to collect the data again: the tables and the portal's texts are updated, your corrections stay and are marked for checking.

Issue for signature freezes the text. The author signs first, then another person with the medical assessment right approves the report. The PDF, Word and Excel files of the approved report are kept exactly as signed, and the PDF goes to the TMF inbox. Before approval the report can go back to draft with a reason; the signatures given are withdrawn. Every action is in the audit trail.

What a follow-up changed

On the Versions and history tab of a case, What changed puts two versions of the case side by side (by default the previous one and the current one) and shows every changed field of the case, its events and its products. The portal marks whether this is significant new information by ICH E2D and GVP VI: a new event, a change of seriousness, of outcome (above all death), of the coded diagnosis, of causality, of expectedness, of a suspect product, or of the patient's sex or age. A significant follow-up of a SUSAR goes to the authority within 15 days of its receipt. When only typos, the narrative or the reporter's name changed, the portal says Corrections only: no new expedited report is needed for them, they go with the next one. It is a suggestion; the safety physician decides.

Submission plan, SUSAR package and late reports

The study's Submissions tab shows whom each SUSAR must reach in every country of the study's sites: the regulatory authority, the ethics committees and the investigators, each recipient with its own deadline, its own version (unblinded or blinded), its form and the language of the letter. The country comes from the site's record. Until the study has rules of its own, the starting values for Russia, Israel, the USA and Germany apply. They follow ICH E2A and the national rules as we read them; they are a template, not legal advice. Your regulatory specialist checks them and keeps them with "Checked: keep these as the study's rules", or edits them: adds recipients and removes them with a reason. Every change goes to the audit trail.

On the Reports tab of a case, the Submission plan shows every line of the plan for the current version with its deadline and state. Record as sent puts the sending in the log with the recipient, the form and the kind of report. The investigators' line is done when the SUSAR is recorded as sent to every active site.

SUSAR package (ZIP) makes a folder for every recipient of the plan: a cover letter in its language and the forms it expects. Blinded recipients get CIOMS I and the blinded E2B, the authority the unblinded E2B. The unblinded file goes into the package only when a member with unblinded access downloads it and the allocation and the blinded product are recorded; otherwise the package's list says what is missing. MANIFEST.txt lists every file with its SHA-256 checksum. A package of a version not approved yet is marked as a draft. Every download of a package goes to the case history.

A report sent after its deadline is not recorded without the reason for the delay from the list and the corrective and preventive action (CAPA). For a late report already in the log, the reason can be added afterwards. The Submissions page shows the share of reports sent on time, the reasons for delays and everything still to send. The table goes to Excel for the inspector.

E2B check, authority acknowledgements and taking a case back

On the case's Reports tab the E2B(R3) check box checks the file of the current version before it is sent. Errors (red) are what an authority's gateway refuses: no MedDRA code or a code that is not 8 digits, no MedDRA version for the study, no suspect product, a patient who cannot be identified, dates out of order, a text longer than allowed. Warnings (amber) are what an authority usually asks about: no outcome, no seriousness criterion, no narrative, no causality assessment, no trial registration number in the study profile, no unblinded version of a SUSAR in a blinded trial. Each line has a Fix link to the tab concerned. A MedDRA code is checked for its form, not against the dictionary: the dictionary belongs to the client under its MSSO licence.

When the administrator has put the official ICH E2B(R3) schemas on the server (the ICH package is free to download from ich.org; the folder is set by E2B_SCHEMAS_DIR), the file is checked against them too and the box says “checked against the official ICH schemas”. Without them only the portal's rules run, and the box says so: such a file is fit for review and exchange, but before a submission run it through the authority's test gateway.

The authority's acknowledgement (ACK). The gateway answers every E2B with an acknowledgement. Load it as a file in the Reports sent box: the platform finds the case, the version and the report from the message number and records the date and the code. CA or AA: accepted; AE: loaded with errors; CR or AR: refused. A refusal shows in red with its errors and does not meet the deadline: correct the report and send it again. Messages missing from the log of reports are listed, so they are recorded first.

Taking back a reported case. The Take back a reported case box is there for the safety physician once the case has gone to an authority, an ethics committee or a partner. A nullification is for a case that should not exist: a duplicate, not a valid case (the four minimum criteria are not met), reported in error. It needs the reason and the password (an electronic signature under 21 CFR Part 11). The case is closed for good and becomes read-only, and the Nullification of the case box lists everyone who had any version of it, with a 15-day deadline (a starting value; your specialist checks each authority's own). The E2B of the current version carries C.1.11.1 = 1 and the reason by itself. An amended report is for a mistake in a version already reported, without new information (for example a wrong MedDRA code): the E2B carries C.1.11.1 = 2, and the recipients are everyone who had that version. If only the assessment changed (not serious, not related), that is a follow-up, not a nullification.

Signal log

On the project's Signals page, below the flagged terms, is the signal log. A flag on the page is only a reason to look; a signal in the log is the decision to look and the record of what was done (as GVP Module IX describes it). Open a signal next to a flagged term opens a signal with the flags as its reason; if one of the events was fatal, the priority is high from the start. A signal can also be raised by hand: from the literature, a partner, an authority or the physician's own judgement.

Then the safety physician validates the signal (there is enough evidence to assess it further) or refutes it, in both cases writing down the evidence: the cases, time to onset, dechallenge and rechallenge, biological plausibility, literature. A validated signal is closed with a conclusion (new risk, known risk changed, not confirmed, not confirmed for now but monitored) and the actions: update the RSI and the investigator's brochure, protocol amendment, updated informed consent, letter to the investigators, refer to the DMC, inform the authorities and ethics committees, describe in the DSUR. A confirmed risk cannot be closed without an action. Closing is signed with the password. Every step goes to the audit trail.

Starting deadlines: validation within 30 days of detection (7 days for a high priority), the conclusion within 60 days of validation. They are the portal's starting values, not a rule of law: the study's pharmacovigilance plan sets them. Overdue signals show in red. Signals are never split by treatment arm: blinded team members read the page; comparing arms is the DMC's work. The DSUR draft says in the overall assessment how many signals detected by the data lock point are closed, refuted and still being evaluated.

Product safety profile

The YouEDC Safety menu item Product profiles shows everything about a product across all your studies on one screen. A product is known by its name without the dose and the placebo, so "YE-101 10 mg or placebo" and "YE-101 5 mg" are one product. The screen gives the number of cases, SUSARs and fatal outcomes, the reactions by preferred term with whether each is in the RSI in force, and the related reactions not in the RSI: candidates for its next version. Below are the cases by month, the latest cases and, for each study, the RSI in force, the literature to screen and the next DSUR data lock point with its submission deadline (60 days by ICH E2F). Nothing here is split by treatment arm, and the allocation is never read.

Liver alerts from the lab results

When a site saves liver tests in YouEDC Capture, the portal reads them the way the Hy's law plot (eDISH) of YouEDC Biostat does: each patient's peak ALT and peak total bilirubin as a multiple of the upper limit of normal (ULN) from the study's own normal ranges. A patient who reaches a potential Hy's law (ALT at least 3 × ULN and bilirubin at least 2 × ULN on the same day or within 30 days after) or an ALT above 20 × ULN (CTCAE grade 4) arrives in the project's Intake at once, as a report from YouEDC Capture. The report shows the peaks with their dates and the study's eDISH: every patient a grey dot, this patient in red, the Hy's law corner marked. Make it a case with New case: the event is an important medical event; then check alkaline phosphatase and other causes and assess it. Each patient's alert comes once; a daily reading also picks up results saved earlier. A result without a normal range is not used, and the arm is never shown. The case card shows the same plot on its summary.

DMC safety package

The project's DMC tab gives the data monitoring committee its safety tables for a cut-off day: patients with a serious adverse event, with a related one, with a fatal one and with a SUSAR; then by MedDRA system organ class and preferred term (from the study's medical coding; without it, by event term). It also shows the rate per 100 patient-years from randomisation, a forest plot of the risk difference of each arm against placebo with its 95% interval (a reason to discuss, not a test) and the Kaplan–Meier curve of the time to the first serious event. Only patients randomised in YouEDC Capture by the cut-off are counted; cases of other patients are named below the table.

In a blinded study the tables by arm are for unblinded members only (the closed session); everyone else sees one pooled column (the open session). PDF prints the package for the meeting; each PDF goes to the audit trail with whether it was by arm.

Inspection room

The project's Inspection tab is for the safety team; inspectors never see it. Open an inspection with who inspects, its first and last day and the period under review. The inspector joins the project on the Team page with the role "Inspector / auditor" (see Team, "Inspectors and auditors"), or with the read-only role "Sponsor safety reviewer"; in the room, give them access until a day, and that day becomes the last day of their membership too. After that day the daily job switches the membership off by itself, and End access now does it at once; closing the inspection ends every inspector's access. Every safety page an inspector opens while their access runs is listed in What the inspectors opened, so the team can prepare.

The card What the inspector checks first reads the study and shows nine points: the share of reports sent on time (target 90%), late reports without a reason and CAPA, reports overdue now, cases late at a step, questions and signals past their date, closed cases without the approval signature, the RSI and the DSURs. Each tile opens the page where it is fixed.

Deadline calendar

The YouEDC Safety menu item Calendar puts every dated duty of your safety projects on one calendar: expedited reports not sent yet, the step targets of the worklist, answers due to authorities and ethics committees, follow-up requests to sites, signals, DSUR data lock points and their due dates (60 days later) and inspections. Late duties are listed on top, the month is on the left and the next 30 days on the right; on a phone only the lists show. Each item opens its case or page. Choose one project above, or see all of them.

Roles

• Safety specialist: intake, cases, follow-ups, narrative.
• Safety physician: the same plus the sponsor's assessment (causality, expectedness) and closing cases.
• Sponsor safety reviewer: reads the cases, comments in the discussion, prints CIOMS I; does not change the case data.
• Project administrator can do everything; data managers, investigators and monitors do not see cases.