I read Marvin Ammori’s book, “On Internet Freedom” the weekend it came out close to one…err…two…err…three…err… four months ago. And, unlike my review, his work is super timely. If you’ve been following internet policy issues over the past couple of years you’re probably familiar with the Internet Defense League and, thus far, some unsuccessful bills: Stop Internet Piracy Act (SOPA), Protect IP Act (PIPA), and, more recently, the Cyber Intelligence Sharing and Protection Act (CISPA).

Tumblr is ‘not for’ malicious bigotry, bullying minors, gore, or sexually explicit content… because ‘we’re not in the business of profiting from adult-oriented videos and hosting this stuff is fucking expensive.’ (Location 1277).

Thanks to Marvin translating the law into understandable concepts via colorful examples, I now understand what Network Neutrality is and how it intersects with Free Speech. Network Neutrality is easy to understand:  the Internet is a platform like the power grid – general purpose and “limited only by imagination, software and caffeine.” (312). How PG&E run the power grid, Internet Service Providers (ISPs) provide access to the internet. Sometimes ISPs argue that they shouldn’t have to provide uncensored access to the internet, and, because they are private companies, think they don’t have to provide access to all kinds of information. But, as Marvin puts it, “you might think this argument is stupid. You’re onto something there (Location 1986).”

He then makes some sophisticated arguments about Congress/FCC not even being powerful remove network neutrality and/or enable ISPs to control our access to the Internet. This overarching legal argument is nice (and necessary), but it’s a bit too theoretical for my taste. What did resonate is the following: Adam Smith’s invisible hand can’t save Free Speech. Here’s the deal, ISPs argue that if someone doesn’t like their censorship, they can move to another ISP (So if AT&T censors information, a person can switch to Verizon.). Here’s why:

  1.  There are rules and people to enforce those rules in competitive markets (think FTC and FCC).
  2. The rules don’t matter. This isn’t a competitive market.

Market competition does a lot of wonderful things. But, like the Internet, it doesn’t always give us unicorns and rainbows. (Location 1921)

People don’t get to make choices about who their ISP is in a lot of instances. I grew up in rural California. I know how it is to only be able to get one kind of internet from one provider. Thanks to my dad being a tech nerd, I distinctly remember him getting totally jazzed over dialup, DSL, and, OMG-it's-lightening-fast cable internet. Why was he so excited? Because you could only get certain types/speeds as they came out. You still can’t get internet in some areas.

It was great I read this before Boing Boing came out with a column that compared telco profit models to uniary tract infections and fee-for-service healthcare:

On the other hand, it's easy to see why telcos would love the idea that every play of "your" media involves another billable event. Media companies, too -- it's that prized, elusive urinary-tract-infection business model at work, where media flows in painful, expensive drips instead of healthy, powerful gushes.

The progeny of this hellish marriage is the non-neutral Internet connection where a telco offers to spy on, and slow down, its users' connections -- but selectively, so that the media from a "preferred partner" comes in more quickly, and doesn't count against a bandwidth cap. This is especially virulent where telcos are entertainment companies -- Comcast and Rogers and so on, all champing to freeze out services like Netflicks by metering its bandwidth, but freeflagging downloads from their in-house competing services.


Speaking of healthcare, somehow, I drew correlations between Internet Free Speech and the FDA’s Mobile Medical Apps guidance (my favorite!). Which helped me put a bit more faith into overarching regulatory frameworks. So Marvin refers to two issues:

When SOPA was introduced in 2011, existing law concerning technologies that enable speech (and infringement) consisted primarily of two components:

First, in the 1984 decision Universal Studios v. Sony, the supreme court decision that Sony’s VCR was not illegal for contributing to the copyright infringement of its users the justices enunciated a new rule in copy right law: if a company sells a device that is “capable of substantial noninfringing uses” then the maker of the device isn’t liable for the infringement of its users.

Second, in 1998, Congress passed the Digital Millenium Copyright Act (DMCA)… so long as the companies followed a notice-and take down procedure and met a few other requirements set out in the law. The company would have immunity. (Location 592)

Ok, so the first component is an information deliverer the second component is the platform for selling software/information and neither are responsible for the copyright infringement. This is exactly what the FDA did in their MMA draft guidance – they aren’t going to regulate either:

  1. Mobile Platforms, aka smartphones and tablets, won’t be regulated so long as it’s used for other purposes. Why not? Because they’re capable of being used for things beside diagnostic medicine. Now that EKG machine, now that is only for diagnostic medicine so they will be regulating it.
  2. Distributors, aka Android marketplace or iTunes, aren’t device manufacturers and just have to comply with takedown procedures. Now if the platform is helping design the mobile medical app or owns the device, well then, maybe we’ll have some regulatory implications.

And, there we have it folks, there is some consistency across lawmaking!

Finally, It reminded me of A Separate Peace, one of the first books I used Spark Notes accessed via dialup internet to analyze. In the last paragraph of A Separate Peace John Knowles refers to the same Maginot Lines Ammori does –

All of them… constructed at infinite cost to themselves these Maginot Lines against this enemy they thought they saw across the frontier, this enemy who never attacked that way- if he ever attacked at all; if he was indeed the enemy.

In his book, Marvin is referring to the way Joe Lieberman circumnavigated the defenses would have protected Wikileaks by phone calls and press statements. My takeaway with these Maginot lines is a little different – my takeaway is that even if lawmakers construct laws that legislate the internet the internet will find a way despite them. Admittedly this may result as he fears: “the ultimate effect would be to silence the many and empower the few.” (758), but I am hopeful that, we can all be, as Marvin puts it,  the hero of this story, and find a way to either take down, go around, or prevent these Maginot Lines from destroying the internet.

Marvin Ammori and I met at a Startup Weekend last June where we were part of a team called Pineapple - a solution that helped people on SNAP to get healthy foods delivered to their corner stores based on open data from USDA. I was the project manager and Marvin the pretty face (who eventually presented at the World Bank’s 2012 Open Government Data Conference). Following another Startup Weekend, he and the amazing Stephanie Nguyen have helped form Silica Labs, a company devoted to applications for Google Glass.

Cover RockHealth

This week I've gotten several emails about my thoughts on the House's Energy and Commerce hearing on mobile app regulation by the FDA. While I could come up with my own thoughts on the hearing, I prefer to recap by sending you over to the incomparable Brian Dolan's lists: 5 take aways and 10 threads. Now you're caught up. So today, as promised in a rather polarizing VentureBeat article, Rock Health came out with a slide deck on digital health regulation by the FDA. (Side Note: when did we start calling it digital health? (Second Side Note: When do we get to call technology enabled healthcare just health?)). I loved all the details they gave on how to go through the 510(k) and PMA process - to date, haven't seen a group put out a free "how to navigate" the FDA presentation (so kudos Rock Health!).

FDA 101: A guide to the FDA for digital health entrepreneurs by @Rock_Health from Rock Health - produced by Malay Gandhi (@mgxtro) and Deborah Pascoe (@deborahpascoe).

A Few Comments:

Slide 1: In addition to the Mobile Medical Apps guidance I'd also suggest developers look at the Medical Device Data Systems and Design Considerations for Devices Intended for Home Use.

Slide 3: I’m not sure why the FDA's birthday is relevant - Personally, I would have gone with when the Food, Drug, and Cosmetic Act was signed into law - 1938. FDCA is what expanded the FDA’s regulation authority to include devices and cosmetics. I guess Rock Health doesn't share my love of flappers and the FDCA.

... following FDA regulations will actually make them a better company, with a higher quality process, and open the door to the entire healthcare market. - Geoff Clapp on Slide 23

Slide 4:

Rock Health Question: Why is the FDA looking at Digital Health?
Rock Health Answer: Widespread Availability & Public Interest

"Widespread Availability" and "Public Interest" are why the House Energy and Commerce Committee had a 3 day hearing on digital health. The FDA is a bit simpler - it looks at "digital" health because if something is a device, the FDA regulates it. That’s it.

Slide 5: Really not sure why they refer to the “current” definition of device. Device was codified way back in 1938's FDCA section 201(h) and isn't likely to change...

(h) The term “device” means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is— (1) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them, (2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or (3) intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.

So what’s this really mean? If you’ve got something that treats something with an ICD-9 code and isn’t a drug you’re a device. And if you are, you're subject to the medical excise tax. What won't be subject to the tax? Things that aren't medical devices (as the laughable Hotair puts it: "the federal government is munificently resisting the temptation to tax our smartphones" just like they're not taxing our fax machines. Or, for that matter, regulating our fax machines.).

device formula

Slide 6: Believe me, I really wanted to love this slide. Then I noticed that it wasn’t to scale and got sad.

MMA Vs Other Apps (not to scale)

MMA Vs Other Apps (not to scale)

Mobile Medical Apps vs Other Apps (Rock Health Numbers, to scale)

Mobile Medical Apps vs Other Apps (to scale)

Not such a big piece of the space, now is it? Since there isn't a numbered estimate for the gray area of apps which “might” be regulated, I couldn't scale that space.

Slide 7: Again, so close to loving this slide. I just wish patient/consumer Safety had made the list. Yes, they said “consumer confidence” but when we’re talking about FDA oversight, we’re talking about medical devices and patient safety. FDA approval does increase physician confidence, but they’re not the end user/consumer in this continuum.

Slide 9: CMS doesn’t regulate devices. Pay for them, sure, but regulate? Not so much. I suppose we can go to futuristic imagination land where everything is mobile and talk about how a future iteration of Meaningful Use may require a provider to use a mobile application per CMS specifications. Barring that, CMS isn’t regulating mobile. Setting reimbursement guidelines, yes. Regulating? No. I’d definitely worry about the FTC before I even though about CMS – particularity in relation to apps which aren’t even considered devices. More on that regulatory continuum can be found in my HIMSS13 presentation. 


Slide 12:  Once I read this article, I understood what they were getting at with this example.  I think my brain still had a problem with it because their Class I example didn't have a mobile application associated with it. Glooko is a good example of the evolution of MMA stages - originally their system/cable was a Class I device - all the cable did was transmit data in its original form for recording. But they couldn't do analytics on it which means its usefulness was limited. Recently they received Class II clearance for their Glooko Logbooks Chart product. And maybe in a few years Glooko will come out with an app that helps control an artificial pancreas device and have to get Class III approval. 

Glooko Example

In closing, great job to the Rock Health team for interviewing so many thought leaders in this space - really enjoyed the emphasis on the FDA being composed of real people (believe me, they are!)!

Author Note: The views in this blog are strictly mine and should not be attributed to any organization mentioned. I do not work for the federal government and the contents of this site do not represent the views of any federal agency. It is important to note that my ORISE fellowship is with the FDA's Center for Drug Evaluation and Research and I do not have inside knowledge regarding the device approval process.


Here's a quick summary of the FDA CDRH's Mobile Medical Apps guidance (edited by amazing mHIMSS Mobile Policy and Regulatory Implications Group members: Daisy Wong, Rebecca Kennis, Wendelyn Bradley, Michael Kuriland, and Lee Kim). While I've copy/pasted an early version here, the official HIMSS version is found here. Remember, don't take this as the word of the FDA- it was just us looking at what they said and making some educated analyses.

Guidance Bottom Line:

The FDA will exercise regulatory authority over mobile medical applications intended to perform a medical device function, regardless of the hardware or platform involved. The regulatory requirements manufacturers must meet are determined by the intended use of the mobile medical app.

Who is Responsible:

This guidance is targeted at manufacturers and distributers of mobile medical apps.

  • Manufacturer” encompasses any person or entity that manufactures mobile medical apps in accordance with 21 CFR Parts 803, 806, and 807.
    • Includes:  Anyone who initiates specifications, designs, labels, or creates a software system or application in whole or from multiple software components. This may include health systems, insurance companies, private software vendors, Health IT startups, physicians, nurses, etc.
    • Does not include:  Developers who strictly operationalize a manufacturers’ design. These people are likely technology programmers who are hired to make someone else’s application work.
  • Distributor” refers to entities that exclusively distribute mobile medical apps. Distributors are expected to work with manufacturers in correcting/removing products, but are not responsible for seeking FDA approval. Common distributors include the iTunes store, Android marketplace, and Blackberry app world.

What is, Might, and isn’t regulated:

Below is a detailed description of what is, might, and isn’t regulated by the FDA. Regardless of regulatory oversight, manufacturers are encouraged to follow the Quality Systems regulations to prevent harm in the development of all mobile apps.

What is Regulated - Mobile Medical Applications:

A “mobile medical application” or “mobile medical app” is a mobile app that meets the definition of "device" in section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act); and its intended use is:

  1. As an accessory to a regulated medical device; or
  2. To transform a mobile platform into a regulated medical device


  • Displaying, Storing, or Transmitting:  If a mobile medical app allows for the display/storage/or transmission of patient-specific information, such as personal health information (PHI), in its original format, it is a medical device. This category of mobile medical apps are primarily used as secondary displays (and not for primary diagnosis/treatment decisions) and will only require Class I requirements. For example, a PACS Viewer (like Centricity® Radiology Mobile Access 2.0 software[i]) or mobile ECG viewer (like AirstripTM RPM Cardiology[ii] device) would be regulated under this criterion.
  • Controlling connected medical devices:  If a mobile medical app allows for the control of another medical device, it must adhere to the regulations applicable to the connected device. These mobile medical apps can control the use, function, modes, or energy source of a regulated medical device. For example, an app that controls a blood pressure cuff (like Withings®[iii] blood pressure monitor) or a portable ultrasound app (such as the Mobisante software[iv]).
  • Mobile platform transformation:  If a mobile medical app transforms a mobile platform into a regulated medical device, it is regulated under the class applicable to its intended use. For example, if a mobile medical app utilizes a phone’s accelelerometer to collect data on Parkinson’s disease such as iTrem software.[v]
  • Interpretation of Medical Device Data:  If a mobile medical app is intended to analyze or interpret data from a medical device for the purposes of creating alarms, recommendations, or information, is considered an accessory to the first medical device and regulated under the first medical device’s class. This would include patient monitoring apps such as the LifeWatchTM cardiac monitoring system.[vi]

What might be Regulated:

The FDA will exercise regulatory discretion regarding mobile apps that meet the FD&C’s device definition but are not an accessory to a regulated device or intended to transform a mobile platform into a regulated device. Manufacturers may proactively register, list, and seek approval/clearance for mobile apps that might meet the criteria for being mobile medical apps.


Applications that might fall under regulatory oversight include:

  • Applications that remind people to manually input information for logging/tracking/graphing, such as the LogFrog DB Diabetes tracking application that reminds users to test their blood and log A1C results.[vii]
  • Patient education data viewers, such as the ActiveMDTM Patient education marketing.[viii]
  • Organization of personal health information – such as dosages, calories, doctor appointments, lab results, and symptoms. This might include something like iLog Lyme, and application that allows users to log the symptoms of Lyme disease and their medication dosages.[ix]
  • Over the counter medication lookup applications that provide the information available on drug labels such as the MEDIlyzerTM application.[x]

What isn’t Regulated:

Non-covered apps include: Electronic versions of reference materials that do not contain patient-specific information; health/wellness applications that do not intend to cure, treat, or diagnose; automated billing, inventory, appointment, or insurance transactions; generic aids (audio recording, note taking, etc); mobile EHRs or PHRs.

Regulatory Requirements:

If the mobile medical app falls within a specific medical device classification or augments functionality to a specific medical device classification, manufacturers are immediately subject to meet the requirements of that classification (either I, II, or III).

According to the Draft Guidance, these requirements include:

  • Class I devices: General Controls
    • Establishment registration, and Medical Device listing (21 CFR Part 807);
    • Quality System (QS) regulation (21 CFR Part 820);
    • Labeling requirements (21 CFR Part 801);
    • Medical Device Reporting (21 CFR Part 803);
    • Premarket notification (21 CFR Part 807);
    • Reporting Corrections and Removals (21 CFR Part 806); and
    • Investigational Device Exemption (IDE) requirements for clinical studies of investigational devices (21 CFR Part 812).
  • Class II devices: General Controls, Special Controls, and (for most Class II devices) Premarket Notification.
  • Class III devices: General Controls and Premarket Approval (21 CFR Part 814).

Approval Process:

Section Author: Daisy Wong

To meet the regulatory requirements described above, developers of mobile app should be mindful that preparing, filing, and waiting for FDA approval will take time and may cost a significant amount of money. The amount and types of resources needed and the duration of the approval process is dependent upon the app/device classification per the descriptions in the previous section. In addition, developers should also budget for the maintenance of the certification once approval is obtained.

Guidance Limitations:

This guidance provides the “current thinking” of the FDA and is iterative. Indeed, the FDA will monitor mobile apps not covered by this guidance to determine if additional/different guidances are necessary to protect public health. This guidance does not consider wireless safety considerations, clinical decision support software, quality systems software, or mobile medical apps intended to analyze, process, or interpret medical device data from more than one medical device. Separate guidances are forthcoming.


  • Mobile Platform: handheld commercial off-the-shelf (COTS) computing platforms, with or without wireless connectivity. Examples: smartphones, tablet computers, personal digital assistants, etc.
  • Mobile Application (Mobile App): software applications that can be executed on a mobile platform; native and web-based.
  • Regulated Medical Device: a product that meets the definition of "device" in section 201(h) of the FD&C Act and that has been classified or otherwise approved or cleared by the FDA. Regulated Medical devices usually profess an ability to diagnose, cure, mitigate, treat, or prevent disease, or are intended to affect the structure or any function of the body of man.
  • General Controls: include requirements regarding good manufacturing practice, labeling, registering all establishments with the FDA, listing all devices to be marketed and submitting a premarket notification [510(k)] before marketing a device.
  • Special Controls: may include special labeling requirements, mandatory performance standards and postmarket surveillance.
  • Premarket Approval: Premarket approval (PMA) is the FDA process of scientific and regulatory review to evaluate the safety and effectiveness of Class III medical devices


This summary is based upon the FDA’s Mobile Medical Apps site.

[i] http://www.hospitalemrandehr.com/2011/12/02/centricity-gets-fda-510k-clearance-for-mobile-radiology-app/.  Centricity is a registered trademark of General Electric Company.

[iii] http://mobihealthnews.com/11275/fda-clears-withings-iphone-blood-pressure-cuff/.  Withings is a trademark or a registered trademark of Withings SAS France.

[iv] http://www.imedicalapps.com/2011/10/fda-sanctioned-mobile-health-apps-making-appearance/

[vi] http://www.lifewatch.com/siteFiles/1/319/5257.asp.  LifeWatch is a trademark or a registered trademark of LifeWatch Holding Services, Inc.

[vii] http://itunes.apple.com/us/app/id398879753

[viii] http://www.activemd.net/design-develop/patient-education-programs.php.  ActiveMD is a trademark of ActiveMD Patient Education.

[ix] http://itunes.apple.com/us/app/id405435677

[x] http://www.medilyzer.com/smart-phone-iphone.html.  MEDIlyzer is a trademark of MediLyzer Systems Inc.