The Food and Drug Administration isn't able to reliably determine how much money it needs

WOW. Sister-in-law sent this to me...

By JENNIFER CORBETT DOOREN

WASHINGTON -- The Food and Drug Administration isn't able to reliably determine how much money it needs to regulate medical products because, among other things, its staff can't track all the adverse-event reports it handles, according to the Government Accountability Office.

Full story here.

Drums fingers on table...

I just emailed the FDA asking them for an update regarding their warning letters search engine.

From what I can determine, they have fixed the issue of certain missing warning letters. However, 2 other significant issues (at least) remain. 1. the date filter is still malfunctioning (see previous post here) and the excel document dump is still outputting html (see previous post here).

"More Eyeballs on AERS"

That's what the Nature Biotechnology editors titled it.

Our correspondence to Nature Biotech regarding AERS data came out yesterday. I can't post the article due to copyright restrictions, but I'm sure you can pick up a copy at your local newsstand.

My Confusion about Postmarket Requirements & Study Commitments

FDA has a database of postmarket requirements and study commitments (translation: "we're going to approve your drugs, but you have to promise to run these additional trials after we approve").

This database is updated quarterly and FDA even provides its own search engine to mine this database.

I've only been indexing their collection of data for a couple of quarters, but with the most recent update (April 30), I noticed something that I hadn't realized before.

Specifically, each new quarter's data *wipes out* the previous quarter's data. For example, the January 31 update contained 3381 postmarket requirements that could be searched via FDA.

In contrast, the April 30 data release contains only 1910 requirements. So, it looks like the FDA removes commitments that have been satisfied (I'm not 100% sure about the precise commitments that are removed each quarter, but this seems like the most reasonable explanation).

In practice, this means that you can't use FDA's search-engine to get a historical look at the types of commitments/requirements that were mandated by the FDA.

For example, if you search the FDA's postmarket requirements database for Zoladex you get no results. If you search using FDAble, you'll see that Astrazeneca UK had 3 requirements relating to Zoladex that were fulfilled in 2008.

I imagine that this historical information would be useful to many people (clinicians, persons performing competitive intelligence & strategy regarding drug development, etc.).

FDA AERS Data & Quality Control

FDA just released its Q4 2008 AERS data (yes, it’s May 13, but that’s another story altogether).

This post is about Quality Control of AERS data. It seems that every quarter, there’s some type of SNAFU with the data release (last year they released AERS data partially contaminated with a previous quarter's data).

This quarter, we have the classic newline-characters-where-they-don’t-belong error that's screwing up my AERS parser.

A little Background:
FDA releases its data in 2 forms (ASCII and SGML). ASCII is the one that I use and each ASCII file consists of row after row after row of $-delimited Adverse Event Records.

2 sample rows might look something like this:

$12345$abcdef$somestuff here$blah$more blah$blah $34321$blahblah$doscum$etcetc$vixerunt$gaius$cicero

Each row should represent one particular database record and my parser dutifully goes through each row extracting all the little bits of information between the dollar $ign$.

But with this latest quarterly release FDA released its Drug data file (aka DRUG08Q4.txt) with 4 significant quality control errors (see sample screenshot below).

[For those who want gruesome details, the following lines in the DRUG.txt file contain errors: 537-538, 258909-258910, 281285-281286, 408948]

The gist of the issue is that whoever entered the data for these 4 drug-records forgot to remove the newline characters (“carriage returns”) and so the record is actually split across 2 or more lines.

While this doesn’t seem like a big deal, if your parser isn’t “smart” it could inadvertently stuff the wrong data into the wrong slots in your database.

And so, you have to design your parser to look for these types of errors--and then you have to have a human look at the problem just to assure yourself that there wasn’t a bigger error. This wastes time...especially when the file you’re looking at has 416,000 records.

‘t would be nicer if FDA did more quality control on their data releases.

FAERS - AERS, but Fancier

Someone at FDA sent this to me recently (see below). It's an email sent around from within the FDA announcing a new Adverse Event Reporting system (sort of).

Emphases are mine. Editorial comments are mine, too.

Spoiler alert: They forked over $$$$$ and went with Oracle.

Bioinformatics Board (BiB) News

Post Market Safety BRB Announces Selection of Vendor[We've decided to shop at Barney's. Can't tell you what we're buying just yet, but it's gonna be FAB!] for New Enterprise Adverse Event System

The Bioinformatics Board (BIB) News provides FDA employees with an update on the activities and progress of the BiB. This month’s news focuses on the Post Market Safety BRB and the selection of the Adverse Event System Vendor. For more information about the BiB or the contents of this message, please contact your BiB representative or email the Bioinformatics Board, bioinformatics@fda.hhs.gov.

Post Market Safety Business Review Board Announces Selection of Vendor for New Enterprise Adverse Event System FDA’s Bioinformatics Board and the Post Market Safety Business Review Board are pleased to announce a significant milestone for the Agency. After an extensive analysis of FDA scientific needs for the management and analysis of post market product safety reports, and an evaluation of leading industry tools, the FDA Adverse Event Reporting System (FAERS) Program has selected Oracle AERS[$$$] (Adverse Event Reporting System) as the new tool for FDA staff[guess who's not getting access to the data juuuust yet...?] to efficiently[you wouldn't believe what we were doing before] analyze post market safety reports in order to identify potential product safety problems.

Selection of the new FAERS tool represents a significant landmark for the Agency. With the selection of an advanced tool that all centers and offices can leverage, the Agency can now focus on implementing processes for sharing post market safety data across our product centers as well as advancing the science of post market report analysis. Achievement of this milestone represents the efforts of numerous individuals from across the Agency over several years[wow. just...wow]. While in many ways this is just a beginning, it is important to recognize our progress towards meeting the goal of providing modern tools necessary to address many post-market surveillance needs. Selection of Oracle AERS[What? no love for MySQL? They're about to be subsumed by Oracle, too, ya know.] positions the Agency for success in this complex and dynamic arena.

We expect the initial users in CDER and CBER to receive training and begin using the new system as early as fall 2009[but don't quote us on that] with additional users being trained and brought on over time. CDRH users are expected to begin using the tool in 2010, and additional centers and offices expected shortly thereafter.

VAERS Update...this time with feeling

The FDA (or is it the CDC? Or is it Health & Human Services? Can't really tell....) just updated its Vaccine Adverse Event Reporting System (VAERS) dataset (April 13, 2009).

What they haven't bothered to note is that they've also changed the structure of their dataset.

VAERS data used to come packaged as 2 CSV files--one called VAERSData.csv and one called VAERSVaccine.csv.

VAERSData.csv used to contain 20 slots per row for symptoms associated with each vaccine adverse event.

In the database world, one says that there is a 1-to-many relationship between a VAERS report and the Symptoms associated with that report.


And day 1 of any remedial Database management course will inform you that because of the 1-to-many relationship, you should separate the VAERS record from the Symptoms records and link each symptom back to its report via a foreign key.

The reason for doing this is that 20 slots for symptoms *may* seem like more than enough slots for any case that you'll ever come across, but at some point, some hypochondriac is going to slip in 21 symptoms and totally screw with your file.

Well, 19 years later, the VAERS folks have finally given the Symptom data its own csv file, appropriately titled VAERSSymptoms.csv. They didn't bother to tell anyone that they did this...and I had to tinker with my parsing algorithm last night to adjust for the changes, but the discerning pharmacovigilantes among us were able to figure it out when we asked ourselves

"Why are there 3 csv files per year now when there used to be 2? And why haven't they updated their file explaining the structure of the VAERS files?" As of this writing, the most recent revision of the VAERS explanation is June 2007.

Ah yes...lest I forget...as of this writing, the Zip file containing all of 2008's VAERS data is contaminated with 2009 data. I think that's just to keep everyone on their toes.