Wednesday, April 17, 2013

But WHY is There an App for That?

FDA should get out of the data entry business.

There’s an app for that!

We've all heard that more than enough times. It started as a line in an ad and has exploded into one of the top meme-mantras of our time: if your organization doesn't have an app, it would seem, you'd better get busy developing one.

Submitting your coffee shop review? Yes!
Submitting a serious med device problem? Less so!
So the fact that the FDA is promising to release a mobile app for physicians to report adverse events with devices is hardly shocking. But it is disappointing.

The current process for physicians and consumers to voluntarily submit adverse even information about drugs or medical devices is a bit cumbersome. The FDA's form 3500 requests quite a lot of contextual data: patient demographics, specifics of the problem, any lab tests or diagnostics that were run, and the eventual outcome. That makes sense, because it helps them to better understand the nature of the issue, and more data should provide a better ability spotting trends over time.

The drawback, of course, is that this makes data entry slower and more involved, which probably reduces the total number of adverse events reported – and, by most estimates, the number of reports is far lower than the total amount of actual events.

And that’s the problem: converting a data-entry-intensive paper or online activity into a data-entry-intensive mobile app activity just modernizes the hassle. In fact, it probably makes it worse, as entering large amounts of free-form text is not, shall we say, a strong point of mobile apps.

The solution here is for FDA to get itself out of the data entry business. Adverse event information – and the critical contextual data to go with it – already exist in a variety of data streams. Rather than asking physicians and patients to re-enter this data, FDA should be working on interfaces for them to transfer the data that’s already there. That means developing a robust set of Application Programming Interfaces (APIs) that can be used by the teams who are developing medical data apps – everything from hospital EMR systems, to physician reference apps, to patient medication and symptom tracking apps. Those applications are likely to have far more data inside them than FDA currently receives, so enabling more seamless transmission of that data should be a top priority.

(A simple analogy might be helpful here: when an application on your computer or phone crashes, the operating system generally bundles any diagnostic information together, then asks if you want to submit the error data to the manufacturer. FDA should be working with external developers on this type of “1-click” system rather that providing user-unfriendly forms to fill out.)

A couple other programs would seem to support this approach:

  • The congressionally-mandated Sentinel Initiative, which requires FDA to set up programs to tap into active data streams, such as insurance claims databases, to detect potential safety signals
  • A 2012 White House directive for all Federal agencies pursue the development of APIs as part of a broader "digital government" program

(Thanks to RF's Alec Gaffney for pointing out the White House directive.)

Perhaps FDA is already working on APIs for seamless adverse event reporting, but I could not find any evidence of their plans in this area. And even if they are, building a mobile app is still a waste of time and resources.

Sometimes being tech savvy means not jumping on the current tech trend: this is clearly one of those times. Let’s not have an app for that.

(Smartphone image via flikr user DigiEnable.)


Alexander Gaffney said...

I largely agree with this, but I think it also raises an issue of the general benefit of mobile platforms.

People aren't always in front of a computer. While plenty of doctor's offices have them, my sense is that FDA saw the writing on the wall and figured that so many people are adopting tablets and smartphones now, that it would be beneficial to have a mobile platform.

There are also advancements happening all the time in data entry, and in particular with voice recognition. It's much easier for me to say, "Steve Smith, Age 35, took Amoxicillin, had an adverse reaction resulting in ____," than it is to type the same thing.

Which isn't to say that any of your points about an open API is wrong. In fact, I agree quite strongly. But I think there might be a silver lining here that might not be realized for a few more years yet.

Paul Ivsin said...

Thanks for the comment, Alec.

Personally, I am not a fan of the voice-to-text options currently available, but I see your point that for some people it will be a step up. And, presumably, as the technology gets better it will be even more efficient.

But I wonder if that's really just an argument for making the current online form a little more mobile-friendly? I can already use voice-to-text when filling out web forms on my phone -- I don't need anyone to develop a separate app for that.

The MedWatch portal for entering a 3500 is a bit dated (as evidenced by the instructions for enabling JavaScript in Netscape 8, but not in, say, Chrome or Safari). But even now I can use my hardly-top-of-the-line android phone to speak my answers into the form.

If FDA wants to dedicate some resources to update the existing web form, I suppose I can't object. That will take a lot less time and fewer resources than building and deploying completely new apps.

Ultimately, though, the world has changed too much to stick to any form of manual data entry method. The data that FDA wants is out there in other applications already, so all resources should be focused on interacting with it directly.