User and administrator guides

Guide for members of the public

You do not need medical knowledge to file a report, and you do not need to be sure the vaccine caused what happened.

Filing a report

1. Open Report an event and choose Member of the public. The form rewords itself in plain English — the same information a clinician would give, asked differently.
2. Answer the questions on each step. Anything marked (required) has to be answered; everything else can be left blank if you do not know it. “I do not know” is a legitimate answer and is better than a guess.
3. Use the ? beside a question if you are unsure what it is asking. The assistant panel on the right answers questions typed in your own words and can take you straight to the step you need.
4. On the documents step, attach anything you already have. The form suggests what would help most based on what you have told it. This is optional.
5. Check the review screen, then submit. You will be given a report identifier — write it down.

If you get stuck

• Your answers are kept as you go, so you can close the tab and come back within the same browser session.
• If a question will not accept your answer, the message under it says what is needed. The list at the top of the step links straight to each one.
• The questions page answers the things people ask most often.

Sending documents after you have filed

Records often arrive later. Open Add documents, enter your report identifier, and attach them. You do not file a second report.

Guide for healthcare providers

The provider path uses clinical terminology and asks for the detail a safety reviewer needs. It collects the same data elements as the public path.

Choosing the report type

The report type drives the whole form. Three are offered:

• Adverse event following immunisation — the full clinical question set.
• Vaccine administration error with an adverse event — both the error detail and the clinical question set.
• Vaccine administration error, no adverse event observed — the error detail only. Every adverse-event field is suppressed, the health-history step disappears, and none of it is required. The panel beside the form shows the live count so you can see it happen. This is PWS 1.6.2 and it is enforced on the server as well as in the browser: adverse-event answers posted alongside this report type are dropped before the record is built.

Supporting documents

The documents step reads your answers and proposes which records would most help a reviewer, with the reason for each. Phase 1 accepts medical and vaccine records as documents and clinical exchange formats (HL7, C-CDA, FHIR). Images are the Phase 2 capability and are rejected with an explanation rather than silently dropped.

Data completeness

After submission the confirmation screen reports how many critical VAERS elements your report populated. Elements the branching logic never asked for are excluded from the calculation rather than counted against you. The critical set is:

VAERS_ID, RECVDATE, STATE, AGE_YRS, SEX, SYMPTOM_TEXT, VAX_DATE, ONSET_DATE, NUMDAYS, RECOVD, HOSPDAYS, LAB_DATA, OTHER_MEDS, CUR_ILL, HISTORY, ALLERGIES, VAX_TYPE, VAX_MANU, VAX_NAME, VAX_DOSE_SERIES, SYMPTOM1

Administrator and configuration guide

This is the guidance PWS 1.8 requires for program-personnel configuration, and PRS#8 is graded on Government-defined update scenarios being completed without a developer.

What you can change

What needs a developer

• Adding or removing a question, or changing which data element it feeds.
• Changing a branching rule — which questions appear when.
• Changing a validation rule, such as a date range or a required condition.
• Adding an accepted file type, or enabling the Phase 2 image capability.

The boundary is deliberate and it is the honest one: wording is configuration, structure is code. Both live in the same declarative definition, so a developer adding a field makes its wording editable in the admin screen automatically — the editor’s list is derived from the form definition, never maintained separately.

Reading survey results

The Satisfaction surveys tab reports both instruments required by PWS 1.5 and 1.7:

• Site navigation satisfaction survey (PWS 1.5) — Offered from the footer of every page, and once automatically after a visitor has opened three pages without starting a report.
• Post-submission satisfaction survey (PWS 1.7) — Presented as a pop-up immediately upon submission, before the reporter leaves the confirmation screen.

Each instrument reports its response count, the mean score and the share of respondents at or above the satisfaction threshold, plus the distribution for every question and the most recent free-text comments.

Reading the performance report

The Performance tab is the measurement PWS 1.10 and PRS#4 ask for: median and 95th-percentile page load against the 3-second target, median end-to-end submission time against the 10-minute target, and the abandonment rate. PRS#4 is a measure-and-report objective — the numbers are reported with their methodology and deviations explained, not treated as a pass/fail gate.

The change and configuration process

PWS 1.8 requires the change and configuration process to be documented, not only the tool. This is that process.

1. 1. Request

   A content change is raised by the programme owner with the reason and the reader it is meant to help. Wording changes need no ticket in the production workflow; a change to a question's meaning does, because it may affect the data.

2. 2. Draft

   The editor edits in the admin screen. Changes are held as drafts until saved, so several related edits go live together rather than one at a time. Every field shows the shipped default beside the current value, so an editor can always see what they are departing from.

3. 3. Review

   The editor opens the public form and the questions page from the links in the editor toolbar and reads the change in context, on both the public and the provider path. Persona-specific wording is edited and reviewed separately by design.

4. 4. Publish

   Saving increments a revision number and stamps who saved it and when. The new wording is live on the next page load. There is no build, no deployment, and no downtime.

5. 5. Audit

   The revision number, editor and timestamp are shown in the editor, on the questions page, and in the change log. Only the strings that were actually changed are stored as overrides, so what an editor has departed from the shipped defaults is always visible and individually revertible.

6. 6. Revert

   A single field reverts by clearing it, which restores the shipped default. Everything reverts at once with 'Reset everything to defaults'. Because overrides are stored separately from defaults, reverting is never a re-typing exercise.

Technical notes

Where content lives

Defaults are compiled from the form definition and the survey instruments. Admin overrides are stored separately and merged at render time. A field added to the definition becomes editable with no change to the editor.

Where reports go

Submissions are validated on the server with the same rules the browser used, pruned of any answer the branching engine hid, mapped to VAERSDATA / VAERSVAX / VAERSSYMPTOMS, and handed to a transmission channel that returns an acknowledgement. The prototype ships a local channel that acknowledges without reaching any network.

Where measurements go

Page-load samples come from the browser's Navigation Timing API; submission timing is measured from persona choice to submit; abandonment is recorded from a page-hide beacon. No answers are attached to any measurement.

What is stored

Synthetic answers, file names, sizes and types, survey responses, and timing samples. No file contents are transmitted or stored anywhere in the prototype.

Environment variables

VAERS_ADMIN_USER, VAERS_ADMIN_PASSWORD, VAERS_SESSION_SECRET and VAERS_DATA_DIR. Set the session secret in any deployed environment.