Ask a pharmacovigilance lead at a 40-person biotech where adverse event reports arrive and the honest answer is rarely "the safety database." It is a shared mailbox, a medical monitor's personal inbox, a site email forwarded twice, and a spreadsheet someone updates on Monday. Oracle Argus, ArisGlobal Safety One, and Veeva Vault Safety do not see the case until a person decides it is a case. That gap is the drug safety inbox.
What actually shows up
The subject lines are not tidy. A coordinator writes "possible rash, subject 104." A CRO forwards a PDF with the narrative in an attachment and the seriousness checkbox blank. A medical monitor pastes three lines from a site call. Someone in quality forwards a product quality complaint because the vial looked cloudy and the patient also had a fever, and they are not sure whether that is a PQC, an AE, or both.
SAE language shows up late. SUSAR is a decision, not a label on the email. The inbox also collects noise: literature alerts, investigator questions, and protocol deviation notes that mention an event but are not a report. A small team does this sorting between other jobs. There is no night desk.
What gets lost before anyone opens a database
- Day 0. The reporting clock starts when the sponsor has enough information to call it a valid case, not when someone later retypes it. If the first email sat unread over a weekend, the clock did not wait.
- Which document the event is judged against. Expectedness depends on the current Investigator's Brochure or company core data sheet. Inbox threads rarely name the version. A later reviewer guesses.
- The original wording. By the time a row exists in a sheet, the site's words have been shortened. The attachment is still in someone's mailbox, until it is not.
- Who touched it. A spreadsheet does not show who changed seriousness from non-serious to serious on Thursday.
None of that is fixed by buying a database you do not have the people to run. The note on Argus and Veeva for early-phase teams is about that mismatch. The inbox problem is upstream of it.
AE, SAE, SUSAR, and the complaint that is also an event
Seriousness is a criterion, not a vibe in the subject line. A qualified person still decides whether the event is an SAE and, with expectedness, whether it is a SUSAR. The inbox's job is to get the narrative, the dates, and the product in front of that person before the clock is a surprise.
Product quality complaints are a related pile in the same mailbox. A cloudy vial with no patient involvement is a quality complaint. A cloudy vial plus a fever is also an adverse event until someone shows it is not. Teams that have one inbox for both need a rule for which path starts the safety clock. AE Connect is not a QMS. If the narrative includes an adverse event, the workspace intake can hold that text and draft seriousness, coding, causality, and expectedness for review. It will not manage the batch record.
A structured draft is not a submission
Moving a narrative out of email into a case screen changes the failure mode. The text is in one place. The draft proposes MedDRA coding and a timeline. A person accepts or overrides it. That is PV case intake. It is not E2B(R3) ICSR submission, and it is not an aggregate report. The IND annual report and the DSUR still have to be written from the cases you actually track. The first-IND PV plan piece is where those obligations sit, including who owns the company core data sheet the expectedness call depends on.
If you already run Argus, Safety One, or Veeva, the inbox is still the front door. AE Connect integrates with any safety database, including those. They remain the system of record. If you do not run them yet, it is a way to stop losing Day 0 in a mailbox while you decide what system of record the pharmacovigilance plan will name.
For the submission side of the house — gateway, XML, what the FDA actually asked sponsors to change — start with the E2B(R3) guide and the readiness checklist. Those are about the filing. This page is about the hour before anyone is ready to file.