Part One of two
Oh yeah, this is a thing. It's just not publicly available.
Aravind Mohanoor recently penned
an article raising the idea that VAERS reports might get deleted for non-nefarious reasons. I think it’s possible, but more likely a mixture of nefarious and non-nefarious activities that lead to deleted reports.
I wrote the following on this subject matter in my paper “
Critical Appraisal of VAERS Pharmacovigilance: Is the U.S. Vaccine Adverse Events Reporting System (VAERS) a Functioning Pharmacovigilance System?”:
Trained contractor staff are required to enter each VAERS report into the database, and if it should be deemed necessary to delete a VAERS ID from this database once entered, then it must be documented with a valid reason for the deletion. In addition, when a VAERS ID number is changed to a new number, this should also be documented by contractor staff.
It turns out, it likely is being documented and kept a big fat secret in a secret file labeled: big_stupid_secret_data.csv. Sorry, feeling a bit saucy.
|
| |
Here’s some interesting stuff I found in the General Dynamics contract that I got ages ago by secret electronic stork delivery. This contract is an order for service from the CDC to
General Dynamics Information Technology, Inc.,; the fifth largest defense contractor in the world by arms sales. By the way, you can go to article here at
Jackanapes Junction to download the contract and read it for yourself.
BY ARMS SALES? Huh? I wrote this up before but I much like Polly the Parrot, I must reiterate in big letters: HUH?
Why was a defense contractor known for being successful in arms sales solicited by contract to sort out VAERS data in the context of SARS-CoV-related adverse event reports?
This should be the first and last question we ever need to ask on VAERS data analytic subject matter.
There are a few screenshots I am going to plop down here for everyone to peruse. I re-read the contract because word on the OpenVAERS street was that the contract stated that follow-up information with regard to VAERS IDs was to be kept hush hush and not publicized. Turns out, word on the street was true.
Go to the heading ‘TASK 3: VAERS FOLLOW-UP ACTIVITIES AND ENHANCED SURVEILLANCE’ (on page 16) as screenshotted here.
|
| |
You’ll find point ‘F.’ on page 18 that includes details on how the follow-up data should be treated. It reads: “
Follow-up information will NOT be included in the VAERS public data”.
|
| |
Why not? Isn’t follow-up data vital information for the people who have submitted VAERS reports? Isn’t this information vital to the proper functioning of the VAERS system? Why is the follow-up only for the eyes of the ‘Government’?
Imagine this if you will. A person succumbs to myocarditis a few days after their second Pfizer shot. Said person submits a VAERS report online and receives a temporary VAERS ID. This person is contacted by vetters at CDC and verifies the details of the filing and in turn receives a permanent VAERS ID accessible in the VAERS public data available for download. I often call this ‘the front-end data’. Their VAERS report likely contains the MedDRA code ‘Myocariditis’ in one of their SYMPTOM fields. Now, imagine that a few weeks later, said person dies. Their GP attempts to update the person’s VAERS ID to indicate that the person succumbed to death. Here’s where it gets muddy.
How does this work? Does the GP call the CDC? Does the GP file the report using the online system? If so, does this ‘Secondary Report’ get merged with the ‘Primary Report’ based on variable field matches? Does this ‘Secondary Report’ get destroyed? According to the contract, the follow-up or updates never make it to the front-end data set.
Read the following found on page 21 and 22 and see if you can figure out if such a death follow-up report would be deemed an ‘Exact Duplicate Report’ or a ‘Redundant Report’, or neither.
|
| |
|
| |