FDA's Regulation Of Mobile Health

mobi health news
Thank you for purchasing this paid report. Please do not distribute. Kinect The Docs | 1
© Copyright 2013 Chester Street Publishing, Inc. All Rights Reserved.
© Copyright 2013 Chester Street Publishing, Inc. All Rights Reserved.
Thank you for purchasing this paid report. Please do not distribute. © Copyright 2013 Chester Street Publishing, Inc. All Rights Reserved. Q3 2013 | 1

mobi health news
CONTENTS
Click
on titles
to go
directly to
chapter start
I. Understanding Intended Use 4
II. Which Apps Does FDA Regulate? 10
III. What about Hardware? 24
IV. The CDS Conundrum 28
V. Who Does FDA Regulate? 33
VI. FDA Regulation of Pharmaceutical Apps 36
VII. FDA Compliance for Regulated Apps and Accessories 41
VIII. Should mHealth Companies Welcome FDA regulation? 47
IX. How to Avoid mHealth Regulation 51
X. Managing the Risk of Being FDA Regulated 56
XI. Does FDA Regulate mHealth Care Providers? 64
XII. FDA’s Enforcement Plan 69
XIII. Policy Making From Here 73
XIV. International Regulation of mHealth 77
XV. EU Regulation of mHealth 78
© Copyright 2013 Chester Street Publishing, Inc. All Rights Reserved. FDA REPORT | 2
© Copyright 2013 Chester Rights Reserved. FDA REPORT | 2

mobi health news
PREFACE
More than three years have passed since I wrote the first edition of this e-book, and much has
changed. Among other things, FDA at last has published its final guidance on mobile medical
apps. Further, the mHealth industry has morphed several times over the last couple years.
Consequently, in this second edition, more than 80% of the content is new.
Not only have I updated the regulatory analysis, but I’m also covering a few new topics like
FDA regulation of pharmaceutical apps. I also convinced my good friend and colleague in
Amsterdam, Erik Vollebregt, to write on EU regulation of mHealth. You might recognize Erik
from his popular blog, www.medicaldeviceslegal.com.
The first edition was basically a collection of posts that I had already written. In this edition,
partly because of the new FDA guidance, I wanted to tell the story of FDA regulation of mHealth
in a more holistic and methodical manner.
My hope is that app developers will now have the certainty they need to make business
decisions about how to enter the mHealth space. To be sure, as I explain throughout the book,
there are still many open issues, including how FDA ought to improve its regulatory scheme for
those apps that are regulated, as opposed to just clarifying the threshold question of what FDA
does regulate. Nonetheless, with this recent action by FDA, we hope and expect that mHealth
technologies that address some of the greatest needs, but also with some risk, will flourish.
The mHealth Regulatory Coalition, where I serve as General Counsel, is organizing a significant
educational effort in partnership with leading engineering schools to train innovators on
complying with the FDA requirements. We plan to use this book as the primary text, but one
objective of the meetings is to give people an opportunity to meet face-to-face and develop
relationships. These engineering schools serve as regional innovation hubs, and make an ideal
setting for the meetings, which will be inexpensive and open to the public. There are some
mHealth entrepreneurs out there who you really should meet—pioneers who have figured out
some emerging best practices in dealing with FDA regulation that they are willing to share.
While it was clearly time to write this second edition, I would also caution you that FDA
regulation of mHealth will continue to evolve quickly. At the end of the book, I discuss numerous
policy initiatives that are likely to produce change in 2014 and beyond. Through blog posts on
MobiHealthNews, I plan to keep you up-to-date on those developments.
In the meantime, I hope you find this new edition useful and please let me know if you spot any
areas where I can improve it in the future.
Bradley Merrill Thompson
October, 2013
© Copyright 2013 Chester Rights Reserved. FDA REPORT | 3

mobi health news
I. Understanding Intended Use
The key to understanding what FDA
regulates as a medical device is the concept
of intended use. People come to me all the
time and describe in loving detail every
element of their widget’s design and then
ask me whether it’s a medical device. I
usually tell them I have no idea. That’s
because by far the biggest determinant
of whether a product is a medical device
is not its design, but rather the uses for
which the designer intends to promote the
widget.
Let me explain.
The natural place to start is with the
definition of a medical device. Since it is so
central to the analysis, I’m going to quote
a portion the statute verbatim. Section
201(h) of the Federal Food, Drug, and
Cosmetic Act defines a medical device as
a device:
“…which is … [either] intended for use in the
diagnosis of disease or other conditions,
or in the cure, mitigation, treatment, or
prevention of disease … [or] intended to
affect the structure or any function of the
body of man or other animals.”
Let’s break that sentence down a bit. See
the word “intended” twice in that sentence?
To be a medical device, an article needs to
be “intended” for a medical purpose.
But I’m going to skip the word intended for just a moment, and focus on those medical
purposes before I explain the concept of intent. At a high level, there are three medical
purposes you need to understand:
Diagnosis, which is listed separately because a device can diagnose either a disease
or other conditions. Other conditions include things like pregnancy or genetic makeup.
Treatment, which includes a range of verbs that are interpreted pretty broadly with
regard to addressing a disease.
Affecting the structure or function of the body. There had to be a category for such
things as cosmetic surgery since we do plenty of things to our body not because we
are sick.
1.
2.
3.
Those three medical purposes are all interpreted quite broadly, so that leads us back to the
concept of “intended use.”
Customers routinely buy products for all sorts of uses. A statutory definition of a medical
device based on whether and how customers actually use products for medical purposes
would be utterly impossible to administer, and frankly unfair. The statute potentially imposes
significant regulatory obligations on the seller of a product, and making those obligations
depend on the whim of the customer would take compliance completely outside of the
control of the seller. So instead, under the statute, it is the seller’s intent with regard to how
the customer should use the product that controls how the device is regulated, not how the
customer actually does use the product.
Not only does the seller’s intended use determine whether a device is regulated as a
medical device, for those devices that are regulated, the concept of intended use also
determines exactly how the product is regulated. As I will describe more below, the Medical
Device Amendments do not impose one singular set of requirements on all medical devices,
but rather the statute stratifies them by risk category. The intended use of a product is
what determines into which of those risk categories the device is placed, and consequently
the level of regulatory controls imposed. Indeed medical device manufacturers typically
become very good about controlling the nuances of their intended use so as to manage the
specific regulatory obligations that the manufacturer must meet.

mobi health news
I. Understanding Intended Use (continued...)
Now you’re probably thinking, how does
this concept of intended use actually work?
After all, in some sense, what I intend is
kind of personal. To know my true intent,
doesn’t FDA have to read my mind?
Fortunately, no. FDA has developed a basic
framework for judging the intended use of
a product. The agency explains its general
approach in a regulation, 21 CFR section
801.4.
Now I need to forewarn you: what I’m about
to tell you is a right brain exercise. If you
are an engineer, chances are pretty good
you will not understand what I’m about to
explain. Just kidding: my son’s an engineer.
But I am not kidding about the fact you
need to use the side of your brain that can
evaluate information holistically.
Intent is actually a pretty familiar concept
in our legal system. Juries are often called
upon to evaluate a person’s intent, for
example in connection with a crime or a
civil claim for damages. If you have watched
Law and Order or any other criminal justice
show, you know that there are significant
differences in intent between first-degree
murder and manslaughter. Likewise
there are significant differences between
intentionally hurting someone, and mere
negligence.
Let’s get back to the FDA regulation. It’s too
long and boring to quote, but I will identify
for you the key elements of the definition
of intended use. Bear in mind that as I
tease out the elements, I am not drawing
only from the text itself but also from the
myriad of enforcement actions that the
federal government has brought based on
its interpretation of intended use.
Really, as with any factual question, it
all comes down to evidence. And the
evidence one would use to determine the
company’s intent generally involves three
different types: (1) words, (2) deeds and (3)
knowledge. I will take each one separately.
1. Words.
Words are generally the most powerful and clear way to prove intent, and seem to be
FDA’s typical starting point. And in this case, the words that are most relevant are the
words the manufacturer uses to convey to its customers the intended use of the device.
So the starting point for this analysis is an examination of all of the product labeling
and promotional materials the manufacturer uses to sell the product. What do all of
those materials, taken together, suggest the manufacturer intends the customer to use
the product for?
Now this analysis can be somewhat subtle. It includes both written words and spoken
words. It includes how the sales representatives and others explain the benefits of the
product. And while I am focused on the words, the pictures used also in advertising
convey the intended use.
Obviously the words communicated to customers are the most powerful and the
government’s typical focus and starting point, but sometimes if the government has
concerns and begins an investigation, they also look at internal memos and business
plans to discern the intended use. Their argument is that such materials reveal the
company’s true intent, and also shed light on what sales representatives and others
might orally say about the product.
The nice thing about a focus on words is that you can choose to be very careful, specific
and clear with your customers about the use you intend. This includes being specific
and clear with your customers about uses that you do not intend. Thus you can manage
your intended use by including warnings and other cautionary statements directing
customers away from uses for which you do not want to be held responsible.
Of course these warnings need to be sincere and effectively delivered. If you add some
fine print in an area where the customer is not likely to see it, the FDA will question
whether you truly intended to discourage that use.
2. Deeds.
In some cases, actions do speak louder than words. But even when they are not louder,
they are typically still relevant. Here, for example, is where design decisions enter the
equation. If a device has a certain design feature that can only be reasonably explained
by a given intended use, the design feature will be evidence of that use.
Take an absurd example. If I make a pacemaker, and I sell it and tell my customers that
it is a great paperweight, the FDA may very well disagree and say that all of the design
decisions that are reflected in that pacemaker show that I intended it to be used as a
pacemaker, and not a paperweight. So where design elements really only have one use,
those design elements will be evidence of that intended use.
That said, there are some instances when design elements are latent, somehow not
available to the customer, for example without an additional software key. Latent
design elements might not be evidence of a given intended use, at least not broadly
with all customers.

mobi health news
Other actions are relevant too. For example,
if I claim that my product is only useful
in urology, but my sales representatives
visit cardiologists and if I do most of my
advertising in the American Journal of
Cardiology – I completely made that up
– FDA will say that I must intend for my
product to be used in cardiology, not just
urology.
3. Knowledge.
This is the most controversial type of
evidence to use to establish intended use.
And it would be very rare for FDA to rely on
this type of evidence alone. But at least in
theory FDA might say that if a very large
percentage of your customers are using
your product a certain way, and if you are
aware of that use, you must’ve somehow
intended your customers to use the product
in that way. This theory has some obvious
weaknesses in it. Sometimes customers
come up with new uses that you never even
dreamed of, and they catch on completely
outside of the manufacturer’s intent. But
if FDA thinks, for example, that you have
been orally promoting your product for
a given use, and they just haven’t found
specific evidence of those oral statements,
they might turn to what they consider to be
the end result – the customers’ actual use
– as evidence of your intent.
In its definition of intended use, FDA also
states that it will only be interested in the
objective intent of the manufacturer. In
legal terms, this means that the agency will
not be particularly interested in subjective
explanations for why the words, deeds
and knowledge should not be interpreted
on face value. In the law of intent, an
attorney might argue that notwithstanding
the evidence, his client didn’t intend
something subjectively because his
client, for example, suffers from a mental
defect. Apparently FDA isn’t interested in
those sorts of subjective explanations,
and intends to judge intent by a normal,
objective standard. I am not sure I agree
with FDA’s position here.
A popsicle stick example
Figuring out the actual intended use of an article depends entirely on the facts. I teach
this topic occasionally at Columbia Law School, and I generally begin the session by
taking out a popsicle stick. To employ the case study approach, I tell the students that
I’m the CEO of a company that makes these sticks, and I want to know whether I have to
comply with FDA regulations. At that point I encourage them to ask questions of me in my
hypothetical role as CEO, and then ultimately to advise me.
If they have done their homework, they will start to ask me how I promote the stick. In my
answers, I’m pretty coy at first, simply explaining that I sell sticks and what my customers
do with them is their business. I explain that my labeling for the product merely identifies
the product as a stick without going into its possible uses.
Hopefully my students have read enough to know how the regulations define “intended
use” so what I say in my labeling is not the last word, but ultimately what matters is the
totality of what I have done to promote the article and perhaps what I know about how
my customers are using it.
Eventually my students start asking me about what trade shows I attend, what types of
magazines I use to advertise the sticks, what my salesmen say to customers, and what I
know about the actual usages of the sticks. And it turns out, in my hypothetical, I know
that many of my customers are using them as pediatric tongue depressors, I promote
them in advertisements in hospital journals, and at least some of my salesmen might
encourage their use as tongue depressors. So eventually my students come to appreciate
the risk that my simple popsicle sticks might in fact qualify as medical devices and be
subject to FDA regulation. I use this example to teach the point that a single stick can be
an FDA regulated tongue depressor or a popsicle stick depending on a whole range of
factual questions quite apart from the stick itself.
Diagram 1. Determining the intended use of a stick
Statements suggesting
pediatric tongue depressor
popsicle stick
It’s a popsicle stick
Sterilized to food grade
Kids love it
Makes popsicles last longer
Statements suggesting
pediatric Statements tongue suggesting
depressor
It’s a pediatric tongue depressor
Sterilized to medical grade
Young patients love it
Narrow enough to access those
hard to reach places in a kid’s
mouth
TASTES GREAT

mobi health news
The endless flavors of intended use
If that isn’t gray enough for you I’d like to add a few thoughts about all the different
styles of intended use. I do so because I think it helps to understand the various
options as a company is strategically trying to decide what it wants the intended
use for its product to be. Deciding how to characterize the intended use is a bit of
marketing and regulatory strategy, and a bit of art.
General versus specific
Among other variables, I can describe the intended use for a mobile app at a very
high level of generality, or very specifically. Let’s look at a few examples that could
be used with regard to an app that allows you to record what you eat, how much
exercise you get, how much sleep you get and perhaps a self-evaluation of the
amount of stress you are under.
“This app will help you manage your life.”
This is a general purpose claim, and it literally covers the waterfront from health
to just general lifestyle management. FDA would not regulate this type of intended
use because it is not specific even to health/disease.
“This app will help you manage your health and certain chronic diseases.”
We have gone from the general purpose claim, to now a general health claim.
We have mentioned that it is intended for use with regard to disease, but have
not specified the disease. Literally this type of claim may meet the definition of a
medical device, but as we will see below FDA seems to be indicating that this type
of claim might well be excluded from active FDA regulation.
“This app will help manage your diabetes.”
More specific yet, not all diseases but specifically diabetes. This pretty clearly meets
the statutory definition of a medical device, but might also be in a category that
FDA would exempt from active regulation because it is low risk. We will explore
that below.
“This app will help you better control your blood glucose so as to better control your
diabetes and reduce the risk of diabetic retinopathy, stroke and heart attack.”
Not only would this claim meet the definition of a medical device, but now we’re
into territory that FDA likely regulates.
The possible variations from general to specific are virtually endless, but hopefully
you get the point regarding the latitude that you have and the implications of the
intended use specificity.
Functionality vs clinical utility
There’s another dimension in which intended
uses tend to vary. Among other choices, an
intended use can be framed either to explain the
technical how or the clinical how for the device.
The technical how is generally referred to as a
tool type claim. Some examples might help.
The classic example is a scalpel. If a scalpel has
any directions for use at all, those directions may
simply indicate that the scalpel is for cutting
tissue. From that, the user may deduce that the
scalpel can be used generally for surgery, or
wherever a sharp blade is needed. The promotion
might be limited to a description of the shape of
the blade or its sharpness or its materials and
its ability to hold a sharp edge or be cleaned.
But all of the claims focus on the functionality
of the tool, rather than saying, for example, this
scalpel is perfect for an appendectomy or a
tonsillectomy. I prefaced this by suggesting that
the directions may not say anything, and certain
tools are so basic that FDA does not require
they be labeled at all, because their uses are
commonly understood. But generally tool type
claims are assumed to have very broad general
health purpose intended uses.
Now let’s get closer to home. Let’s talk about
the mobile app from my hypothetical above
for tracking daily living, but now this time let’s
look at functionality claims versus clinical utility
claims.
“This app allows you to track every morsel of food
you eat during the day efficiently through its simple
yet elegant user interface that allows you to type in
the general name of the food you ate, the quantity,
and then answer certain basic questions that allow
the software to calculate with great accuracy the
amount of fat and calories in everything you eat.”
This is a classic functionality or tool type claim.
With this sort of claim, FDA would assume a
general purpose diet management intended
use. As such, under the rules that I will identify
below, FDA would probably agree that this is not
a medical device.

mobi health news
Functionality vs clinical utility (continued...)
“If you suffer from diabetes, this app allows you to track every morsel of food you eat
during the day efficiently through its simple yet elegant user interface.”
So here I have identified the relevant disease and connected the use of the device to
that disease, but I’m still principally focused on how the tool works in general terms
without connecting it to a specific outcome. So this is a tool type claim blended with a
disease specific claim but without a clinical outcome.
“This app, by empowering a patient to carefully monitor their fat and calorie intake,
guides the patient through the steps necessary to substantially reduce the risk of diabetic
retinopathy, heart attack and stroke that often accompany diabetes.”
This is a clinical utility type claim that expressly declares how the device can help the
patient achieve a certain clinical outcome in the context of a disease. FDA regulates
these products closely.
Obviously, I could go on. The basic point is that there are at least two dimensions on
which these intended uses can be arrayed, general versus specific and claims that focus
on function versus claims that focus on the clinical purpose or outcome. People who
work in the FDA regulated space become very adept to creating the perfect intended
use statement that maximizes marketing potential while it minimizes the regulatory
obligations. It’s important in this industry to learn that calculus.
The meaning of disease
I have left out a couple of key definitions, including the meaning of the word “disease.”
I did so because in most respects the word disease is not terribly ambiguous, but
also because the design of the statute is not to rely too heavily on the word disease.
For example, as I’ve already pointed out, the statute says “disease or other condition.”
Further, something can be a medical device if it is used to affect the structure or
function of the body. So disease is only one among several elements that might trigger
medical device status.
But the word “disease” does have at least one important role, and that is to distinguish
those devices that merit regulation from those that are used in general health or
wellness that do not merit FDA regulation. Over the years, FDA has reaffirmed that
products used to support a healthy lifestyle in general are not regulated. This means
that a product designed generally, for example, to help a healthy person get or
stay physically fit is not regulated. A common treadmill, therefore, with claims that
it will help you improve your cardio functioning is unregulated by FDA. But if the
manufacturer of those treadmills instead made claims about the treadmill being useful
in conducting a stress test to evaluate your cardiac health, it might be regulated. Same
product, different outcome because of different intended use.
If you don’t think this dichotomy causes real problems, talk to the Chairman of the Board
of General Mills. In 2009, he received a warning letter from FDA because the marketing
people at General Mills had gotten, at least in FDA’s eyes, too aggressive in drawing a
connection between eating Cheerios for breakfast and managing your cholesterol. In
various advertising and promotions, the company had shared evidence from studies
showing that eating Cheerios regularly for
breakfast reduced your cholesterol. FDA said:
those claims make Cheerios into a drug. The
definition of a drug is very similar to the
definition of a device, with regard to relying on
the concept of intended use. This issue comes
up often with regard to food as food marketers
try to tie the consumption of certain food to
overall improvements in health, and specific
improvements with regard to conditions like
high cholesterol.
This dichotomy is incredibly important for
products in the mHealth space. Much of
mHealth is about integrating information
into our lives in a way that it can help us
make healthier choices. There are tens of
thousands of apps designed to let consumers
better manage their general fitness and
health by giving them access to important
information at the point where it can be most
useful – where they work, play and live. The
mHealth revolution has come about because
of two separate revolutions – the technology
revolution that allow us to gain easy access
to information on the go, and the wellness
revolution that helps us understand how daily
choices like diet, exercise, sleep and so forth
can have a dramatic impact on our health
in general and our risk of certain diseases
specifically.
It is that last bit that causes the regulatory
confusion. Now that we understand more fully
the risk factors for many diseases, the desire
obviously is to help people manage those
risk factors to reduce the risk of the disease.
Further, psychologists and other experts
will tell you that explaining the connection
between those risk factors and disease is an
important step in motivating people to take
better care of themselves. But technically,
the mere mention of a disease arguably trips
the line into FDA regulated territory. This
is because the FDA definition of a medical
device is not a risk-based definition, but an
intended use based definition. If an intended
use meets the literal terms of the statute, it
can be a medical device. So then it falls to FDA
to use its enforcement discretion to exempt
out those intended uses which are low enough
risk that they do not merit FDA oversight.

mobi health news
The meaning of disease (continued...)
Take, for example, as before the app that monitors and tracks a user’s
daily exercise. This developer might claim that using the app can reduce
the risk of heart disease or diabetes or help treat obesity. You might recall
that just a couple of months ago obesity was officially classified as a
disease. Technically the app would be a medical device.
If the developer instead claims that the same app can be used to monitor
daily activity, manage your health, or improve the user’s physical condition,
the FDA would likely not regulate the app. Those simple variations in
claims can potentially impact its FDA regulatory status in a very concrete
way. We talk about this much more below.
The meaning of device
Under the statute, a device is “an instrument, apparatus, implement,
machine, contrivance, implant, in vitro reagent, or other similar or
related article, including any component, part or accessory.” Frankly, I
generally don’t spend much time analyzing that, because it’s so wide-open
it normally is not very useful in determining whether an article is
a regulated medical device. This definition was written in the mid-1970s,
and so from a technology standpoint tends to use some old-fashioned
terms. But over the last several decades, FDA has interpreted this definition
broadly, and for example has interpreted the term contrivance to include
software, so long as the software is on computer media. If I wrote code on
a simple piece of paper, that would not be a contrivance and therefore not
a medical device. But once I load the code onto computer readable media,
according to FDA, it now qualifies as a device and might be a medical
device if it meets the intended use element of the definition.
That doesn’t mean the device element of the definition is irrelevant. One
situation where the definition is important is the distinction between
selling a thing, and providing a service. Selling a device is regulated
and providing a service is not. So those of you in the software business
immediately start to think about different models where software can be
a service. But don’t get too excited.
Fully distinguishing the sale of software from the sale of services is well
beyond the scope of this book. But in a nutshell, the difference between
selling a thing and selling a service is the human element. At least in
this context, services are provided by people, not software. FDA does not
regulate the practice of medicine, but the practice of medicine is done
by doctors, not by software developed by doctors. Further, FDA could care
less what the nature of the financial transaction is. You could give the
software away for free and FDA would still regulate it. You could rent the
software, and FDA would still regulate it. But if what you are selling is
truly a human service, as opposed to access to software, that’s where we
draw the line of FDA jurisdiction.
Conclusion
As FDA says, it all comes down to function,
which is a more vernacular term for intended
use. FDA jurisdiction often really has little to
do with the technology, unless the technology
reveals something of the intended use. The
technology always changes and will continue
to change. The FDA statute is not specific to
a technology, but instead focuses on how the
seller of that technology intends for the user
to make use of it. If the technology has one
of the medical purposes outlined above, it’s a
medical device. In the next chapter, were going
to take this general rule on intended use and
FDA’s recent guidance, and start parsing exactly
which apps fall within FDA jurisdiction.

mobi health news
II. Which Apps Does FDA Regulate?
Most normal people would expect this chapter to be about putting
mobile apps into two buckets—(1) those FDA regulates and (2) those it
does not. But alas, the world is not so simple.
There are actually three buckets, including (1) those FDA regulates, (2)
those it does not and (3) those FDA could regulate but which the agency
has decided at least temporarily not to regulate. Good grief. I have a
headache already.
Why is it so complicated? Well, Congress, in its wisdom, came up with
a statutory definition of a medical device that is too all-encompassing.
Heck, if you read the statute carefully, you realize that even an ambulance
is a medical device. I’m not talking about all the crap in the back, but
the actual vehicle itself including the engine and the driver’s seat and
the headlights and so forth. The vehicle itself is used in the treatment
of people with diseases or other conditions. Indeed, if the ambulance
breaks down and can’t get to the hospital, the patient could suffer.
Fortunately, FDA is supposed to use its judgment and limit the scope of
medical devices to those that truly need to be regulated, even though
the statutory definition is not expressly based on any risk criteria. And
FDA does this through a legal concept called enforcement discretion.
Regulated apps
It is useful to start at the top with the apps
FDA regulates because to some extent
the other two categories are defined as
the universe of health-related apps minus
those that FDA regulates. By far the greatest
precision comes in defining what FDA does
regulate because it is defined by law, and
the other two categories are at least partly
defined as excluding what FDA regulates.
For those who are new to FDA regulation of
medical devices, figuring out which mobile
apps FDA regulates may feel foreign and
difficult to understand. But the reality of it
is that figuring out what FDA regulates is
actually very simple and can be explained
in a nutshell. Quite simply, the agency
regulates the same stuff it has regulated
for the last few decades.
Generally enforcement discretion is the
power that an agency has to limit the
scope of its own regulatory requirements
when it deems that broader regulation is
not necessary to serve the purposes of the
statute. Once in a while you hear about
prosecutors deciding not to prosecute a case
when they do not feel that it meets the spirit
or intent of the statute, even if literally they
could. Same thing here. FDA can decide to
limit its regulatory reach so as not to waste
private or governmental resources.
As a result, I am going to describe for you
each of the three buckets. And I like to
borrow FDA’s visual depiction of these three
buckets as layers of a triangle. FDA uses this
visual aid to make the point that the smallest
category, and the one logically shown as the
top of the triangle, includes the apps FDA
regulates.
What gets regulated?
Regulated
mobile
medical apps
Mobile apps subject to
enforcement discretion
Unregulated mobile apps

mobi health news
II. Which Apps Does FDA Regulate? (continued...)
Regulated Apps (continued...)
In its final guidance, FDA repeatedly says that it is the functionality, not the platform,
that determines whether FDA regulates the app. So, to use an example from FDA’s past
enforcement in the mobile app space, if an app is used for urinalysis, and if FDA has
traditionally regulated urinalysis machines, the app would be regulated because it does
the same thing as a traditionally regulated machine. It is the intended use of urinalysis
that determines FDA regulation, not the machine on which the urinalysis is performed.
To me, that actually makes the dividing line between regulated and unregulated apps
fairly clear, but I also recognize that someone who has not been studying the scope
of FDA regulation for decades may find that explanation unhelpful. But bear with me.
Figuring out whether FDA regulates a given functionality is probably easier than it
sounds. The FDA website provides in searchable form a database of all those medical
devices that the agency has approved or cleared over the years. So if you find a machine
that FDA has cleared the does substantially what your app does, that’s pretty clear
evidence that FDA will regulate your app.
You need to be careful to remember, however, that FDA regulates some medical devices
without requiring that they go through any sort of clearance or approval. These are
referred to as class I medical devices, and they usually are subject to FDA quality
system requirements and adverse event reporting requirements. These you can find by
searching the FDA classification database. By regulation, FDA has classified most of the
typical functionalities that it regulates. FDA has included a list of some of the more
common classifications as Appendix D to the final mobile medical app guidance.
Admittedly, these searches are not foolproof. For one thing, some of the classifications
are defined in a very strange way, not using the words necessarily that you would expect
Accessories to medical devices
As already explained, FDA classifies medical
devices according to risk, and the regulatory
requirements are tailored to each of those
risk levels. In the FDA’s vocabulary, the
classification scheme looks like the following:
There has been a basic and fundamental rule
at FDA with regard to classification that any
product that accessorizes a medical device
is regulated in the same manner, meaning
in the same class, as the medical device it
accessorizes. Often that’s pretty simple to
figure out. If I sell an ultrasound machine, and
someone else sells the transducer that is used
to send the sound waves into the body and
record the returning waves and transmit them
to the ultrasound machine, it makes sense
that that transducer would be placed in the
same classification as the medical device it
accessorizes, namely the ultrasound machine.
If the transducer doesn’t work, the patient
is potentially at risk for the same safety and
effectiveness issues as when the ultrasound
machine itself doesn’t work.
to describe the functionality. So, if you don’t find
anything after searching, you might use one of
the vehicles for asking FDA this type of question.
In connection with the mobile medical app
guidance, FDA has created an email address you
can use to ask whether your app is regulated. For
cases where you think you fall into a gray area
and you want a more certain answer, there is a
process for filing what is referred to as a 513(g)
submission that gives you a more definitive
answer. It takes about 60 days for FDA to respond
typically, but they have been running longer than
that recently.
What the guidance says
Beyond looking to see if FDA has regulated the
same functionality previously, there is a more
conceptual way to determine whether your app
is regulated. In the final mobile medical app
guidance document, FDA lays out three different
categories of regulated apps. I will describe each
one in turn.
Figure 1. Three different categories of regulated apps
Class Risk Regulatory requirements
Class I Low Typically, mostly observance of the quality
system and repor ting of adverse events.
Class II Medium The class I re quirements plus often an
obligation to seek FDA clearance before
marketing. FDA clearance involves showing
that your product is substantially equivalent to
others in the mark et, and often involves 90 or
more days of FDA review.
Class III High The class I re quirements plus an obligation t o
seek FDA approval before marketing. Approval,
in contrast to clearance, involves showing
fundamentally that the product is saf e and
effective. Often this requires clinical studies
and takes much longer in t erms of FDA review.

mobi health news
Accessories to medical devices (continued...)
So here’s where mobile apps come in. Some of the
mobile apps that are being developed would seem
to fit the accessory category. They are being promoted
with a specific intended use to accompany, and indeed
to accessorize, a recognized medical device. Examples
abound, including apps that are designed to take data
from a blood glucose meter and trend it to help the
person with diabetes better manage their glucose levels.
Some mobile apps are even being used to control the
medical device, for example they might be paired with
a blood pressure cuff. The app is used to inflate the cuff
and then measure the blood pressure.
Now, having suggested that it’s actually pretty simple
to figure this out, unfortunately like many rules, this
can lead to overregulation. There are relatively simple
accessories that do not engender much risk of failure, but
if they are paired with a high risk device, this accessory
can find itself in the same high risk classification. That
has significant practical implications because anytime
the vendor of the accessory wants to make changes,
the vendor will find itself having to jump through extra
hoops at FDA.
As a practical matter, FDA is supposed to avoid that
overregulation by publishing specific classifications for
low risk accessories. The problem is, that process requires
a rather elaborate form of rulemaking, and FDA in the
present environment of budget challenges is not inclined
to create those classifications. A couple of years ago FDA
created a new classification for software accessories that
they called medical device data systems, or MDDS, and
the development of that classification took years. So
instead of pursuing new classifications, to save money,
FDA does not promulgate these accessory classifications
very often and instead favors less formal routes that are
not always available. Unfortunately, as a consequence,
many types of software that play relatively benign
accessory roles get up classified and overregulated.
FDA recognizes the problem, and in the guidance
indicates that they will be developing a separate guidance
providing some general rules designed to minimize the
effect of this up classification. Presumably they will
come up with descriptions for categories of accessories
that they will treat as low risk, notwithstanding the
accessory status. I have to admit, to me that is a Band-
Aid approach because by law the agency is supposed to
adopt classifications and it’s very awkward to do all of
this by guidance. But, so far, no one has offered to make
me King so I can’t just tell FDA what to do. Being King
really would be handy though.
As a consequence of all of that, FDA is trying to
articulate at least a general definition for when it
believes that a mobile app will accessorize a medical
device, while avoiding the use of the term accessory.
It’s funny how politics and budget issues can cause
an agency to behave in such a way.
In the mobile medical app guidance, FDA declares
that it will regulate apps that are an “extension” of a
medical device. To be an extension, the app must be
connected to the medical device, and must do one of
two things:
1. Control the medical device or
2. Display, store, analyze or transmit patient
specific medical device data.
To my simple way of thinking, these two
subcategories relate to information sent to the
device and information taken from the device.
I assume most people agree that the first category
makes eminent sense. If a medical device is regulated,
and if an app is used to control that medical device,
it surely seems reasonable that FDA would regulate
the app that’s doing the controlling. So if a blood
pressure cuff is regulated, and if an app is controlling
inflation of the cuff and the taking of the blood
pressure reading, FDA should regulate the app. If the
app doesn’t work, the device doesn’t work. Many of
the safety or effectiveness issues associated with the
medical device could potentially be implicated by
the controller of the device. Footnote 23 of the final
guidance says that controlling the device includes
controlling the intended use, function, modes or
energy source of the connected medical device. It’s a
pretty broad category.
Upon reading the second prong of the accessory
category, that is apps that “display, store, analyze or
transmit patient specific medical device data,” in a
burst of excitement the reader might say: hey that’s
a medical device data system. But that reader would
be wrong. Sorry.
To be sure, medical device data systems are included
within the scope of that section, but the new
language goes much further. A medical device data
system is a piece of software that displays, stores,
converts (through limited preset parameters) or
transmits patient specific medical device data.

mobi health news
Accessories to Medical Devices (continued...)
One of the key differences between those two categories is “analysis.” MDDS
software cannot analyze data. If a piece of software analyzes data, it does
not qualify for MDDS class I treatment. Software that analyzes the data from
the medical device is considered much higher risk than merely the much
dumber functions of just moving data around. FDA considers analysis to be
an inherently riskier activity, and therefore is much more likely to classify
software which analyzes medical device data into the same class as the
medical device that generated the data.
In this section, FDA does not define what “analyzing” means. Later in the
guidance, in the enforcement discretion bucket, apps that “trend” blood
pressure measurements and share that data with healthcare providers are
subject to enforcement discretion. Therefore, I would gather that analyzing
means something more than merely trending. But where exactly does FDA
draw the line between relatively benign analysis like trending and more
rigorous analysis that would be subject to FDA regulation?
I would note, too, that there is a big difference between the displaying
of data permitted in MDDS and the displaying of data that might cause a
mobile app to be an accessory to a medical device. MDDS software may only
display data in its original form from the medical device. So if, for example,
a blood glucose meter produces data on blood glucose values and time,
MDDS may only present that data as ordered pairs. The software may not, for
example, produce a linear graph. FDA believes that a linear graph is actually
an interpretation of the data, suggesting a linear relationship between data
points.
My point is simply this: The scope of this accessory category is broader than
MDDS. A mobile medical app that functions as MDDS is certainly regulated,
but so too is an app that interprets medical device data by analyzing it
or even just displaying it in a different format than was generated by the
medical device.
Freestanding medical device apps
Some of the more innovative and frankly cool medical apps are those which
don’t simply connect to an existing medical device, but transform a mobile
phone into a medical device itself. So what does FDA include in this category?
Apps can do a whole lot more than simply supplement another, otherwise
independent medical device. Apps can be so sophisticated, and the range of
potential accessories to the mobile phone so diverse and so powerful, that it’s
actually easy to turn a mobile phone into a medical device. Typically this is
done in one of three ways.
First, you can use the phone’s built-in functionality like the accelerometer,
microphone or camera that comes almost standard with a smart phone to
make a device. Just about any of those built-in sensors can be turned into
some sort of medical device. For example, an app can make use of the built-in
microphone to turn the mobile phone into
an electronic stethoscope. With this app,
just put the microphone up to your chest
and listen to your heart beat. Or, use the
camera to read a urinalysis test strip, and
you can turn the phone into a urinalysis
instrument. This category includes the
rather substantial category of apps that
allow the display of radiological images.
Mobile phones and tablets have become
quite popular in serving as a class II picture
archiving and communication system, or
so-called PACS. In this way, these mobile
phone systems replace common viewers
that physicians used to use for displaying
these radiological images.
Second, you can connect the mobile phone
to a common attachment of some sort, like
a general-purpose heart rate monitor, and
with a special app turn the phone into a
medical device used to monitor the heart
for diagnostic or therapeutic purposes.
This is a combination of technology with
medical device-type promotional claims of
the kind discussed in the chapter 1.
And third, you can connect a mobile
phone to specialized attachments such
as a blood glucose strip reader and turn
the mobile phone into a blood glucose
meter. This is an area that would seem
ripe for future growth as more and more
specialized attachments are created that
take advantage of the computing power
and sophistication of modern smartphones.
In Appendix C to FDA’s mobile medical app
guidance, on pages 26 through 27, FDA lists
almost a dozen different kinds of medical
devices that you could create either using
the internal sensors or simple attachments.
In analyzing these possible scenarios,
FDA offers up the basic standard already
discussed: does the resulting configuration
of software and hardware serve the same
function as a traditional medical device
previously regulated? If it does, FDA
regulates the app.

mobi health news
Clinical decision support software, but called something else
Here’s another section of the guidance that does not come across as clearly as it
could because of politics. FDA has publicly promised they will examine the issue
of clinical decision support software through a separate public process, and indeed
consult with FCC and ONC on this topic as a part drafting the FDASIA report due
in January 2014. I will talk more about that later, but my point here is the agency
doesn’t want to get ahead of that process by defining clinical decision support in
this mobile medical app guidance document.
However, here’s the conundrum. FDA really can’t define the universe of mobile
medical apps without talking about one of the key categories, clinical decision
support software. So they go ahead and describe it, but don’t use the proper name.
Just between you and me, we both know that it is clinical decision support software,
or CDS.
In defining this third category, FDA says they regulate apps that:
1. Perform patient specific analysis and
2. Provide patient specific diagnosis or treatment recommendations
That should be a dead giveaway that we’re talking about CDS. The definition lines
up very closely with what FDA has used in the past to define CDS.
But after providing a very general definition, FDA provides only a couple of examples
in the guidance itself of apps that the agency intends to regulate. The archetypal
example is computer aided detection software, or CAD. This software, and other
examples like radiation therapy treatment planning and imaging processing
software, do not use any specialized hardware other than the computing power of
the mobile phone or tablet. Nonetheless, in FDA’s views, these types of software
meet the definition of a medical device because they are, and I am paraphrasing,
a contrivance used in the diagnosis or treatment of a disease or other condition.
Even though the topic is given very shallow
treatment in the final mobile medical app
guidance, this category of CDS deserves
more attention and so I dedicate a whole
chapter below. What’s important to
understand is that even though FDA has
not fully defined CDS, they are already,
and in fact have been for quite some time,
regulating the higher risk products in this
category.
Having defined what FDA regulates, it
becomes easier to understand what the
agency doesn’t regulate, principally by
subtracting the regulated apps.
But FDA goes further and gives specific
guidance as to things which in the agency’s
mind do not constitute medical devices.
The list is nowhere near comprehensive,
because there would be an endless list of
apps that do not qualify as medical devices.
But the agency picked a few that perhaps
they have received questions regarding to
use as examples. FDA provides five major
categories of apps they do not regulate.
1. Electronic copies of medical reference
materials
FDA does not regulate electronic copies of
medical reference materials. This would
include such things as electronic medical
dictionaries, electronic medical textbooks,
and Physicians’ Desk Reference materials.
On the one hand you might say, of course
they don’t. But think about how broadly
the statute is written. Does an electronic
textbook meet the device component of
the statute? Well it probably does. Does
it meet the intended use requirement?
Well, in a sense, it is used in the diagnosis
or treatment of disease. A doctor might
consult an electronic textbook in making a
diagnosis. So it is a good thing FDA states
it has no intention of regulating these
articles?
Regulated
mobile
medical apps

mobi health news
Unregulated mobile apps (continued...)
For each of these exclusions I think it’s important to understand why FDA is
excluding them from the medical device category, because often it is not simply
a literal interpretation of the statute. Rather, FDA considers other factors not
expressly stated in the statute. If you understand the reasoning as to why
these five categories are not medical devices, you will be able to make better
judgments about other products.
The reason that electronic medical textbooks are not medical devices is the
generality of the information. Information in a medical reference is not
customized to a particular patient. In that sense, it serves a different function
from CDS or any other software that provides specific information about a
specific patient to aid in a specific decision making process. It’s the generality
that makes these reference materials not medical devices. So any software that
provides truly general – not patient specific – information should not constitute
a medical device.
2. Educational tools
FDA does not regulate educational tools. This category includes, for example,
medical flashcards, medical quiz apps, interactive anatomy diagrams, surgical
training videos and so forth. FDA excludes this category for the same reason
as the medical reference materials – the information is quite general and not
patient specific.
3. Apps that a patient might use to get medical information
FDA does not regulate apps that a patient might use to get medical information.
This is a huge and diverse category. In fact, it probably would be helpful to break
it down into a few major subcategories. As I look at the list of items that the
agency provides as examples, I would group them in the following subcategories.
Educational materials. Here the defining characteristic would be
the generality of the information, much like the category above for
professional reference materials. These are not patient specific, and
these apps simply allow patients to do with they might do using a
search engine – find general information out there relevant to their
interest. Think about all the websites like WebMD and Mayo that
provide general information to patients. Further, think about apps
that help patients learn things like CPR. FDA does not treat these as
medical devices.
Apps that help consumers find medical care. Several of the examples
FDA offers fit into this category, including apps that help patients find
relevant clinical trials and apps that help patients find the closest
medical facilities or emergency care hotlines.
Apps that help consumers shop, for example to compare drug costs.
In explaining the scope of this unregulated category,
FDA emphasizes that it is not meant to include
apps that provide clinical decision support. More
specifically, FDA explains that this category does not
include apps that “facilitate a health professional’s
assessment of a specific patient, replace the judgment
of the health professional or perform any clinical
assessment.” So the hallmark of this category appears
to be again the generality of the information, but also
a focus on assisted shopping. Apparently you can use
an app as a patient to find health professionals and
products, but not to figure out at least specifically why
you might need them.
4. Automate general office functions
FDA does not regulate apps that automate general
office functions. Like the others, this one is probably
obvious because this category does not impact patient
care. These functions do not in any way diagnose or
treat patients, but rather simply provide the office
infrastructure. So any software that limits itself to
these office functions, such as billing and insurance,
accounting, or scheduling, is safely outside of FDA’s
purview.
5. General-purpose products
FDA does not regulate general-purpose products,
and this category is one of the reasons I covered the
intended use concept in such detail in chapter 1. If the
intended use of a product is general enough to include
significant nonmedical uses as well as potentially
medical uses, FDA does not regulate that product. FDA
does not regulate a test tube, just because some uses
of a test tube could be clinical. Likewise, FDA does not
regulate an app used to record diet and exercise, just
because some health professionals might adopt that
app for use with patients with diabetes.
If the developer of the app legitimately keeps the
descriptions of the app to such a high level that
they have both medical and nonmedical uses, and if
those nonmedical uses are material and not fictional
or hypothetical, FDA will not regulate the app. FDA
gives as examples apps that can be used as a generic
magnifying glass, recording audio or notetaking,
a.
b.
c.

mobi health news
email and maps. All of those things
could be used in a medical context, but
have obvious nonmedical uses as well.
Typically the promotion of these products
must remain at a high level of generality,
but under certain circumstances the
developer can explain specific uses so
long as the developer does not raise
any new issues of safety or effectiveness
in providing specific examples. New
issues might be raised, for example, by a
developer promoting a general purpose
magnifying glass as a great way to find
life-threatening melanoma.
Enforcement discretion
Now we get to tackle arguably the hardest
of the three categories – the middle
category – enforcement discretion.
I wish I could say that these are simply
apps that fall within the statutory
definition of a medical device, but FDA
has decided to exempt because they are
low risk. That’s close, but not completely
accurate. There are two inaccuracies in
that statement.
First, not everything in this category
clearly belongs in the statutory definition
of a medical device. While I would agree
that some of them are medical devices,
some of them are not. Basically FDA is
saying, let’s not quibble about the apps
in the definitional gray area; we will just
treat them as subject to enforcement
discretion. Okay, I can live with that.
But second, and arguably more
importantly, FDA is not simply saying that
these devices are exempted from FDA
requirements. Here’s where FDA really
muddies the waters. Instead of a simple
exemption, I believe the following are
all bundled up in FDA’s creation of this
enforcement discretion category.
1. This grant of enforcement discretion is not permanent and unconditional. FDA explicitly
says that they will monitor the situation and periodically reevaluate their position. In other
words, they could decide to regulate these apps in the future.
2. FDA recommends that apps in this category be developed under an FDA compliant quality
system. About now you’re probably thinking, what the hell does that mean? What does
it mean for a federal agency to “recommend” compliance with a set of regulations? More
specifically,
What will happen to us if we do not follow that recommendation? Can we get in
legal trouble if we do not? I would say probably not. I know it’s not completely
reassuring when an attorney inserts the word “probably” in his opinion, but that’s
the best I can do here. As a lawyer, when an agency simply recommends something,
I would say it’s not binding and that means you cannot get into trouble for declining
the recommendation. But the document isn’t especially clear.
Can they come and inspect us? Well I’m not entirely sure what the law would
permit, but as a practical matter I do not think they plan to conduct inspections of
apps developed under enforcement discretion. However, …
a.
b.
3. There are incentives for following the quality system. Actually, I can think of three or four.
As I said above, FDA plans to monitor the situation and may change its view on
enforcement discretion in the future. If FDA gets the sense that companies in this
category are not making use of the quality system (and I’m not offhand sure how
they would know), this could be a reason that FDA would shift to actively regulating
these apps. In other words, industry is being given a chance to do the right thing by
itself without a regulatory requirement, but if industry fails to do with the agency
thinks it should do, a requirement might be in our future. Long-term I’m sure that
FDA would love to collect data to assess whether adoption of a quality system for
mobile apps enhances quality and reduces adverse events, but under the current
scheme I’m honestly not sure how they would collect such data.
Given the risk that FDA might require a quality system in the future, it may be
economically advantageous to employ a quality system now so that you don’t need
to go back and remediate the quality of your app later. It’s a whole lot cheaper to
build it right the first time, than to try to go back and re-create under a quality
system what you’ve already done.
Here’s a bit of a downer. Now that FDA has made this recommendation, if a company
does not adopt a quality system for one of the products in the enforcement
discretion category, and someone does end up getting hurt, I can well imagine a
plaintiff’s lawyer in a product liability suit arguing that the company was negligent
by not employing a quality system recommended by a federal agency. I really don’t
think FDA contemplated that when they made the recommendation.
Actually, data do show that using a quality system improves the quality of your
product, which leads to increased value in the hands of your customers. In other
words, quality is good.
a.
b.
c.
d.

mobi health news
Enforcement discretion (continued...)
4. Although it’s not clearly stated, I believe that products in the enforcement discretion
category will not be subjected to other FDA requirements like adverse event reporting.
At the same time, I know there is a movement afoot among policymakers responsible
for health information technology to devise a better and broader system for collecting
adverse event information associated with any HIT. So perhaps FDA is not requiring these
enforcement discretion apps to comply with the FDA adverse event reporting process, but
at the same time is anticipating that these apps might get swept into whatever new adverse
event reporting mechanism might ultimately be adopted.
As I said, it’s not as simple as a general exemption from FDA regulation. That would be
too easy. As you can probably tell, these ambiguities are brought about by FDA facing the
hardest task for any regulatory agency – letting go. Regulators find it very hard to just
completely exempt out anything. When it’s your job to regulate, deregulating makes you
very nervous. And so this is what we have.
But let’s move on to discussing what exactly is in this enforcement discretion category.
And here I applaud FDA for extending enforcement discretion to some pretty important
categories of apps. There are six subcategories within enforcement discretion, and each of
them has a policy basis for existing.
1. Patient self-management
Mobile apps subject to enforcement
Regulated
mobile
medical apps
There has been quite a bit of social science research into
what motivates people to take better care of themselves.
Now much of that research is finding expression in mobile
apps. That’s the beauty of a technology that follows us
all day long, to work, to play and at home. Many people
even reportedly sleep with their mobile phones. So
this mobile technology becomes an ideal platform for
helping us change our habits, our lifestyles. Through
creating messages our mobile phones can prompt us to
do certain things like exercise or take our medicine, offer
us encouragement to do things like stop smoking and
lecture us on the consequences of eating that third éclair.
Actually, it sounds kind of annoying to me, but some people
apparently like it.
One of the keys to understanding this category is to
recognize that the app must stop short of “providing
specific treatment or treatment suggestions.” Unfortunately,
the guidance provides no explanation beyond that. But
there does seem to be a distinction between coaching
and reminding on the one hand, and diagnosis and
treatment on the other. Presumably an app that allows
the consumer to enter a list of symptoms and be told
that she has a migraine is outside of simple coaching and
reminding. However, I imagine a gray area where an app
wants to amplify its message by not just reminding me, but
cautioning me that my behavior might lead to a certain
disease such as hypertension.

mobi health news
2. Patient trackers
We need data to make decisions, so I truly
believe that apps that allow us to collect
data on ourselves during the day allow us
to make much more effective decisions
about future behavior. For example, people
who carefully manage their budgets,
keeping track of all of their expenses, often
seem to make better purchasing decisions
down the road. Likewise, people who track
what they eat, how much exercise they get,
how much sleep they get and so forth can
make better decisions down the road.
But this goes beyond simple lifestyle
decisions. People who track their blood
pressure, weight, drug intake times, stress
and other factors can do a better job
both in making their own general health
decisions, but also in communicating more
accurately with their doctors.
As always, there is a limit to this category.
In this particular case, FDA wants to
make sure that such apps don’t drift into
“providing recommendations to alter
or change your previously prescribed
treatment or therapy.” So this category
involves mostly passive data collection,
and presumably display in useful formats
like graphing and trending. But what these
apps should not do is take a step further
and recommend changes to therapy.
This limitation is somewhat difficult to
manage because it’s hard to know whether a
given patient would be following a doctor’s
treatment plan. The limitation seems to
turn on something that the developer not
only doesn’t control but doesn’t even know:
whether the patient has received specific
advice from a doctor. I suppose one way
to address this is to constantly inform the
patient through reminders that they should
always follow the doctor’s orders over the
software. A more conservative route would
be to not make recommendations at all,
but that would seem overly conservative.
This is an ambiguity that will need to be
worked out as we go forward.
3. Access to contextually relevant information
Hopefully you remember that one of the categories of nonmedical devices discussed
above was those apps used for accessing general information such as the kind provided by
WebMD. or the Mayo Clinic. There also was a similar category for professional information
that exempted such things as providing electronic copies of medical reference books.
This subcategory in the enforcement discretion category is different, indeed, closer to the
border, in that this category is focused on apps that allow a patient or a doctor to get more
focused, more specific information relevant to the health needs of a particular patient. This
subcategory starts to butt up against what FDA would call CDS, because it begins to be
more specialized, less general.
FDA defines this category as an app that allows the user to find “contextually-relevant
information … by matching patient-specific information … to reference information
routinely used in clinical practice … to facilitate a user’s assessment of a specific patient.”
That’s really complicated, and FDA actually spends very little time explaining it. Again, this
is because of politics. This particular category is an element of CDS, and as FDA has said, it’s
keeping its powder dry with regard to CDS for the moment while it works with the other
federal agencies – ONC and FCC. So instead they lay out the basic framework, but then don’t
explain it. That’s a pity.
I will try to tease this definition apart somewhat because it is very important. For simplicity,
I deleted portions of the sentence to make it more understandable, but let’s go back and fill
in some of the details I omitted.
First, patient specific information apparently means “diagnosis, treatments, allergies, signs
or symptoms.” That’s pretty broad, and indeed those are only examples and not meant to
limit the scope of patient specific information. So apparently we’re talking about nearly any
type of medical information that is specific to a given patient.
Second, reference information routinely used in clinical practice apparently means such
things as practice guidelines.
So we start to see what FDA intends to include in this category. They would include an
app that takes that patient specific information, and through algorithms, identifies specific
relevant medical guidelines that the doctor or patient should consult. So these apps are
more tailored and in a sense more valuable than an app that simply allows you to pull
up specific reference material that you probably already have read. This app specializes
in making the association between the patient information and the clinical guidelines.
Indeed, one of the two examples FDA provides is an app that uses a patient’s diagnosis
to provide a clinician with best practice treatment guidelines for common illnesses like
influenza.
This is significant, and welcomed. There is a movement in healthcare to help doctors by
pulling up relevant clinical guidelines to ensure that the doctors can employ best practices
at the point of their decision-making. This has tremendous implications for improving the
quality of healthcare, and I must congratulate FDA for wanting to encourage this trend.

mobi health news
4. Patient communication and telemedicine
For various reasons not the least of which is
reimbursement, communication with doctors has been
largely stuck in the dark ages. But that is starting to
change, and FDA clearly does not want to stand in the
way of that change.
Telemedicine is evolving into a much broader concept
than it was 20 years ago. In the old days it was primarily
focused on simply helping people in rural areas get access
to specialists hundreds of miles away. It also emphasized
peer-to-peer collaboration over geographical differences.
Now telemedicine means use of different models for
physician patient encounters, where patients don’t need
to be physically present with their physician for many
routine matters.
FDA’s posture is designed to facilitate this larger use
of telemedicine that ultimately will improve care by
encouraging more consultations with doctors. This, in
turn, will increase patient compliance and enhance
early and preventative care in particular, while perhaps
simultaneously reducing the cost of care overall by
making the encounters more efficient.
In this area, there have been some nagging regulatory
questions about the use of some very basic technology
such as cameras, for example, to allow for remote viewing
by a doctor of skin lesions or wounds, and for video to
help a doctor in an overall assessment of the patient.
Claims that technology could be used in this manner ran
a substantial risk of making the technologies subject to
FDA requirements.
In this new position, FDA seems to be liberating much
of this technology from active FDA regulation. FDA
seems to be saying that so long as these technologies
are simply used in general communication, albeit in a
medical context, that the agency will consider them to be
in enforcement discretion.
There is, however, an important limitation to this. FDA expressly says that
the promotional materials for these technologies cannot promote the
technologies for a medical use. I really wish FDA had been clearer here. On
the one hand, isn’t promoting a camera or video capability for use in a medical
encounter a “medical use”? I’m afraid we have to do a fair amount of reading
between the lines here.
I would say that claims of specific utility to clinical conditions may make the
product regulated. Maybe an example would help explain the difference.
With this app, a patient can use the camera
on her mobile phone t o take pictures of her
skin to share with her dermat ologist as par t
of a virtual examination, thereby making
health care more convenient for the patient .
Enforcement
discretion
With this app, a patient can use the camera
on her mobile phone t o take pictures of her
skin to share with her dermat ologist, so that
her dermotologist can assess any lesions for
possible melanoma.
FDA regulated
The difference is that the second of those two claims draws a specific
connection between the use of the camera and a specific outcome, appropriate
diagnosis of possible melanoma. I think FDA is saying, apropos to our
discussion of intended uses above, that they will allow general telemedicine
claims, e.g. the use of technology in communicating in a medical context, but
that specific clinical claims will still trigger FDA regulation. This is another
area where we will have to watch to see how FDA interprets this category
over time.
Over time, we will also need to sort out how this enforcement discretion
category butts up against the MDDS category. One of the new areas for apps
is using the camera function basically is a scanner to capture medical device
data and transmit it to physicians. Obviously of a general purpose smartphone
is used for this, there is no issue because the smart phone has a very general
intended use. But let’s say a developer creates a specific app that makes use
of the camera to transmit medical device data as a part of a system especially
designed for that purpose. Does this enforcement discretion category create a
loophole in the MDDS classification?

mobi health news
5. Simple, professional calculators
In defining the scope of calculators that FDA will treat under
the enforcement discretion category, FDA repeatedly uses the
word “simple”. I have to admit, while I understand the logic
and the intent, I think the use of the word “simple” is a bit
too subjective. What might seem simple to you might seem
extremely complex to me.
FDA does try to define the term with respect to two objective
criteria. Specifically, FDA says that an app is simple if it is (1)
taught in medical schools and (2) routinely used in clinical
practice. Okay, that helps some.
At their heart, these calculators are like any other calculators
used in math and science. While they are expressed in the
clinical context, the heart of the technology is the execution of
a mathematical formula. So the intent of these apps is merely
to help the user avoid a mathematical mistake. These do not
really bring any additional intelligence to the clinical decision-making
process other than the avoidance of math errors.
When I talk to people about this, it seems the most effective
explanation FDA provided is the numerous examples that
illustrate what they intend to include. The examples are:
• Body mass index
• Total body water/urea volume of distribution
• Mean arterial pressure
• Glascow coma scale score
• APGAR score
• NIH stroke scale
• Delivery date estimator
Most people, by the time we get to the examples, feel like
they understand at least generally what FDA intends. But, if
you have a calculator that is on the bubble, you can always
consult FDA through their email system especially set up for
this enforcement discretion category.
6. Connections to EHRs
The federal government has spent billions of dollars over
the last few years trying to encourage healthcare providers
to make meaningful use of electronic health records. The last
thing FDA wants to do is stand in the way of that progress.
The benefits of greater adoption of electronic health records
are so substantial that imposing FDA regulation as an obstacle
to that enhanced use would be a bad policy choice. FDA
recognizes that.
So while FDA has repeatedly said that it is presently putting electronic
health records in the enforcement discretion category, now they have
expanded that to software apps used to access the information in the
EHR. That’s a logical extension.
At the same time, FDA seems pretty clear that they are limiting this
enforcement discretion to apps which “allow individuals to view
or download EHR data.” That’s a pretty passive use. It should not be
confused, for example, for an app that analyzes the data. As I have
said before, display and analysis are fundamentally different and
have fundamentally different risk profiles. So this extension of the
enforcement discretion must be understood to apply to those apps that
engage in passive display without analysis.
Summary of the enforcement discretion category
At an even higher level, several of those enforcement discretion
categories involved in patient empowerment. There is widespread
recognition across the federal government that one of the best ways
to really help improve the health of Americans is to empower them to
do a better job of managing their own health. We face epidemics of
chronic disease, and we need to find a new model that will be more
effective in stemming those epidemics. Patient empowerment seems to
offer great promise, and the FDA does not want to stand in the way of
this movement.
At that same high level, the first, third and fifth categories are all flavors
of CDS. The fact that all three of these categories are in enforcement
discretion reveals an intent at FDA to tread lightly in this broad category.
This is good news indeed.
Resolving the ambiguities
FDA recognizes that it is hard to be very precise and comprehensive
in its explanation of what is included in this enforcement discretion
category in a static guidance. Innovators will continue to come up with
new ideas for how to create apps that add value in ways that we haven’t
previously contemplated. So to its credit, FDA has not only included
a liberal number of examples throughout the guidance document,
but also created a mechanism for innovators to get hopefully timely
feedback on whether new apps fall within or without the enforcement
discretion category.
Specifically, FDA has mechanism for contacting the agency via email
or by phone to discuss new ideas for apps and how they might be
categorized. To ensure a level playing field and transparency, the agency
has also indicated that it will continuously update a webpage with
new examples of apps that are placed in this enforcement discretion
category.

mobi health news
Resolving the Ambiguities (continued...) 2. Hardware
This is a useful and fair way to handle this
issue, but companies need to understand
the open public nature of this process. If
you have some clever new idea for an app
and you consult FDA and they give you a
decision on whether it’s in the enforcement
discretion category are not, that app may be
summarized on their webpage. Thus it creates
an interesting dilemma regarding the optimal
timing of consulting the agency. If you consult
them very early you can potentially save
yourself a lot of time and hassle depending on
the answer. But you may also be telegraphing
to your competitors a potentially clever idea
for a new app.
There is an opportunity for a more private
assessment. FDA has a process called a
513(g) submission where you can get a
concrete answer to your question privately.
Unfortunately, it takes FDA typically 60 days
and even more to respond to such a request.
From the FDA’s vantage point, they obviously
want to keep the playing field as level as
possible by treating everyone in the same and
by sharing important information about how
they are applying the rules.
Questions left open
I don’t think anyone expected the final mobile
medical app guidance to answer every question
related to mobile health. In part that’s because
the questions are constantly changing, but it’s
also because FDA did not try to answer every
question in this one document. Even so, I
thought it might be useful here to summarize
some of the larger open questions that remain
to be addressed.
1. Clinical Decision Support Software
I have noted throughout the course of this
chapter that one of the big open questions,
by design, is the scope of FDA regulation of
clinical decision support software. And indeed,
I think it’s such a big topic that I have written
an entire chapter below on it.
FDA was very clear in the scope of this guidance document that it was focusing on
the apps. But obviously many people are interested in the hardware associated with
mobile health. So I dedicated the next chapter on this topic.
3. Wellness versus disease
In chapter 1 on intended use, I explained that the statute focuses on disease, and
does not regulate intended use claims that relate to wellness. I further explained
that this is a terribly important issue for mHealth, because a huge number of apps
relate to wellness rather than health. But alas, the dividing line between wellness
and disease is not a clear one. So much so, that FDA has announced plans to develop
a separate guidance on this topic.
Fortunately, while we wait for FDA to develop its new guidance on wellness versus
disease, the final mobile medical app guidance did provide some insight into this
topic. The insight isn’t found in the explanations of what FDA regulates, but rather in
the appendices where FDA provides examples. FDA has an entire section on examples
of wellness related apps that would not be regulated.
Those examples focus on one particular functionality associated with wellness, that
is tracking important information to help people maintain healthier lives. According
to appendix B which lists the apps found in the enforcement discretion category,
tracking the following information renders an app in the enforcement discretion
category:
Provide tools to promote or encourage healthy eating, exercise,
weight loss or other activities generally related to a healthy lifestyle
or wellness;
Provide dietary logs, calorie counters or make dietary suggestions;
Provide meal planners and recipes;
Track general daily activities or make exercise or posture suggestions;
Track a normal baby’s sleeping and feeding habits;
Actively monitor and trend exercise activity;
Help healthy people track the quantity or quality of their normal
sleep patterns;
Provide and track scores from mind-challenging games or generic
“brain age” tests;
Provide daily motivational tips (e.g., via text or other types of
messaging) to reduce stress and promote a positive mental outlook;
Use social gaming to encourage healthy lifestyle habits;
Calculate calories burned in a workout.
•
•
•
•
•
•
•
•
•
•
•
Well, that’s a start. But it’s important to recognize that the functionality permitted in
enforcement discretion is simply tracking; appendix B says nothing about analysis or
making recommendations for how to live a healthier life. So there is much work to be
done in getting FDA clarification.

mobi health news
Questions left open (continued...)
4. The interplay between the new guidance and old
regulations like MDDS
Most people know how to play the game rock, paper, scissors.
The game works and is understandable because there
are clear rules about what beats what: rock beats scissors,
scissors beats paper, and paper beats rock. If we didn’t have
those rules, the game wouldn’t make any sense.
I’m afraid FDA’s use of guidance to address these issues of
mobile health has created a bit of a conundrum with regard
to interpreting these rules. In law school, they teach you that
the Constitution is supreme, below that are congressional
statutes, below those are agency regulations, and at the
bottom of the heap is agency guidance which is purely
educational in nature. The problem is that FDA seems to
be using guidance in effect to overrule regulations. I’m not
going to complain because I like the outcome. So please don’t
tell this to FDA, but the guidance can’t be used to overrule a
regulation.
At a practical level this insistence on using the easier to
create guidance in preference over the more difficult to
create regulations means that we have a bit of a challenge
in interpreting the law. For example, medication reminders
which are identified by a specific product code – NXQ – and
covered by a specific regulation found at 21 CFR 890.5050
are now placed in enforcement discretion, contrary to the
regulation. I love what FDA is trying to do, but just wish
they would update the regulations. Trying to accomplish this
through guidance is really not the right way to do it.
At least in that example the FDA intent to overrule the
regulation is clear. So in that sense, it’s unambiguous,
although a court would certainly have trouble figuring out
which to follow. But on a deeper level I’m concerned that FDA
is effectively updating a lot of different regulations without
being nearly so clear. For example, I’m concerned that not all
of the guidance is consistent with the MDDS regulation. The
MDDS regulation indicates that trending would fall outside
of MDDS and would be considered a higher risk feature,
potentially class II. However the guidance (enforcement
discretion, category #2) indicates that trending would be
subject to enforcement discretion. How do we reconcile these
two approaches? More generally, where the FDA’s intent to
overrule a regulation is not clear, FDA’s strategy makes it
particularly difficult to put your faith merely in the guidance
over the regulation.
5. Drawing the line between software modules, regulated versus
unregulated
Sophisticated software often consists of independent modules that
function separately and as part of overall software programs. In
fact, the Federal Aviation Administration (FAA) currently approves
reusable software modules or reusable software components (RSC),
allowing for reuse of a GPS software module, for example. The FAA
has used this approach in all types of aviation systems, including
those in the highest risk classification. According to the FAA, if
properly planned and packaged, software life cycle data (including
software code) can be reused from one project to the next, with
minimal rework.
Mobile applications similarly are made up of distinct modules from
a variety of sources, but FDA does not have a policy of allowing easy
mixing and matching of modules, some regulated and some not.
The European Commission recently distinguished between modules
that have a medical purpose and those that do not and acknowledged
that non-medical device modules are not subject to the medical
devices requirements. The guidance requires the manufacturer to
identify the boundaries between the medical and non-medical use
modules based on the module’s intended use.
In contrast, the FDA regulates medical device software programs
or apps as a single product. It views software as one system and
applies the highest applicable regulatory classification to all
modules included in software.
The current regulatory approach does not stratify functionality
within a software app based on the risk associated with specific
functional modules. This creates a significant regulatory burden and
restricts the use of reusable modules in innovative software designs.
For example, an app could include a module to facilitate the
download of information from a medical device (e.g. blood pressure
cuff or blood glucose monitor). The app could also include a module
to generate graphical reports to show the data received over time
and a database module to store the information. The app could also
incorporate a calendar module, allowing the user to add reminders
for appointments, when tests were taken, etc. From a software design
perspective, the modules can be designed with logical separation to
compartmentalize risks within each module; only communication
linkages are exposed to the other modules. The design establishes
confidence that the risks are mitigated for information shared
between modules.

mobi health news
Questions left open (continued...)
Under the current regulatory framework, if one of the modules in the
example of the blood glucose app is classified as Class II, the other
modules such as the calendar might also be classified as Class II. In
my opinion, that’s overkill. It means that any time the developer of that
calendar module wants to update it, for example to make it work with
Facebook, they may need to get FDA clearance.
I am hopeful that this is an issue that FDA will tackle in the future.
Conclusion
I’d like to go back to where I started with this category. Fundamentally,
it’s pretty simple. FDA regulates mobile apps that do the same thing
as medical devices the agency has always regulated. Ever since the
1976 Medical Device Amendments, FDA has regulated blood-pressure
cuffs, EEG machines, urinalysis equipment, and devices for viewing
radiological images. Now that all of those things can be done on a
mobile phone or tablet, FDA regulates the software used to accomplish
those functions.
To be sure, there are some new functionalities – capabilities that have
never existed before. The scope of FDA regulation with regard to those
new capabilities will be discerned by applying the basic statutory
principles to determine whether the article involves an intended use
of the kind described in the statute. But in addition to the analysis,
developers may wish to confirm their assessments using the FDA’s new
dynamic guidance approach. I for one intend to watch the FDA webpage
closely to see what new apps the agency puts in the enforcement
discretion category.

mobi health news
III. What about Hardware?
The scope of the final mobile medical app guidance
is exactly that: mobile medical apps. The guidance
was never intended to address hardware. Perhaps
someday FDA will put out a guidance on hardware,
but I wouldn’t count on it anytime soon. So we need
to make the best of what we have.
Fortunately, the guidance does give us several clues
as to how FDA approaches hardware. I’d like to break
this discussion down into two general categories
(1) mobile phones and other mobile devices and
(2) accessories that might connect with the mobile
phones.
Mobile phones and other mobile devices
After having just said that FDA does not address
hardware in its guidance, there is a single sentence
that is very important. On page 8 of the guidance,
FDA explains: “Under this guidance, FDA would not
regulate the sale or general/conventional consumer
use of smartphones or tablets.” That’s an extremely
important statement by FDA, but not to be a party
pooper, I need to explain what that statement actually
means, including its limits. That statement means FDA
will not regulate mobile phones, usually. Don’t you
just hate that word “usually.” Broadly speaking, there
are three circumstances when FDA would regulate a
mobile phone.
1. Medical device claims
Recall in chapter 1 where I explained that whether
something constitutes a medical device turns
principally on its intended use. Remember also
that I explained that nearly anything, including a
popsicle stick or my shoe for that matter, can become
a medical device if the seller promotes it for use,
loosely speaking, in the diagnosis, cure, mitigation or
treatment of disease or other conditions.
In its statement regarding mobile phones, FDA is saying that merely having an
intended use to host a mobile medical app will not make the mobile phone
an FDA regulated medical device, at least in the hands of the mobile phone
seller. That’s a useful statement. Getting that clarity really helps mobile phone
manufacturers.
But that is not an unqualified statement that a mobile phone will never be a
medical device. If the mobile phone manufacturer decides to promote its mobile
phones somehow directly for use in diagnosing or treating disease, the mobile
phone company may cross the line into regulated territory. FDA just said that the
mere use by customers with mobile medical apps does not transform the phone
into a medical device as sold by its manufacturer.
Intended use is incredibly important to understand for this chapter on hardware.
In particular, I would direct you to the end of chapter 1 where I discuss the
different types of intended uses. One of the areas where mobile phone
manufacturers could run amok and find themselves regulated is if they depart
from the general intended uses of communicating and computing power, and
dive too deeply and too specifically into medical applications. Even if the mobile
phone has no particular features that are uniquely medical, if the mobile phone
manufacturer through its promotion makes claims about the utility of its mobile
phone as somehow especially well-suited for some medical purpose, it could
cross the line into regulated territory. The mobile phone manufacturers need
to remember to keep their claims general, encompassing a wide variety of uses
both medical and nonmedical.
2. Design features
It isn’t just marketing claims that might get a mobile phone manufacturer
into regulated territory. Design decisions could also cause a phone to become
regulated. I’ll offer a few possibilities here.
First, it’s possible that a mobile phone manufacturer, wanting to pursue a
business strategy of excluding competitors from certain software products,
would design both a mobile app and a mobile phone handset to be intertwined
in a proprietary way. If a mobile medical app is basically designed to work with
only one phone, the associated integration might indicate that the phone and
the app are inseparable and therefore the mobile phone too would be regulated.
Second, right now mobile phones come with certain typical hardware built-in
such as a camera, a microphone and an accelerometer. But let’s say a mobile
phone manufacturer became enamored of the medical market and started to add
certain accessories that really only had a medical purpose. That would cause the
handset to become itself a regulated medical device.

mobi health news
III. What about Hardware? (continued...)
Mobile phones and other mobile devices (continued...)
Third, it’s possible that either hardware or the operating system would be
designed in such a way so as to meet specialized medical standards. The
features of the mobile phone added to comply with those special medical
device standards evidence at least some intent for the product to be used as
a medical device specifically. There isn’t a theory by which you look at all the
different functionalities of a mobile phone and the majority rule. If you add a
single medical device functionality to a mobile phone that single functionality
gets regulated. That said, I’m hoping that someday FDA issues guidance to
the effect that merely complying with certain medical standards does not
cause a product to be regulated. I think FDA should take that direction under
enforcement discretion, but FDA has not clearly stated it yet.
Fourth, consider what would happen if a mobile phone manufacturer promotes
its phones for use in the diagnosis or treatment of disease because they
contain certain hardware or software features that make the phones especially
suitable for hosting certain kinds of mobile medical apps. They might get away
with that without making the phone a medical device, but it’s not clear. On
the one hand, they are specifically claiming some sort of special compatibility
with medical apps, but on the other hand it still fairly general claim. I could
see FDA looking the other way under enforcement discretion but they haven’t
said that yet.
These are just a few of the examples of scenarios where the mobile phone
could indeed be regulated through design choices. The bottom line is, if you
give the mobile phone a uniquely medical function, even if it retains all of its
other functionality, you have arguably made the phone into a medical device.
3. Mobile phone as component
In the previous two discussions, I’ve talked about whether the mobile phone
might be a medical device as it leaves the hands of the manufacturer. But
there is an additional question: Is the mobile phone considered a component
of a medical device in the hands of the customer?
In its guidance, FDA says: “When mobile medical apps are run on a mobile
platform, the mobile platform is treated as a component of the mobile
medical app’s intended use.” I am really not even sure what that says, but if it
suggests that the phone is a component, I disagree. Of course you need to also
understand that I don’t make the rules, but that is my opinion for what it’s worth.
Something can only be a component when it is added to other components to
ultimately produce a finished medical device in the hands of a manufacturer.
When a customer joins two articles, that is not manufacturing and it doesn’t
make either article into a component. Typically when a customer joins two
things, that’s the definition of an accessory, but FDA’s conundrum is that calling
the phone an accessory would mean that the phone was regulated at the time
it left the mobile phone manufacturer’s hands. FDA obviously doesn’t want to
call a mobile phone a medical device when it leaves the manufacturer’s hands
(and I agree that it’s not an accessory). But at the same time, FDA seems to
really want to call the phone regulated in the hands of the customer. So they
misuse of the term component and call the phone a component.
In my analysis (and I feel pretty comfortable with
this), the mobile medical app would be a medical
device and the mobile phone on which it operates
would simply be part of the environment in which the
medical device operates. As such, the mobile medical
app manufacturer is obligated to make sure that its app
will operate in the environments which it recommends
or that can reasonably be anticipated. In this case, that
environment would be a combination of hardware
and software (for example, the operating system).
The app manufacturer needs to test and validate the
app as working in the recommended and anticipated
environments.
I’m not sure that my disagreement with FDA matters
very much, because the agency concedes that: “the
mobile platform manufacturer is exempt from the
Quality System regulation and registration and listing
requirements.” But it still concerns me that for some
reason FDA feels inclined to call the mobile phone and
the operating system “components” of a medical device.
Attachments to mobile phones
What do we know about the regulatory status of the
stuff that plugs into the phone? Unfortunately, the
final MMA guidance does not provide much insight into
when and how attachments might be regulated. FDA
declared such issues to be out of scope for this guidance
document. In speeches, FDA has explained that they are
developing a separate guidance document to cover
these accessories, but that could take some time. So I
will have to draw upon other guidance documents and
regulatory pronouncements to see what we can learn.
I’d like to start this part of the analysis by discussing
a bit deeper the statutory difference between an
accessory and a component.
In the area of mobile health technology, it’s important
to understand that both an accessory and a component
of a medical device are themselves regulated medical
devices. Further, the difference between an accessory
and a component is who buys it. End-users buy
accessories, while manufacturers buy components.
Thus the exact same piece of equipment could be
either an accessory or a component depending on the
target purchaser.

mobi health news
Attachments to mobile phones (continued...)
Deciding whether something is an accessory
or a component makes a big difference in
terms of applicable regulatory requirements.
Components are exempt from most FDA
regulatory requirements, with the regulatory
burdens being borne by the finished device
manufacturer. Accessories, on the other hand,
since they go right to the end user, must meet
the FDA requirements before they leave the
hands of the accessory manufacturer. These
differences are summarized in the figure
below.
The level of regulation imposed by FDA on
an accessory or component is determined by
the parent device to which it relates. So if the
accessory relates to a high risk device, say an
implantable cardiac defibrillator, it will be
subject to a high level of regulation even if
the accessory is relatively benign in and of
itself.
This approach would seem to regulate
accessories once removed, twice removed—
indeed, the whole family tree – at the same
level as the “parent” device. The agency’s
theory is simply: if an accessory breaks, the
risk to the patient would be the same as if
the parent medical device broke.
Let’s take as an example: headphones.
Headphones obviously have a very generic
use, listening to sound from a player of
some sort. But let’s say that headphones are
specifically promoted to be used together
with a mobile medical app. Let’s say the
mobile medical app uses sounds as therapy for
treating individuals with disorders including
autism. In the face of specific promotion of
the headphones for that medical use, the
headphones would be regulated to the same
level as the underlying app.
With that as general background on accessory
regulation, let’s analyze the potential range of
hardware that can attach to a mobile phone,
and look at what the likely regulatory status
of those attachments will be. I have come
up with at least three different categories of
attachments.
1. Attachments with specific medical functionality.
There is a growing market of specialized medical attachments that can plug into a
phone that to make it function as a medical device. We discussed these accessories
in chapter 2 in relation to the associated apps, but here we focus on the hardware.
Examples would be attachments like a blood glucose strip reader or ECG electrodes.
Based on the description of this category, I hope by now you can guess that these
devices will be regulated. That should be pretty obvious.
I would predict that some of the medical attachments will fall into the MDDS category
because they will be used in the display, transfer or storage of medical device data. Most
people think of MDDS as software, but the classification also covers hardware. In the
FDA system, such devices are class I, exempt from premarket notification but subject to
the quality system requirements.
Falling outside the MDDS classification has two potentially opposite consequences. On
the one hand, falling outside might mean that the product is not regulated by FDA
at all. Perhaps it’s because the accessory is a generic accessory of the type described
in the next section. On the other hand, falling outside the MDDS classification might
mean that the product is a class II or III medical device, a very different outcome. This
would be because, for example, the accessory provides functionality beyond merely
transmitting, displaying or storing medical device data.
Figure 1. Types of devices
Element
of device
definition
Finished stand
alone parent
device
Accessory Component
Definition
A medical device
in finished form,
ready to use
perhaps with
accessories,
intended for sale
to the end user
An article intended
for use in or with
a finished medical
device, intended for
use by the end user
An article intended
for use in or with
a finished medical
device, intended
for use by a
manufacturer
FDA clearance
required?
Yes, unless exept
from clearance
Yes, unless exempt
from clearance
No
GMPs
required?
Yes, unless
exempt from
GMPs
Yes, unless exempt
from GMPs
No, but quality
must be assured t o
the satisfaction of
the finished device
manufacturer

mobi health news
2. Generic accessories.
By now you’re probably getting pretty sick of me
talking about the difference between general versus
a specific intended uses. But that concept is important
to the hardware that attaches to a phone. If I attach a
general-purpose, supplemental display unit, FDA does
not regulate the attachment so long as I only make
those general claims. If I claim that the display unit is
especially suited, for example, because of resolution or
some other feature to show ultrasound images, I have
just made it into a medical device.
In the preceding section, I discussed the likelihood that
certain accessories would qualify as MDDS because they
would be intended for use in the storage, transfer or
display of medical device data. But if you think about it,
if I sell a common cable perhaps with a USB connector
on one end and an Apple Lightning connector on the
other, and I just say it’s for connecting stuff to your
iPhone, that cable will not be MDDS because I have not
claimed any specific medical function. So it’s possible
that by staying at a high enough level of generality
many accessories can escape regulation altogether.
3. Wellness sensors like heart rate and weight scales
For decades, FDA has permitted electronics companies
to produce and sell various kinds of sensors used by
people to manage their health and wellness. Examples
include a common bathroom scale, heart rate monitor
used by athletes during training, and an activity or sleep
tracker. These sensors are easily and cheaply available
through retailers.
Let’s say a mobile medical app developer sells an app
that requires the customer to go out and buy one of
these sensors and use it in tandem with the app. By
definition, because I use the term mobile medical app,
I’m referring to the variety of apps that FDA regulates,
so it must have an intended use in the cure, mitigation,
treatment or diagnosis of disease or other conditions
(loosely stated).
If the app maker does that unilaterally with no
involvement of the sensor manufacturer, the intended
use of the sensor does not change in the hands of the
sensor manufacturer when it sells the sensor to the customer. The sensor
manufacturer intends the generic wellness use for its sensor. Just as I
argued for the mobile phone scenario above, I would say that the sensor is
not even an accessory or a component of a medical device. Rather it is just
part of the environment in which the mobile medical app will operate. For
its part, the developer of the mobile medical app needs to prove that the
app will perform safely and effectively using a generic, off-the-shelf sensor.
Even if the mobile medical app developer goes so far as to specify a
specific brand of sensor to use, when the sensor manufacturer sells that
specific sensor it is still not a medical device. It is the sensor manufacturer’s
intended use for its sensor it sells that matters, at least while the sensor is
still in the sensor manufacturer’s hands.
But let’s say the sensor manufacturer and the app manufacturer collaborate
in some way, first maybe to test to make sure that the sensor and the
app work well together, and then likewise engage in some level of joint
promotion for the use of the two articles together. Boom. The line has been
crossed. The sensor is now an accessory to the mobile medical app, and
regulated in the same manner.
I told you the concept of intended use is important.

mobi health news
IV. The CDS Conundrum
Unfortunately, there is an enormous hole in FDA’s final mobile medical app
guidance document. That hole is the definition of clinical decision support
software. There isn’t one.
That’s a problem, because CDS is one of only three flavors of FDA regulated
mobile apps, and may yet prove to be the biggest of the three. FDA goes through
a lot of verbal maneuvering on the one hand to explain that there is this category
of clinical decision support software, but on the other hand not define it .
I explained in Chapter 1 why the FDA felt it necessary to omit the key definition.
CDS has been long undefined in FDA land, and in 2011 FDA announced its
intention to develop a guidance document defining the types of CDS that FDA
regulates. Indeed, in September 2011, when FDA held its hearing on mobile
medical apps, the agency tacked on an extra morning to cover CDS specifically.
And we have been waiting ever since to see the proposed guidance.
Since then, in the summer of 2012 Congress passed the Food and Drug
Administration Safety and Innovation Act (FDASIA). In section 618 of that
legislation, Congress directed FDA to work with ONC and FCC to write a
comprehensive regulatory strategy for all health information technology,
including mobile medical apps. That report is due to Congress by January 2014.
At a recent meeting, Dr. Jeff Shuren, the Director of the Center for Devices and
Radiological Health of FDA, was asked how the agency plans to address the CDS
issue. He explained that the agency’s intention is to collaborate with ONC and
FCC to analyze the CDS issue as a part of drafting the FDASIA section 618 report.
He explained that in addition to the report to Congress, which will talk about
CDS but only as one element of an overall HIT strategy, FDA may publish a CDS
proposal or perhaps just a concept paper after January 2014 to get public input.
While I am disappointed by the delay, this approach makes sense because CDS, in
contrast to most of the others things FDA regulates, is often directly interwoven
with the electronic health record. Thus ONC, and to a lesser extent FCC, have an
interest in CDS. Ensuring that federal policy is as coordinated as possible among
the agencies will certainly help industry.
In the meantime, there’s this darn hole in the mobile medical app guidance
document. And even come January, we are not likely to get definitive answers but
only perhaps more questions from the agency. So what do we do in the meantime,
before FDA speaks more definitively of its regulatory approach to CDS?
Current FDA policy on CDS
What do we know in advance of FDA’s January
report? Turns out, we know quite a bit. Consider the
following four sources of intelligence.
1. The statute
Okay, there’s honestly not a whole lot we can glean
from the statute itself, other than the fact that FDA
has authority to regulate software that is intended
for use in the diagnosis or treatment of diseases
or other conditions. I’m paraphrasing a bit, but I’ve
covered that several times already.
At a very fundamental level, though, it is important to
appreciate that as with mobile medical apps, this is a
case of FDA needing to clarify its existing regulatory
policy, as opposed to a new area the FDA is thinking
about regulating. Indeed, as I show below, FDA has
regulated several categories of CDS since 1976.
In contrast with mobile medical apps, though, this is
different because FDA’s regulation of this category
has never been clear for very many forms of CDS. In
the case of mobile medical apps, really all FDA is
saying is that they regulate apps that function the
same as a traditional medical device. So if an app
performs urinalysis and if FDA traditionally regulated
the machines that did urinalysis, FDA will regulate
the app. That’s a pretty modest revelation.
In the case of CDS, for decades industry has been
asking FDA to clarify the types of software FDA
regulates, and the agency has utterly failed to do
it except in a few very narrow categories such as
calculators and computer-aided diagnosis. So there’s
no simple explanation here; rather FDA truly is
articulating new interpretive rules.

mobi health news
IV. The CDS Conundrum (continued...)
2. FDA comments: September 2011 hearing.
As I mentioned above, FDA held a half day
hearing on the topic of CDS in September
2011. If you are interested in this topic, I highly
recommend you go to the FDA website and
read the transcript. There was quite a bit of
discussion. At the risk of oversimplifying things,
I’d like to present a couple of takeaways that I
got out of the hearing.
First, at least one FDA speaker seem to suggest
that CDS was characterized by a three-step
process.
Step one is the collection of data, quite
frankly nearly any data. FDA did not seem to
care too much whether it was medical device
data, environmental data, demographic data
or any other data that might be relevant to
inform clinical decision-making. I do think that
logically there has to be two different types
of data used. One type of data would relate to
the patient, and the other type of data would
relate to medical learning of some sort. Clearly
this sort of medical data might be simply
inherent or embedded in the analysis that
comes in step two. But the whole point of CDS
is to take patient specific information and then
apply more generalized medical knowledge.
Step two is the analysis of that data. Here
again FDA didn’t seem too particular about
what kind of analysis might be performed.
Whether it’s simple database lookups or more
elaborate algorithms, FDA seemed to sweep it
all into this category of CDS.
Step three was the production of a patient-specific,
actionable recommendation. Now
there are finally some words that limit
the scope of this category. Patient specific
is probably self-evident, but to me it
distinguishes this type of software from
software that might, for example, make
population-based recommendations for public
health officials. Actionable, as I understood
that term, means specific enough in the form
of the recommendation to prompt action. If
the output of the software is simply a laundry
list of possibilities and the software leaves
everything to the human decision-maker, such
output would not be actionable.
Thus, as I gather it, the FDA’s concept of CDS in general is that it has to produce a
recommendation that might say something like, Mr. Thompson, you probably have a
migraine. Or Mr. Thompson, take two aspirin and call a doctor in the morning. But in any
event, the output would be a specific recommendation for the specific patient.
To be clear, FDA wasn’t suggesting that this is the definition of what FDA should
regulate, but rather the starting point of the definition for CDS. As in MMA, FDA has said
that it only wishes to regulate the riskiest, and not to impede the development of low
risk software.
Diagrammatically, I visualized the FDA definition of CDS in illustration #1 below.
Information
• Data from a
medical device
Illustration 1. What do we know today on CDS?
• Environmental data
(e.g. pollen count,
temp.)
• Demographic data
(e.g. age, sex, socio-economic
status)
Conversion
• Algorithms (fixed or
iterative)
• Formulae
• Database look-ups
or comparisons
• Rules or
associations
Clinical Decision
• Patient-specific
• Actionable result
September 2011 preliminary definition of CDS
After FDA presented its basic framework on what it thought CDS meant, the agency
then provided some examples as in illustration #2 below. Further, the agency wanted to
make the point that CDS exists along a rather wide risk continuum, and that some CDS
is much riskier than others. The following are the examples I heard presented at the
September 2011 hearing.
Illustration 2. Examples of CDS software
Low Risk High Risk
BMI
Calculator
Radiation dose
calculator
Medical image analyzer for
disease/anomaly detection
Cancer treatment
recommendation
Complex analyzer for
untrained user
Trending algorithm for
determining next clinical action
Medication
reminder
Drug-drug interaction/
allergy verification

mobi health news
Current FDA policy on CDS (continued...)
While this information is now over two years old, from everything I’ve heard FDA would
continue to regard these materials as accurate on these basic concepts. I find it very
interesting that out of the examples given in September 2011, the MMA guidance just
released placed the BMI calculator and medication reminder in the enforcement discretion
category. More on that below.
3. FDA classification regulations
As I said in the context of the statutory discussion above, FDA does have existing statutory
authority to regulate at least certain categories of CDS. Indeed, they long have. There are
several different FDA classifications for software that would fall into the CDS category. I
picked just one, calculators, and ran a search to see how many different calculators FDA has
already classified. The results are in the following illustration.
Other common forms of CDS that FDA has actively regulated for a long time include such
area as computer-aided diagnosis. That’s software a radiologist uses to help her evaluate
a digital medical image to see where potential tumors and other abnormalities might
be found. The software scans the image and then perhaps uses color to highlight the
abnormalities, drawing the attention of the radiologist.
So, if you have an app that serves as a medical calculator or helps to evaluate a digital
image or frankly any other type of CDS, you might invest some time looking at the existing
categories of FDA regulation to determine whether FDA already regulates your app.
4. September 2013 MMA guidance
Throughout chapter 2, as I was looking at each of the categories of mobile apps, including
those that are regulated, those that are not and those that are in enforcement discretion, I
made note of where FDA addressed CDS even if they didn’t call it that by name. I don’t want
to repeat all of that here, but rather I will direct your attention to the following.
Medical devices
With regard to apps FDA regulates, the
guidance specifically calls out the CDS
category, although unfortunately not by
name, as a type of app the agency does
indeed regulate. The agency included a
very brief high level definition of CDS, and
then gave the example of computer-aided
diagnosis.
Nonmedical devices
With regard to apps FDA does not regulate,
in the third category regarding apps that
facilitate patient access to information,
I pointed out that FDA was careful to
distinguish this category from CDS.
Enforcement discretion
With regard to apps that FDA places in
enforcement discretion, I pointed out
that the first, third and fifth categories
all related to CDS. Further, in this same
vein, Appendix B which is a list of apps
subject to enforcement discretion includes
numerous examples of CDS.
Actually, for a guidance document which
professes not to address CDS, the final
guidance sure does provide a lot of
information about it.
Summary of what we’ve learned
Let’s take a look at all of this together:
what does it tell us?
First, obviously, it gives us some specific
software types that FDA considers within
its regulatory oversight. This includes
things like computer-aided design and
radiation dosage calculators.

mobi health news
Summary of what we’ve learned (continued...)
Second, we know that FDA’s inclined to put in enforcement
discretion a variety of low risk CDS including routine
drug reminders and simple calculators for such things
as BMI. Likewise, FDA’s inclined to put in enforcement
discretion those apps which are really more about
motivating people than actually diagnosing or treating
people. Further, FDA is inclined to put in enforcement
discretion apps that simply pull up contextually relevant
information like treatment guidelines associated with
the patient’s particular disease.
Third, a bit more broadly, we see FDA focusing on
software that gives specific recommendations for specific
patients, as opposed to accessing general information
even if the software selected the information because
it’s relevant to a specific patient.
Fourth, we see a sensitivity to replacing the physician
as opposed to aiding the patient or a physician more
generally. This FDA concern comes into play particularly
with consumer directed apps where a patient might rely
on the software rather than seek a medical professional.
Fifth, we see the concept of simplicity, where FDA calls
out very basic calculations that are taught in medical
school and that use well-accepted content. Software
that merely facilitates calculations or access to such
information seems to get much more relaxed treatment
from FDA.
Sixth, studying what FDA puts in enforcement discretion
is revealing both for what they include, but also for what
they do not include. To my surprise, FDA does not include
straight up software that makes recommendations to
physicians in low risk areas other than basic calculators
and apps that pull-up clinical guidelines. If that
means such software that makes recommendations
to physicians beyond simple calculations or accessing
guidelines is indeed subject to FDA regulation, that will
be a problem.
I am hoping that is not what it means, but rather FDA is
simply keeping its powder dry while they go through the
collaborative process with the other agencies.
While we have those general principles, obviously those
create as many questions as they answer, so I suspect
many people will be interested to see what FDA comes
up with in January.
CDS coalition proposal
During this time when the agencies are considering options for regulatory
approaches to CDS, a coalition I represent, cleverly called the CDS Coalition,
has spent almost 2 years developing ideas around ways to draw the line
between regulated and unregulated CDS. Thus, to be transparent, I must
acknowledge a self-interest in what I’m about to share.
Through that work, we have come up with some ideas for ways that we
recommend FDA go beyond merely considering the risk associated with the
disease at issue and the role that software plays in diagnosing or making
treatment recommendations with regard to that disease. We believe, and
have communicated to FDA, that the agency ought to also examine closely
the relationship between the software and the user. In a phrase, we believe
that only software that creates “substantial dependence” on the software by
the user merits FDA regulation. If the user is not substantially dependent on
the software, FDA regulation would seem to be overkill.
Conceived another way, this is the difference between (1) on the one hand
mere information that a person could get from the library or other source,
and (2) on the other hand a medical device that directly plays a role in
diagnosis or treatment. Dependence on the software is the difference.
So our proposed definition of “regulated CDS” is CDS that causes the user
to be substantially dependent. Now you might be wondering why the heck
it took us two years to figure that out. Actually most of that time we spent
writing proposed guidelines to determine whether the user is substantially
dependent on the software. These guidelines focus on three criteria. If CDS
software meets these three criteria, the user is not substantially dependent
on the software and therefore the software should not be regulated.
1. The software is transparent. This refers to how easy it is for the user to
understand the basis for the software recommendation. Does the software in
a meaningful way reveal the underlying data it considered, the source of its
clinical analysis, and the context and clinical logic of its recommendation?
2. The user is competent to make the clinical decision. Is the user qualified
– through training or professional experience – to understand and critically
evaluate the software recommendations and make the decision?
3. The user has time to reflect. Does the user have enough time to reflect
and/or challenge the software recommendation?
So if those three conditions exist, the user is not substantially dependent on
the software and the software is not acting as a medical device and under
our proposal should not be regulated.
Below the coalition gives a little bit more description and context for these
three factors. This is a summary of about 30 pages of guidelines.

mobi health news
1. Transparency of CDS Software
Transparency requires clarity with regard to four types
of information.
a. The intended use
Software should explain its role in the decision
making process, situations where software should not
be used, who should use it – doctor, nurse, consumer,
etc. – and where it should be used – hospital, home,
etc.
b. Information that is entered into the software
Either manually or automatically, the user enters
information about the patient into the software.
The software must also contain clinical information
of some sort, for example clinical guidelines or
algorithms based on clinical knowledge. The software
must reveal to the user at least in general terms the
information, both patient specific and clinical, on
which its recommendation is based.
c. Recommendation
The software should reveal its full recommendation
regarding what the diagnosis or treatment should
be. Sometimes the patient specific inputs or clinical
knowledge do not lead to a single recommendation
with much certainty, so the software has to be able to
communicate the limits of its recommendations.
d. The rationale
The software should explain how it reached its
recommendation. What’s important is the clinical
thought process, not the mechanics of the software.
In this way, the software ought to roughly mimic how
colleagues would consult with each other, offering
the clinical rationale for their conclusions not just the
conclusions.
2. Competent human intervention
Competent human intervention means the intended
user (healthcare professional or consumer) is
competent to use the software. More specifically, it
means that the intended user is competent to make
the underlying clinical decision. If the end-user is fully
trained and experienced in the type of decision that needs to be made, the
software acts merely as a convenient aid to synthesize the relevant information.
Thus there can be CDS that supports decisions made by consumers as well as
CDS that supports the decisions of expert physicians. The key is making sure
that the intended user is well-qualified to make the decision.
3. Time to reflect
Adequate time to reflect means the CDS software is intended to be used in a
setting that allows the user sufficient time to evaluate and consider the CDS
recommendation before making the particular decision. To determine whether
adequate time for reflection exists, we need to consider two different factors.
The first is the amount of time available in the anticipated care setting, with the
anticipated clinical condition. Treatment of a gunshot wound in an emergency
department allows less time to reflect than a visit with a patient with diabetes
in the doctor’s office.
The other factor is the complexity of the decision to be made. The clinical
decision can be simple, moderate or complex. This complexity depends on how
many elements the user must consider in order to make the decision.
So in determining overall the adequacy of the time for reflection, we must
consider the complexity of the decision in light of the anticipated available time.
An “adequate” amount of time means that the anticipated time for reflection is
indeed sufficient, given the complexity of the decision, for the competent human
described above to make a confident decision with the aid of the software, but
allowing needed time for appropriate challenge to the software.
Conclusion
CDS is potentially a big category. There are many apps that do not connect with
any special hardware but instead simply use the computing power of the mobile
phone to do remarkable things with data. This is one of the more exciting areas
of mobile medical apps, so we will be watching with great interest to see what
FDA does in January 2014.
At the same time, we do know quite a bit already about how FDA regulates
certain categories of CDS. The agency has clearly signaled that some of the low
risk categories belong in the enforcement discretion category. What we are less
sure about is medium risk CDS. The high risk CDS is already classified in most
cases as a medical device.
Many of the stakeholders hope that FDA broadens its thinking with regard to
factors that should determine whether CDS gets regulated by FDA. Speaking on
behalf of the CDS Coalition, we hope FDA considers whether the software creates
substantial dependence in its users. If a user isn’t substantially dependent on
the software, the software becomes like any other knowledge base, simply
another learning aid in the quiver of the caregiver.

mobi health news
V. Who Does FDA Regulate?
I’m going to keep this chapter short and sweet, in large part
because I intend to reserve two of the more interesting questions
for subsequent chapters. In this chapter, I’m going to cover
what the MMA guidance says about which organizations will
be regulated, and which will not. But I’m going to reserve for
subsequent chapters (1) the circumstances under which FDA will
regulate a healthcare provider and (2) how to shift the regulatory
burden on to someone else.
App developers get regulated
The primary FDA regulatory obligations will typically fall on the
app developer. I realize that’s an ambiguous sentence because
in this virtual world many apps are developed by a group of
organizations working together.
I could torture you with a long and complex analysis of all of the
terms in the statutes and regulations in order to show you how
all of this fits together, but I’m old and impatient, so I thought I
would just cut to the chase. The primary FDA regulations will fall
on the organization that:
1. Controls the product specifications, and
2. Controls the marketing claims made about the product
In FDA’s terminology that organization goes by various names,
including manufacturer and specification developer. But you
don’t need to remember any of that. Just figure out who does
those two things, and that’s the organization responsible for FDA
compliance.
Perhaps you’re wondering why that is the rule, why those two
things? It’s because those two activities are the focal point of the
regulatory requirements. Controlling the product specifications
means that your organization is at the top of the heap from a
product production standpoint. It means you’re the boss of the
manufacturing. You control what FDA cares most about from the
standpoint of assuring safety and effectiveness, and the most
important element from the standpoint of a quality system.
Controlling the claims made about the product
is of equal importance, because as I’ve said
probably 50 times so far in this book, intended
use is the key to the level of regulatory
requirements imposed, and a key determinant
of the safety and effectiveness of the product.
In a very real sense, FDA regulates the intended
use, so whoever controls that intended use is
squarely in FDA’s sites.
Perhaps some Smart Alec out there is thinking,
well Brad, what happens if two different
organizations control those two different
things? To that question I would respond, I
really hope not. How could one organization
control the marketing claims, but not have
control over the nature of the product they are
marketing? It would be utterly dysfunctional for
one organization to monkey around with what
the product is, while a separate organization
working independently decides what claims
to make about the product’s performance.
Product specifications and product claims are
inextricably tied, so it darn well better be the
same organization controlling both. Maybe
in reality it is a partnership of two where
they decide together, but my corporate law
background tells me that a partnership is in
fact one organization. So take that any Smart
Alecs. (Sorry, I’ve been writing for five straight
days.)
Organizations getting a free pass
I have to say that as I read the final MMA
guidance, FDA is being pretty practical in
limiting the obligations of other potentially
responsible parties. Let’s look at a few discussed
in the guidance.

mobi health news
V. Who Does FDA Regulate? (continued...)
App stores
Call them distributors or call them retailers,
these are typically virtual stores that sell the
apps. Think “Google play,” “iTunes store,” and
“BlackBerry App World”. FDA shows an intent to
tread lightly here.
Before discussing the app stores specifically,
I’d like to give you some background on what
the statute authorizes FDA to do with respect
to distributors and retailers. Under the statute,
FDA has authority to regulate any organization
in interstate commerce that deals in regulated
articles such as medical devices. As a practical
matter, FDA generally doesn’t pay too much
attention to the folks low down in the chain
of distribution, except that they expect two
things out of these organizations.
First, they expect them to use what are
generally referred to as good distribution
practices. You won’t find these practices in any
regulation, but rather these concepts are more
folklore. But the point is that FDA expects a
distributor to handle regulated articles in a
way that does not cause them to be, to use
the technical statutory terms, “adulterated or
misbranded.”
Typically adulteration means that somehow
the product has been rendered unfit. With
food and drugs, you can imagine that these
requirements involve a certain level of
cleanliness as well as perhaps control over
temperature and humidity. If a distributor is
dealing with a medical device that is sensitive
to the environment, the medical device
distributor would likewise need to store the
product in a way that does not cause it to
become less safe or effective.
Typically misbranded refers to the way
products are promoted. If a distributor or
retailer buys products for resale, and then
changes the claims made about the products,
the distributor or retailer is responsible
for those new claims. That means they are
responsible to FDA for ensuring any regulatory
compliance necessary for those new claims.
The second thing that distributors and retailers are responsible for is helping to facilitate
a recall or corrective action when necessary to protect the public health. So if a product
is found to be flawed, and evidence suggests that the flaw could be putting people at
risk, the distributors and retailers are expected to cooperate with the manufacturer
in correcting the problem, however that is best done. Sometimes it’s by recalling the
product, but sometimes it’s by fixing the product in the hands of the customer. In the
case of software, this might mean ensuring the distribution of an appropriate patch for
the software.
With that as background, let’s return to what the guidance says about app distributors. In
the final guidance, FDA says: “FDA does not consider entities that exclusively distribute
mobile medical apps, such as the owners and operators of the “iTunes App store” or the
“Android market,” to be medical device manufacturers.” Well of course not.
To go back to the first section, these app distributors do not control the product
specifications or the marketing claims. While they might have terms of use that limit
what can be said through the site and what products can be sold, that’s not the same as
controlling how an individual product is designed or marketed. That is just setting up
parameters for who can participate on the site.
I would note that in the relevant passage FDA uses the word “exclusively” to modify the
term “distributing.” By adding that word, FDA is leaving the door open to regulating an
organization that goes beyond mere distribution into controlling specifications and the
claims associated with the product. I would further point out that FDA is merely stating
the obvious, that these organizations are not manufacturers. But as I explained above,
they are distributors and distributors do have obligations under the statute.
Mobile phone Manufacturers
In chapter 3, I discuss FDA regulation of hardware, and in particular the mobile phone
itself. Most of the time the mobile phone will not be regulated so long as the mobile
phone manufacturer maintains an intended use that is general, for example all of the
uses for which a smart phone typically is suitable without any special emphasis on
specific medical applications.
Assuming the manufacturer maintains that general intended use, the mobile phone
is not regulated and thus the mobile phone manufacturer need not comply with such
things as the quality system requirements.
Mobile operators and other internet service providers
FDA makes it quite clear that they have no plans to regulate those who provide the
communications connectivity only. Again, this is because those organizations have an
intended use for their products that is very general including all communication needs.
They are not promoting their services as somehow uniquely tailored or suitable for the
purposes listed in the statutory definition of a medical device. Nothing shocking here.

mobi health news
V. Who Does FDA Regulate? (continued...)
IT tool providers
FDA also calls out a wide variety of other providers of general IT services and
tools, including providers of:
1. General purpose computer or information technology
2. Web hosting services for content or software application
3. Customer support services
4. Data center hosting services
5. Cloud hosting services
6. Application hosting services
7. Software development kits
The key element in all of these cases is a general intended use that covers
a broad range of IT applications, only one of which is health. However, it
is important that even within the general use, the providers do not make
specific claims associated with the uses that would trigger the medical
device definition. The ability to make a general claim is not a license to make
a wide variety of specific medical claims.
FDA has a somewhat outdated guidance on general versus specific claims
which explains that the ability to make a general claim does not necessarily
mean a company can make any specific claim that logically fits within it. The
policy reason behind that position is that specific claims often raise specific
issues of safety and effectiveness that may not have been evaluated as a part
of the decision-making regarding the general claim.
An example would probably make that more understandable. I may be
authorized by FDA to sell a scalpel, with the general claim that it cuts tissue.
However, being able to make that general claim that it cuts tissue does not
give me authority to claim that the scalpel is ideally suited for a certain kind
of open heart surgery, and then provide details as to how to use the scalpel
in that open-heart surgery. That more specific use raises many additional
safety and effectiveness issues which would not have been evaluated and
validated as a part of preparing to make a general claim that the scalpel cuts
tissue. Bottom line, the ability to make a general claim does not automatically
authorize you to make any specific claims that fall logically within it.

mobi health news
VI. FDA Regulation of Pharmaceutical Apps
Mobile apps seem all the rage in the pharmaceutical industry. There are
presently over 200 of them publicly available. Based on what I’m hearing
from pharmaceutical companies, that’s only a small number compared to the
apps in development.
There’s been a debate going on in the UK about whether pharmaceutical apps
are medical devices under EU law. A consulting firm called Bluelight & d4
suggested in a January 2012 report that many health-related apps are indeed
medical devices. Specific to pharmaceutical apps, the report suggests that at
least in the UK “if your app will be associated with, contributes to or makes a
clinical decision, assume that it will be classified as a medical device….” The
report stirred quite a controversy among champions of innovation and free
speech.
In the US, pharmaceutical companies have begun to focus on these issues
for a couple reasons. First, FDA held a public hearing in March 2012 to take
testimony on whether greater reliance on patient decision support software
could allow certain drugs to switch from prescription status to over-the-counter.
That prompted companies to wonder how such software would be
regulated.
And second, given the technology trends and the opportunities to enhance
patient care, pharmaceutical companies and healthcare providers alike
have been interested in identifying all the possible uses for mobile apps
in connection with drug therapy. Much creativity and energy is going into
identifying the best uses for pharmaceutical mobile apps.
Strangely, though, FDA’s final guidance on mobile medical apps says little
about apps used for pharmaceuticals. Substantively, in the entire document,
drug-related apps are only mentioned a handful of times, mostly in passing
or in minor examples.
In the first several chapters, I laid out the basics of FDA regulation of mHealth.
Given how little discussion there is of pharmaceuticals in the final guidance,
we have to use reasoning to discern how FDA regulates pharmaceutical apps.
I’m hoping that FDA adds clarification in this area as time goes by.
Regulatory categories
The starting point is to understand the four
different possible regulatory categories into which
pharmaceutical apps might fit. Those categories are:
1. Heaven on earth, a.k.a. unregulated apps.
Just about everyone wants their app to be unregulated.
And Utopia it is. But, not to be a downer, I need to be
clear that this just means unregulated by FDA. Most
apps would still be regulated by the Federal Trade
Commission, and indeed it was the FTC that brought
one of the first enforcement actions against a mobile
app developer. Further, nearly all apps would be
subject to state regulators, Lanham Act challenges by
competitors, and tort law if they hurt somebody. So it’s
probably still a good idea if app developers exempt
from FDA nonetheless test their apps to make sure they
work.
2. Drug labeling.
FDA law makes it clear that information provided by
a pharmaceutical company in support of its drugs
qualifies as a regulated drug labeling even if it is not
physically near the drug itself. Generally there are two
kinds of labeling:
Prescribing information, which also is sometimes
referred to as product labeling or a package
insert, provides carefully crafted information
regarding instructions for use. This information is
highly regulated, and for new prescription drugs
is the subject of much negotiation between the
manufacturer and the agency.
a.

mobi health news
VI. FDA Regulation of Pharmaceutical Apps (continued...)
2. Drug labeling. (continued...)
Promotional labeling, which is used to help sell the drug. This kind of labeling
comes in all different shapes and sizes from brochures and booklets, videotapes,
refrigerator magnets, cups and other giveaways to virtually anything else
where a pharmaceutical company tries to convey a message about its drugs.
There are different levels of promotional labeling, and for example a reminder
advertisement is intended merely to convey the brand name. A full discussion of
the contours and scope of promotional labeling is well beyond on this book, but
suffice it to say that apps and other software used to convey information about
a prescription drug will typically be at least regulated as drug labeling. As such,
it will be regulated, which may include, at a minimum, providing full prescribing
information and perhaps need to be filed with FDA at time of first use.
b.
3. Medical device.
Yes, I said a medical device. In chapter 2, I explained the medical device definition
ad nauseum, and I don’t want to go through all that again. Basically software, if
intended for a medical purpose in the treatment or diagnosis of disease, can be a
medical device. Let’s look at the three basic categories covered in chapter 2.
FDA regulated. The main possibility for FDA regulation would seem to come in
the category of CDS. I say this because many of the pharmaceutical apps with
which I am familiar exist in order to give either professionals or patients a
better understanding of how to determine if, when, how and in what dosage to
take the drugs. I will get into this more below.
Enforcement discretion. Here the guidance contains some good news with
regard to three different kinds of pharmaceutical apps.
Medication reminders. Even though medication reminders have been
explicitly regulated for quite some time, the guidance seems to overrule 21
CFR section 890.5050 to declare that the medication reminder intended to
help the patient adhere to a predetermined medication dosage schedule
would fall in the enforcement discretion category.
Medication trackers. FDA also indicates that an app used by a patient to
track drug intake times would likewise fall within enforcement discretion.
Drug interaction lookup tools. Similarly, FDA indicates that apps used
for drug-drug interaction or drug-allergy lookup tools likewise fall in
enforcement discretion.
i.
ii.
iii.
Unregulated. In this category, FDA put apps used for shopping for drugs – apps
that might help with price comparisons and pharmacy location.
Further, on May 18, 2012 Dr. Shuren
of FDA gave a speech at a Capitol Hill
briefing where he revealed a little bit of
their thinking. In his speech, Dr. Shuren
explained that certain low risk CDS would
likely not be regulated, and in addition to
some of the items already mentioned, he
included IV drug dose calculators (e.g.,
for calculating drip rates). Because it was
a speech, we don’t have much detail on
specifically the scope of those categories.
I’m wondering whether the IV calculator
was not included in the MMA guidance
because it will be addressed in the
upcoming CDS guidance.
4. Combination products.
This category only applies if the app first
is a medical device. If that’s true, and if
the app cross-references a drug to be
used with the app, and if likewise the
drug cross-references the app to be used
together, that creates what is called a
combination product. Below I’ll give some
examples of combination products, but
for the moment it is simply important
to understand that if an app and the
drug together constitute a combination
product, that means the FDA regulatory
process gets a bit more complex. Literally
it means that two different centers at FDA
get involved in regulating the product,
the drug people and the device people.
FDA has put in place some procedures for
trying to improve the coordination of the
reviews between those two centers, but it
is not without its challenges.
Okay, that’s the background. Now let’s
get to the interesting stuff: the apps. The
easiest way to organize this part of the
discussion is to divide the apps between
those for professionals and those for
patients.
a.
b.
c.

mobi health news
Apps for healthcare professionals
There are a ton of different apps for
professionals that relate to pharmaceuticals,
and I thought I would just pick a few of the
more common categories to discuss.
1. Drug labeling
I’ll go out on a limb and say that a drug labeling
app ordinarily would fall into the regulatory
category for “drug labeling.” If an app is an
electronic version of the approved drug labeling,
the FDA requirements for drug labeling apply,
including, for certain products, submission
to FDA that the time of first use, and all the
other rules around the content itself. For the
most part, FDA doesn’t allow manufacturers to
mess around with the package insert, and there
are many, many restrictions on promotional
labeling. The good news is drug labeling apps
generally should not be medical devices. The
final MMA guidance says FDA does not regulate
mobile apps that are electronic “copies” of
medical textbooks, teaching aids or reference
materials. These types of apps do not contain
any patient-specific information. So as long as
the drug labeling app doesn’t add functionality
like a dosage calculator or decision support, it’s
just drug labeling.
2. Drug dosage calculators
Here I wish I had better insight to offer you.
The only thing I really know is that not all
drug dosage calculators are created equally.
On the one hand, Dr. Shuren in his speech
called out IV drug dose calculators as likely
to be unregulated. That’s terrific, but the topic
was conspicuously omitted from the final
guidance. Further, in September 2011, in a
speech on clinical decision support software,
the agency identified radiation dose calculators
and software used to determine chemotherapy
as high risk CDS. Further, as stated in the
draft MMA guidance, “the FDA has previously
classified software that calculates a drug dose
based on a patients height, weight, mass, and
other patient-specific information as a “Drug
Dose Calculator” under 21 CFR 868.1890.” That
Diagram 1. Possible Regulatory Categories for Patient Apps
Function
Communication
Management
Tracking
Data Collection
Storage
Regulatory Implications
Electronic Records, Electronic
Signatures (21 CFR Part 11)
Investigator record keeping
and record retention (21 CFR
Part 312.62)
Protection of Human
Subjects (21 CFR Part 50)
Electronic Records,
Electronic Signatures
and record retention
Electronic Records,
Protection of Human
Subjects cGMP
(21 CFR Parts 210 and 211)
Electronic Records,
Protection of Human
Subjects
Electronic Records,
and record retention
Description
Apps allow parties to:
•
Communicate at will
•
Synch and transmit data and
documentation (CRFs, drug logs, etc.)
•
Share notes and calendars
•
Schedule appointments
Apps can provide monitors and
investigators with:
•
To-do lists and other guides
to trial rules and management
•
Audit trails through data
and time stamping
Apps can assist investigators in
tracking tasks by:
•
Creating forms (e.g., screening
and enrollment, drug regimens,
ordering supplies, etc.)
•
Printing labels and handling
information for biological samples
Apps prompt patients to record required
clinical data and information in
prescribed, common, electronic formats.
•
Enables quick, timely and easy
transmission of data to central
repository for analysis, reaction
and trial adjustment.
•
Can fulfill compliance req.
Store a variety of trial documents on
investigators’ mobile devices for easy
reference, including:
•
Protocols and potential violations
•
Clinical practice tutorials
•
Rules for sample handling
•
Inclusion/exclusion criteria
•
Annotated CRF templates
classification includes mostly insulin calculators, and places them in class II, which is
for moderate risk devices that typically require premarket clearance from FDA. But in
the final guidance, the topic was completely omitted. So basically I don’t know what to
tell you except some are regulated and some aren’t. Hopefully the CDS guidance will
address this issue.

mobi health news
VI. FDA Regulation of Pharmaceutical Apps
3. Drug/drug interactions
The final guidance explains that most apps or other software that look for drug/
drug interactions will not be regulated under the agency’s enforcement discretion.
We do not have a lot of details on that, so we will have to play that one by ear.
4. Decision support apps
In chapter 3 I explain FDA’s approach to decision support software. We need to wait
and see what FDA publishes as a draft hopefully in January 2014. All indications
point to FDA taking a similar approach to the one they took with mobile apps
where they stratified the types of software based on risk and proposed only to
regulate the riskiest. As to where they draw that line, that will be the interesting
part.
5. Clinical trial management
As I understand it, there are a whole slew of apps being developed for many
different functionalities for drug clinical trials. To create the chart featured on the
previou spage, I borrowed the categorization of these apps that was developed
in, “Opportunities: Advancing The Pharmaceutical Industry Through Mobile
Technologies, An ArcStream Solutions Whitepaper.” Frankly, all of the functionalities
have potentially applicable FDA requirements. FDA does offer a specific bit of
insight in its recent mobile medical app guidance. In particular, FDA observes
“Mobile apps used for data collection in clinical studies (such as electronic Patient
Reported Outcomes (ePRO) apps) are not considered on its own a mobile medical
app. However, manufacturers and users of this type of mobile app should see FDA’s
draft guidance related to use of computers in clinical trials, ‘Electronic Source Data
in Clinical Investigations,’ 44 issued on November 20, 2012.”
6. Adverse event data management
Frankly, no one should accuse FDA of not being hip. Not only are they making major
forays into social media – you can look at their Flickr page and see pictures of all
the lovely items that are being recalled – but they’ve also developed their own app.
In April 2013, FDA announced the availability of its new MedWatcher Mobile App.
MedWatcher “allows individuals to submit voluntary reports of serious medical
device problems to the FDA using a smart phone or tablet. The app makes it easier
and faster for healthcare professionals, patients and caregivers to send voluntary
reports of medical device problems to the FDA, compared to the traditional
reporting methods - mail, phone or online. The MedWatcher app allows users to
upload photographs of medical devices, which can help identify visible problems
with the device, such as breakage or corrosion.” Actually that sounds pretty cool. I
wonder if it’s a medical device. Makes you wonder who would regulate it?
7. EHR functionality
FDA has said over and over again that it is using its enforcement discretion to not
regulate EHRs. In the final guidance, FDA goes a step further to say that they will not
regulate those apps that allow access to EHRs. That seems clear. The ambiguities
arise when an app goes beyond the functionality of merely storing and retrieving
data entered manually based on a healthcare professional’s observations. For
example, a software app that stores data from
a medical device is itself a medical device, and
goes under the name of medical device data
system, or MDDS. Further, functionality that
goes beyond mere storage and retrieval to add
an analytical piece can be CDS. So in the future
it will be interesting to see how broadly or
narrowly FDA interprets this category.
It’s hard to make any generalities regarding these
apps to be used by healthcare professionals, but
certainly some of them address uses that carry
with them much risk, but on the other hand by
definition they involve a healthcare professional
trained in the subject matter. This area should
be significantly clarified when FDA publishes its
guidance on CDS, perhaps early in 2014.
Apps for patients
Usually apps for patients address less important
subjects, but on the other hand involve people
who may have very little training or expertise in
the task at hand. Balancing those out, it seems
as though these apps present a wide range of
risk. Some of the apps discussed above can be
targeted at patients, for example CDS apps that
help patients make self-diagnosis or therapeutic
decisions. I won’t repeat any of those topics
here. Instead I’ll go through a few apps that are
uniquely tailored to patients.
1. Public toilet finders
I’m over 50, so I really like the sound of this
app. Pfizer cleverly developed this app where
the user community can note the location of
bathrooms and rate them based on cleanliness
and other factors. Pfizer launched the app for
Israel, where I understand it can be very difficult
to find a public restroom. Why Pfizer? I suppose
it might have something to do with the fact that
they have a drug for overactive bladder. So if
this app were introduced into the United States,
which it was not, the question would be whether
the app constituted promotional labeling for
the associated drug. Sometimes the connection
between the drug and the supposed labeling
can be pretty remote.

mobi health news
2. Drug reminders
There are many different apps that provide drug
reminder functionality, and the functionality can be
based on different technologies. Some can be just a
manual programming an app to alarm at a given time,
while others might be reminders sent by the health
professional. In any event, if they’re like an alarm clock
that simply reminds you that it’s time to do something,
that’s pretty low risk, and as explained above, the final
guidance put these in the enforcement discretion
category if they simply alert the user to take medicine
at a preset time. If the app is branded to work with a
particular drug, it’s pretty easy to fall into the drug
labeling category.
3. Drug tracking logs
Compliance with medication regimens is a big issue for
a lot of patients, and doctors want as much objective
evidence as they can obtain. So it can be quite useful for
patients to keep track of what drugs they take and when.
As explained above, simple apps used for recording when
drugs are taken fall into the enforcement discretion
category. If the apps get more elaborate than that, we are
into a gray area.
4. Smart Pill Apps
By now most people are well aware of the ability to use
technology to very precisely measure the exact time a
pill is ingested, for purposes of tracking drug compliance.
It should come as no surprise that the software used to
manage that technology will at least be a medical device,
if not also in some cases part of a combination product.
5. Apps That Are a Condition of Drug Sale
Public health officials have long been trying to figure out
ways to improve medication adherence. For a variety of
reasons, people just don’t take their medicine. Sometimes
it’s because the regimen for taking the medicine is pretty
darn complicated, and sometimes it’s because people
just don’t want the hassle and the cost of getting the
prescription in the first place. FDA believes apps can
help with that. Apps that use what would amount to CDS
functionality can help people decide whether they need
medications for certain common and chronic diseases
such as high cholesterol or high blood pressure. Further,
as discussed above, apps can help instruct people on
how to properly take their medications. There is so
much potential here that FDA is actually thinking about
switching certain common medications for chronic
diseases from prescription status to over-the-counter,
Diagram 2. Possible Regulatory Categories for Patient Apps
but on the condition that the patient makes use of the software. In FDA’s early
thinking, the software might be available at the pharmacy or through some
other means. FDA held a hearing on this topic on March 22, 2012, and sought
comments. From a regulatory standpoint, software used in this manner may
very well constitute either drug labeling or a medical device, for example CDS.
If it is CDS, it’s quite likely that the drug and device pair would be considered
a combination product.
This is a lot of information, so I thought I would summarize it in the following
chart showing the possible regulatory categories for these types of patient
apps.
Conclusion
The possibilities for using apps to improve the delivery of pharmaceutical care
seems almost endless. The mobile medical app guidance was a positive step
forward in that it clearly placed in enforcement discretion several popular
categories of pharmaceutical apps. Unfortunately, some of the more important
uses of apps were not addressed, and hopefully will be the focus of the CDS
proposal yet to come from FDA.

mobi health news
VII. FDA Compliance for Regulated Apps and Accessories
Up to this point in the book, I’ve mostly focused on whether or not an app or a piece
of hardware is regulated by FDA. Now I’m going to shift gears and start to address,
for software and hardware that is regulated, the FDA requirements that would apply.
At a high level, those requirements include getting clearance or approval from FDA,
manufacturing the product according to the quality system requirements, reporting
adverse events, and registering your manufacturing facility. I’ll take those one by one.
Premarket clearance or approval
In contrast to components that are simply sold to another manufacturer, medical
devices and accessories sold to end users may require some form of premarket
clearance or approval. Once you know you have an FDA-regulated device (software or
hardware) or an accessory, here’s how you figure out if clearance is required:
Step one
Figure out the most appropriate classification for your product.
There is a bit of both art and science to this. FDA has published about 1,700
classification regulations. Each of those regulations has a description or
“identification” of the types of devices covered by that regulation. FDA has a
searchable database of these regulations accessible through their website. Some
hardware and software are so important that FDA has separately classified them,
and you can find them directly through searching. The regulations are organized
by clinical application so all of the orthopedic devices, for example, are in one part
of the regulations. You might get lucky and find one that directly describes your
product. A quick search of the regulations revealed that the word “computer” appears
in 225 regulations, “software” in 431 and “network” in 43. There is, for example, a
classification for remote medication management systems in 21 CFR 880.6315.
As of the publication of this book, FDA has cleared over 100 apps. I keep a list of
them, and if you are in this industry, you ought to as well. FDA has started keeping
a webpage with example mobile apps the agency has cleared, but their list is
incomplete. It’s just examples. Knowing the range of what FDA is clearing is important
because if someone else has already gotten the clearance for a similar type app, that
will give you a roadmap for how to classify your product.
If you can’t find a classification that directly
describes your product, perhaps it’s because
FDA considers your product to be merely an
accessory to a “parent” device. I’ll give you
an example. In 2009 FDA cleared an updated
version of the Polytel glucose meter accessory,
which is a small module that plugs into the
port of a glucose meter, receives data from
the meter and transfers it wirelessly to an
Internet capable communication device like
a mobile phone or an APT. In clearing the
device, FDA agreed with its classification in 21
CFR 862.1345, which covers all glucose test
systems, including the “parent” glucose meters.
Step two
Read the second half of the classification
regulation to see how FDA regulates that
particular article.
FDA assigns each product into one of three
classifications, cleverly called class I, II and III.
Class I devices represent the least risk, while
class III represent the greatest. Associated with
those classifications are specific regulatory
requirements. Many class I devices will be
exempt from premarket clearance, and some
products will be exempt from other regulatory
requirements that I’ll describe in a minute.
Some class I and most class II devices require
filing a premarket notification (or 510(k))
with FDA. These submissions are manageable
documents that compare the new device to
those lawfully on the market. The specific data
requirements are discussed below.

mobi health news
VII. FDA Compliance for Regulated Apps and Accessories (continued...)
The highest risk devices – class III – usually
require premarket approval (PMA) from FDA,
which can cost hundreds of thousands of
dollars if not millions. Most apps will not
be in that classification, unless they are an
accessory to a high risk device. If your device is
classified as an accessory, it is subject to all of
the regulatory requirements applicable to the
parent device.
Step three
Research the requirements.
FDA has published scads of guidance
documents on its website that cover many
different aspects of the technologies they
regulate. It’s important you find all of these
so-called “special controls” because you’ll
need to make sure that your product complies
with those technical standards.
Afew examples include:
Guidance for Industry – Wireless Medical
Telemetry Risks and Recommendations
Guidance for Industry, FDA Reviewers and
Compliance on Off-The-Shelf Software
Use in Medical Devices
General Principles of Software
Validation; Final Guidance for Industry
and FDA Staff
Guidance for the Content of Premarket
Submissions for Software Contained in
Medical Devices
Cybersecurity for Networked Medical
Devices Containing Off-the-Shelf (OTS)
Software
Device-specific guidance (e.g. glucose
monitors)
Step four
Consider your options.
Even once you know how a device is classified and the specific regulatory requirements,
you may well have options for how you get marketing clearance. Let’s say your device
is in class II, and some sort of premarket notification or so-called 510(k) is required.
510(k)s come in lots of different flavors, including traditional, special and abbreviated.
For some, as an alternative to filing at the FDA, you can seek to have your device
reviewed by an independent third-party who then certifies its review to the FDA. Going
through each of those options is beyond the scope of this article, but it’s important
to understand that you have options. I have tried to illustrate the major options in
Diagram 1 below.
Step five
Determine the type of evidence needed for FDA clearance.
Even more choices need to be made here. The amount and type of data needed to
secure clearance depends directly on the types of claims you want to make. In many
cases, as explained in chapter 1, you might have the option to merely make a “tool”
claim: a claim that your product simply does a specific function. In the accessory
example I gave above regarding the Polytel product, the company makes a tool claim
that its article merely connects one medical device to the Internet.
•
•
•
•
•
•
Diagram 1. Some major pathways to market for IT devices
Is it a device or an
accessory to a
device?
yes
Does a classication
regulation cover it?
Covered
What options are
available for gaining
marketing clearance
or approval?
Unregulated
by FDA
It is
automatically
Class III
Exempt
510(k)
PMA
Petition for
Re-classication
de novo 510(k)
PMA
Traditional 510(k)
Special 510(k)
Abbreviated 510(k)
510(k)
3rd Party Review
No
Not
Covered

mobi health news
You might prefer to make an outcome type
claim: a claim that your device will help
treat or diagnose a specific disease or
condition. For example: “Using this device to
transmit your blood glucose readings to your
physician typically allows for better control
of diabetes and will help you wean yourself
of dependency on insulin.”
The types of data you need to provide FDA
will depend on which type of claim you
make and indeed on the exact wording of
the claim. Typically, you could support a tool
type claim with bench testing or other non-clinical
evaluation. Basically you need to
prove that your tool works. If you choose to
make outcome based claims, you’ll need to
prove that the device indeed achieves those
outcomes. That’s much harder, and requires
testing in a clinical setting.
If you are following the 510(k) pathway,
the fundamental standard is whether your
device is substantially equivalent to other
lawful devices. So most submissions follow
a comparative format where the submitter
compares his device to others in the
marketplace.
With regard to the type of evidence required,
there are many open questions at this point.
For example, what does an app developer
need to show with regard to the suitability of
the underlying mobile platform?
Apps where the classification is not clear
Let’s say you try to use my five-step process above, but you get stuck on the very first
step. You are stuck because there does not seem to be clear FDA classification for your
software. What do you do? Unfortunately, you are in a gray area, and you are not alone.
The FDA’s final mobile medical app guidance starts us well down the path of
understanding which apps are regulated, and which are not. But it doesn’t address, even
slightly, the question of when a particular app subject to FDA oversight must be cleared
prior to marketing. I’m afraid we will have to wait further for the answer to that.
What are software companies supposed to do in the meantime? What fits within this
regulated but exempt from premarket notification category? The best anyone can do
right now is look at a variety of risk factors to figure out which side of the premarket
clearance line again an app falls. Based on FDA comments and actions over the last 20
years, I would propose the following list of factors be considered:
Whether the app is intended or designed to provide any real time, active, or
online patient monitoring functions.
The capability to display, create, or detect alarm conditions, or actually sound
an alarm, or the capability to create alarms that are not already present from
the connected medical devices.
The seriousness of the particular disease or condition which the app
is intended to diagnose, cure, mitigate, treat or prevent and how the
software contributes to the user’s decision-making for diagnosis or clinical
management of the patient. Example: Is the app designed to call attention
to imminent hazard conditions or does the app provide long-term storage for
diagnostic information?
The amount of time available before using the information provided by the
app, i.e., the time until a therapeutic or additional diagnostic intervention
must be implemented by the health care provider after the results of the
software have been provided. Example: app provides an EKG reading and
analysis package whose output is “SHOCK NOW” or does it provide a proposed
reading with notation that the rhythm itself should be checked?
Whether the data output is provided or manipulated in a novel or non-traditional
manner, or whether decision trees within the app depart from
customary use. Example: Does the app’s algorithms, parameters, internal
decision trees, or other output manipulations depart from customary use or
traditional data presentation?
Whether the app provides individualized patient care recommendations, e.g.,
whether app suggests or recommends specific treatment for a specific patient.
Example: How specific is the app’s output with regard to particular patients?
Is the app providing general advice or information, like a library, article, or
textbook, or is the app designed to provide a specific recommendation for a
specific patient whose individual data have been entered as input?
•
•
•
•
•
•

mobi health news
Apps where the classification is not clear (continued...)
Whether the mechanism by which the app arrives at a decision is hidden or
transparent, i.e., does the product use undisclosed parameters or internal
decision trees or other mechanisms that are not available for review by the
health care professional. Example: How transparent is the app’s manipulation
to the intended user community? Included in transparency is the extent to
which limitations on the process are made known to the user, such as data
contraction, deletion, editing, or simplification. Also, how are comparisons made
to normative databases and how are normative databases created?
•
In the past, I have validated that with people at FDA. That said, this is an evolving area
and we will have to continue to watch FDA to see what they do in the absence of written
guidance. My hope is that we might get written guidance, but I wouldn’t count on it very
soon.
Apps requiring validation
A 510(k) submission for an app will need to be based on an appropriate level of validation
for the software. If the app is an accessory, the parent device determines the level of
validation required. If not an accessory, to determine the validation required, you will need
to figure out whether FDA classifies the software as “major”, “moderate” or “minor” “level of
concern.”
It’s major if the software directly affects the patient or anyone else such that
a failure could result in death or serious injury
It’s moderate if the injuries would be nonserious
An app’s risk and the associated “level” determine:
the depth and degree of hazard analysis and mitigation that is expected
the depth and degree of documentation
what needs to be submitted vs. merely documented
the rigor applied to the verification and validation of the software
the degree to which the device manufacturer’s software development
process is scrutinized
•
•
•
•
•
•
•
•
In addition to the premarket clearance or approval question, devices must comply with
other FDA requirements, as described in the next section.
Quality system requirements
The other big hurdle is ensuring compliance
with the quality system regulations. As
the name suggests, these requirements
are focused on ensuring manufacturers
produce quality products commensurate
with the risks associated with using the
device. So the exact nature of the quality
system will depend on the intended use
of the article. For companies that are ISO
13485 certified, becoming compliant with
the quality system regulations is mostly a
matter of creating documentation systems
so that you can prove your compliance.
More substantial changes are required if
the company is only ISO 9001 certified.
In its final mobile medical app guidance,
FDA asserts that the majority of the quality
system requirements “are consistent
with commonly used and accepted good
software development practices, such as
those from the Institute of Electrical and
Electronics Engineers’ (IEEE), Software
Engineering Body of Knowledge (SWEBOK),
and Carnegie Mellon Software Engineering
Institute’s Capability Maturity Model
Integration (CMMI) methods.”
One of the most frequent questions I get
is how to comply with the full range of
quality system requirements when some of
them seem applicable to hardware but not
software. In its final guidance, FDA agrees
that “Certain portions of the QS regulation
that apply to medical device hardware
(such as the production and process
controls outlined in 21 CFR 820.70) may
not clearly apply to mobile medical apps.”
In these cases, a company need only
comply with the requirements that apply
to the particular operations in which the
company engages. Section 820.1 of the
quality system regulations states that
“if a manufacturer engages in only some
operations subject to the requirements
in this part, and not in others, that
manufacturer need only comply with those
requirements applicable to the operations
in which it is engaged.”

mobi health news
Quality systems requirements (continued...)
These quality system regulations apply cradle-to-grave, so the minute you begin
the design process, the design controls must be observed. Design controls specify
the process used and the records to be created during the design, development, and
manufacturing scaleup of a device. They extend all the way to postmarket issues such
as complaint handling, risk management, and failure analysis and feedback to the
design and manufacturing organizations.
In the medical device world, component suppliers are exempt from these regulatory
requirements.
Being exempt from the requirements doesn’t mean the components need not be high
quality, but rather it means that the finished device manufacturer has the regulatory
burden of assuring the quality of the components it uses. While this could mean
incoming inspections of raw materials, components and subassemblies, it more often
means that a device manufacturer must apply the necessary controls on a supplier-by-
supplier basis to make sure that any controls the supplier is missing, the device
manufacturer provides.
Reporting adverse events and product fixes
As kind of a belt and suspenders, in addition to requiring premarket review of the
product and imposing quality system requirements, FDA expects companies to be
vigilant for reports of people getting hurt or products malfunctioning. In some cases
those incidents might rise to the level of needing to be reported to FDA. These so-called
Medical Device Reports are time sensitive (an assessment is due in a matter
of days or weeks), and require the company to have in place systems for reviewing
all relevant incoming information to assess the potential of each report to be
categorized as an Adverse Event.
The basic trigger for the obligation to file the report is “whenever they receive or
otherwise become aware of information, from any source, that reasonably suggests
that a device they market may have caused or contributed to a death or serious injury,
or has malfunctioned and the device or a similar device that they market would be
likely to cause or contribute to a reportable death or serious injury if the malfunction
were to recur.” Unfortunately, that broad standard requires a lot of interpretation by
the manufacturer.
If the company decides to take corrective action, in some cases the company needs
to notify FDA. According to the mobile medical app guidance, “mobile medical app
manufacturers are required to promptly report, within 10 working days from the time
the correction is initiated, to the FDA certain actions concerning device corrections and
removals for the mobile medical app. Specifically, mobile medical app manufacturers
are required to report to FDA any corrections made to a mobile medical app to reduce
a risk to health posed by the mobile medical app or to remedy a violation of the
FDC Act caused by the mobile medical app which may present a risk to health.
The reporting requirement does not extend to
all modifications to mobile medical apps. For
example, certain actions that would improve
the quality of a mobile medical app but that
would not reduce a risk to health posed by the
mobile medical app or remedy a violation of
the FDC Act are not required to be reported
under 21 CFR 806.1(b)39. If there is not a “risk to
health” involved, a report to FDA is not required,
but the mobile medical app manufacturer must
keep a record of the correction. An example of
such action taken by the manufacturer could be
changes made to correct a defect that creates a
nuisance for the user but does not present a risk
to the health of the user or patient.”
It all sounds kind of painful, and it does require
having a process in place and training your
people to follow it. Once it’s in place, however,
most companies find it to be manageable.
Testing your app to make sure it works
It’s quite common in the app world for
developers to release early, beta versions of their
apps in order to get feedback from users. That
makes sense, and it’s a very worthwhile exercise.
But in the world of medical devices, releasing a
regulated app for user experience creates risk. By
definition, FDA only regulates apps that serve a
medical purpose, where if the app doesn’t work
someone could get hurt or at least suffer from
an ineffective product.
That’s why the FDA has specific requirements for
investigating whether early versions of medical
devices work properly. These requirements can be
found in FDA’s Investigational Device Exemption
regulations. If an app is what FDA would refer
to as “a nonsignificant risk device” (and most
apps will indeed fall into that category), the
requirements are fairly modest. The two
biggest requirements are that you conduct your
evaluation under the oversight of a healthcare
institution’s Institutional Review Board, or IRB,
and that you ensure that you have informed
consent from any patient whose information
might be involved in the study (subject to a few
exceptions).

mobi health news
Other regulatory requirements
FDA has a variety of other requirements that may apply,
including such things as registering manufacturing
facilities, listing the products manufactured, export
and import restrictions, and labeling and advertising
requirements. FDA also has a variety of requirements
that apply to post-market distribution to ensure that
products can be identified and traced back. These
requirements are pretty boring and also typically
fairly straightforward, so I would refer you to the FDA’s
website for the details.
Conclusion
Those are the basic FDA requirements that apply
to bringing an app to market in the mHealth field.
Undoubtedly, to those not accustomed to the FDA
regulated world, those hurdles might seem high. In
the next chapter, we’ll tackle the benefits and burdens
of going through those admittedly rigorous FDA
requirements from a business standpoint. In particular
we’ll focus on the competitive advantages that can be
derived from entering the regulated space, weighed
against the cost of achieving those advantages.
There is no doubt that these requirements can be
quite burdensome. But to state the obvious, thousands
of companies have found it possible and worthwhile
to enter the medical device realm.

mobi health news
VIII. Should mHealth Companies Welcome FDA regulation?
At the risk of insulting my new friends in Silicon Valley, I submit that
traditionally-unregulated IT companies may want to adopt a different view of
federal regulation. Over the last couple years, I’ve had the opportunity to observe
firsthand the culture clash as free-spirited, libertarian Silicon Valley meets
Rockville, Maryland, the home of the decidedly more buttoned-down U.S. Food
Drug Administration. Rather than fleeing in fear of the federal bureaucracy, I
would argue that at least some IT companies should consider embracing federal
regulators. Well, maybe start with at least shaking hands.
With the basic framework behind us, in this chapter we will explore the burdens
and benefits of entering FDA regulated territory. Yes, I said benefits.
It’s okay to consider the benefits of federal regulation limiting
competition
As I’ve learned recently working with Silicon Valley companies, IT companies
generally seem to love nothing more than a good, competitive, bare-knuckled
fight with their competitors, and abhor the first hint of artificial restraints on
competition, especially those from the government. In the IT industry, cooperation
around the development of industry standards sets the rules of engagement for
the market, and then everyone competes intensely based on those rules and
execution of their business plan. Innovation can flourish, with upstarts appearing
and challenging big, established companies’ dominance of any particular
portion of the business. The big companies accept it because they are moving
aggressively too; adjacent markets can be pretty attractive if it appears there is
money to be made by offering a faster, better, cheaper alternative to the current
market leaders. The goal of unrestricted competition is great, and undoubtedly
benefits customers in terms of producing products that they want at the best
possible prices.
However, as IT companies consider entering the health market, they need to
appreciate the differences. In traditional IT and telecommunications markets,
if a product doesn’t work, such as a server crashing, people can become really
annoyed when they can’t check their email from their mobile phone every
second. Inconvenient and somewhat costly, for sure, but all might be forgiven
once the server is back up and running. If it happens with any frequency, the
company that produced the technology will get a reputation for poor reliability,
and may go out of business.
But companies in the health space that produce
medical devices, using many of the same components
as what goes into the email server, face a much
different problem set. If their product doesn’t work
consistently and reliably, they can hurt people, or
even cause their deaths. So we don’t, and can’t, rely
simply on competition to weed out the good from
the bad. Instead, the government regulates them.
That’s more than just a legal framework: that’s
a philosophy for how the marketplace in health
works. You can think of federal regulation as just a
bunch of health and safety laws that prescriptively
require that you do this and not do that, but it’s
more accurate to think about federal regulation as
saying we only want companies willing to invest
the significant resources required to get the product
right the first time they enter the market, and to take
the risk of failure to meet high standards of safety
and effectiveness.
To put it in business school terms, federal regulation
amounts to a significant barrier to entry for the health
markets. And that is quite deliberate. FDA law means
“don’t enter this business unless you’re willing to do
it right.” And, as classic economic theory suggests,
companies that are willing and able to invest the
additional resources required and take greater risk
get rewarded with greater return. That’s as it should
be, to protect the public from unsafe protects and to
further the public health by encouraging companies
to invest in medical innovation. In that later regard,
FDA law rewards innovation in a manner similar
to the patent laws. We simply do not want all
companies to be able to make health care products.
We choose to impose much higher standards in that
field, and for companies willing and able to meet
those standards we allow them to earn a potentially
higher return.

mobi health news
VIII. Should mHealth Companies Welcome FDA regulation? (continued...)
Benefits and Burdens of FDA Regulation
Let’s bring it down from the 100,000 ft. view and
get more specific about how entering FDA-regulated
space affects both the company’s cost structure and
opportunities to earn a higher return. For a specific
company, this would require a fairly detailed analysis,
but let me provide you with an overview here. To
conduct this analysis, I’ve chosen the competitive
strategy framework developed by Prof. Michael
Porter at the Harvard Business School. It’s familiar
to many and reasonably well-suited to assessing the
impact of a regulatory scheme on a business. In a
pair of roughly 500 page books, Prof. Porter details
an entire methodology for considering a company’s
strategic options in light of the markets and business
environment in which they operate. I’ll focus on two
tools he uses in his analysis.
FDA regulatory impact on the value chain
In his value chain tool, Prof. Porter focuses on the
individual firm, and how the firm creates value. In
Diagram 1 below, Prof. Porter shows conceptually
along the bottom the sequence of steps necessary
to produce a product, and in the rows at the top the
overhead necessary for the firm to function.
The specific activities that the company selects
to engage in directly determine its profit margin.
Certain activities are high-value and produce higher
margins, while others not surprisingly are lower. A
firm’s competitive advantage derives from its ability
to select and execute the most highly value-added
functions.
Much more could be said, but let’s move on to look
at how FDA regulation impacts the value chain.
To convey this impact at a high-level, I’ve drawn
the intensity map included as Diagram 2 below.
To understand an intensity map, think National
Geographic magazine and a map showing population
density through colors. I’ve borrowed that approach
here to show the intensity of FDA regulation on each
of the different elements of the value chain analysis.
This is a bit subjective, so others might disagree. I
also made an assumption that the company has a
basic ISO 9001 type quality system already.
Here’s how I came up with the intensities depicted.
Diagram 1. Value Chain Activities
firm infrastructure
human resource management
technological development
procurement
inbound
logistics
operations
outbound
logistics
source: Michael Porter, competitive advantage
marketing
sales
margin
service
margin
Diagram 2. FDA Impact on Value Chain Activities
Validation
firm infrastructure
Training
human resource management
technological Design development
Controls
procurement
Purchasing
controls
inbound
logistics
Supplier Controls
outbound
logistics
operations
Claims
Regulation
marketing
sales
In Process
Quality Controls
Shipping
Validations
margin
Complaints
and
AEs
service
margin
FDA requirements will
be very similar to ISO
systems
FDA requirements will
be more stringent
FDA requirements
will be far more
demanding than ISO
FDA Approval. One of the most challenging steps of FDA regulation is securing
premarket clearance or approval; there is no “beta testing” allowed in healthcare.
You can’t offer someone the chance to sign up for a discount if they help you
test the product first to see if it works as you intended. For an innovative device,
that requires substantial effort to design and then test the device to ensure that
it meets its intended use safely and effectively, and perhaps highly regulated
clinical trials. In the diagram, I suggest that the effects of this requirement are
felt as a part of validation and design controls, as well as in the regulation of the
claims that can be made.
Marketing Regulation. In addition to FDA rules regarding securing approval of
specific claims, other federal and state regulators impose stringent requirements
on the marketing function. Thus federal regulation is perhaps most intensely felt
in the marketing function of the company. Again, this will feel quite foreign in
Silicon Valley, where battles between “Marketectures” wage almost daily.

mobi health news
FDA regulatory impact on the value chain (continued...)
In the post-market servicing function, companies in the
medical device field must adopt systems designed to
vigilantly watch for and report any problems, and take
perhaps significant corrective action when problems arise.
In the quality system area, companies that are certified to
ISO standards will have the most new work to do in the
design control and validation areas.
In the modest impact category, the quality system
requirements will require that the device manufacturer
take greater measures to assure the quality of inputs
being supplied. This will include periodic auditing of
suppliers to ensure their systems are robust enough.
The wide spread decision to outsource and off-shore
customer service functions, prevalent in IT, would have to
be considered in light of these requirements. They could
still be done, but doing so could take longer, be more
involved, and actually end up costing more than keeping
it in-house.
The changes necessary in the actual production of the
products are perhaps least burdensome for a company
that is ISO compliant. In general, all of those measures:
Impose added cost.
Lengthen lead times in product development.
Add complexity.
Can be difficult to implement from a cultural
standpoint for a company unaccustomed to that
environment because they require discipline and
rigor.
And of course multiply the paperwork.
•
•
•
•
•
In their analysis of the opportunity health markets
present, many companies go no further than this. But
this is exactly where some companies should persevere
in their assessments, and consider the dynamics of the
medical device market place.
FDA regulatory impact on competitive forces
In Diagram 3 below, Prof. Porter depicts the five forces that in his model
drive the industry dynamics. Those five forces include:
Threat that new companies will enter the market
Threat that new products will become substitutes for marketed products
Bargaining power of suppliers
Bargaining power of customers
Competitive rivalry within the industry itself
1.
2.
3.
4.
5.
Diagram 3. Five forces: impact of FDA regulation
bargaining
power of
suppliers
threat of
new
entrants
competitive
rivalry
bargaining
power of
buyers
threat of
substitute
products

mobi health news
FDA regulatory impact on competitive forces (continued...)
The degrees of those threats and powers determine the
ability of the company to earn a profit. With regard to the
threat that new companies will enter the market, Prof.
Porter identifies several barriers to entry, and one of them
is government policy or regulation.
Assessing the five competitive forces, in some cases the
analysis reveals some interesting opportunities. In diagram
3, again using an intensity map where darker yellow
represents more competition, I suggest where I perceive the
greatest sources of competition to reside for the medical
device industry generally.
In the industries regulated by FDA, the greatest competition
tends to be from established firms in the same industry. This
is true for the simple reason that entering the regulated
industry often requires a very significant investment to
create the innovations and establish the manufacturing
systems necessary to produce them, as well as considerable
lead time to get through the FDA clearance or approval
process. Thus the threat of new entrants is lower than
the competition created by existing firms that have well-established
systems in place for bringing new regulated
products to market. Indeed a company’s ability to cope
with the regulated environment becomes a key asset,
determining competitive advantage.
There is an important limitation to this, however. Companies
that follow the premarket clearance route, if they don’t
have patent or other intellectual property protection for
their products, might find that other established device
companies can quickly follow them through the FDA
clearance process. This is sometimes referred to as a first
mover disadvantage. Further, the laws administered by
the FDA do not create any private cause of action that an
individual company can use to force competitors to abide
by the law. FDA is solely responsible for enforcement
of its laws, and if the agency isn’t paying attention or
simply doesn’t have the needed resources, less reputable
competitors might get away with taking shortcuts.

mobi health news
IX. How to Avoid mHealth Regulation
Most people know the difference between
tax avoidance and tax evasion. Tax
avoidance is the lawful planning of such
things as charitable contributions to
minimize taxes, while tax evasion is the
unlawful and usually deceitful actions
taken to hide income. In this chapter, I
will share some tips for the avoidance of
FDA regulation, not the evasion of FDA
regulation.
The first several chapters in this report
dealt with understanding the scope and
nature of FDA regulation for mHealth, and
the last chapter advanced the notion that
IT companies wanting to make money in
health ought to consider entering the FDA-regulated
zone. Nonetheless, subjecting
your company to FDA regulation is not for
everyone, so this chapter is designed to
help those who have decided to stay out
of the production of FDA-regulated apps. In
particular, I explain four ways to connect
to health markets, and the pluses and
minuses of each such approach.
The binary misunderstanding
Some IT companies new to the health
field seem to misunderstand the nature
of FDA regulation, and think of it as all
or nothing. In other words, a company is
either a manufacturer of medical devices
and subject to the full panoply of FDA
requirements, or they’re not and likewise
are not subject to any FDA restrictions. But
that’s not an accurate depiction.
Instead, companies should think of FDA
regulation as a continuum. Diagram 1
illustrates the two extremes and a few of
the cases in between.
On the far right side, the diagram depicts
the traditional manufacturer of finished
medical devices that is indeed subject to
all of the FDA requirements for medical devices. Even here, though, there are different levels
of FDA requirements depending on the novelty and risk associated with a particular device.
As outlined in the second chapter, devices are classified into three different classifications,
and the types and burdens of FDA regulations vary considerably. Class III medical devices
include such things as pacemakers, embody the greatest risk and thus must meet the most
demanding requirements. Class I devices include such things as tongue depressors and
have very minimal FDA requirements. Indeed, most class I devices do not even need to be
approved by FDA, and the quality system requirements might be very basic. Many mobile
medical apps might fall into class I or class II. All of this was covered in much greater detail
in the second chapter.
On the far left side, the diagram includes unregulated articles such as personal computers
that contain no medical references at all and over which FDA has no regulatory authority.
It’s the stuff in the middle that is interesting for mHealth purposes.
The cases in the middle include, for example, companies that merely make components for
others to use in manufacturing medical devices, distributors of finished product that have no
control over the promotional claims or the design specifications of the device, and contract
manufacturers that make finished medical devices at the direction of another company.
These different functional responsibilities all have narrower sets of FDA requirements that
apply to them, directly or indirectly. It’s important to understand the range of possible
relationships before talking about ways to reduce or avoid FDA requirements, and exactly
what that means.
Diagram 1. Continuum of potential involvement in the device industry
1 2 3 4 5 6
Compliance
7 8
Full FDA
Compliance
510(k)
Full FDA
Compliance
But Often
Exempt
Finished
Class I
Medical
Device
MFR
No FDA
Reach Full FDA
GMP
Good
Distribution
Practices
Marketing
Compliance
Compliance
Contract
Medical
Device
MFR
Inspections
by Finished
Device
MFR
Component
And Kit Part
Suppliers
Unregulated
Article
MFR
Full FDA
Compliance
PMA
Finished
Class III
Medical
Device
MFR
Medical
Device
Distributors,
Retailers
Servicers
Finished
Medical
Device
MFR
That uses
Contractors for
Compliance
Finished
Class II
Medical
Device
MFR

mobi health news
IX. How to Avoid mHealth Regulation (continued...)
Four ways to connect to the health market while reducing or avoiding FDA requirements
Before I go through the four strategies, it probably goes without saying that each one is predicated on the company implementing the
strategy in good faith. Anything less potentially becomes FDA law evasion, rather than avoidance.
Okay, so here they are:
In the last couple years as I’ve been
watching what’s coming out of Silicon
Valley, I’m seeing a tremendous number
of hardware and software products that
probably could be sold as unregulated
articles, but where the manufacturer,
possibly quite inadvertently, is making
claims that would cause FDA to regulate
them. FDA is stretched pretty thin these
days, so they aren’t watching everything
coming out of the IT industry, but someday
I suspect FDA will get more active in this
space.
There are limits to this strategy. As I
explained in the first chapter, I can’t make
a pacemaker, for example, and try to pass it
off as a simple, generic piece of electrical
equipment. In designing the pacemaker,
I’ve done too much to make the design
specific to a medical use to later disclaim
that use. Remember intended use is judged
by words, actions, and in some cases,
inaction. If you’re interested in this strategy,
you ought to go back and review the first
chapter of this report.
A number of startups in mHealth have
come up with very innovative business
plans that put them squarely in the gray
area between medical and nonmedical
intended uses. For example, there are
companies developing strategies for
remote monitoring of people, rather than
their disease or condition. There are gray
areas between wellness programs and
disease programs where FDA needs to
give industry clearer guidance. Obesity, as
a disease, is often difficult to distinguish
from general physical conditioning.
Unfortunately, I suspect we will all need to
feel our way along in the dark for the time
being until the FDA releases new guidance
on disease versus wellness.
Strategy 1: avoid medical devices and their
accessories.
About now you’re wondering whether this
chapter is worth reading, but stick with
me for a second, there’s a more subtle and
profound observation to be made. In your
mind, go back to chapter 1 on intended use.
I went through an example of a stick, and
how it could be either a popsicle stick or
a pediatric tongue depressor, depending
on what claims the company chooses to
make. My point is that in many cases, the
design of the product does not determine
its regulatory status, but rather the
promotional claims determine its status. So
if your company can reach its commercial
objectives without medical claims, and if
the product has legitimate and material
nonmedical uses, you might be able to
avoid FDA regulation by avoiding medical
claims, for example by making very general
claims.
The mobile phone itself is an example. A
mobile phone can be promoted merely as
a mobile phone, and no FDA compliance
issues will arise. But as explained in
Chapter 3 if the manufacturer of the
mobile phone starts to make claims that
the phone is suitable specifically for
healthcare applications, the mobile phone
manufacturer runs the very real risk of
turning its simple phone into a regulated
medical device.
Remember from the first chapter
that the manufacturer might get into
trouble making claims that its product
is specifically intended to accompany a
medical device. That may very well make
the product an accessory to the medical
device, which makes it a regulated device.
Again, claims are pivotal in determining
whether something is an accessory or not.
Finally, to employ this strategy, the maker
of the equipment must be duly diligent
in avoiding making medical claims. My
emphasis in that sentence is on the word
diligence. That means the company needs
to have some level of compliance and
training systems in place to ensure, for
example, that sales representatives do not
go rogue. Even unauthorized sales activity
can come back to haunt the company if
the government decides that the company
wasn’t careful enough in managing its
people.
Strategy 2: avoid controlling the product
specifications and the claims made.
In the chapter on who FDA regulates, I
explained the essence of manufacturing
as controlling the specifications and
controlling the claims. Most FDA
requirements, including the need to
obtain FDA clearance or approval and
the responsibility for reporting adverse
experiences, fall on the company that owns
and controls the product specifications and
the claims made. Because most of the risk
of a medical device stems from its design
and the claims made about it, whoever
controls those two features has most of
the FDA compliance responsibilities. So, if
you don’t want those responsibilities, don’t
own or control those two features of the
device.
Some examples probably would help. In
most cases, a contract manufacturer does
not control the product specifications or
the claims made about the product. That’s
true even if the contract manufacturer
produces finished product and drop ships it
to the ultimate purchaser on behalf of the

mobi health news
place supplier controls sufficient to ensure
the quality of the components it uses.
These controls might include, for example,
periodic inspections of suppliers.
Another strategy is to supply finished
medical devices to a firm that will co-package
its own device with yours. From
a regulatory standpoint, this is essentially
the same as the component supplier
scenario just discussed. Even though the
article is a finished one, if it is bundled
together with another product before it
is sold to the end user, the company that
does the bundling has responsibility for
ensuring that each product in the bundle
has the requisite regulatory compliance.
Sometimes the supplier for the article to
be bundled will undertake compliance
with the FDA requirements itself, and
sometimes the bundler takes that job.
But because the bundler is considered to
own the specifications of the bundle and
whatever claims are made for the bundle,
it generally has the ultimate regulatory
responsibility.
Let’s take, for example, again a common
mobile phone, hypothetically call it a
mePhone. If the mobile phone manufacturer
makes no medical claims about it, the
mobile phone manufacturer will have no
direct FDA responsibilities. But let’s say a
blood glucose meter manufacturer claims,
in promotional materials, “our meter will
pair with the mePhone to download data
for analysis on our special app.” As I pointed
out earlier, in FDA’s eyes arguably the blood
glucose meter manufacturer has made the
mePhone and the app into components
of its medical device system. (Personally, I
think the mobile phone is just part of the
environment, but that’s just me.) So the
blood glucose meter manufacturer may,
for example, either need to prove through
a risk assessment that mePhones available
in the market place will remain suitable
for that intended use, or need to enter into
an agreement with the mePhone maker
such that the two companies, through
cooperation and control, will ensure the
future compatibility of the two devices. I’ve
kept this simple but in real life these facts
are usually much more complex.
I want to underscore something I said
earlier: almost none of the organizations in
this section are completely outside of FDA’s
jurisdiction. They all have some, albeit
perhaps minor, FDA responsibilities. Even
distributors and retailers have to ensure
their promotion remains consistent with
the approved labeling, and their facilities
appropriately safeguard the integrity of
the products. They must also cooperate
in a recall. Components suppliers, while
technically exempt from the quality system
regulations, often must nonetheless ensure
that they are not selling adulterated
components for use in medical equipment.
Over the last several years, I have read a
dizzying array of corporate agreements
that provide for various kinds of
collaborations like these between
companies. Some of them are fashioned as
supply agreements, while others look like
contract manufacturing agreements, and
yet others look like intellectual property
license agreements.
As a regulatory lawyer, when I read these
agreements, often I’m asked to make a
judgment as to who has the FDA regulatory
responsibilities. And sometimes, honestly, it
just isn’t clear. I’ve read agreements where
all the specifications and promotional
claims have to be mutually agreed upon
between two parties. In other cases, one
party maintains a general level of control
over the specifications and claims, while
the other party is able to exercise wide
latitude within certain limits.
In those cases, where it is genuinely unclear
which party has the FDA responsibilities
under the regulations, I believe FDA permits
the parties to specify in the agreement
who has those responsibilities, so long
as that division is reasonable to resolve
the gray area. So my advice: have your
regulatory lawyer work closely with your
corporate lawyer to make sure that your
various collaboration agreements specify a
reasonable – and your intended — division
of labor on the regulatory compliance side.
Strategy 3: contract out the hard stuff.
Even if your company markets what is
admittedly a medical device and controls
the specifications and the promotional
claims so that your company is clearly
regulated by FDA, that doesn’t mean your
company itself must do the hard stuff. The
regulatory work can generally be contracted
out, even if the regulatory responsibility
has to remain with the specification owner.
It probably won’t surprise anyone to know
that there are whole industries designed to
conduct various responsibilities of medical
device specification owners in compliance
with FDA requirements. For example, there
are clinical research organizations that
can do all of the clinical research, soup to
nuts, and one of their main selling points
invariably is that they take responsibility
for the FDA compliance for that function.
There are regulatory consultants who can
quite ably prepare premarket submissions.
There are contract manufacturers who
specialize in producing product under
FDA quality system requirements, and
there are other consultants who can help
bring the specification owners’ facilities
up to code, so to speak. There are design
organizations well-versed in conducting
the design process in compliance with
FDA design controls. Bottom line: if there’s
some feature of FDA regulatory compliance
that makes you nervous, there’s probably a
whole industry out there quite willing to
help you do it.
That said, it bears repeating that you
can contract out the work but not the
responsibility. If your organization is the
one that controls the specifications and

mobi health news
The trade-offs
As Milton Freidman observed, there ain’t no such thing as a free
lunch. Each of these strategies involves trade-offs, and I’ve tried to
depict those at a high-level in Diagram 2 below.
As with some of my other diagrams, this one reflects subjective
judgments concerning the magnitude of the benefits and burdens
associated with a few of the strategies. I’ve used blue stars to
depict features where more is better, and I’ve used black stars to
indicate attributes where less is better.
So, if we look in the column for FDA regulated articles (#8 for class
III), we see my assessment that the potential profit margins are
the greatest and the product life cycle length is the longest and
barriers to entry are the greatest, but on the negative side internal
overhead costs are the greatest. I chose to characterize product
lifecycle length as good simply because it means the company has
a longer time in which to recoup its investment. I realize some IT
companies like the short product lifecycles because they consider
speedy new product innovation to be a competitive advantage for
the firm.
On the other end of the spectrum, I indicate that unregulated
articles normally have much lower profit margins and shorter
product lifecycles and fewer barriers to entry, but lower overhead
the claims, it will bear ultimate responsibility for FDA compliance.
As a practical matter, if you choose to contract out any of that work,
it means you have the obligation to be duly diligent in selecting
the right qualified firm to help you do the work, and providing
reasonable oversight for the function. So the handoff isn’t complete.
Strategy 4: sell a service or be a user, not a product producer.
This strategy is sometimes risky, but sometimes it can work. FDA’s
jurisdiction is very clear: the agency regulates products. Earlier, I
discussed the need for a physical product that is the subject of FDA
regulation. FDA does not regulate services, nor do they regulate the
practice of medicine.
That circumstance has led some medical professionals to be able
to do things that product manufacturers and sellers cannot. For
example, clinical laboratories routinely develop their own clinical
tests that they use with their own customers. For decades, FDA
has taken a nearly hands-off approach to that practice, saying that
clinical labs are sufficiently regulated under a different piece of
legislation, the Clinical Laboratory Improvement Amendments
of 1988. Likewise, pharmacists who are regulated under state
pharmacy laws have a certain latitude to compound drugs. In
these cases, FDA has decided that these are professional service
businesses rather (already regulated by others) than the sellers of
devices or drugs.
Conceptually, it may be possible to position
certain healthcare services as services,
rather than the sale of products. But be
mindful that this is not simply converting
outright sales to rentals, or selling software
as a service. That makes no difference to
FDA. Instead, the difference between a
service and a product is the predominance of
the human element. Services are performed
by humans, whereas FDA regulates products
and machinery no matter how they are
provided. Further, as you might guess, if a
particular operation starts to look too much
like manufacturing, FDA will regulate it. My
only point is that healthcare professionals
have a certain latitude to provide services
to their patients without FDA intrusion.
We will discuss in much greater depth in
chapter 11 the latitude that doctors have
to provide services with apps they make for
themselves.
FDA
Regulated
8
Contract
out tasks
5
Component
supplier
2
Not
regulated
1
Profit
margins
Product life
cycle length
Internal over
head costs
Barriers to
entry

mobi health news
The trade-offs (continued...)
costs. However, I’m sure everyone can think of examples where that’s not true. In
some cases companies are able to develop patent protection around truly novel
technologies and earn tremendous profit margins over the full length of the patent
life. Further, the development of those innovative products might be a tremendously
high cost. But I’m treating those as the exception, not the rule. Perhaps I’m wrong,
but in the consumer electronics area, it seems as though competition is fierce and
technologies quickly become commoditized despite whatever patent protections
might be available.
In the middle you find compromises between those two extremes. In scenario 5
where the company simply contracts out certain difficult tasks, the profit margins
go down correspondingly as the costs of contracting go up, but the company still
benefits from some barriers to entry and earns a comparatively better profit margin
than the far right side of that table. Likewise, component suppliers often enjoy fewer
barriers to entry and have comparably lower profit margins to the finished medical
device manufacturers, but they also face a lower cost structure.
There is a quantitative basis for this judgment that bears noting. According to
Thomson Reuters, medical equipment manufacturers enjoy an average five-year
gross margin of 59%, compared with 45.8% for the SP500. Research coming from
the Deloitte Center for the Edge, which has studied the business climate for US
industries over the past forty years, calculates the average return on assets (ROA) for
the entire U.S. economy had fallen to almost one-quarter of its 1965 levels by 2008,
while performance in the Health Care industry has run contrary to the trend. That
occurred while the ROA in healthcare rose from 1.7 percent in the early 1970s to 3.8
percent in the same period, nearly doubling.
Choosing a strategy is a very complicated exercise that involves looking at these
issues, plus most of the competitive issues discussed in the prior chapter. The
dynamics of the marketplace and the competitive strengths of the firm itself will
play major roles in any assessment of the optimal strategy. My only point here is that
each strategy has its own rewards and risks.
Conclusion
This chapter is meant to give you a high-level understanding of some broad strategies
for avoiding or at least reducing your company’s FDA compliance obligations. Within
each of these broad strategies are multiple variations that raise complexities well
beyond the scope of this chapter. The last strategy, selling services or being a user of
products, is complicated enough that it deserves its own chapter below.

mobi health news
X. Managing the Risk of Being FDA Regulated
Some technology companies are sitting on the sidelines,
or just dipping their toes in the mHealth waters, out of
fear of the unknown. Does FDA regulate this particular
app? If we get into healthcare, will we get sued if
someone breaks a finger nail using our app? Will the FTC
come after us if we don’t have a bunch of clinical trials to
support every claim we make? Will a patient come after
us if personal health information somehow gets into the
wrong hands? What about the company’s reputation if
something goes wrong? And don’t get me started if your
product triggers Medicare reimbursement. In many ways,
the healthcare field seems scary at first, just based on the
headlines we all read concerning regulatory and legal
landmines.
Equally troubling, some technology companies are diving
in without understanding the risks or having a plan to
mitigate them. Indeed some just seem to be in a state of
denial, as if not thinking about these issues makes them
go away. Something akin to don’t ask, don’t tell. Others
figure that as long as they don’t intend any harm, nothing
bad can happen to them.
Both approaches are equally misguided. Instead of those
approaches, I suggest you deal with the risks upfront –
understand and address them. This isn’t rocket science. I
promise you can handle this, and make money doing so if
your idea is good.
I am not going to do a treatise and describe all of the
obscure legal and regulatory risks. If you like reading
statutes and regulations, you’re in the wrong place. I’m not
even going to paraphrase the law most of the time. My
goal is simply to give you practical guidelines for how to
navigate these uncertain waters.
I’m also not going to cover the myriad of legal and
regulatory risks including product liability, HIPAA
compliance, fraud and abuse, and the FTC. Instead I’m
going to focus on FDA, partly because it’s representative
of the other risks, and partly because it’s the area I know
best. If your product doesn’t work well and someone gets hurt, you will
have to both deal with FDA and face product liability.
At its heart, FDA regulatory risk is fairly intuitive because you only need
to remember one thing: it’s all about putting the patient first. Every FDA
requirement can be explained by reference to what’s necessary to protect
the patient. And that includes protecting the patient from misleading
information, not just physical harm.
A technology company new to the potentially regulated mHealth space
needs to start by understanding: (1) the regulatory risk – its sources, nature,
magnitude and likelihood and then (2) more importantly, the primary risk
mitigation strategies – how to avoid getting in trouble with FDA. I will
tackle the issues in that order.
Root cause of regulatory risk
I’ve been doing this stuff nearly 30 years, and it’s been my observation that
companies get in trouble for one of three reasons:
1. FDA has not spelled out the regulatory requirements clearly enough so
you know what to do.
Fortunately, we do have FDA’s recently released final guidance. But as you
can tell from reading this book, there are still numerous ambiguities. In the
case of extreme ambiguity, this could even be a defense, because criminal
statutes are supposed to be clear enough that a person knows what they
need to do to comply. As a practical matter, out of fairness, FDA is usually
reluctant to proceed with enforcement if the rules are not clear. Indeed,
FDA has been very slow to enforce the rules in the mobile app space since
they haven’t yet published their guidance, frankly even when the violations
appear reasonably clear.
2. You don’t know what you don’t know.
It’s possible that the FDA requirements are clearly specified somewhere,
for example, on the agency’s website, but you don’t know what those
requirements are out of simple ignorance. As probably everyone in America
knows, though, ignorance of the law is no excuse. So this represents one of
the most dangerous pitfalls.

mobi health news
X. Managing the Risk of Being FDA Regulated (continued...)
3. You screw up the execution.
Here, I’m assuming the law is clear and that you know what
it was, but in a big organization sometimes the left hand
doesn’t know what the right is doing, or you simply do a poor
job of complying. These can be hard cases to defend if the
violation itself is clear. It all comes down to the facts and
what you did or didn’t do.
So these basically are the ultimate sources of regulatory
enforcement risk, and I want you to keep these in mind as
you go through this chapter. That’s because, if I’ve done this
right, the mitigation strategies all relate back to these three
fundamental risks.
FDA’s fairness in practice
FDA for the most part is pretty fair and practical. I think a lot
of people outside the device industry fear that FDA is arbitrary
and unreasonable, but that’s not been my experience. These
industry people fear that if they make an innocent mistake,
FDA will come down on them with a sledgehammer. But that’s
a myth. Instead, FDA approaches enforcement in a common
sense way, where they start with the least aggressive action
first to see if they can bring about compliance. They do this
both because it’s fair, and because it is more cost-effective
than getting too aggressive too early. The following tends to
be the escalating steps FDA would take to bring a company
into compliance.
1. Private communication.
Sometimes in the form of a letter, FDA may simply talk to
you about your compliance, or suggest the need to address
some deficiency. They will do this for what might be minor
violations. FDA recently did this last spring when they sent
a letter to Biosense explaining that it has “come to our
attention” the company was selling an app for urinalysis. The
letter raised concerns over the marketing of the app without
clearance. It was a very gently worded letter. And, the only
reason FDA published this particular letter was that I had
been very public in raising the issue in testimony before a
congressional committee and in the media. I was making the
point, which I will explain more in a subsequent chapter, that
enforcement needs to be evenhanded. So FDA posted the
letter to its website. But I would not expect them to continue
posting such letters as a matter of general practice. Normally,
they are much more private.
2. Warning letter.
This is an official correspondence that routinely gets posted on the FDA’s
website. The warning letter is directed at a more significant deficiency
that requires immediate attention.
3. Administrative or judicial enforcement action.
An administrative enforcement action is one that the agency has the
power to do without involving the court. An example in the medical
device realm is “administrative detention” where they can literally
quarantine your products for up to 20 days. Most of the other really
severe enforcement steps require the involvement of the court. This
includes actions like seizures, injunctions and criminal penalties.
In practice, when FDA is really concerned about the conduct of a company,
FDA has two additional very powerful weapons up its sleeve that do not
require the direct involvement of a court.
The first is adverse publicity. FDA has the power to talk to the media
where, for example, they believe the public is at risk. In my observation,
FDA has been using this more and more to get their point across, and
there’s no question that it has a punitive effect on the companies that
are the target of FDA’s wrath. From a legal standpoint this is a bit scary
because there are very few legal controls over what FDA can do.
The second is recalls and other field corrections. Technically this is
not a punishment, but it sure feels like one sometimes. FDA can push
companies into very expensive recalls – both in terms of out-of-pocket
but also reputational. Ostensibly necessary to correct the violation, I do
believe that FDA also uses them occasionally to make a point. At the
same time, to the agency’s credit, I believe they only pursue these when
they are genuinely very concerned about the conduct of the company and
the public health risk.

mobi health news
Types of regulatory risk
So, you screwed up. The question is, what can they
do to you? I hate it when someone asks me that
because essentially they’re asking the question
broadly of what are all the possibilities. The
honest answer is offhand “I’m not sure what they
can’t do to you.” For example, they can:
1. Detain your product. I’m not exactly sure how
they would do that in the case of software, but I
would guess they would think of something.
2. Seek to impose criminal sanctions, either on the
company as a whole or the responsible officers.
3.Go to court and get an order for you to do or not
to something.
4. Seek fines.
5. They can shoot you, bury you, dig you up, shoot
you again, and your mother too.
If you are debating whether to intentionally
violate the law based on the magnitude of the
regulatory risk, you might want to comply.
At the same time, for fair balance, I don’t want to
leave you with the impression that if you screw up
they will throw you in jail. It depends very much on
nature of the screw up and your intentions. In fact,
the phrase screwup suggests an innocent mistake,
and for those types of mistakes you ordinarily
simply get a warning and an opportunity to do the
right thing.
What triggers these risks?
I will bypass the technical, mumbo-jumbo about
jurisdiction. Basically if you are doing business in
the U.S. and you are putting a medical device in
commerce, you are subject to FDA regulation.
But regulatory liability comes into play when you
fail to meet the standards that apply to a given
activity associated with bringing a medical device
to market. The following table illustrates some of
the more common requirements and the activities
to which they relate.
Diagram 1. What triggers these risks?
Activity
Development
Manufacturing
Promotion
Requirement
Good clinical practices
Good manufacturing practices
Good promotional practices
If the requirement applies, the responsibility for meeting it can’t simply be contracted
away, generally speaking. However, you can shift the whole activity and with it much
of the day-to-day work. But typically, if you control (1) the specifications for the
product and (2) the marketing strategy for the product, as I have explained before,
you will possess ultimate responsibility for regulatory compliance.
Intent: what it’s not and what it is
As I explained in the first chapter, anyone who has watched Law and Order knows
that intent plays a very important role in the American justice system. But what you
would not get from the show is the relevance of intent to a regulatory violation of
the Federal Food, Drug and Cosmetic Act. It’s different. Boy is it different.
For starters, for a low level violation, it doesn’t matter whether you intended the
violation or not, the conduct is still a violation. For example, to establish a violation,
no one cares whether you had specific intent to do something you knew was wrong,
or whether you were even directly involved in the wrongdoing. Further, no one really
cares if you feel good about yourself or have a clear conscience. And certainly no one
gives a darn whether you think your conduct is legal.
Civil remedies
(e.g. warning letter,
injunction, recall)
Civil monetary
penalties
Criminal penalties
misdemeanor
Criminal Penalties
felony
Diagram 2. Intent: What it tends to be
Company
None, FDA just needs to
establish the product is
violative
Tipically for repeat offenders
or egregious cases
Did the company fail to be
duly diligent, proactively
controlling its people
Same as misdemeanor plus
intentional conduct
Individual
None, but rarely individual
consequences
Typically personal involvement in
the activity
Did the person have:
(1) Power to fix the problem
(2) Responsibility for the function
where the problem existed
Same as misdemeanor plus
intentional conduct

mobi health news
Intent: What it’s not and what it is (continued...)
Intent does come into play in that it is the distinction between a felony and misdemeanor.
But if we’re talking felonies and misdemeanors, you probably ought to be reading something
more scholarly than this article. For the rest of you, the chart on the previous page depicts
very broadly and imprecisely the role of intent in the various levels of FDA enforcement.
I don’t want any comments from attorneys asking me where in the statute this language
appears. It doesn’t. Instead, this is based on my observation of FDA practice.
For me, the key take away from the chart is the very first row where the chart explains you
do not need any intent at all for the vast majority of FDA enforcement actions. It’s not about
blaming someone, but rather simply the existence of a violation. If the device is broken, it
needs to be fixed, whether anyone is blame worthy or not. The second take away is that
traditional intent really doesn’t come into play until you arrive at the last row, where we
are talking about criminal felonies. For the stuff in the middle, the issue is more about
whether the company fulfilled its obligation to be duly diligent in controlling its people,
and whether an individual had the power to do something to avoid the violation, and the
responsibility to act.
Statistically, well more than 99.99% (pure estimation) of people in the medical device
industry will never have to worry about whether they had the requisite intent for a felony.
Those prosecutions are very rare. But there is an aspect of intent that is much more relevant
to developers of mHealth apps. A few folks have asked me over the last couple of years
what I would expect the FDA response would be to a software developer that produces
a medical app without complying with FDA requirements, if it turns out they are indeed
required. My response is to describe two different scenarios that involve two different types
of intent.
The first is a true borderline case where it is unclear, based on all the different
sources of FDA guidance (and there are many beyond the draft mobile apps
guidance), that the app is FDA regulated and the developer truly believed that they
had a reasonable case for deciding that it is not. I would also include in this category
a situation where there is reasonable ignorance of the law. You’ve always heard
that ignorance of the law is no excuse, but in practical terms FDA is willing to cut
some slack to very small businesses that don’t have many resources. The larger the
business, the more sophistication FDA expects. In these cases, I would expect FDA to
respond with either a private or public warning directing the company to come into
compliance. If it was truly a reasonable interpretation and low public health risk, I
would imagine FDA would try as hard as it could to allow for a reasonable transition
to regulatory compliance without disrupting patients and the delivery of healthcare.
A different scenario would be where the company took a more reckless or arrogant
or sneaky position where it really was clear that the FDA requirements applied,
and maybe the company was just gambling on flying under the radar or simply
felt that it wanted to wait until FDA got serious. In that instance, I would expect
FDA to respond with a more public warning but also to be much less willing to
accommodate a smooth transition. Among other things, FDA might demand (a)
that the product be taken off the market until compliance is achieved, (b) that the
existing products on the market be recalled, and (c) public warnings be issued. If you
add to the scenario that the public was put at risk by the noncompliance, which is
frankly more often than not because every FDA requirement is there to protect the
public, or more extreme sneakiness or indifference you might also see the agency
pursue the penalties described in the next section.
Magnitude and likelihood of
regulatory risk
If someone casually picks up the statute
to read about the penalties (okay I have
no idea why anyone might do that), that
person might be surprised to see that
the basic misdemeanor violation of the
act is punishable by no more than one
year in prison and a fine of not more
than $1,000. That doesn’t seem so bad.
The problem is, that’s for each violation,
and each widget sold in violation of the
act is a separate violation. So if you sell
thousand adulterated widgets, that means
the maximum penalty is 1,000 years in
prison and 1 million bucks. Actually, in
that case, calculating the prison term is
more complicated, but you get the idea
– it multiplies. In practice, FDA has quite
a bit of discretion, and the penalties they
seek are generally proportionate to the
blameworthiness of the conduct as they
see it.
The likelihood of facing FDA penalties is
really hard to predict. In chapter 12 below,
I explain that FDA enforcement has been
rather uneven lately. I’ve seen in many
cases blatantly unlawful conduct to which
at least publicly FDA does not respond. In
this area of mobile apps, FDA has not yet
developed, let alone publicly articulated,
an enforcement strategy to deal with
the torrent of new mobile apps. They’ve
talked about doing things almost like class
actions, where they would send a raft of
warning letters to a bunch of companies all
doing the same thing, as they did with the
pharmaceutical companies over the issue
of sponsored links. I’m hoping they don’t
go too far down that road because at the
end of the day this is America. They need
to take appropriate steps to document a
violation first. I hope we don’t see ready,
fire, aim.
That said, traditionally the likelihood of
FDA enforcement depends on five factors,
as follows:
1.
2.

mobi health news
Magnitude and likelihood of regulatory risk (continued...)
1. Visibility of the conduct.
Obviously visibility doesn’t mean some conduct is actually worse than others,
it just means that in practical terms when an agency is strapped for resources,
if you go and stand in front of their offices in Silver Spring, Maryland and shout
about all sorts of off label uses for your product, it seems more likely they will
pursue you. That’s obviously hyperbole, and a more realistic example would be
an app that makes a big splash in the media or on the Internet. FDA loves to surf
the Internet because they can do that very inexpensively. They also love to go to
large trade shows because they can walk up and down the aisles and see what
everyone is doing all in one visit.
2. Disgruntled employees.
Statistically, a very large portion of the complaints FDA receives about the
conduct of companies comes from the company’s own employees. This tends to
be one of two scenarios. The first is where an employee is pissed off at a company
for any number of reasons, including being laid off or simply not getting the pay
raise they were expecting. But the other kind is the conscientious employee who
is bothered by the conduct of her employer. Particularly in the quality field, those
jobs attract people who are personally very invested in the safety and quality of
their products, and are bothered in their souls when the company decides to cut
corners. In either case, the FDA is only a phone call away, and they use it.
3. Competitor dynamics.
An even bigger percentage of the complaints FDA receives are from competitors.
While the reason is obvious, there are some more subtle predictors that you
want to watch. One is if your competitor has gone to the trouble and expense of
complying with the FDA requirements, you know darn well that they will expect
you do the same.
4. Public health consequences.
In reality, FDA lets a lot of minor stuff slide simply because they don’t have the
time to do anything about it. But what will galvanize FDA most quickly is if they
believe the consumer is at risk. If your conduct even arguably puts people at risk,
your regulatory risk goes up substantially.
5. Clarity.
Here I am referring both to the clarity of the FDA rules as well as the clarity of
your conduct. When pursuing an enforcement action, FDA always has to think
about how well it can prove its case, and the clarity of the lines that were crossed
and the documented conduct by the manufacturer get scrutinized carefully before
FDA proceeds. The government doesn’t like to invest in enforcement cases they
might lose.
So there you have it. That’s what I see in terms of the regulatory risk of entering,
or skirting the edges of, the medical device industry. The reason for going through
all of that to lay the foundation for discussion about all about ways to minimize
the risk of those regulatory consequences. We’ve covered the painful part; I
promise the next part will be more uplifting.
Risk mitigation strategies
So that’s all the nasty stuff that can happen if you
enter mHealth and your app or your hardware
ends up FDA regulated, but you don’t comply.
That discussion was ugly, but it had to be done,
because it laid the groundwork for this portion.
Now I’d like to share the good news that there
is plenty you can do to mitigate your risk of
FDA enforcement. As usual, I think in lists. The
following is my checklist.
1. Check your attitude.
As I’ve said I’ve been doing this for almost
30 years now, and I can generally tell which
companies will succeed and which will fail when
it comes to FDA compliance. There is one very
clear hallmark of the companies that succeed:
In their attitude they are able to embrace the
FDA and put patient safety first. If you can do
that, you’ve won easily half the battle. It sounds
almost silly, but it goes to the very DNA of the
organization. If the organization views FDA as a
stakeholder that needs to be kept happy, they will
organize their business partly around pleasing
that stakeholder, in addition to customers,
shareholders, employees and others. These
companies make it part of their mission to learn
the rules and play by them. If you can’t do that,
my advice is simple. Stay out of this space.
2. It’s all about intended use.
In chapter 1, I tried to explain the concept of
intended use. As you might recall, intended
use is the manufacturer’s objective intent with
regard to how its customers will use its product.
This concept is the linchpin of FDA regulation.
It determines everything, including (1) whether
or not FDA regulates your product, and (2) if
it’s regulated, to what level. Intended use is
therefore by far the single biggest determinant
of regulatory risk, and companies that figure that
out put in place robust systems for managing
the intended use of their products. That means
they carefully manage how they promote the
products and what design features they add. They
tightly control all of the things which ultimately
determine the company’s intended use for their
product, so that it stays exactly where they
wanted it to stay.

mobi health news
Risk mitigation strategies (continued...)
3. Aim as low as you can.
To reduce regulatory risk, focus on the lowest risk conditions and the
least claims you can make. The risk associated with the health conditions
you target partly determines the regulatory category (it’s an element of
the intended use), and the claims you make about your product need
to be proven to FDA’s satisfaction. So I say, aim as low as you can. I can
almost hear the marketing people screaming. Okay, I get it – you need
to be bold in business to make money. So what I’m really saying is pick
a happy medium between the “our product will save the world” claims
the marketing people want to make, and selling an inert paperweight.
Carefully pick whatever the least is that can accomplish your sales goals.
Less can definitely be more. Further, many companies not traditionally
in the healthcare space confuse “common” with “low” risk. Diabetes is
quite common these days, but not low risk. Similarly, claims of real time
monitoring of patients with serious conditions are not low risk. Learn the
difference.
4. Pursue a generic intended use.
I covered this in chapter 1. You don’t always have to tell people exactly
how to use something. I can make and sell test tubes without regulatory
oversight so long as I’m just making a glass tube and the claims I make
relate, for example, to the quality of the glass and its cleanliness. I can
make a network router that is just a router. Where I tend to get put in
the regulatory soup is when I start to make specific medical claims that,
for example, my router is especially good because of its design for some
specific medical application. For the generic intended use strategy to be
legitimate, there have to be legitimate nonmedical uses, which for test
tubes and routers is not a problem. Please remember, though, how broad
the concept of intended use is, in that it encompasses, for example, (1)
the words I use to describe the product, (2) any special design features
I might add that have only medical uses, as well as (3) uniquely medical
channels of distribution I choose to pursue.
5. Take a more nuanced approach.
It’s not all in or all out. There are many different roles the company
can play in the industry. Companies can avoid many of the regulatory
obligations by limiting their role to serving as a contract manufacturer.
Or a design firm can collaborate with the manufacturer without taking
on all of the regulatory obligations. Or you can just be a distributor if
someone else’s willing to be the manufacturer. There are lots of roles to
play, they aren’t all equally risky. I explained that in excruciating detail
in chapter 9.
6. Manage your supply chain well.
The most successful folks I know in the medical
device industry would put this at the top of their
list, as a matter of general business practice.
It makes my list with regard to ensuring
regulatory compliance for several specific
reasons. Companies should get accustomed
to using supplier contracting to share the
burdens of regulatory compliance—asking their
suppliers to shoulder some of the obligations.
At a minimum, contracts should specify the
regulatory obligations rather than leave the
issues unaddressed. Warranties are important,
and there is even a so-called “pure food and
drug warranty” in the FDA regulations which if
you use that wording you can shift regulatory
risk upstream. There also are whole tasks that
can be outsourced, notably the clinical research
function to a Clinical Research Organization.
This is a little bit controversial in the device
area; there’s an express provision on the drug
side of FDA that allows this but not so on the
device side. Even so, using a CRO typically can
help reduce the risk.
7. Build a robust compliance infrastructure.
You’re probably thinking, wow, what great
insight he has. Well, I couldn’t exactly leave it off
the list even if it’s perfectly obvious. And frankly
I don’t want to attempt to thoroughly cover
the compliance process—whole books have
been written on that. Instead, let me just say
that compliance tends to depend very heavily
on having written procedures, documenting
compliance, and training your people. It
requires a continued investment to control your
organization that includes in equal measure
auditing to find noncompliance and fixing what
you find. It’s funny – some companies are really
good at auditing and not very good at fixing.
Other companies are not so great auditing but
they do fix what they find. Frankly it takes both,
in a sustained way.

mobi health news
8. Control your communications.
Once companies figure out that intended use impacts
regulatory risk, and that they need a very proactive compliance
program, they generally implement an intense program
to control communications. At many science-based non-medical
companies, the scientists are encouraged to engage
in discussions rather freely. That doesn’t work very well in
the medical device space. But even more importantly than
the scientists, companies target communications that create
impressions in the marketplace with regard to the intended
use of their products. In this regard, companies learn that
what they put on their website really matters, because in this
era of limited resources, FDA makes disproportionate use of
visiting websites to gather evidence for enforcement. Equally
so, companies control what they say at trade shows because
FDA attends those shows to efficiently learn what everyone
in industry is saying. Further, emails can be rather dramatic
evidence of a company’s intended use for its products. So
companies train their people to stay within fixed parameters
when describing intended use in email, just as in any other
communication. When you are regulated by FDA, what you
say really matters.
9. Run a tight ship.
Operations plays a big role in regulatory compliance,
particular because product quality is such a central focus
of FDA regulation. The companies I’ve seen that have been
most successful aspired to meet very high quality standards.
I want you to understand that I chose the word “aspire”
very carefully just then. I selected it instead of, say “set”
high quality standards, because a company should not self-impose
through policies an extremely high quality standard
beyond what FDA would require. The reason is simple – you
can hang yourself by not meeting your own standard. So
companies that document reasonable standards and then
push their people to always in practice aspire to the highest
quality do the best. After all, high-quality products generally
mean you won’t have customers complaining or people
getting hurt, and therefore you are less likely to have FDA
knocking at your door. The practical reality is that FDA goes
after public health risk, so if you don’t create a public health
risk, you stand a better chance of avoiding FDA enforcement.
In addition, documenting what you do should become part of
the DNA of the company. In FDA’s view, if it’s not documented,
it didn’t happen. So the practice of documenting actions has
to get woven into every day operations in an efficient and
effective way.
10. Invest in recall preparedness.
Sorry to be the bearer of bad news, but if you end up in FDA regulated
space, you need to be prepared for recall. It will happen. They are a
common fact of life. If you put regulated software or hardware out onto
the market and it doesn’t work the way it should, FDA’s going to expect
you to recall it. The good news is that there are techniques you use in
your operations that will make it far easier to efficiently identify and
quarantine the scope of what needs to be recalled, and then recall it
efficiently. But it takes prior planning. There are many consultants and
vendors out there who can help companies put in place systems to make
recalls less painful. Recalls will never be pain free, but with prior planning
the pain can at least be minimized.
11. Consider setting up a separate health business.
Without trying to be pejorative, think of FDA regulation as a virus that
needs to be contained. Then think through how best you can use corporate
structures to limit the scope of FDA regulation on your operations. In
tandem with creating separate corporate forms, you will need a relatively
clear delineation between those operations subject to the quality
system, and those that are not. In addition to limiting regulatory risk, this
separation might also be an opportunity to limit reputational risk to your
brand. In the table below I have sought to outline some of the pros and
cons of creating a separate corporate structure to own and operate the
medical device operations.
Pros Cons of Separation
Cons
Cost and complexity
May not be completely
effective if company
remains closely connected
operationally
Pros
Might be able to limit
exposure
Facilitates separate
branding to protect
franchise name
Can give focus to the
operation
Can save money by limiting
the scope of compliance

mobi health news
If you decide to pursue this, though, be aware that separation might prove to
be complicated. One of the most heavily regulated aspects under the quality
system is the design control process, but figuring out how to separate RD in a
meaningful way might be difficult. Generally, the research side would not need
to be separated, but the development side would. Further, just like any divorce,
you have to separate the assets including the plant, equipment, intellectual
property and records. All of the records associated with the quality system
must belong to the medical device corporation. In addition to assets, the actual
manufacturing processes will need to be separated. It is possible though, to
use one company as a contract manufacturer for the other, but that means the
contract manufacturer is subject to the quality system. People and governance
need to be separated, keeping control at the strategic level without destroying
the separation. If the separation is not sufficient, the regulatory requirements
could carry over to the mother ship.
12. Get good help.
Well, duh. This has always been a rule of business, but it is particularly important
here. You need to get good advisors and vendors with regard to medical device
compliance matters including submissions to the FDA and any clinical testing
that you need to do, among other things. You can also reduce your risk by
getting second opinions by outside attorneys and consultants, but you need to
realize that those opinions do not constitute a get out of jail free card. You still
have ultimate responsibility. All the opinions do is make it more likely that FDA
will respond to you with at least some sympathy. The companies you partner
with, including critical areas like the design process and manufacturing, can
have a big impact on your regulatory risk if you are the entity that bears that
risk. So get good help, and use appropriate due diligence to make sure that all
of your advisors and partners can perform to the levels needed.
13. Work with FDA.
The very first item on this list was to challenge you to critically self-assess
whether you can treat FDA as a strategic partner. So assuming you can do
that, you need to start building a relationship with the agency and lines of
communication. If you find yourself involved in advocacy, make sure that
you’re advocating policies that are sensible for patients as well as innovation.
Remember, everything we do is about the patient. Generally, if you plan to
consult FDA, consider doing it early when you have the most flexibility to adapt
and to give them time to think about it. Also, seek clarity, but not too much.
Some people just can’t stand ambiguity, so they will over communicate with
FDA to try to pin down even the smallest details. I don’t recommend that. When
you do that, you have to realize you will get the most conservative advice
each time, plus eventually they will get annoyed. They are not your consultants
– they are too busy to field every question. Sometimes taking a good faith,
informed position is the best in the face of ambiguity. If FDA raises questions
about your compliance, treat them right. Always be respectful, be prepared for
surprise inspections and take any warning you receive seriously. It’s really not
that hard, but it needs to be part of your DNA.
14. Watch out.
Vigilance in this industry is essential.
Watch your competitors. If they go through
the FDA compliance process, you can be
darn sure they will expect you to, and will
complain to FDA if you don’t. Watch out for
changes in the law, regulations and FDA
sentiments. This is an area that changes
constantly. Subscribe to the right journals,
monitor the right websites and attend
the right meetings. It’s terribly important
to stay up-to-date on the regulatory
environment.
15. Be proactive.
Indeed, this is the main point I’m trying
to make. Confront the issues directly and
intelligently, rather than just hoping they
go away. Don’t just assume that compliance
will happen so long as you’re a good
person. It’s doesn’t work that way. It takes
a lot of affirmative effort.
This probably sounds scary, and it is a bit.
But realize that there are roughly 20,000
companies registered with FDA as medical
device manufacturers, and about 80% of
them qualify as small manufacturers. If
they can do it, you probably can too, if you
really want to. Often the rewards are well
worth it. But it’s up to you.

mobi health news
XI. Does FDA Regulate mHealth Care Providers?
At mHealth meetings, I keep hearing representatives from hospitals and other healthcare providers say they don’t believe FDA regulations
extend to them. They seem to believe that an institution must have a smokestack and an assembly line before it needs to worry about FDA
regulation beyond clinical research. But that’s just not true. FDA can and frequently does regulate even those engaged in the practice of
medicine, if they are also engaged in FDA-regulated activities.
FDA tackles the issue squarely in its final MMA guidance. Given how directly FDA addresses this issue, I’ll quote the guidance at length. FDA
says the following is not a medical device manufacturer:
Licensed practitioners, including physicians, dentists, and optometrists, who manufacture a mobile medical app or alter a
mobile medical app solely for use in their professional practice and do not label or promote their mobile medical apps to be
generally used by other licensed practitioners or other individuals. For example, if Dr. XYZ, a licensed practitioner, creates
a mobile medical app called the “XYZ-recorder” which enables attaching an ECG electrode to a smartphone, and provides
the “XYZ-recorder” to his/her patient to use it to record the patient’s electrocardiographic readings for 24 hours, Dr. XYZ is
not considered a mobile medical app manufacturer. If Dr. XYZ is in a group practice (including a telehealth network) and
permits other physicians in the practice to provide the XYZ-recorder to their patients, Dr. XYZ is not considered a mobile
medical apps manufacturer. However, if Dr. XYZ, the licensed practitioner, distributes the “XYZ-recorder” and, through
labeling or promotion intends to make it generally available to or to be generally used by other physicians (or other
specially qualified persons), Dr. XYZ would be considered a mobile medical app manufacturer (emphasis added);
When I read that passage, I immediately think of two questions:
What does FDA mean when they talk about doctors “who manufacture a mobile medical app”? How literally do I need to read
that? Does that mean the doctor, obviously trained in medicine, also knows enough about computer coding to actually create
the app with his own hands (and computer)? What if a doctor pairs with a computer scientist to jointly create the app? Does it
matter if the computer scientist works full-time for the clinic, or does the work on a contract basis? I’ll tell you why I ask these
questions. In similar circumstances FDA reads the language surprisingly narrowly. For example, FDA has said that it will allow
clinical laboratories under enforcement discretion to create diagnostic tests for their own purposes. But in conversations I’ve had
with the agency, they’ve asserted that the statement is quite literal, meaning that the lab cannot use outside vendors to assist it
with that process and remain within enforcement discretion. Notice that is squarely at odds with the definition of the manufacturer
discussed in chapter 3, where I observed that a manufacturer is the one who controls the specifications and controls the claims.
So apparently in these matters of enforcement discretion, FDA may mean something much narrower when they say manufacturing.
They may mean that the doctor has to do it with his own two hands himself. I don’t know.
What does “group practice” mean? I am no expert, but my partners in the healthcare side of our law practice routinely create a
dizzying array of medical practices, some of them loosely affiliated confederations and others tightly-knit, centrally-controlled
organizations. An HMO is a group practice, but as you know some HMOs are huge. One of the largest has 9000 physicians. Does
that mean that a large enterprise can use an app that they develop internally? Going back to my first question, what if this large
organization has a whole bunch of doctors and a whole bunch of computer programmers. Can they all collaborate to create an app
that can be used internally within this large organization on millions of patients?
1.
2.
In the context of enforcement discretion, FDA has a habit of being vague, and sometimes it drives me crazy. They deliberately choose to be
vague in order to not limit their discretion in the future. But the Federal Food, Drug and Cosmetic Act is a criminal statute, and American
citizens have a right to a clear explanation of the scope of a criminal statute. We should not be left guessing like this.
In the face of the ambiguity, the best we can do is go back to the statute and regulations to try to figure out the scope of FDA oversight.

mobi health news
XI. Does FDA Regulate mHealth Care Providers? (continued...)
Background: The law
In this section, I review examples of where FDA has
regulated caregivers to identify the factors that
lead the agency in that direction, and provide a
high-level overview of the relevant law. With that
as background, I also examine some mHealth care
provider practices that might end up FDA regulated,
and offer suggestions for how care providers can
avoid FDA regulation if that prospect doesn’t excite
them.
FDA care provider regulation examples
If, as an example, a large hospital were to buy a
medical device company, FDA would not all of a
sudden lose authority over the products the medical
device company sells. In fact, it’s actually somewhat
common for FDA to regulate activities of healthcare
providers and professionals who wade into product
waters. I’ll give four examples.
First, over the last couple of decades, in FDA’s view
some pharmacies went beyond the traditional
practice of pharmacy services into the production
of new drugs. Pharmacies have always compounded
drugs, which can include mixing various ingredients
to make them taste better or easier to digest.
But according to FDA, in some cases pharmacies
started to basically make their own versions of
commercially-available drugs. Apparently some
of those pharmacies also did so in advance of
receiving a prescription, and in large quantities
unrelated to any one patient. So FDA adopted an
enforcement policy declaring those activities to be
regulated drug manufacturing. Actually, they did that
even before the recent outbreaks of contamination
brought this issue into the public eye. Unfortunately,
not all of the pharmacies had been following the
FDA requirements.
Second, as already mentioned, some clinical
laboratories develop their own chemical reagents
and software for conducting tests on blood and
other specimens. FDA declared it has the right
to regulate those chemical products just as if
they were made by commercial manufacturers.
Indeed, FDA has proposed to regulate a subset of
laboratory-developed tests that combine multiple
variables (e.g. gender, age, and weight) using an
interpretation function (i.e. algorithm) to generate a
patient specific result.
Third, physicians and other clinicians sometimes directly sell drugs to, or use
medical devices on, patients. When they do so, these clinicians also might
promote their services. If they promote uses the FDA has not approved for the
products, FDA may enforce its regulatory requirement on the caregivers. In the
1960s and 70s, FDA took several clinics to court that were hawking various
remedies for cancer and all sorts of other maladies. A few years ago, FDA went
after a clinic that was offering hyperbaric chambers to treat conditions like
stroke, coma, and multiple sclerosis. When the clinicians stand to directly gain
financially and use aggressive promotion beyond the cleared label, FDA tends to
get involved.
Fourth, and perhaps most analogous to mHealth, FDA regulates the hospital
reprocessing and reusing of “single use devices.” Manufacturers of disposable
products do not validate cleaning and re-sterilization of their products. So
when hospitals decide, as a matter of saving money, to reuse devices intended
to be thrown away, FDA says in industry guidance that the reuse is a new use
beyond what the original clearance contemplated. As the promoter of the new
use, the hospital needs to satisfy FDA regulatory requirements just as any other
manufacturer, securing approval and following good manufacturing practices.
The point of these examples is FDA has shown no reluctance to impose its
requirements on any type of healthcare organization that engages in what the
agency believes to be manufacturing. Smokestacks are not required.
Legal overview
A warning to lawyers: this is not a law review article. These issues are
complicated, but I’d like to distill these complex laws down to an executive
summary.
Being a math nut, I developed the formula on the following page to describe
how FDA jurisdiction is established.
In its simplest terms, FDA regulates medical devices that have an adequate
connection to commerce. As already mentioned, in the first chapter I described
what it takes to be a medical device. The definition includes both a tangible
device such as software and an intended use for a medical purpose.

mobi health news
Legal overview (continued...)
So the question becomes whether these
articles in the hands of hospitals and
other providers satisfy the connection to
commerce necessary for FDA jurisdiction.
One piece of that required connection
is the interstate element. While I won’t
bore you with a dissertation on interstate
commerce, most lawyers realize that
almost any commerce now is connected
enough to interstate commerce to give the
federal government jurisdiction. Indeed,
in medical device law, that connection is
presumed.
The Federal Food, Drug and Cosmetic Act
says that if an organization, when holding
a device for sale, does anything to cause
it to be “adulterated or misbranded”,
including promoting for an unapproved
use, the organization has committed a
prohibited act. So in this case the issue
really comes down to whether an article
is “held for sale.” Broadly speaking, there
are a variety of judicial cases over the last
40 years which suggest that healthcare
providers may be holding devices for sale if
they resell or otherwise provide the device
to the patient, or even use the device on
a patient. When enforcing this particular
provision, FDA seems to look for instances
where the caregiver is in the distribution
chain and engaged in promotion.
Upon learning this, many doctors will
quickly point out that they are engaged in
the practice of medicine and section 906
of the Act says that FDA will not regulate
that. That is true. But there is a line the
doctors can cross leaving the practice
of medicine behind and entering the
business of selling devices. The statute
contemplates giving freedom to those who
are regulated by state boards of medicine
under professional standards, with regard
to the activities traditionally within that
realm. The statute does not contemplate
giving freedom to software engineers
working away from patients, developing
software and hardware configurations,
even if they are hired by and collaborating
with doctors.
Diagram 1. Formula for FDA jurisdiction
Medical
Device
Jurisdiction =
Connection
To Commerce + FDA
Device + Intended +
Use
Held for
Sale
It is also true that manufacturing custom
devices falls within an exemption from
most FDA regulations. While the exact
scope of that exemption has been the
subject of much debate and was modified
in 2012 by FDASIA, most agree the custom
device exemption is directed to the practice
of tinkering with approved devices to make
them suitable for individual patients or
individual doctors or other professionals.
It does not contemplate producing HIT
systems used by multiple patients or
multiple caregivers.
The bottom line is that the Act can quite
comfortably be read as applying to
hospitals and other caregivers engaged
in the development and production of
software and hardware configurations that
support mHealth.
Implicated hospital activities
So what mHealth hospital activities
might fall within FDA regulation? The
following are just hypothetical and
broad categories of activities that under
certain circumstances FDA might decide
to regulate. Let’s say a hospital wants to
Jurisdiction + =
Interstate
Commerce
FDA
use mHealth to better manage the care of
people with diabetes. Let’s also say there
are commercially available apps that allow
people with diabetes to download their
glucose readings into the app on their
smart phones. As I’ve explained before,
that app is quite likely to be FDA-regulated
itself. Let’s further say the plan is for that
app to transmit the data back to a hospital.
Now here is where it gets interesting. What
if the hospital wants to develop its own
proprietary system that sits on its own
servers to collect the data from patients
using apps and manage a database into
which physicians can tap using an app
that the hospital develops? Let’s say
the hospital pursues this route because
either it’s simply not satisfied with the
commercially-available software products,
or there’s some need to develop a better,
more integrated approach that fits the
hospital’s legacy systems.
That hospital developed proprietary
system might be FDA-regulated. Even
though the system is one-of-a-kind, in this
hypothetical it is used for each and every
patient enrolled in the program. If that
system hiccups and switches the identities

mobi health news
Implicated hospital activities (continued...)
of two patients, care can be affected. Compounding this, hospitals
are apparently starting to sell access to their own HIT systems
to smaller hospitals and physician practices. In these cases, the
hospitals risk even more likely becoming resellers of the software.
That practice frankly makes it easier for FDA to assert jurisdiction.
Under the final mobile medical app guidance, it would also be
hard to characterize most hospitals as a physician group practice.
Legally, they are just not structured that way.
Avoiding FDA regulation of care providers
As before, I’m not giving advice on the evasion of detection, but
rather on staying outside of the regulated territory. The following
is merely my personal list of eight factors that may keep FDA
from deciding to regulate a hospital’s software or hardware
development.
First, it would help if some regulatory authority stepped in and
oversaw this area of hospital activity. In the examples above, FDA
was most likely to stay away from regulating a given activity if the
agency felt another agency already was doing the job. FDA avoids
duplicating the efforts of the state boards of pharmacy, state
boards of medicine, and federal and state regulators of clinical
laboratories. If hospitals work with an accrediting organization or
some other body that could oversee this activity, they may well
keep FDA from getting involved. However, it’s unlikely the current
CCHIT certification is demanding enough to give FDA much
comfort.
Second, these hospitals and clinics may wish to avoid mHealth
apps that involve too much public health risk. That includes the
disease or condition being treated (cancer compared to sinus
infections) and the clinical role of the technology, as well as the
novelty of the apps. FDA is much less likely to regulate apps that
merely embody tried and true algorithms than those that advance
novel approaches. Further, the more proactive a hospital is in
conducting quality assurance of the kind a manufacturer would
pursue, the less likely FDA will regulate.
Third, the hospital should stay as far away as possible from the
actual parent medical device. FDA is more likely to regulate
software or hardware that more directly accessorizes a blood
glucose meter or other traditional medical device. Further, the
less tailored the software or hardware is to the particular medical
device, the less likely FDA will regulate. These factors all revolve
around close functionality, not the physical proximity of the
hardware or software to the medical device.
Fourth, FDA will be less likely to regulate hospitals if the
hospital is filling an important void. If there are already
commercially-available products and the hospital is
making its own either to save money or because of some
other idiosyncratic preference, FDA may view the activity
as trying to skirt its authority. In a fast-moving area like
mHealth, the question is not only whether there already
is a product available commercially, but whether there
could be a commercial product. FDA would not want to see
hospitals jump in simply because they are impatient with
commercial manufacturers conducting a more diligent but
time-consuming development process.
Fifth, in all of the examples above where FDA chose to
regulate, the agency was responding to aggressive promotion.
The more aggressive the promotion and the more outside of
traditional FDA clearances, the more likely FDA is to regulate.
Sixth, scale is a big factor. In nearly all of the examples
above, FDA only got interested when the practices grew big.
That’s a practical factor in the sense the technology starts to
affect more patients, and commercial manufacturers could
actually supply that need.
Seventh, sharing the hardware and software with others
makes it easier for FDA to assert the hospital is in the
business of reselling.
Eighth, and perhaps most obviously, if the hospital is engaged
in modification of commercial systems, staying within
any existing FDA clearance avoids FDA interest. Obviously
“modification” can encompass a wide range of activities from
life-critical changes to changes in the user interface, and
configuration changes to hardware and network design and
support. The regulatory risk of each type of change needs to
be considered on a case-by-case basis.

mobi health news
Conclusions
At the end of January 2010, FDA held a
public meeting on the interoperability of
medical devices. At that meeting, many
of the speakers talked about the need for
systems integrators. The favorite analogy
was the aircraft industry where two
primary manufacturers are big enough to
set specifications for individual component
suppliers to assure interoperability. By
analogy, some people at the meeting
suggested hospitals and other end-users
play that role with medical devices.
For mHealth, that’s problematic if neither
the systems integrator nor the individual
component suppliers secure the necessary
FDA clearance for the system as a whole.
FDA regulates systems. So if the individual
component companies don’t take on the
responsibility of FDA compliance for the
system, it’s up to the integrator.
Perhaps some hospitals want to take
on that role and secure the necessary
clearance from FDA. That could make some
sense. But frankly it seems far more likely
that an independent third party would play
the systems integrator role, securing FDA
clearance, and then selling that system to
multiple hospitals and other caregivers.
Either way, FDA will want to make sure the
systems are safe and effective.

mobi health news
XII. FDA’s Enforcement Plan
Over the last few years, the mobile medical
apps community has been living in the Wild
West. In the absence of a clear articulation
of the scope of FDA regulation with regard
to mobile medical apps, the agency has
held back on enforcement. Instead, the
Federal Trade Commission picked up the
mantel and pursued a couple of different
app developers over their claims regarding
the treatment of acne. In fact, recently FTC
announced that it plans to continue to
focus on health-related mobile apps.
Now that FDA has published the final
guidance, many observers expect FDA to
begin enforcing its requirements. For its
part, the agency has taken a measured
approach in their public statements, saying
that they are not out for scalps – my
word not theirs – but rather want to work
with innovators to help them come into
compliance. They clearly do not want to
scare innovators away, and I applaud them
for that.
At the same time, FDA will need to level the
playing field. We’ve been seeing a growing
issue among developers of mobile medical
apps where a considerable number of them
seem to be flouting even the clear FDA
requirements. This creates an enormous
challenge for responsible medical device
manufacturers that want to obey the law.
Some app developers come out with $.99
apps that, they claim, are as effective as
any other app out there, but at a fraction of
the development cost because they don’t
worry about a quality system, let alone
FDA premarket notification. That puts the
app developers who are trying to do things
right in compliance with FDA requirements
at a substantial disadvantage.
Frankly I’m hoping to start a conversation
around this issue, because companies are
really struggling to do the right thing.
Unevenness of the past few years
Some app developers already follow FDA’s
regulation, and implement appropriate
quality systems, registration, and adverse
event reporting processes in order to
ensure compliance with the regulatory
requirements. But some are not.
Biosense case
In the spring of 2013, a company called
Biosense made a big splash with a Ted talk
regarding an innovative app that allows
you to do urinalysis with your iPhone.
The company website presented the app
as able to help patients understand and
manage diseases like diabetes, urinary
tract infections and pre-eclampsia, a high
blood pressure pregnancy complication.
You do the test mostly the old-fashioned
way of collecting urine in a cup and then
inserting a test strip. The app objectively
reads the results using the camera on the
phone.
The company launched the product
through iTunes and sold a kit consisting
of a color mat to calibrate the app plus 5
sample urine dipsticks for $19.99 through
the company’s website.
But here is the problem–this app falls
within longstanding FDA regulation for
urinalysis. When I first heard about it, it
seemed to me that the company must be
aware of the potential for FDA regulation,
because on its home page, at the very
bottom, after extolling the clinical uses
of its product to monitor disease, the
company tried to simply disclaim FDA
medical device status.
Significantly, the company’s website was
also full of statements suggesting that
people use their kit in lieu of the FDA
regulated instruments used for urinalysis.
It stated the smart phone app “can help you
analyse, interpret and trend your urinalysis
data to help you understand and manage
diseases like diabetes, … urinary tract
infections and pre-eclampsia.”
Further, it couldn’t have been any clearer
that instruments used for urinalysis
are indeed medical devices. The device
classification regulation, 21 CFR Sec.
862.2900 Automated urinalysis system,
clearly establishes that FDA regulates
urinalysis systems:
“An automated urinalysis system is a device
intended to measure certain of the physical
properties and chemical constituents of
urine by procedures that duplicate manual
urinalysis systems. This device is used
in conjunction with certain materials to
measure a variety of urinary analytes.”
Moreover, measurement of blood glucose
and occult blood actually raises the profile
of the device to class II requiring premarket
notification. Indeed, a search of FDA’s
databases reveals that the other devices
that measure those analytes had gone
through the FDA premarket notification
process.

mobi health news
XII. FDA’s Enforcement Plan (continued...)
Biosense case (continued...)
Here’s the problem. There are all sorts of companies out there trying to do this kind of
stuff right. They follow the rules, and that costs money. In the case of the class I device that
means using a quality system to make sure the device actually does what it’s supposed to
do. For class II, they must file a premarket notification with FDA. It would appear that this
company wished to avoid using the quality system, registering, reporting adverse events
and doing all the other things that bona fide medical device companies do.
This app kit sold for about 20 bucks. Companies that employ a quality system probably have
to charge more than that to make a decent return. How can a company lawfully compete
with those that are willing to try to avoid FDA regulation with a simple disclaimer?
So I raised this issue, first in a blog post, and then in testimony before a congressional
subcommittee. My goal was to put on the table the need to level the playing field so that
all companies are treated equally.
On the one hand, it might seem like I am picking on this company. But frankly, it is simply
typical of what we are seeing day in and day out show up in the various app stores.
At the end of the day, these rules are there for a reason. People get hurt when medical
devices do not possess the quality they need to reliably perform their functions. If this
urinalysis test, for example, under-reports or over-reports an analyte, a person might
be lulled into believing they do not have a medical condition when in fact they do. For
diseases like diabetes, that can have deadly consequences. Of course, if FDA regulation is
no longer necessary for urinalysis, I am sure everyone in that business would appreciate
FDA rescinding that regulation.
For a regulated industry, one of the worst things that can happen is to have a law on the
books that is not enforced. That puts every ethical company in a dilemma – do you sink to
the level of your competition that seems to be getting away with flouting the laws, or do
you stick to your ethical guns.
FDA agreed with me, at least with regard to this particular app. In May 2013, FDA sent a
letter to Biosense explaining that it had come to the agency’s attention that the company
was selling the app for urinalysis, and FDA records did not show that they had filed a
premarket notification. Overall, it was a very gently worded letter, and I think that’s exactly
the right approach to take. FDA should not charge in and treat people like criminals. I
thought they took a very professional approach to this matter. The agency did take the
unusual step of publishing the letter to their website, a step they normally reserved only for
warning letters. But I gather they did that because I had so publicly raised the issue they
felt they needed to bring closure to it.
Over the summer of 2013, I saw communications from Biosense suggesting that they were
indeed going to seek FDA clearance for an expanded app. However, some of the same
communications explained that they needed money, so they were taking orders for the app
in advance of the FDA clearance in order to fund the work to obtain the FDA clearance.
Good grief. I really wish these guys would get experienced FDA counsel, rather than trying
to just wing it. The law is quite clear that companies may not presell medical devices in the
hopes of obtaining FDA clearance later. That’s been the law for decades. Making matters
worse, after they did that, I saw some other app developers do the same thing. I assume FDA
will communicate with them, but they will probably do so privately this time.
Plan going forward
FDA faces very serious challenges in
coming up with an enforcement strategy
for mobile apps. On the one hand, we are
awash in a sea of apps, and developing
a carefully constructed factual case to
support enforcement is quite resource
intensive. On the other hand, FDA simply
cannot take enforcement lightly and
proceed without the needed evidence.
One strategy that FDA might be thinking
about is the strategy they deployed when it
came to pharmaceutical companies using
sponsored links to promote description
drugs. The FDA sent a raft of 14 so-called
untitled letters in a single day to
14 different pharmaceutical companies
that made use of sponsored links. I’m not
sure that sending the letters all at once
necessarily was more efficient for FDA, but
rather I think it was designed to send the
industry as a whole a message regarding
how serious the agency was, as well as a
way of showing that FDA wanted to be fair
and evenhanded in their treatment of the
issue.
I’m not sure that’s quite the right approach
because you still have to make sure that
every company in fact deserves to receive
such a letter. Enforcement includes at least
three elements, and each element presents
its own challenges:

mobi health news
Plan going forward (continued...)
1. Finding the companies that are violating the law
Actually, this first element is probably the easiest of the
three. It’s actually a bit like shooting fish in a barrel. An FDA
enforcement official can sit at his or her desk and surf the
Internet, going to app stores and looking at the claims being
made. Indeed, the agency could hire pretty inexpensively a
few college students and train them to find the offending
apps. In that way, without even leaving the office, the agency
could probably find as a rough estimate 80% of the apps that
should be subject to FDA review but are not. Given that so few
apps have as of yet been approved or cleared by FDA, it’s not
difficult for FDA to check its own files.
2. Building the factual case regarding the violation
One of the primary violations at issue, selling an app without
having submitted a premarket notification, will depend mostly
on assessing the app’s intended use. An initial pass at that
evaluation can be done simply by looking at the information
that’s available at the App Store, and linking to the company’s
promotional website. To be sure, that doesn’t answer all the
questions around intended use as frankly many websites are
quite ambiguous, incomplete and out of date.
For those apps that look to be intended for a medical device
use, the agency then needs to double check its own database
to make sure that a premarket notification has not in fact
been filed. Sometimes ambiguities around corporate names
and so forth make it difficult to be confident of the search, but
in some cases it’s easy.
For class I medical devices where premarket clearance is
not required, instead of checking the premarket notification
database the agency would simply check the facility
registration database. Here too ambiguities can arise with
regard to corporate names.
Because the fact checking in many cases cannot be certain,
I would be in favor of FDA adopting the process of sending
an informal inquiry to a company to get the facts before FDA
decides to send a more formal enforcement letter. At FDA, this
is known as the “it has come to our attention letter.” It seems
to me that this is a prudent step to ensure that the agency has
the facts before chastising the company publicly.
3. Pursuing the companies through some sort of enforcement
For a huge percentage of companies, receiving either an
untitled enforcement letter from FDA is enough to cause them
to come into compliance. I don’t have the exact numbers, but
it seems to be an application of the 80/20 rule, where 80% of
companies will come into compliance and 20% will drag their
feet. From a resource standpoint, it’s clearly the 20% that cause
concern for FDA.
As a matter of policy, the agency doesn’t want to send warning
letters out unless they are prepared to back them up with the
full power of the federal government. Otherwise the agency
would gain a reputation as a toothless tiger.
So that’s really the conundrum. For the 20% who might not
come into compliance upon receiving a letter from the agency,
with all of the budget cuts and other limitations on resources,
how can FDA be confident that it can fully pursue and achieve
compliance among those who don’t go there voluntarily?
I certainly understand that FDA can’t make a threat unless
it is prepared to follow through, and they’re simply not sure
they can follow through with a high-volume of threats. On the
other hand, I’m not sure that FDA fully appreciates how self-regulating
the healthcare market can be when it has good
information. If FDA ends up sending a public warning letter to
an app developer, I believe that many customers and partners
of the app developer will back away from the developer, even if
the developer itself is slow to respond. Doctors, hospitals and
others in the healthcare environment are sensitive to product
liability and malpractice, and usually careful not to use products
where FDA has raised the concern about safety, effectiveness
and regulatory compliance. So even if FDA does not have the
resources to pursue those 20% of companies that do not come
into compliance on their own, the receipt of a warning letter
can still be a very important and impactful step.
But I truly do understand that FDA cannot send out warnings
without being prepared to enforce them, even if customers and
others can be counted on to apply pressure to the recalcitrant
developer. I don’t have the answer here, but I want to start a
conversation to try to find some approach that keeps ethical
companies from getting hurt while trying to do the right thing.

mobi health news
Bottom Line: Enforce it or get rid of it
Let me be clear: what I’m objecting to is unenforced requirements. Unenforced
requirements that clearly apply mean that a reputable company has a choice:
1. Comply when others are not, at great expense and competitive
disadvantage; or
2. Don’t comply and presumably violate the company’s own code of
conduct mandating compliance with all relevant laws.
Notice that that’s far more than an ethical conundrum. If a company starts
ignoring legal requirements, the company has a very difficult time imposing
legal requirements on its own people. The system starts to look arbitrary,
based not on whether there is a requirement but rather based on the
likelihood of getting caught for a violation. It has extremely corrosive effects
on an organization’s overall compliance.
Both of those choices stink. Obviously the government has two different ways
of solving the dilemma. The government can either:
1. Enforce the law; or
2. Remove the regulatory requirement
Which they choose of course depends on whether there remains a safety
issue that needs to be regulated. But if there is indeed a safety issue, the
government needs to regulate in an evenhanded manner.
Conclusion
I expect we will slowly start to see the government’s strategy for enforcing the
mobile medical app guidance. I do not expect a dramatic shift. I imagine the
government will spend the next six months or so trying to educate everyone
about the guidance, and then gradually thereafter start to get sterner in its
communications. I also expect that they will favor those companies that come
to the agency to try to work out a compliance plan, over those that the agency
has to take to task. If a company comes proactively to FDA, and if there’s no
evidence of a safety issue, the agency may well allow the company to remain
on the market while the company comes into compliance.

mobi health news
XIII. Policy Making From Here
As should be obvious from the prior
chapters, FDA is not done with regard to
policy making in the area of mHealth.
Through publishing the final mobile
medical app guidance, the agency has
addressed numerous questions, but has
created additional questions and left
some questions unanswered. One of the
largest gaps, as explained above, is the
scope of FDA regulation of clinical decision
support software. So what does the future
of policymaking in this area look like?
For that, we have to consider a couple of
different forums.
FDA
Notwithstanding pressure from some IT
trade groups, I think FDA will continue to
regulate mobile apps that do the same
thing as traditional medical devices, like
the urinalysis app and apps used to read
ultrasound images. At the same time, there
will be much discussion around apps that
are more peripheral to those core medical
device functionalities.
The current forum for these policy
discussions is the collaborative working
group created by the three agencies – FDA,
the Office of the National Coordinator and
the Federal Communications Commission
– to develop an overall strategic plan for
regulating health information technology,
including mobile medical apps. As I write
this book, in the fall of 2013, as soon as the
agencies come back from their furlough,
they will work intensely on drafting that
report. Under section 618 FDASIA, the
report is due to Congress in January 2014.
better through more educational outreach,
and (2) use of enforcement discretion to
exercise a light touch in areas where the
risk was very low and the opportunity for
innovation great. In addition, the working
group recommended that FDA clarify how
its existing requirements would apply
to mobile apps, including premarket
requirements as well as post-market
reporting obligations. Further, the working
group favored exemptions from the
quality system for the lowest risk software
products.
All three agencies have a tradition of
trying, wherever possible, to accept the
input of their advisory committees, so it’s
my hope that the agencies will take these
various recommendations seriously as
they develop their strategy. I guess we will
see in January 2014, although I must also
say that the agencies do not always meet
their deadlines, especially when being shut
down by Congress for a sizable amount of
time.
Congress
While FDA has been developing its
regulatory strategies for mobile health,
Congress has been interested in the same
topic and suggesting that it may legislate in
this area. In March 2013, the House Energy
and Commerce Committee, through two
subcommittees, held three days of hearings
on the regulation of mobile health. I had
the opportunity to testify at that hearing.
Much of the hearing focused on the
medical device tax, and frankly those
on the Republican side expressed some
I obviously have no clue what the report will
say. However, I do think that the agencies
will seriously consider the input of the
advisory committee they put together as a
part of this process. In the spring of 2013,
under guidelines established by FDASIA,
the agencies pulled together 29 individuals
from a wide variety of sectors involved in
HIT. I had the opportunity to serve, and was
asked to cochair the Regulations Subgroup.
Over the course of the summer of 2013,
the advisory committee worked intensely,
sometimes having up to three conference
calls a week, to develop a comprehensive
set of inputs for the agency’s deliberations.
To be clear, we were not called to develop
a draft regulatory strategy, but rather to
identify important aspects of that strategy
that were needed to balance safety, with
innovation. The advisory committee
completed its work by the first week of
September, and made a public presentation
before ONC’s HIT Policy Committee. If
you are interested in the report, both
the written work product and an audio
recording are available on the ONC website
by going to the section on the HIT Policy
Committee.
Of particular relevance to the mHealth
segment, the advisory committee
recommended that FDA clarify several
areas including (1) the definition of clinical
decision support software, (2) the scope
of FDA regulation over accessories, (3) the
dichotomy between health and wellness,
and (4) FDA regulation of software modules.
We also made several recommendations
to improve the FDA regulatory process,
including (1) identifying ways to help
industry understand the requirements

mobi health news
XIII. Policy Making From Here (continued...)
Congress (continued...)
outrage that innovative mobile apps would
be taxed. While I wholeheartedly support
the repeal of the tax, in this particular
case it was a bit distracting because the
tax actually exempts mobile apps sold at
retail. So apps purchased by consumers
through iTunes, for example, would not be
subject to the tax.
But the tax issue aside, it seems that most
people in the room wanted to figure out a
way to ensure that innovation in mHealth
continues to flourish. Throughout the
summer of 2013, various Congressmen
and their staff were discussing different
approaches to legislation. Representative
Mike Honda (D—CA) has an interest in
creating a separate office at FDA to take
responsibility for wireless health generally,
including mHealth. The theory being that
by giving mobile health more attention
and more focus, the agency could develop
better policy more quickly. Representative
Marsha Blackburn (R—Tenn.) wants to
take on the definition of a medical device,
and separate out software type devices
from traditional physical medical devices.
Among other things, that would remove
mobile medical apps from the medical
device tax.
All of those legislative efforts are relatively
early on in their development, and I would
anticipate that Congress will wait until the
agencies have come up with their strategy
under FDASIA section 618 to see what it
says. Nonetheless, I do anticipate that 2014
will be an interesting year for mHealth on
Capitol Hill and at the agencies.
How FDA can avoid unduly treading on mHealth innovation
As Congress and the federal agencies work this fall to assess how they can improve FDA
regulation with regard to mHealth, I think it’s important for all involved to start a discussion
around what it would take to encourage innovation in mHealth. Under section 618 of
FDASIA, in formulating the government’s strategy, the agencies are supposed to encourage
continued innovation as much as possible. The question is, how should they do that?
It seems to me they ought to start by understanding the factors that drive innovation in
mHealth. So what are those factors, beyond the availability of pizza?
In this chapter, I’m going to share what I think are some best practices that support
innovation. Here we are not talking about macroeconomics and policy such as the
availability of venture capital and good IP protection, but rather microeconomics and
company conditions that need to exist for innovation to thrive.
The nature of innovation in mHealth
I divide the universe of factors important to innovation into two broad categories,
specifically (1) the act and process of innovating and (2) the business model for supporting
innovation.
The act and process of innovating
I have tried to collect best practices from leading companies in mHealth to discern how
they succeed in innovation. I’m sure this is only a partial list, but hopefully it represents a
good start in identifying what needs to be protected and allowed to flourish.
Collaboration among app developers, clinicians, medical device developers and
scientists of many sorts. Collaboration is the wellspring of innovation. Perhaps in
some areas of technology, innovation can occur from a lone, brilliant scientist
tinkering late at night in his own lab. But in the area of mHealth, true innovation
uniformly comes from collaboration among very disparate sets of expertise. After all,
mHealth often is about connecting the patient to this data, and often to his caregiver.
Finding talent wherever it might be. In a sense, this is a continuation of the
collaboration need, but here I am focused on the fact that the needed experts might
be dispersed around the world. In other areas of technology development, it’s more
traditional to bring everyone together under one roof to facilitate the development
process. In IT, it’s quite common not to bring everyone together physically but to let
them interact virtually throughout the United States and the world.
Tinkering and experimentation, with feedback loops. Any form of engineering requires
the development of prototypes, but software development in particular involves the
development of beta versions that can be tested in real world situations in order to
obtain feedback and strengthen the technology. Consequently, to make real progress
in mHealth, we need to ensure that that tinkering and experimentation can continue
in some appropriate way.
•
•
•

mobi health news
The act and process of innovating (continued...)
Major breakthroughs followed by many, many incremental
improvements. The pace of innovation is uneven. Certainly there are
inspirations in which new technologies are created, or new uses for
existing technology are identified. But those breakthroughs typically
are followed by a significant number of incremental enhancements
over sometimes a prolonged period.
Nonlinear process. Creative minds tend to zig and zag. If you add to
that collaboration where many people are working together, innovation
tends to happen here and there, not necessarily according to some
linear process. Regulatory restrictions, for example, in the name of
a quality system that attempt to make development a purely linear
process are doomed to cause confusion and unnecessary burden.
Short product lifecycles. Indeed, this is simply the other side of the
coin from the rapid progress in mHealth technology. But it’s important
also to understand and appreciate the cultural impact that the short
lifecycles have on the developers themselves. Developers thrive in an
environment in which change is constant, and progress is something
that can be made virtually every day. Fundamentally changing that
culture and environment by imposing regulatory obligations that
would dramatically lengthen the product lifecycles would have a
tremendous stifling impact on the exciting cultures that exist in these
technology developers’ organizations.
Sensible technology standards driven by industry. The promise of
mHealth depends tremendously on the interoperability of medical
devices and IT systems. Thus, for mHealth to flourish, the developers of
these technologies need to agree upon common standards to be used.
While this in a sense constrains innovation, industry organizations are
in a position to develop the standards in a way that balances the need
for innovation with the need for standardization.
Modularization of software. It never makes sense to reinvent the wheel.
Software development is no exception. Over the last few decades
hundreds of thousands of software developers have created literally
millions of software programs that accomplish a mind-boggling range
of tasks. It simply doesn’t make sense to ignore those existing software
modules when developing new programs. So instead, developers stitch
together existing programs and then add a new innovative coding to
do whatever is new or different that the developer wants to accomplish.
Sometimes this is done by drawing those modules together into a
single program, and sometimes it is effectively accomplished by a
software program being designed to interact with other software on a
given platform, such as a mobile phone. A simple example is a software
application on a mobile phone making use of the existing program
that tracks date and time. Any regulation needs to appreciate this
fundamental design dynamic.
The business model for supporting innovation
mHealth innovators must live in the real world, and
that real world has economic issues as well. The
following are at least a few of the economic factors
that need to be considered as we look to preserving
and enhancing innovation in mHealth.
Small companies. Fortunately for everyone,
mHealth in particular is not a capital-intensive
business, so small companies can engage in
innovation and product development. This
is good news, because it means that we can
open up to a broader group the opportunity to
develop innovative products. The bad news is
that these companies tend to have less capital,
and also tend to need more assistance from
government regulators in understanding and
navigating complex regulatory systems.
Venture capital and angel investment. These
small companies, because they often lack
sufficient capital from the founders, need to
seek out and obtain venture capital and angel
investments. Okay, that’s a macroeconomic
factor but I use it to lead into a microeconomic
factor. To access that capital, the innovators
need to be able to put together business plans
that identify clearly the regulatory demands and
the timetables associated with bringing their
products to market. Thus, clarity in the regulatory
pathway becomes extremely important.
Access to markets in a reasonable time. There’s
no getting around that mHealth is a business.
While we all certainly have a focus on the
patient and protecting the patient, healthcare
doesn’t work in this country if those engaged in
it can’t make a living. Thus, when determining
the appropriate level of regulation, we need
to keep in mind that the healthcare system
cannot succeed in caring for patients if those
working in it cannot operate a viable business
and cannot bring their products to the market in
a reasonable time. Again, this is partly because
the innovators are often small, and may not
have a diverse portfolio of products.
•
•
•
•
•
•
•
•

mobi health news
The business model for supporting innovation (continued...)
Joint ventures and other deals between parts of the mHealth ecosystem.
Because we are focused on technology networks, we need to appreciate
that this will mean many different forms of business agreements among
vendors supplying various components of those systems and their
customers. These deals will impact the intended use of the various
components of these mHealth systems. Regulators such as FDA focus on a
product’s intended use, so the regulatory framework will need to be flexible
to accommodate these innovative joint ventures that will undoubtedly
impact the intended use.
Reasonable and clear regulatory risk. Above we talk about the need for
a relatively clear regulatory pathway to market, but here we are focused
on regulatory liabilities associated with marketed products. For innovative
businesses to attract capital, the regulatory risks need to be reasonable and
quantifiable. These regulatory risks include such post-market obligations
as adverse event reporting and conducting recalls. In a networked
environment, presently these obligations are anything but clear.
•
•
Ambiguity and the entrepreneur
I have just suggested that clarity is often desirable in regulatory requirements.
But it is important to be precise in where clarity is desirable. In fact, depending
on the particular regulatory requirement, ambiguity can be either good or bad in
its impact on innovation.
Ambiguity can be good when it creates the opportunity for flexibility in
compliance. It’s actually okay for many regulatory standards to be written
in a general way. The quality system regulations are written at a high
level, which in a sense makes them ambiguous with regard to what they
require. But that form of ambiguity is good in that it allows flexibility and
innovation on the part of the manufacturer in determining how it will
come into compliance.
Ambiguity tends to be bad when it relates to the scope of a regulatory
requirement. Industry needs to know whether a particular requirement
applies or not. Knowing whether a given piece of software is subject
to FDA regulation can make a big difference in the cost and timeline
associated with bringing that software to market, so the developer of that
software needs a fairly clear and certain understanding of the scope of
FDA regulation. Likewise, knowing the classification of a medical device
is critical to determining what types of regulatory requirements apply.
Ambiguity there is not helpful.
•
•
So that’s my assessment of important conditions at the individual company
level that allow creative people to innovate in mHealth. My hope is that we can
begin a discussion about what the agencies should take into account as they are
developing their approach to mHealth for the future regulation.

mobi health news
XIV. International Regulation of mHealth
I’ve always found the saying, “Be careful
what you wish for; you might just get it” to
be rather condescending. In a way it suggests
that we are too stupid to manage our own
affairs. But like any popular saying, it probably
has a kernel of truth.
Frankly, I’m a little nervous about a request
made by industry for international medical
device regulators to focus on standalone
software, including mobile medical apps. At
the request of an international trade group,
on March 21, 2013, the International Medical
Device Regulators Forum (IMDRF) decided
to pursue harmonization of the regulatory
approach to standalone medical device
software. Standalone software in healthcare,
as most people use that term, would include
mobile medical apps, clinical decision
support software, electronic health records
and any other software used in healthcare
that does not drive a medical device (hence
it stands alone.)
Many of the industrialized and developing
nations around the world established IMDRF
in 2011 to provide a forum to discuss future
directions in medical device regulation, and
harmonization at an international level. The
IMDRF builds upon the work of the Global
Harmonization Task Force.
IMDRF membership includes regulators from
Australia, Brazil, Canada, China, European
Union, Japan and the United States, as well as
the World Health Organization (WHO). In the
US, for example, FDA is the participant, and
in the EU the representative is the European
Commission Directorate – General Health
and Consumers. The recent IMDRF meeting
that examined software took place in Nice
(France) from 19th to the 21st of March 2013.
The IMDRF manages its agenda by formally adopting so-called work items.
These work items then become the focus of activities between the full,
semi-annual gatherings of the Forum. In 2012, at the fall meeting in Sydney,
the DITTA (Global Diagnostic Imaging, Healthcare IT and Radiation Therapy
Trade Association) recommended the creation of a work item dedicated to
medical software. In an October 29, 2012 letter to IMDRF, DITTA wrote:
DITTA greatly appreciates the Management Committee’s further
consideration during their session on 27 September of our proposal
for a possible future IMDRF work item on medical software.
Reasons which justified our suggested work item to IMDRF are
that medical software is playing an increasingly greater role in
medical technology in product-embedded software applications or
in stand-alone software solutions. This includes but is not limited
to aspects of software vulnerability with potential impact on patient
safety. Therefore global harmonization of regulations and standards
governing medical software is critical for patient safety as well as to
the future innovation and prosperity of our industry.
Selecting standalone software as a work item is a big step as the 2-year-old
forum only maintains about a half-dozen work items. Indeed, the most
recent meeting only produced two new ones.
This is either a tremendous opportunity or a tremendous threat depending
on whether you are an optimist or pessimist. I frankly don’t know what
it is. Subject to what region you’re from, international harmonization can
either raise the tide or lower it. Some folks worry that when regulators get
together to compare notes on an issue the hurdles typically go up, kind of
a regulatory arms race, but the positive side is that harmonization can be
very helpful to international businesses.
Certainly there is a lot going on in the US with
regard to mHealth regulation, but most people in
the space can’t afford to simply ignore the rest of
the world. Indeed, even if you’re only involved in
US, this Forum has the potential to influence US
regulation. Industry needs to be actively involved
in all of these discussions to ensure the resulting
regulation is sensible, and accommodates
innovation. I just hope we like what we asked for.

mobi health news
XV. EU Regulation of mHealth
by Erik Vollebregt
mHealth is a hot topic in the EU, and the EU has firmly embedded
mHealth policy in its overarching healthcare goals in its digital policy:
“ICT can be our most powerful ally for good and affordable health care.”,
the European Commission says. Especially mHealth plays a pivotal role
in this, because it empowers people to easily take control of their own
health; the Commission is working on a Green Paper, which will launch
a public debate on that issue and a guidance document on the legal
framework applicable to health and wellbeing apps. Both of these
documents are scheduled for end of 2013.
Also, with 28 different member states working on different things,
interoperability is an important issue. That’s why the EU is planning to
propose an eHealth Interoperability Framework by 2015.
The EU is further working on a regulation on eIdentification, of which
the timing is not clear yet, but may impact mHealth services as well.
Internationally the EU will likely work on the harmonization further to
the Memorandum of Understanding signed with the FDA in 2010, and
in the TTIP negotiations.
The EU regulates mHealth in a number of ways: by means of medical
devices regulation, regulation of personal health data, reimbursement
of healthcare rules and product liability. This chapter focuses on
medical devices regulation, as the previous chapters have done. You
can find a convenient if not a little dry overview of other regulations
applicable to mHealth regulation at the EU level in the European
Commission’s Staff Working Paper on Telemedicine. The overall policy
goals are in the eHealth Action Plan, adopted in December 2012, which
looks ahead until 2020.
In the EU there is no integrated health regulation framework with a
single FDA as in the US. mHealth as a service is not regulated at the
EU level but the software to provide the service is. Individual member
states may pose constraints on the provision of healthcare services via
mHealth, or may choose to reimburse it or not. However, like in the US
states cannot just hinder interstate commerce without good reason: if
member states enact rules that hinder the provision of services from
another member state they must be able to justify them.
They must show that the rules indeed serve to achieve
a goal of protection of public health or another ground
of public policy that the EU Court has held to be a valid
justification. They must further show that the restrictions
are proportionate in light of the goal and do not go further
than necessary.
While this chapter is not the exhaustive word on software
regulation under EU medical devices rules, it provides
a lot of information to start from. You can find a lot
more detail and how-to materials on my blog at http://
medicaldeviceslegal.com. If you want an overview of
the political initiatives in the EU, the ENVI committee’s
workshop on eHealth of 24 September 2013 is a good
start.
mHealth as medical device
Under the EU medical devices directive the software used
to provide mHealth services may constitute a medical
device under the Medical Devices Directive. Software made
available to the user over the internet (directly or via
download) or via in vitro diagnostic commercial services,
which is qualified as a medical device, is subject to the
medical devices directives.
mHealth as a service is also covered by the e-Commerce
Directive, like general Software as a Service (“SaaS”). This
directive harmonises the EU member states’ laws with
respect to the provision of online services to end-users.
These laws are also controlled by EU general supervision
over the free provision of services. The European Court has
recently ruled that member states have a lot less freedom
than they thought they had in regulating the provision
of mHealth. At least, that is my reading of the Ker-Optika
judgment from 2012.

mobi health news
XV. EU Regulation of mHealth (continued...)
Don’t forget that the data that the software collects,
processes, and/or sends on to be processed elsewhere
likely constitutes ‘personal data’ in the meaning of the
EU Personal Data Directive. Mind you, the EU probably
has the strictest regime in the world for controlling
the processing of personal data and regulates ‘data
concerning health’ under the strictest rules of this
regime. If you deploy software to collect and process
health data of EU citizens, personal data regulation
should be top of mind, if only because of the privacy
by design requirements. This means that you have to
design your software in a way that it can be compliant
with these rules, and preferably already is in its default
settings. A good point to start is the helpful guidance
on processing of personal data by smart apps. You
should keep in mind that the EU is currently revising
the personal data rules to make them not only stricter
but also make them significantly more unattractive to
contravene by proposing a 2% of worldwide turnover
penalty on breaking them. Following the adoption of
the new rules, the so-called General Data Protection
Regulation, the Commission plans to issue additional
guidance on the application of EU data protection law in
the field of eHealth. We don’t know where this regulation
will land as a result of the EU discovering the degree
to which the NSA is able to access personal data across
the world. This has put a serious dent in the EU’s trust in
US companies being able to manage sensitive personal
data in the way they promise, and has led the European
Parliament to call for more controls on the export of
personal data to the US.
If the software is used to interpret data derived from an
in vitro diagnostic medical device, the software could
constitute an in vitro diagnostic medical device under
the In Vitro Diagnostics Directive (“IVDD”) . This is a
subcategory of medical devices with its own directive to
regulate in vitro diagnostic medical devices, including
apps and other standalone software that has IVD
functionality.
Like in the US, EU law divides software into two
categories: (1) standalone software and (2) accessories.
Software that comes pre-installed on the device when
the device is placed on the market is not regulated as
a separate medical device. Unlike in the US, there is
no enforcement discretion for the medical devices
authorities. Either something is a medical device and
they have enforcement power, or it is not and some other
authority has power to oversee this.
Accessories
Accessories are software that whilst not being standalone software
(a device as such) is intended specifically by the manufacturer of the
accessory to be used together with a device (which can be standalone
software) of another manufacturer to enable it to be used in accordance
with the use of the device intended by the manufacturer of the device.
Understanding that framework is important because it determines the
regulatory requirements that apply to a given piece of software. If the
software is designed, for example, to analyze data downloaded from a
blood glucose meter, the software is an accessory and will be regulated
in the same manner as the blood glucose meter. The classification and
most of the EU regulatory requirements will be dictated by how the parent
medical device is regulated. Standalone software, in contrast, is regulated
or not on its own merits, without regard to another medical device.
Categories, MDD or IVD?
If you are sure of the regulatory category in which your app falls, you
can determine its regulatory status. Typically that would be one of the
following three options:
Software that does NOT meet the legal definition of a device and is
not regulated under the EU MDD;
Software that DOES meet the legal definition of a device and can
be self-certified before it may be placed on the market or put into
service; and
Software that DOES meet the definition of a device and needs to be
certified by a notified body before it may be placed on the market or
put into service.
1.
2.
3.
Software that does not meet the legal definition of a medical device
would be, for example, a system that would not serve any of the intended
purposes set out in the definition of device in the MDD :
Diagnosis, prevention, monitoring, treatment or alleviation of
disease;
Diagnosis, monitoring, treatment, alleviation of or compensation for
an injury or handicap;
Investigation, replacement, or modification of the anatomy or of a
physiological process; and
Control of conception.
•
•
•
•

mobi health news
Categories, MDD or IVD? (continued...)
Software that does not meet this definition is typically software that may be
used in a medical context or may contain medical data, but which does not have
a medical purpose itself, such as scheduling software or documents containing
medical reference tables. See below under “Unregulated software” for more
detail.
If the software falls within the scope of the MDD, the manufacturer must take
another step to determine as what specific medical device the software is
regulated: as a ‘general’ medical device or as and in-vitro diagnostic medical
device. The latter category is regulated under yet another EU directive, the EU
In-Vitro Diagnostic Devices Directive (“IVDD”) . The IVDD regulates software that
qualifies as medical device in the above definition and is moreover intended to
be used in vitro for the examination of specimens, including blood and tissue
donations, derived from the human body, solely or principally for the purpose of
providing information:
concerning a physiological or pathological state, or
concerning a congenital abnormality, or
to determine the safety and compatibility with potential recipients, or
to monitor therapeutic measures.
•
•
•
•
With apps specifically in mind: software that is intended to create or modify
medical information might be qualified as a medical device. If such alterations
are made to facilitate the perceptual and/or interpretative tasks performed by
the healthcare professionals when reviewing medical information, (e.g. when
searching the image for findings that support a clinical hypothesis as to the
diagnosis or evolution of therapy) the software could be a medical device.
Unregulated software
Software that is outside the scope of the MDD is not regulated. This typically
concerns “software for general purposes when used in a healthcare setting” .
However, all software “when specifically intended by the manufacturer to be
used for one or more of the medical purposes set out in the definition of a
medical device, is a medical device”. So, software that is not specifically intended
by the manufacturer as medical device is not covered, even if it is used in a
medical context (like a medical reference book in an iPad app). That would for
example be general database software, reference materials and spreadsheet
software. Generally speaking, if the software does not perform an action on
data, or performs an action limited to storage, archival, communication, ‘simple
search’ or lossless compression (i.e. using a compression procedure that allows
the exact reconstruction of the original data) it is not a medical device.
There is some difference in opinion between EU member states about the scope
of the concept of ‘medical device’ in relation to software. Sweden, for example,
tends to interpret the scope of this concept in relation of software very widely.
Software that can be self-certified
The certification system for medical devices in the EU
is set up in the way that the devices falling in class I,
the lowest risk class, are not subject to review by a third
party but may be self certified by the manufacturer.
As stated above, all SOFTWARE is by default in class
I, so capable of self-certification, unless an exception
applies (see below).
Self-certification involves composition of a technical
file and design of a quality system, for example in
conformity with ISO 13485, the standard for medical
devices quality systems accepted by the EU as state of
the art.
Design controls
Building the technical file involves checking your
software against all of the ‘essential requirements’
in the MDD or IVDD. These design requirements for
software are incorporated in the MDD and for IVDs
in the IVDD, and are further implemented by means
of harmonized standards that relate to a particular
essential requirement. While the essential requirement
often gives a general description of what is required,
the harmonized standard will give you a lot more
detail. Meeting the requirements of the relevant
harmonized standard entitles you to a presumption of
conformity with the essential requirement concerned.
The process of checking involves usability
requirements with respect to your GUI, for example.
Also, your software must be validated according to the
state of the art taking into account the principles of
development lifecycle, risk management, validation
and verification. This requirement involves application
of the EN 62304:2006 standard, the EU harmonized
version of the ISO 62304 standard for this particular
essential requirement. A very good FAQ document on
the application of the EN 62304 standard was recently
released by Team NB, the association of notified bodies.
Making sure that you document your development
process in the logic of the EN 62304 process is probably
one of the biggest favours you can do yourself as a
developer. My experience is that EU authorities and
notified bodies otherwise find it very difficult (and time
consuming) to make sense of whether your software
meets the essential requirements.

mobi health news
When does software need to be certified
by a third party?
All apps that are medical devices will fall in MDD
risk class I by default, except if a classification
rule applies that bumps it up in risk class to
class IIa or IIb, because the software’s risk profile
changes. An example would be that the software
can influence or control high risk devices. If
the software has functionality that allows it to
drive a device or influences the use of a device,
it falls automatically in the same class as that
device. An example of this would be an app
that can implement the recommend action by
exercising control over another device that is in
class IIa or higher, e.g. an iPad app that assists a
cardiologist in interpreting data read out from a
patient’s pacemaker at a distance via WiFi, and
then after having obtained the cardiologist’s OK
on a suggested reconfiguration, implements the
reconfiguration of the patient’s pacemaker at a
distance.
The Standalone Software MEDDEV
The most relevant EU guidance document for
apps is MEDDEV 2.1/6. This document provides
for guidance in the application of the above
criteria and to determine if an app is a, (in vitro
diagnostic) medical device or not. It further
provides for guidance on design documentation,
many useful examples and guidance with
respect to modularization of software.
The MEDDEV contains two flow charts, one for
deciding if an app is a medical device and one
to be applied subsequently to determine if the
medical device is an in vitro diagnostic medical
device.
MDD flowchart for apps
So, you want to determine if your app is a
medical device - the medical devices flow chart
directly to the right.
Diagram 1. MDD Flowchart for Apps

mobi health news
MDD flowchart for apps (continued...)
Step 1: computer program?
Software is regulated under the MDD as a so-called ‘active device’, which means
it has to be able to act autonomously to an extent. For software this translates to
the criterion that it must be able to execute, as opposed to documents that only
contain information.
Step 2: embedded or standalone?
Software that is embedded on the device and comes pre-installed is regulated
together with the device. It does not need to be certified separately from the
device. Any updates will also be seen as updates to the device on which the device
runs.
Step 3: does it create or modify medical information?
If the software does not perform an action on data, or performs an action limited
to storage, archival, communication, ‘simple search’ or lossless compression (i.e.
using a compression procedure that allows the exact reconstruction of the original
data) it is not a medical device. ‘Simple search’ refers to the retrieval of records
by matching record metadata against record search criteria, e.g. library functions.
Simple search does not include software which provides interpretative search
results, e.g. to identify medical findings in health records or on medical images.
If the software makes alterations to medical information like measurement
readings to facilitate the perceptual and/or interpretative tasks performed by
the healthcare professionals when reviewing medical information, (e.g. when
searching the image for findings that support a clinical hypothesis as to the
diagnosis or evolution of therapy) the software is likely a medical device. The
MEDDEV mentions as examples of alterations that would be regulated:
reconstruction,
lossy compression,
filtering,
pattern recognition,
modelling,
interpolation,
transformation,
classification (e.g. scoring of tumors against specific criteria),
segmentation,
registration (e.g. mapping a data set to a model or atlas or to another data
set, e.g. registering an MRI image on a CT image),
calculations,
quantification,
qualification (e.g. comparison of data against references),
rendering,
visualisation, and
interpretation.
For example: plotting data points over time against
a bandwidth of (un)healthy values would typically
be regulated functionality.
Step 4:
is the software for the benefit of individual patients?
This step is to determine if the data provides
actionable information relating to one or more
specific patients. Examples of software that are not
considered as being
for the benefit of individual patients are those
which aggregate population data, provide generic
diagnostic or treatment pathways, scientific
literature, medical atlases, models and templates
as well as software for epidemiologic studies or
registers.
Step 5:
is the functionality within the scope of the definition
of medical device?
This step requires application of the definition of
‘medical device’ i.e. is the software intended for
either of:
Diagnosis, prevention, monitoring, treatment
or alleviation of disease;
Diagnosis, monitoring, treatment, alleviation
of or compensation for an injury or handicap;
Investigation, replacement, or modification of
the anatomy or of a physiological process; or
Control of conception.
•
•
•
•
Step 6:
if it is not a device, is it an accessory to a device?
Apps may also be intended to enable medical
devices to function according to their intended
use, for example an app that allows controlling IV
pumps in a hospital ward at a distance.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

mobi health news
IVD flowchart for apps
The IVD flowchart looks as follows:
Step 1: Medical device?
Determine if the app is a medical device
by means of the flowchart for medical
devices. If the app is not a medical device
or an accessory to a medical device, it may
(theoretically) still be an accessory to an
IVD (see below in step 5).
Step 2: In vitro diagnostic medical device?
Determine is the app is intended to
function as a stand alone software with
expert function, by providing information
on e.g. differential diagnosis, prediction of
the risks of developing a disease, prediction
of the percentage of efficiency or failure
(e.g. of a treatment), or identifying species
of bacteria.
Step 3: Data from IVD?
If the information that is the input for the
expert system is provided by an IVD device
(e.g. a blood glucose meter) the software
containing the expert system is an IVD as
well.
Step 4: Data from only from MDD?
If the information provided by the software
is based on data obtained from medical
devices only, the software would be a
medical device.
Step 5/6: Accessory?
These steps are identical and serve to
determine if the app is an accessory under
the IVDD. The accessory criterion under
the MDD is identical to the accessory
criterion under the IVDD, see above under
Accessories.
Diagram 2. IVD Flowchart for Apps
Revision of the MDD and IVDD and other developments
EU medical devices law with respect to apps is currently very much in flux:
Both the MDD and IVDD are currently under revision and the legislative proposals
contain both more detail on software and stricter requirements:
A much expanded definition of ‘medical device’ which includes software for
‘indirect medical purposes’. The EU Parliament’s ENVI Committee has voted that
this decision should be adopted, even if nobody has a clue of how broad the
scope of ‘indirect medical purpose’ is. Would that include apps that make sure
that you move enough during the day to stay at a healthy weight? Nobody
knows at this stage and the definition may still change further along in the
legislative procedure.
•
•

mobi health news
A much expanded definition of ‘accessory’, which includes also devices that
‘assist’ a medical device in its intended purpose. The concept of ‘assist’ was
already included in the GHTF’s definition of medical device , but the EU will
now implement this. The EU Parliament’s ENVI Committee has voted that this
decision should be adopted.
oRules for the provision of medical devices and IVD functionality at a distance
as service, so-called medical device as service.
Design requirements for software that runs on ‘mobile computing platforms’.
Risk management measures regarding ‘the risk associated with the possible
negative interaction between software and the environment within which it
operates and interacts’.
Clinical data requirements with respect to software validation and verification.
•
•
•
•
MEDDEV 2.1/6 on standalone software is under revision and may be influenced by the
Swedish lobby for a wider scope of regulation of software.
The EN 62304 standard is getting old and there are initiatives at ISO level to update it
with the IEC 82304-1 “Health Software” standard. This International Standard applies
to the safety of health software that is designed to operate on general purpose IT
platforms and intended to be placed on the market (or be made available) without a
specific hardware. In other words, this standard has mHealth written all over it. This
standard could well be harmonized under the EU MDD and IVDD in the near future.
•
•
All of this means that if you are currently developing apps or have them on the market
in the EU, you must closely monitor these developments. Especially with respect to the
new medical devices and IVD regulations the process is technically complex with a lot
of policy involved. Either the regulations are finished in early 2014, well before the EU
parliamentary elections in May 2014 and they enter into force in 2014, or they will be
delayed by the elections and may be put on the agenda again after the elections in a new
political constellation and will probably not enter into force before 2015/2016.

mobi health news
Terms and Conditions
Chester Street Publishing, Inc. (“Chester Street”) is pleased to to publish FDA Regulation of Mobile Health (Second
Edition) (the “Publication” or the “Report”) for viewing and download via the World Wide Web. The Report is avail-able
under the following Terms and Conditions:
NO ADVICE: The Material of this Report is for informational purposes only.
LIMITATION OF LIABILITY: Reader is entirely liable for activities conducted by Reader or anyone else in connection
with Reader’s use of the Material of this Report. If Reader is dissatisfied with the Report or with these Terms of Use,
Reader’s sole and exclusive remedy is to stop using the Report. Chester Street will not pay Reader any damages.
Chester Street does not warrant the accuracy, completeness, currentness or other characteristics of any Material
available in this Report. Chester Street will not be liable for any loss or injury resulting directly or indirectly from
Reader’s interpretation and/or use of the content of this Report, whether or not caused in whole or in part by Ches-ter
Street’s negligence or by contingencies within or beyond Chester Street’s control. Neither Chester Street, nor
suppliers of Third-Party Content, are responsible or liable, directly or indirectly, for any loss or damage caused by
use of or reliance on or inability to use or access this Report.
READER’S ACCESS TO AND USE OF CHESTER STREET’S REPORT MATERIALS ARE AT READER’S SOLE RISK. CHESTER
STREET REPORTS ARE PROVIDED “AS IS” AND “AS AVAILABLE.” CHESTER STREET REPORTS ARE FOR Reader’S PER-SONAL
USE ONLY AND CHESTER STREET MAKES NO REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED. CHESTER STREET EXPRESSLY DISCLAIMS ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE OR USE.
THE READER IS ALLOWED TO: (1) Save the Publication to the hard disk of a personal computer; (2) Make 1 print
out of the complete Publication for personal use only; (3) Print out a reasonable number of pages for personal use
and for departmental use; (4) Include information from the Publication in presentations and internal documents
provided the material credits the copyright owner (MobiHealthNews).
THE READER IS NOT ALLOWED TO: Modify or re-work the Publication in any way and must not distribute, lease, rent,
sub-license, charge or sell the publication.
COPYRIGHT: Reader is permitted to read the PDF version using an HTML browser and/or Acrobat software, and to
download it for Reader’s personal use. Chester Street owns the copyright or the publishing rights to the Report and
the Reader acquires no ownership rights. The Reader may not include material from the Report in published work
without clearly crediting the copyright owner. In the event of a breach of these terms and conditions Chester Street
has the right to ask for reasonable costs. All information Chester Street collects is subject to our privacy policy, avail-able
at: http://mobihealthnews.com/privacy-policy/.
Chester Street maintains full copyright protection on the Report. Reader is NOT permitted to amend, copy, reprint,
offer for sale, or otherwise re-use material from these documents without explicit written permission from Chester
Street. Readers who acquire the HTML/PDF version of Chester Street’s Report from a source other than Chester
Street should be conscious of the fact that HTML/PDF is a revisable format and that the un-official, probably illegal,
version they acquire might have been changed from the original.

FDA's Regulation Of Mobile Health

More Related Content

What's hot

Viewers also liked

Similar to FDA's Regulation Of Mobile Health

Recently uploaded

FDA's Regulation Of Mobile Health