🖨️ Print Article

---

Multi-Instance Records and Safety Signal Loss

---

VAERS ORDER Field Report: Multi-Instance Records and Safety Signal Loss

Report Date: June 22, 2026
Data Source: CDC/HHS VAERS downloadable CSV files (1990–2026) in this directory
Comparison Platform: MedAlerts.org (NVIC VAERS search engine)

---

Executive Summary

VAERS publishes multiple rows for the same VAERS_ID in its raw data files. These rows represent follow-up reports, amended outcomes, supplemental filings, and other changes to the same adverse event case over time. The ORDER column is present in all three file types (VAERSDATA, VAERSVAX, VAERSSYMPTOMS) but does not provide a clear, documented, or reliable method for distinguishing record revisions from unrelated multi-row data.

Platforms such as MedAlerts that ingest VAERS data and treat each VAERS_ID as a single record remove additional instances during processing. This collapses multi-instance cases into one row and loses safety signals that appear only in later (or earlier) instances of the same VAERS_ID.

Analysis of the full downloadable dataset in this workspace finds:

Metric	Value
Total VAERSDATA rows	2,792,953
Unique VAERS_ID values	2,718,994
VAERS_IDs with multiple DATA rows	67,273
DATA rows suppressed if deduplicated by VAERS_ID	73,959
Death (DIED=Y) appearing only in non-first ORDER instance	336
Life-threatening (L_THREAT) changes across instances	3,000

---

1. The ORDER Field Does Not Represent What Users Assume

1.1 ORDER means different things in different files

The ORDER column appears in all three VAERS CSV file types, but its role is inconsistent:

File	Role of ORDER	Duplicate ORDER values for same VAERS_ID?
VAERSDATA.csv	Distinguishes separate report instances for the same case	No — each instance gets a unique ORDER (1, 2, 3…)
VAERSVAX.csv	Links vaccine rows to a specific report instance	Yes — 377,958 (VAERS_ID, ORDER) pairs have multiple vaccine rows
VAERSSYMPTOMS.csv	Links symptom rows to a specific report instance	Yes — 636,792 (VAERS_ID, ORDER) pairs have multiple symptom rows

In VAERSVAX and VAERSSYMPTOMS, many rows sharing the same VAERS_ID intentionally share the same ORDER number because ORDER identifies the parent report instance, not a unique row. For example, VAERS_ID 0855308 in 2022 has three vaccine rows all at ORDER=2 (FLU4, HPV9, MNQ).

This dual meaning — instance identifier in child tables, sequence number in the parent table — is not documented in the official CDC VAERS Data Use Guide (September 2021), which does not define an ORDER field at all. The word "order" in that guide refers only to field layout or alphabetical symptom sorting.

1.2 ORDER is not a reliable revision timestamp

In VAERSDATA, higher ORDER values generally correspond to later RECVDATE values, but ORDER does not consistently represent "the latest truth" for a case:

• Outcome flags can change in either direction across instances (a death in ORDER=2 may be absent in ORDER=3).
• Severity signals can appear in middle instances and disappear in the final instance.
• There is no published CDC specification stating that the highest ORDER is authoritative.

Example: VAERS_ID 0027170 (3 instances)

ORDER	RECVDATE	DIED	L_THREAT	HOSPITAL
1	12/26/1990			Y
2	02/04/1991	Y
3	02/07/1991		Y	Y

A platform that keeps only ORDER=1 misses the death. A platform that keeps only the highest ORDER (3) also misses the death, but captures life-threatening.

---

2. No Clear Method to Distinguish Record Changes

The raw VAERS files provide no unambiguous key for identifying which row is a revision of which. Available fields are insufficient:

• VAERS_ID — identifies the case, not the instance (multiple rows per ID).
• ORDER — sequences instances in DATA files but is shared across child rows in VAX/SYMPTOMS; not documented by CDC; not a reliable "latest" indicator.
• RECVDATE / TODAYS_DATE — can differ across instances but do not uniquely identify revisions.
• SYMPTOM_TEXT — often partially overlaps between instances; cannot be used to programmatically match revisions.

Without a composite key such as (VAERS_ID, ORDER) enforced consistently across all three files — and without CDC documentation defining ORDER semantics — there is no clear, standards-based method to distinguish:

1. A follow-up amendment to an existing report
2. A new supplemental filing for the same case
3. Multiple symptom or vaccine rows belonging to one report instance

Analysts must treat each (VAERS_ID, ORDER) pair in VAERSDATA as a distinct report snapshot and join child-table rows on both VAERS_ID and ORDER. Most downstream databases do not do this.

---

3. Safety Signals in Multi-Instance Records

Among the 67,273 VAERS_IDs with multiple VAERSDATA rows, outcome flags frequently change between instances:

Signal	IDs with changes across instances
DIED=Y only in a later ORDER (not ORDER=1)	336
L_THREAT changes	3,000
Any severity flag change (DIED, L_THREAT, DISABLE, HOSPITAL)	thousands

3.1 Worked examples (2022 data)

VAERS_ID 1999681 — death reported in follow-up

ORDER	RECVDATE	DIED	HOSPITAL
1	01/03/2022		Y
2	05/02/2022	Y	Y

VAERS_ID 1999703 — death reported in follow-up

ORDER	RECVDATE	DIED	HOSPITAL
1	01/03/2022		Y
2	05/27/2022	Y	Y

VAERS_ID 1999404 — life-threatening in middle instance

ORDER	RECVDATE	L_THREAT	HOSPITAL
1	01/03/2022		Y
2	01/14/2022	Y	Y
3	01/19/2022		Y

VAERS_ID 1999155 — disability toggles across three instances

ORDER	RECVDATE	DISABLE
1	01/03/2022	Y
2	04/16/2022
3	04/28/2022	Y

VAERS_ID 1996900 — new adverse event in follow-up

ORDER	RECVDATE	Summary
1	01/01/2022	Injection site pain, fatigue after booster
2	08/06/2022	COVID-19 illness (breakthrough)

These are not duplicate errors. They are sequential report instances for the same case. Collapsing them loses clinically relevant updates.

---

4. Comparison with MedAlerts (medalerts.org)

MedAlerts, operated by the National Vaccine Information Center (NVIC), is one of the most widely used public interfaces for searching VAERS. As of this report date (June 22, 2026), MedAlerts does not account for the multi-instance VAERS_ID / ORDER discrepancy in its primary database.

4.1 MedAlerts stores one row per VAERS_ID

MedAlerts documents its downloadable Access database as containing "a row for each VAERS case" in the VAERSDATA table (MedAlerts access.php, archived December 2024). Third-party analysis of that database confirms VAERS_ID is used as the primary key:

ALTER TABLE dbo.[VAERSDATA]
ADD CONSTRAINT pk_vaersdata PRIMARY KEY (vaers_id);

(Source: vaxstudy.org — Loading the VAERS MDB Access File, 2020)

A primary key on VAERS_ID alone physically prevents storing more than one instance per case. All additional ORDER instances must be discarded at import.

4.2 ORDER is not exposed in MedAlerts search

MedAlerts Expert Mode exposes dozens of searchable fields (OUTCOMEDIED, OUTCOMETHREAT, SYMPTOM, VAX, WRITEUP, dates, demographics, etc.) but does not include ORDER as a queryable field. Users cannot search for, filter by, or count specific report instances.

MedAlerts does offer a "Show History of Changes" option when viewing an individual VAERS_ID, and a "Wayback Machine" feature to compare across government data releases (added 2012, per NVIC MedAlerts history). These tools track changes between download releases, not the multiple coexisting instances within a single release identified by ORDER.

4.3 Side-by-side comparison for the same VAERS_IDs

VAERS_ID	Raw VAERS DATA instances	MedAlerts effective instances	Signal lost if deduplicated
1999681	2 (ORDER 1, 2)	1	DIED=Y in ORDER=2
1999703	2 (ORDER 1, 2)	1	DIED=Y in ORDER=2
1999404	3 (ORDER 1, 2, 3)	1	L_THREAT=Y in ORDER=2
1999155	3 (ORDER 1, 2, 3)	1	Disability progression across instances
1996900	2 (ORDER 1, 2)	1	COVID-19 breakthrough in ORDER=2
0027170	3 (ORDER 1, 2, 3)	1	DIED=Y in ORDER=2; L_THREAT=Y in ORDER=3

2022 subset: Raw files contain 251,982 DATA rows for 248,516 unique VAERS_IDs. MedAlerts-style deduplication would suppress 3,466 rows (1.4% of 2022 reports) from that year alone.

Full dataset: Deduplication by VAERS_ID suppresses 73,959 rows (2.6% of all DATA rows).

4.4 Death counts under MedAlerts-style processing

Counting method	Unique IDs with DIED=Y
Any instance (correct multi-instance handling)	50,879
Keep only ORDER=1 per ID	50,543
Keep only highest ORDER per ID	50,806
Death signals lost	73 to 336

Even if MedAlerts retains the highest ORDER instance (which cannot be confirmed without access to their import logic), 73 death signals would still be lost because death was reported in a middle instance and cleared or absent in the final instance (e.g., 0027170).

---

5. Impact on Pharmacovigilance and Third-Party Platforms

MedAlerts is not alone. Any platform that:

1. Uses VAERS_ID as a unique identifier / primary key
2. Does not preserve the ORDER column
3. Deduplicates by keeping "first" or "last" row only

will silently drop report instances and the safety signals they contain.

This affects:

• Aggregate death and serious-outcome counts used in public discourse and research
• Symptom incidence rates when follow-up instances add new MedDRA-coded terms
• Vaccine lot analysis when later instances add or correct lot numbers
• Temporal trend analysis when RECVDATE differs across instances

As of June 22, 2026, this discrepancy is not documented in MedAlerts search results, not accounted for in its Expert Mode field list, and not corrected in its downloadable Access database schema.

---

6. Recommendations

1. CDC/HHS should publish a formal definition of the ORDER field, its relationship across VAERSDATA, VAERSVAX, and VAERSSYMPTOMS, and guidance on whether the highest ORDER is authoritative.
2. Data consumers should use (VAERS_ID, ORDER) as the composite key for VAERSDATA and join child tables on both fields.
3. MedAlerts and similar platforms should either:
   • Store all (VAERS_ID, ORDER) instances as separate searchable records, or
   • Merge instances intelligently (union of all severity flags, all symptoms, all vaccines) with explicit documentation of merge logic, or
   • Display a prominent warning that multi-instance records are collapsed and counts may underreport outcomes.
4. Researchers should report both unique-VAERS_ID counts and total-instance counts, and document deduplication methodology.

---

7. Data Provenance

• Files analyzed: All *VAERSDATA.csv, *VAERSVAX.csv, *VAERSSYMPTOMS.csv in /home/woolman/Server/RAIDER/vaers/VAERS/0_VAERS_Downloads/Z
• MedAlerts references: medalerts.org, access.php, Expert Mode field documentation (archived January 2025)
• CDC reference: VAERS Data Use Guide (September 2021) — does not define ORDER
• Analysis date: June 22, 2026

---

Appendix: Why Many Rows Share the Same ORDER Number

This is expected behavior in child tables, not a data error.

In VAERSSYMPTOMS.csv, each row holds up to five MedDRA terms. A single report instance (one ORDER value) may require multiple symptom rows. In VAERSVAX.csv, a patient may receive multiple vaccines at one encounter, producing multiple rows at the same ORDER.

The confusion arises because analysts and database designers see ORDER in all three files and assume it uniquely identifies every row. It does not. Only in VAERSDATA does each (VAERS_ID, ORDER) pair identify a distinct report instance — and that instance-level identity is what downstream platforms discard.