Certifying Health Apps 7/18/12

Before I get to the post, I wanted to share my new family documentary obsession because it’s awesome and I wish somebody would have told me about it. When we watch movies together as a family, it’s pretty much always a BBC nature series (Planet Earth, Blue Planet, Life). They are incredible and educational. Our newest addition is Human Planet. It chronicles how different groups of people adapt and survive in different environments. From hunting narwhal to living bridges to hunting collaboratively with animals, it’s amazing! Well worth the $20 on Amazon.

On to the post. Last week I reported about Happtique issuing draft guidance for its mobile health app certification program. It’s open to comments. The reason for my interest is that I think some form of app certification or recommendation, beyond FDA clearance, is important for providers to feel comfortable prescribing mobile health apps. I wrote about this exact topic earlier this year. I think prescribers are an essential link to patients and a key component of engaging patients with mobile apps. Here’s another take on why app certification is important.

With Happtique’s guidance, the highlights of which I’ve outlined later in this post, it got me thinking about what a mobile health app certification program should include. What does an app need to do — or not do — in order for it to be certified? And by extension, trusted by providers and patients. It’s an interesting question and one that I’ve never tried to formally answer. It’s also a question that needs to know where its edges are and where the FDA begins.

I feel strongly that you need to balance certification with enabling innovative small companies to develop and test new apps with users. Many small companies outside of healthcare grow by building cheap, small versions of apps and testing them with early adopters. They then fail, iterate, and keep testing as cheaply as possible until they find a winner. Having to have each new app certified is a major hurdle for these companies.

As I’m writing this, I realize that early adopters might be willing to use something that isn’t necessarily certified, so maybe I just proved this point moot. After all, I’m not talking about FDA clearance. What do you think?

Below is the list of things that I think need to be certified about an app to give providers, and consumers, a sense of security.

  • Description. The app clearly describes what it does. Any future enhancements, if listed by the app owner, are clearly indicated as not currently available.
  • Performance. The app opens and runs. This one is pretty straightforward. I think any other metrics, such as usability or app crappiness, should be the domain of users, not the certifying body.
  • PHI. If PHI is or may be included in the app, the app attempts to segment data by PHI and non-PHI. All data deemed potentially PHI is encrypted at rest and in transmission (somebody else can define what encryption schemes should be used.) Education about PHI is included, but in layman’s terms. If legal departments would allow it, the certifying body should provide templates for this PHI language.
  • Data ownership. Ownership of data is outlined in no more than four sentences or bullets, and is included as part of registration or initial launch of the app.
  • Data export. The user has the ability to export data in standardized format (even CSV) at any time. I don’t think this should be overly burdensome. Data export ability could be rated as part of the certification process to differentiate those apps that are more interoperable.
  • Privacy. The privacy statement cannot be more than four mobile screens (let’s say four inches is the assumed size of screens) and clearly lays out who has access to data. This is probably impossible. but it’s something I think should be a universal standard. This would make it useful for users. More than this is only useful for attorneys.
  • Content. All educational content should have sources cited, even if it’s the MD cofounder of the app company. I’m not sure if the certifying body should require certain content sources or do clinical validation of the content. This likely would become too big of a process. I suppose the certifying body could look at the sources of content and rate them, similarly to how evidence is rated. Then the app would have a level of confidence attached to the content.
  • FDA. If the app is a medical device by FDA definitions, it has obtained FDA certification. If the app is not considered a medical device by the FDA, the app states simply the reasons why it is not.

More detail is probably required for each of these, but keeping the certification requirements simple would be a good best practice.

In terms of Happtique’s guidance, it’s very complete and includes some things I think aren’t necessary. Below are some of the highlights from the draft guidance.

  • The design of the app should take into consideration efficiency (the speed with which users can complete their tasks), effectiveness (the accuracy and completeness with which users can complete tasks), and satisfaction (the user’s satisfaction with how well the app operates). This is a bit too subjective to me and something that a certifying body shouldn’t be doing.
  • The app user is informed if the app accesses local resources (e.g., device address book, mobile and/or LAN network interface, GPS and other location-based services, contacts, camera, photos, SMS or MMS messaging, and Bluetooth) or resources from and/or for social networking platforms, provided with an explanation by any appropriate means (e.g., the “About” section) as to how and why such resources are used, and prior consent is obtained to access such resources. I thought parts of this were a bit too much because informing users how many SMS messages or e-mails would be sent is overkill.
  • Cloud-based apps meet SAS 70 requirements and a SAS 70 audit report is provided. I’m torn on this requirement. If the app provides necessary security for PHI, I’m not sure SAS 70 audits are necessary, especially because they aren’t cheap. Amazon has completed a SAS 70 Type II audit, but I imagine this isn’t really applicable to the individual apps that host their data with Amazon.
  • For any app derived from a third-party source that does not contain the original source’s complete content, such app’s description or “About” section shall indicate the specific portion(s) absent and contain an explanation as to why each portion(s) is not included. If an app owner cuts and pastes content from sources like CDC or WHO, this is going to make for a lot of explanation. If complete content is displayed, it might be unreadable on a mobile screen.
  • When operated, the app performs with sufficient accuracy and reliability for the intended purpose. I think this needs some further clarification.

As I was reading the Happtique guidance, my fear was that app owners were going to have to provide very long privacy and explanatory statements that users would then have to either decipher, or more likely, ignore because of overload. Maybe this is a necessary evil today and can’t be avoided if you want to be transparent with users.

This post was about mobile apps, but I think the same rules apply for any digital health service. While I believe mobile is the future of engagement, certain services, or even components of services, are still valuable non-mobile. My personal opinion of certifying web health services: do not require support for IE 7 and 8. The world would be a happier place without those browser versions.

If I’m missing some areas that should be a part of an app certification process, please let me know.


Travis Good is an MD/MBA involved with health IT startups. More about me.

↑ Back to top

Founding Sponsors

Platinum Sponsors