AdverseEvent.ai

How to Fill Out FDA Form 3500A: A Complete 2026 Guide

If you've been told you need to file a MedWatch 3500A and you've just opened the form for the first time, this guide is for you. We'll go through the whole form section by section, point out the fields that most often cause problems, and show you the shortcuts that actually save time — including the ones that don't cost anything.

We'll also cover what's changed in 2026: the September 2025 instructional supplement, the transition from FAERS to AEMS, and what the October 1, 2026 E2B(R3) deadline means for whether you should still be filling out a paper form at all.

This is the long version. If you want a one-paragraph summary: Form 3500A is the FDA's mandatory adverse-event report. Manufacturers, importers, distributors, and user facilities must file it for serious AEs and product problems. Most drug and biologic reports now go in electronically as E2B(R3) XML, not on paper. The form is still the underlying structure — knowing the form is knowing the data.


What 3500A actually is (and when you don't use it)

Form FDA 3500A is the mandatory adverse-event reporting form for industry. It's not the same as 3500 (voluntary, for consumers and healthcare professionals) or 3500B (consumer-friendly voluntary form). If you're a manufacturer, importer, distributor, or user facility and a serious adverse event happened with one of your products, 3500A is the form you owe FDA.

A few situations where 3500A is not the right form:

  • Vaccines. Vaccine adverse events have historically gone to VAERS (now consolidating into AEMS, but VAERS-style submission is still the path).
  • Animal drugs. These go to FDA's Center for Veterinary Medicine.
  • Food and dietary supplements. These go to the CFSAN Adverse Event Reporting System.
  • Voluntary reports. If you're a clinician reporting something you observed and you're not under a mandatory reporting obligation, you want 3500, not 3500A.

For drugs and biologics, the September 2025 instructional supplement is the current authority. Earlier supplements (the 4/16 version is the one most people remember) are obsolete; if you're working from an older PDF, your field interpretations may be out of date.

Do you need to file on paper at all?

Probably not, depending on what you make.

FDA has been pushing electronic-only submission for years. The current state, as of 2026:

  • Drugs and biologics (CDER/CBER): Mandatory electronic submission. Paper 3500A is not accepted for postmarketing ICSRs. You submit through the Electronic Submissions Gateway Next Generation (ESG NextGen), and starting October 1, 2026, the submission must be in E2B(R3) XML format. E2B(R2) was the legacy format and was deprecated; FDA extended the cutover by six months in April 2026, but it's coming.
  • Medical devices: Electronic via eMDR (Electronic Medical Device Reporting). Paper 3500A is accepted in a few narrow cases, but for any manufacturer doing more than a handful of reports a year, eMDR is what you use.
  • Cosmetics: Paper or fax 3500A is still accepted, mailed to the FDA CDER Mail Center in Silver Spring.
  • HCT/Ps (human cells, tissues, and cellular/tissue-based products): Electronic submission required for CDER-regulated biologics; paper is allowed in narrow circumstances for CBER-regulated HCT/Ps.

In other words, even if you fill out the form on paper to think through the case, what actually gets submitted is almost always XML. Knowing the 3500A field structure is still essential — it's the data model — but the artifact FDA receives is different. We'll come back to this.

How long do you have to file?

The deadlines that drive most of the operational pressure:

  • 15 calendar days for serious, unexpected adverse drug events (21 CFR 314.80).
  • 15 working days for medical device serious injury and death reports by manufacturers; 5 working days if FDA has specifically requested a 5-day report or the event suggests a need for remedial action.
  • 30 calendar days for follow-up reports with new information.
  • Periodic reports at intervals defined by the product type — these are separate from the 15-day clock.

These deadlines are why getting good at the 3500A workflow matters. Mistakes that send a report back for correction can put you outside the window.


Section A: Patient Information

This is where almost every report starts, and it's also where smaller reporters get tripped up by what FDA considers acceptable when you don't have full patient identity.

A.1 Patient Identifier

A de-identified code — initials, a case number, "Patient 1," anything that lets you respond to follow-up requests without exposing the patient's identity. Don't put a real name here. Identifiable patient information in 3500A is protected from FOIA disclosure, but the principle still applies: you give FDA enough to talk to you about the case again later, no more.

If the case is genuinely anonymous (literature case, unidentified consumer report), enter a placeholder like "Patient A" or "Case-2026-001." Leaving the field blank is acceptable in some scenarios but better practice is to provide something you can map back to your internal records.

A.2 Age

The September 2025 supplement specifies how to choose units:

  • 3 years or older: enter years (e.g., "62")
  • Less than 3 years: enter months
  • Less than 1 month: enter weeks or days as appropriate

Or you can give a date of birth instead. Date format is dd-mmm-yyyy: 01-Jan-1900, not 01/01/1900, not 1/1/1900. This date format applies to every date field on the form. Get this wrong and the electronic submission will fail validation on multiple fields at once.

If age and DOB are both unknown, this is one of the fields where you can use a "nullFlavor" in the electronic submission — nullFlavor="UNK" or "ASKU" (asked but unknown). On paper you just leave it blank with a note in Section B explaining why.

A.3 Sex and Gender

The current 3500A separates sex (at birth) from gender (current). This is a change from older versions of the form. Both fields use closed code lists:

  • Sex at birth: Male / Female / Undifferentiated / Decline to answer
  • Gender: Cisgender man/boy / Cisgender woman/girl / Transgender man / Transgender woman / Genderqueer / Other / Decline to answer

For most case reports drawn from a clinical record, you'll have sex at birth and may or may not have gender. If gender isn't documented in the source, leave it blank; don't infer.

A.4 Weight

Numeric, with a unit. Pounds or kilograms; pick one and stick with it across the report. The form accepts both.

A common error: copying weight from a clinical note that has it in pounds and putting it in the kilogram field. Validators won't catch this — they'll see "150" and accept it. The patient was just reported as a 150-kilogram (330-pound) person to FDA. Double-check unit.


Section B: Adverse Event or Product Problem

This is the heart of the report. It's where the most narrative judgment is required and where smaller reporters most often underfill the form.

B.1 Adverse Event / Product Problem

Two checkboxes. You can check both. An adverse event is a reaction in a patient; a product problem is something wrong with the product itself (a syringe that delivered the wrong dose because the plunger was sticky). Many reports involve both — the product malfunctioned and the patient was harmed.

B.2 Outcomes Attributed to the Event

This is the seriousness criteria block, and it's where reports get rejected most often for being incomplete. You can check multiple boxes:

  • Death (with date — separate field)
  • Life-threatening
  • Hospitalization — initial or prolonged
  • Disability or Permanent Damage
  • Congenital Anomaly/Birth Defect
  • Other Serious (Important Medical Event)
  • Required Intervention to Prevent Permanent Impairment/Damage (medical devices only)

A report is considered serious for FDA's purposes if any one of these is checked. If none are checked, the report is non-serious and may still need to be filed but on different timelines.

The judgment that trips people up: "important medical event." Internal industry guidance (ICH E2A and CIOMS V) says an event is "important" if it requires medical intervention to prevent one of the other serious outcomes. A severe allergic reaction treated successfully in an ED with epinephrine and discharge home isn't, on its face, hospitalization or life-threatening — but it would have been if untreated. Check "Other Serious."

If you're uncertain whether something qualifies as serious, the safer default for industry reporters is to call it serious. Under-reporting carries enforcement risk; over-reporting carries an administrative cost but not a regulatory one.

B.3 Date of Event

dd-mmm-yyyy. If the date is partial (you know it was March 2024 but not the day), most reporters enter the first of the month and flag the partial date in the narrative. Electronic submission allows partial dates explicitly in some contexts; on paper, you do the best you can and explain in the narrative.

B.4 Date of This Report

The date you're filling out the form (the date of submission for paper; the date you generate the XML for electronic). For follow-up reports, this is the date of the follow-up, not the original.

B.5 Describe Event, Problem or Product Use/Medication Error

The narrative. This is where the case lives. The September 2025 supplement is direct about what to include:

Describe the event in detail using the reporter's own words, including a description of what happened and a summary of all relevant clinical information (medical status prior to the event; signs and/or symptoms; differential diagnosis for the event in question; clinical course; treatment; outcome, etc.)

What this means in practice:

  • Use the reporter's words where possible. "Patient developed a rash" is the source's language; "Type IV hypersensitivity reaction" is a diagnosis you may or may not have evidence for. The narrative carries the original observation.
  • Cover the timeline. When the drug started, when symptoms began, what the time-to-onset was, what was done, what happened next. A reviewer who reads only your narrative should be able to reconstruct the case.
  • Mention dechallenge and rechallenge. Did the event abate when the drug was stopped? Did it return when the drug was restarted? These are separately coded in Section C (fields C7 and C8), but the narrative should mention them too.
  • Acknowledge what you don't know. "Concomitant medications not documented in the source record" is more useful than silence.

The free-text field is large (4,000 characters in 3500, more in 3500A's electronic equivalent), but FDA reviewers still appreciate brevity. Aim for the briefest narrative that fully describes the case.

B.6 and B.7: Relevant Test/Laboratory Data and Other Relevant History

Specific lab values that bear on the event (LFTs for hepatotoxicity, eGFR for nephrotoxicity, ECG findings for cardiac events) go in B.6. Comorbidities and relevant exposures (alcohol use, prior reactions, kidney disease, pregnancy status) go in B.7.

These two fields are often the difference between a report FDA can act on and one that goes into the database without changing anything. The drug caused liver enzyme elevation — but the patient was also on three other hepatotoxic drugs and drinks daily. Both facts belong in the report.


Section C: Suspect Product(s)

Section C is where the form gets densest. You can list up to two suspect products on one 3500A; for combination products or cases with more than two suspects, you attach additional forms or use the electronic submission's repeatable product blocks.

C.1 and C.2: Name (Brand and Generic)

Brand name and generic (active ingredient) name. For combination products, list all active ingredients. The form has separate fields for each; don't combine them into one.

C.3: Dose, Frequency, and Route of Administration

Three sub-fields. Examples that pass validation:

  • Dose: 50 mg, 2 puffs, 1 unit
  • Frequency: BID, every 8 hours, as needed for pain
  • Route: PO, IV, topical, inhalation

The electronic submission uses controlled vocabularies for route (EDQM) and frequency. On the paper form, plain English is accepted, but if your report will eventually be converted to E2B(R3), getting the structured values right at the start saves work.

C.4: Therapy Dates

When the patient started the drug, when they stopped (if applicable), and the total duration. Partial dates are common here — patients often can't remember exactly when they started a chronic medication. Document what you know.

C.5: Diagnosis or Reason for Use

What the drug was prescribed for. Not the adverse event — the original indication. This is one of FDA's most useful fields for analyzing whether off-label use contributed to a problem.

C.6: Expiration Date and C.7/C.8: Dechallenge/Rechallenge

C.6 is the lot expiration date for the specific product the patient used (often relevant for biologics, vaccines, and devices).

C.7 asks whether the event resolved after the drug was stopped or the dose reduced. Three options: Yes / No / N/A.

C.8 asks whether the event returned after the drug was restarted. Same three options.

These two questions matter disproportionately for causality assessment. A clean dechallenge (event resolves when drug stopped) plus a clean rechallenge (event returns when drug restarted) is among the strongest evidence of causality in pharmacovigilance.

C.9: Concomitant Medical Products

What else the patient was taking at the time of the event that you don't think caused it. Suspect products go in C.1–C.8; concomitants go here. This includes prescription drugs, OTCs, supplements, and (for some report types) medical devices.

The judgment "is this a suspect or a concomitant" is a real one. A patient on five drugs has a hepatotoxic event. You think drug A is the cause based on temporal pattern. Drugs B–E are concomitants. But maybe drug B is the actual cause; you're guessing. A common practice is to list as suspect any drug with a temporally plausible relationship and let causality assessment happen downstream.


Section D: Medical Device-Specific Information (Devices Only)

Skip this section if the suspect product is a drug or biologic. For devices:

  • D.1 Brand name and D.2 Common device name
  • D.3 Manufacturer name, address, and (critically) the manufacturer's FEI number
  • D.4 Model number, catalog number, serial number, lot number, UDI
  • D.5 Operator of device (HCP, patient, lay user, etc.)
  • D.6 Expiration date of the device
  • D.7 Implant date (if implanted)
  • D.8 Was device available for evaluation?
  • D.9 Concomitant medical products in use at the time of the event

The UDI (Unique Device Identifier) is now expected for most devices. It's a barcode/identifier on the packaging that encodes the device identifier and the production identifier (serial, lot, expiration). If your report has a UDI, putting it in field D.4 will save the FDA reviewer significant time and improve your report's usefulness.

For device reports filed by user facilities, also pay attention to the date the device was first used in the patient — this isn't always the same as the date of the event, and the difference matters for analyzing failure modes.


Section E: Initial Reporter (Only Filled in by Manufacturers)

If you're a manufacturer reporting an event that someone else reported to you, this section identifies that initial reporter — the HCP, consumer, or other source.

For user facilities, this section is usually blank (you are the initial reporter for facility-detected events).

For manufacturers, common practice is to fill in the initial reporter's professional category and country and leave personal identifiers minimal. Names typically go in your internal records, not on the FDA form.


Section F (Devices) and Section G (All Manufacturers)

These sections are specific to mandatory reports filed by manufacturers and importers.

Section F (devices) covers detailed device evaluation: who did the evaluation, what was found, the FDA evaluation codes (these are the alphanumeric codes that classify the device problem, the evaluation method, and the result).

Section G covers: - G.1 Manufacturer's contact information - G.2 PMA, 510(k), or NDA/ANDA application number - G.3 Report source (literature, consumer complaint, user facility, etc.) - G.4 Date received by manufacturer (this starts your 15-day clock) - G.5 Type of report — initial, follow-up, periodic - G.6 Manufacturer report number (your internal tracking) - G.7 Type of report — 15-day, 7-day, etc. - G.8 Adverse event term coded from MedDRA (for drug reports) - G.9 Manufacturer narrative

A note on G.4: the "date received by manufacturer" is the date someone in your organization first heard about the event, not the date the report was finalized for submission. This is where 15-day reports get filed late: someone in the call center took a complaint on day 1, it wasn't routed to PV until day 10, and now you have five days, not fifteen. Document the actual first-knowledge date and accept the consequences if you're past the window — fudging this date is the wrong move.


The shortcuts that actually save time

The form is dense. A 3500A from scratch, with all sections filled, typically takes 45-90 minutes for a complex case if you're working manually from a source document. Three legitimate shortcuts that cut that significantly:

1. OCR a scanned 3500A back to a fillable form

If a clinician or consumer faxed you a paper 3500A (this still happens), and you need to ingest it into your safety database or convert it to E2B(R3) XML, OCR is the right starting point. Open-source tools like Tesseract (free, command-line) can read most reasonably scanned forms. The output won't be perfect — checkboxes are the hardest part — but it'll save you 80% of the retyping.

The workflow: 1. Save the PDF. 2. Run Tesseract with --psm 6 (treat as block of text) on the rasterized pages. 3. Manually correct the OCR output (especially dates, dosages, and checkbox states). 4. Type the corrected values into your fillable form or safety database.

If your 3500A is already a fillable PDF (saved with form fields intact), you can extract those values programmatically with pdftk or similar. No OCR needed.

2. Extract from a published case report

For literature surveillance — papers describing adverse events that you need to file ICSRs for — the workflow is:

  1. Find the relevant case in the paper (case report, case series, or in some clinical trial publications).
  2. Pull out: patient demographics, drug + dose + duration, reaction, time course, outcomes.
  3. Cross-check against the paper's safety table (if any).
  4. Type into the 3500A.

For papers that are well-structured (a "Case Report" section with subsections), this is doable manually in 30-60 minutes. For papers where the case data is scattered across the methods, results, and supplementary materials, it can take much longer.

LLMs can help here, but with a critical caveat: they hallucinate, especially on dosages, dates, and concomitant medications. If you use an LLM (GPT-5, Claude, Gemini) to draft the extraction, treat its output as a first pass that must be verified against the source text field by field. Don't submit to FDA without that verification step.

3. Convert intake notes into structured data

If your source is a call-center transcript, an intake email, a sales-rep field report, or any free-text description of a case — and you need to turn that into a structured 3500A — this is the most painful manual workflow because the source text is unstructured and incomplete.

The manual approach: read the notes carefully, map each piece of information to a 3500A field, flag the fields where the notes are silent (which is most of them, usually), and fill in what you can. Expect to follow up with the original reporter to get missing fields.

An LLM-based extraction can do the first-pass mapping faster than a human, but again: verification matters. The notes will often imply things that the LLM will confidently infer, and inference isn't acceptable in regulatory reporting. The LLM thinks the patient was hospitalized because the notes mention "admitted overnight"; that's likely right but it's not what the notes literally said. Reviewers need to make those calls, not the model.


A note from AdverseEvent.ai: If you do this regularly — say, more than a handful of cases a month — you'll get to a point where the manual workflow stops being practical. We built AdverseEvent.ai to handle the structured extraction step: upload a scanned 3500A, a research paper, or paste intake notes, and the form populates with field-by-field source highlights so you can verify quickly. FAERS analytics is free for everyone, no signup. The reporting tool itself is a paid product starting at $99/month. Mentioning it once so we're not being coy.


Common reasons 3500A reports get rejected (and how to avoid them)

If you're submitting electronically (and you almost certainly are, for drugs and biologics), the FAERS / AEMS validator will reject reports that don't meet the rulebook. Common rejection reasons:

Date format errors. Anything other than dd-mmm-yyyy (or the underlying ISO format in XML) will fail. 01/01/2024 is invalid; 01-Jan-2024 is fine.

Missing seriousness criteria. E.i.3.2 (the seriousness BL flags) must be present for every reaction. Each reaction needs at least one seriousness value or an explicit nullFlavor="NI". Empty isn't accepted.

Missing reporter information. C.2.r — at minimum, the primary source identifier (qualification + country) needs to be present. If you're submitting on behalf of an anonymous consumer, you still need to say the source was a consumer and what country.

Invalid code list values. Sex, route, frequency, outcome — many fields use closed code lists. Plain-English values like "by mouth" instead of "PO" will fail validation. The 3500A instructions list acceptable values for each.

Missing MedDRA code for reactions. E.i.2.1b — every reaction needs a MedDRA Lowest Level Term (LLT) code. The form accepts the verbatim reaction term as a separate field (E.i.1.1a), but the coded LLT is required.

Reporter and sender confusion. The "sender" is the entity submitting the report (your company); the "reporter" is the person who reported the event to you (the HCP, consumer, etc.). C.3 is sender; C.2 is reporter. Putting your company info in C.2 is a common new-user mistake.

Sender's organization missing. FDA rule R0022 requires the sender's organization (C.3.2) for any sender type that isn't 7 (Patient/Consumer). Manufacturers cannot omit this field.

The good news: most of these errors are caught by validators before submission. If you're using a tool that validates against the FDA rulebook before you send, you'll see the errors at draft time, not after a rejection round-trip.


What's changed in 2026

A few things worth knowing if you've been away from this for a while:

FAERS became AEMS in March 2026. The FDA Adverse Event Reporting System was renamed to the Adverse Event Monitoring System and unified with VAERS, MAUDE (device reports), and the food/cosmetic/animal reporting systems. The submission path for drugs and biologics is unchanged: you still go through ESG NextGen with E2B(R3) XML. The dashboards and APIs have been redesigned and are being rolled out through 2026.

E2B(R3) deadline extended to October 1, 2026. FDA had originally set April 1, 2026 as the cutover from E2B(R2). In April 2026 they extended it by six months. After September 30, 2026, postmarketing ICSRs must be in E2B(R3) format.

FDA Form 3500A Supplement 09/2025 is the current instructions. Previous editions (notably the 4/16 supplement that many smaller reporters were still using) are officially obsolete. If your internal SOPs still reference the older instructions, this is a good time to update them.

IND safety reports moved to FAERS/AEMS. Premarketing safety reports for INDs and IND-exempt BA/BE studies are now submitted via the same E2B(R3) path as postmarketing reports, rather than through eCTD. Different rules apply, but the form and format are the same.


When 3500A isn't the right level of effort

Two scenarios where the form is overkill:

One-off events from clinicians or consumers. If you're a clinician who saw something unusual and you want to tell FDA, use Form 3500 (voluntary), not 3500A (mandatory). 3500 is shorter, has lower field requirements, and was designed for exactly this case.

Aggregated periodic reports. If you're a manufacturer with many non-serious events to report, periodic safety reports (DSUR, PADER, PSUR depending on context) consolidate cases into a single submission rather than one 3500A per case. Talk to your regulatory affairs lead about whether your reporting can shift to a periodic structure.


The right way to learn this form is to fill it out

Reading about 3500A is the second-best way to learn it. The best way is to fill in a real case, with a real source document, and watch yourself get stuck. The fields that trip you up will tell you which parts of the case you don't know yet, and that's how reporters get good at this.

A few suggested practice cases:

  • A published case report from a journal (PubMed Central has open-access ones). Try to extract every 3500A field.
  • A made-up clinical scenario with realistic complexity (multiple suspects, partial dates, concomitants).
  • A scanned 3500A from a colleague (anonymized) — practice reading the form, not just writing it.

The skill you're building isn't form-filling, it's case characterization: turning a clinical narrative into the structured data FDA needs to do its job. The form is just the vehicle.


Further reading:

Run FAERS / AEMS analytics yourself — free

Disproportionality, time-series, and product comparison for any drug in the AEMS database. No signup required.

Open the analytics tool →