How v-safe INCREASED the under-reporting rate for COVID19 vaccines
How v-safe INCREASED the under-reporting rate for COVID19 vaccines
The case for Vaccine Data Science - Part 5
This is Part 5 of my Case for Vaccine Data Science series.
In my previous article, I went over David Gorski’s claim about how the v-safe app could have reduced the under-reporting rate to VAERS, especially for severe vaccine injuries.
As I explained before, there is already a giant mismatch between the number of v-safe participants who sought medical care (~770K) and the number of VAERS reports filed by the v-safe call center folks (~35K).
But there is also another way that v-safe introduces under-reporting. It is called “throttling” and is already well known in the VAERS analyst community1 - it is the phenomenon where there is a substantial time delay between the date of an adverse event and the date the report is actually seen on VAERS. While these reports are technically “in the system”, it is not used in any data analysis and thus undercounts adverse events.
In this article, I will also demonstrate an interesting phenomenon within the throttled v-safe VAERS reports.
Remember that you can download the VAERS dataset and filter for SPLTTYPE = ‘vsafe’ and check out all of this for yourself.
Days between symptom onset and the report entering VAERS
In the VAERSDATA CSV file, the field ONSET_DATE indicates the date when the patient first observed their symptom. The RECVDATE indicates the date when the report is actually published to VAERS (so it becomes public).
I created a dataset where the X-axis is the difference in the two dates (RECVDATE - ONSET_DATE) measured in number of days. The Y-axis is the count - that is, how many times this difference is seen across the whole dataset.
I then omitted the reports where the number-of-days difference is less than 20 (because the numbers are quite high, and it makes the chart harder to read). The spikes become much easier to observe when the height of the chart is less2.
Ideally, you should see a non-decreasing curve with very large numbers upfront (i.e. for small X values) tapering off to really small numbers as the difference-in-days gap widens.
Not only is the tapering too slow, we actually see clear spikes around Day 90, Day 180 and Day 365.
I don’t know what causes these spikes, but I imagine it happens because of some kind of incentive for the v-safe call center to send in their reports so that there is no more than 3 months, 6 months and 12 months delay between date of symptom onset and date of filing the report to VAERS (remembering that there will also be a few more days of additional lag after the v-safe call center files the report and before it goes public on VAERS).
It is already unacceptable that the peak number of per-day reports filed for the 6 month mark are nearly as many as the peak number for the 3 month mark, but we even see that the peak for the 12 month mark is almost as high as the 3 month one. If you click on the interactive chart, you see the peak for the 3 month mark is 154 reports on Day 93, 152 reports on Day 183 and 140 reports on Day 366.
You can also see the same throttling for serious adverse events reported from v-safe. In fact it is even worse, because the peak for the 365 day cluster is 42 serious AE reports for Day 366, which is higher than the other two peaks and in fact is higher than every other day after Day 55 (45 reports).
Is the throttling problem restricted to v-safe?
Not really.
You see similar throttling delays all over VAERS.
For example, look at this completely insane delay of more than 2 YEARS from date of death to date the report appears in VAERS (thanks to WelcomeTheEagle for finding this!)
Why this is also a form of underreporting
This throttling delay is itself now an underreporting factor.
People who write papers based on the current snapshot of VAERS (including the CDC) are undercounting the incidence rate of nearly any adverse event they are studying.
The much bigger issue here is that while these reports are throttled the regulatory machine just keeps moving along pretending nothing at all happened.
For example see this article and this dashboard
I am aware of the “trick” some people use to lop off some portion of the X or Y axis to make a chart look better or worse. But post-20-days is still a highly representative dataset. You can take a look at the raw data for yourself and see that - there are ~9500 reports where the difference-in-days is less than 20, and ~25000 reports where the difference is greater than or equal to 20. In other words, the number of reports shown in the graph is over 70% of all the reports
Thank you , Aravind. The periodicity of v-safe's throttling in interesting. I can understand a 3 month cycle, a 6 month cycle, or a one-year cycle, but not all of them together. It makes me think that the ONSET_DATEs of some v-safe reports may be missing or imputed. That is, v-safe staff might just put placeholder dates (the first or middle of a month, say) for some events when they don't know the dates. Likewise, it might be worth investigating how often v-safe makes reports and their schedule. For instance, maybe v-safe reports on a monthly or quarterly basis (as indicated by RECVDATE), sending all reports as a batch, perhaps aligned with the placeholder dates (such as the first or middle of a month). Intermittent reporting like this, combined with missing/imputed ONSET_DATEs could possibly produce the peaks at 3, 6, and 12 months. However, I don't know why v-safe wouldn't know the dates of events, but I haven't seen the inner workings of the v-safe app.
I think you've interpreted RECVDATE correctly in this article, except for this statement: "The RECVDATE indicates the date when the report is actually published to VAERS (so it becomes public)." RECVDATE is when VAERS receives the report from the reporter (in this case, v-safe). I don't think there is a field for the date a report is published on VAERS. That's something an analyst has to add -- as MedAlerts and WelcomeTheEagle88 do. WelcomeTheEagle88's analysis of throttled reports focuses on the delay between RECVDATE and the VAERS publication date.
Yes so basically in the last ~6months, there is over 10K reports where VAERS has held the report in their possession 240days< before publishing to the world. If you push the "lag days" back between date received and date published, the throttling just grows exponentially! https://imgur.com/gallery/83perIm The other type of throttling existing with deaths is the delay between death date and VAERS received date. I give some examples here (both types of throttling) where each image is hyperlinked to the actual report.: https://www.vaersaware.com/throttled-deaths