Navigating Regulatory Uncertainty for Smartphones

Navigating Regulatory Uncertainty for Smartphones

Uncertainty abounds regarding the potential regulation of smartphone apps by FDA and other international regulatory bodies. For this discussion we’ll divide uncertainty into two categories, uncertainty due to a lack of knowledge about the potential regulations on the part of manufacturers and uncertainty about just what various regulatory agencies are doing – or going to do – about new and innovative products that meet the definition of a medical device.

What is a Medical Device?

Let’s start with the first category; there is an astounding amount of misinformation and just plain wrong-headedness on the part of many vendors (and providers) who are outside the ranks of traditional medical device manufacturers. The first issue we need to address is the question, “What is a medical device?” Here’s the legal definition of a medical device, courtesy of FDA:

A device is:

  • an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
    • recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
    • intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
    • intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

If you look up the word contrivance, you’ll see that almost anything can be a medical device:  tongue depressor, superglue, software, even services – let your imagination run free. If it quacks like a duck – is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease (or other health related conditions like injury), it is a duck. Calling it a chicken or even a turkey does not change a regulatory agency’s perception of the quacking product’s “duckness.”

There is also a new classification of medical device call a Medical Device Data System, or MDDS. An MDDS acquires data from one or more medical devices, stores it, can transform it per written specifications (e.g., change units of measurements or labels of data elements), display the data and make the data available to other applications. Thus if a product meets the definition of an MDDS it is a duck, and cannot claim to be something else because all their doing is automated record keeping.

Automated record keeping is generally held by regulators to not be a medical device – but the first step of acquiring data from the medical device does qualify as a medical device. The only way to acquire medical device data without being categorized as an MDDS is to get the data from another application that is an MDDS, or have users hand enter the data into your application.

I’ve heard the argument that, “we’re only storing the data, and that’s not a medical device.” This can be true, if what you’re doing with the data (besides storing it) does not meet the definition of a medical device, and if you’re not acquiring the data directly from the medical device (because that’s an MDDS).

The Regulatory Significance of Marketing Claims

Fierce Mobile Healthcare captured a great quote in a story the other day by Bakul Patel, a policy advisor in CDRH at FDA about the potential for smart phone app regulation,

Companies that make health claims in their marketing, or actually perform clinical operations on their mobile devices, may be the first targets.

So we’ve already dealt with the second part of Patel’s statement, about whether the product preforms clinical operations and thus meets the definition of a medical device. The first part, about marketing claims is next important regulatory concept. Claims are also referred to as “labeling” by FDA, and include a product’s positioning statement, brochures, advertisements, white papers, and what sales reps tell customers verbally, in email or PowerPoint presentations.

You can’t take a duck and call it a chicken in your marketing claims if its really a duck. Likewise, if there’s a likelihood customers will use it as a duck after purchase, regulators will treat it as a duck. For example, say you develop software to view DICOM images (xrays, CT scans, MRIs, maybe some sexy 3D reconstructions) on the iPhone and iPad – but you tell physicians they can’t use your product to render an actual diagnosis. What then are they to use the app for, a novelty? A similar product was identified as a duck by FDA a couple years ago, and just recently received FDA clearance for sale by the vendor.

Another important thing regarding claims about medical devices is that regulatory agencies will treat your product like a regulated medical device if you make claims that your product is a medical device. For example, Apple came perilously close to claiming the iPhone was a medical device during their iOS 3.0 intro event. Since then, Apple’s toned down their aggressive marketing of the iPhone (and iPad) as medical devices, though they still show examples of medical device applications in commercials, at events and on their web site. In another example, a few years ago Cisco produced a brochure that showed a patient monitor alarm message and associated waveform displayed on a Cisco VoIP handset. This quickly drew a visit by FDA and a “request” to withdraw the brochure, which they did.

The bottom line is whether your product is a medical device or not, if you make claims that give the impression that it is a medical device, you are likely to find yourself regulated – or claw back your claims.

Regulation of Off-the-Shelf Technologies

A similar topic that is rife with confusion is whether generic products like smartphones, wireless carriers or network equipment will be regulated. Currently available smartphones, by themselves, do not meet the definition of a medical device. There are three ways the smartphone itself could become regulated:

  1. The smartphone manufacturer could make medical device claims – even though the product does not meet the definition of a medical device
  2. The smartphone manufacturer could add features, say an interface to acquire data from sensors like glucometers, implanted pacemakers or some other medical device
  3. A third party could develop a product, notably software that runs on the smartphone, and perhaps other components, that all together meet the definition of a medical device

Item one above relates to the Apple and Cisco examples used earlier. If your product is not a duck, don’t make claims that it is and you need not have to deal with FDA and their international brotherhood of regulators.

The second scenario above is really just as straightforward. If HCI built an Android smartphone with an interface for glucometers, and then promoted the product to diabetics like, “Hey, buy my smartphone to acquire data from your glucometer to better manage your diabetes,” they’ve transformed their product into a medical device. Another similar situation would be where the smartphone manufacturer creates a port on their phone to attach a blood pressure cuff, which they sell as an accessory to their smartphone. A generic equipment manufacturer who does something like this will likely see someone from FDA in the very near future.

Now what about a generic interface like Bluetooth? What if a third party uses that Bluetooth interface already built into the smartphone to connect a glucometer to help diabetics manage their disease? Then the third party becomes the regulated entity, and the smartphone is just another off-the-shelf component that goes into the overall medical device. In this case, the medical device is regulated – through the third party/manufacturer – and the smartphone maker never hears from FDA. From this example you see that which manufacturer ends up getting regulated is what’s important, and not the device itself.

Bottom line, general purpose smartphones, tablets, personal computers, wireless carrier’s networks, LAN equipment – none of these manufacturers will be regulated, with one exception. If the general purpose equipment manufacturer makes medical device claims, the general purpose equipment manufacturer will be regulated. If a third party uses general purpose equipment as off-the-shelf technology in their medical device, the third party gets regulated and not the general purpose equipment manufacturer. (Of course there’s a third possibility where the general purpose manufacturer adds specific features to their product transforming it into a medical device – which we’ve addressed above.)

So when people ask, “Is the FDA is going to regulate smartphones?” they are asking the wrong question. If the smartphones are components in a medical device, or transformed into a medical device themselves, the manufacturer of the medical device will be regulated. It is true that indirectly smartphones are regulated by FDA, but such a statement really distorts what’s actually going on.

Regulatory Agency Actions

Regulators have what’s called, “discretion,” whereby they decide if they want to ignore something they legally could pursue or not. This can be divided into regulatory discretion, where they chose not to regulate, and enforcement discretion where they do regulate.

It is common for regulators to observe the development of new medical device markets without enforcing regulations, provided there is no undue risk to patient safety. This action (or inaction) is called regulatory discretion. At some point, when the market has matured sufficiently, and/or FDA’s understanding of the new market matures, or risk to patient safety becomes to big to ignore, the regulator shifts from regulatory discretion to enforcement discretion. Regulators may signal this shift through a reclassification of the device category (as FDA recently did with MDDS), by publishing a guidance document (there’s one in the works by FDA on smartphones), or they may simply start enforcing regulations.

Regulatory discretion in no way limits a regulator’s future actions. Just because they chose to look the other way before doesn’t mean they can’t change their minds – at any time – and later pursue enforcement. This is true in relationship to past inaction and future regulatory actions, and the retroactive enforcement of actions that previously received regulator discretion.

Regulators rarely, if ever, publicly announce a policy of regulatory discretion regarding a medical device market or product. They only sometimes signal a shift to regulatory discretion. Nor do regulators clearly state that, “if you do x, we will not pursue enforcement, but if you do y we will pursue enforcement.” It is possible to infer such distinctions retroactively, but with nothing on the record either way this becomes an exercise in supposition.

What types of products meet the legal definition of a medical device is pretty black and white; what makes things confusing is all the products that meet the definition that aren’t actively regulated due to discretion. All of this discretion creates a lot of uncertainty for manufacturers. This uncertainty requires management to make judgement calls about how much regulatory risk they want to assume with a given product in a given market. Unlike mature markets like hospital patient monitors, emerging markets like smartphone apps have a lot of uncertainty.

Probably the biggest risks are having to incur unanticipated costs and time-to-market to become a regulated manufacturer and, if necessary, receive clearance from the regulatory agency to sell the product. The manufacturer of the smartphone app for viewing DICOM images mentioned above was delayed 2 years in getting their product to market, and they had to bear significant costs to bring company operations in to regulatory compliance and generate clinical data to demonstrate their products safety and effectiveness. If they’d had a regulatory strategy from the get-go, their costs would have been substantially less (but still more than an equivalent product that’s not a medical device) and probably gotten to market sooner. Eliminating regulatory uncertainty is all about getting informed and planing, rather than having to react to something you’d hoped to avoid.

What is a Manufacturer to Do?

The first thing is to pay attention! Actively track regulators to learn about any enforcement actions against vendors or products similar to yours. Seek access to informal or back channel communications with regulators. You can do this by attending meetings attended by regulators and building personal relationships with regulators through standards work and other means. If your company lacks the resources to do these things directly, engage with someone who can do them for you. Next, continuously apply your awareness of the regulatory environment around your product to your specific situation.

If you manufacture general purpose products or services (e.g., smart phones, cellular carrier networks, Ethernet or Wi-Fi equipment) and you know your products are being used in medical devices, you should probably have or develop a regulatory strategy to ensure you maintain your unregulated status. If you’re a general purpose manufacturer or service provider, know your stuff is used in medical devices, and want to encourage the medical device market for your products, you definitely need a regulatory strategy. Encouraging the use of your products or services in medical devices can cause you to become regulated, if you don’t do things in the right way.

If you are using off-the-shelf components and creating your own stuff (writing software, creating services or developing specialized hardware) for health care related activities, you too should have a regulatory strategy. If your product does not meet the definition of a medical device, you need a strategy that clearly demarcates what makes your product not a medical device, and the actions you will take to maintain those distinctions.

Most likely your product does meet the definition of a medical device, and in many nascent markets – like smartphone apps – enforcement discretion is not being pursued by regulators. In that case you need a more complex strategy. Your strategy should include:

  • An attempt to discern what, if any, actions will cause regulatory discretion to shift to enforcement, and if or how to avoid those actions
  • Judge the maturity of your market and any indicators (especially actions or comments by regulators) as to when regulators might shift from regulatory discretion to enforcement
  • Evaluate the impact of being regulated on both your operations and external market factors like potential competitive advantage – it is common for some companies to voluntarily be regulated before the actual shift to enforcement discretion
  • Develop your plan for when and how to become regulated

Like any evolving situation, the biggest challenge comes from not knowing what you don’t know. Hope is not a plan, and the worst thing you can do is nothing. Start turning over those rocks – you may find a few icky things, but there’s no monsters.

Related posts:

Charting Your Regulatory Course

Final MDDS Rule Signals FDA Shift to Enforcement

Comments on FDA Wireless Medical Device Guidance

Facing FDA Regulations for the First Time

The photo accompanying this post was taken at the 2010 mHealth Summit – this is definitely a medical device!

Share

4 comments

  1. As usual, an insightful, enjoyable, and informative analysis of the intricacies within the medical device space.

    I always look forward to your posts. http://www.mddionline.com/blog/devicetalk/smartphones-back-away-regulatory-claims-whats-your-strategy

    Thanks, Tim.

    Heather

  2. Thank you many times over, Tim. You always illuminate the vagueries for me. I’m curious how you see this from the provider perspective. From some viewpoints one could say that our entire network is an MDDS because it transports medical information to and from devices. Does the fact that it’s more “general purpose” exclude it from regulation? You also mention the onus on the marketing claims…if we’re simply creating interfaces to move PDF snapshots of medical device data to the EMR for our own purposes alone and not selling it to anyone else, does that make us a duck?

  3. Kate you touch on two issues, 1) what makes a provider a manufacturer that can be regulated by FDA, and 2) what is a medical device, especially as it relates to general purpose IT components.

    To put it simply, a provider becomes a manufacturer by creating something that meets the definition of a medical device. In the vast majority of cases, the FDA choses to exercise regulatory discretion and does not pursue enforcement against providers. There are also things providers may do that raise the risk of enforcement (like marketing your hospital to patients by highlighting the medical device you’ve created, or selling the device to other providers).

    A system that acquires data from medical devices and converts it into a PDF (or HL7 messages, or any other format) is a MDDS. If you’re simply moving a PDF produced by one system and sending it to an EMR is not a MDDS. In this example, the product that creates the PDF is either a MDDS or an accessory to the medical device.

    The final rule defines an MDDS pretty narrowly. Don’t worry, your enterprise network isn’t an MDDS. But, if you’ve got a medical device system (including an MDDS) is running on your network, your network is a component of the medical device.

    The responsibility for specifying network configuration and performance is the responsibility of the medical device manufacturer. The manufacturer is also responsible for ensuring that the hospital’s network meets their device’s specifications at installation. Hospitals who insist that a medical device manufacturer install their system with different network specifications are typically asked to sign a letter that states that the hospital is modifying a regulated medical device and releases the manufacturer from liability for the entire system.

    After the system is installed, it is the hospital’s responsibility to maintain the network to the medical device system’s specifications. The manufacturer is responsible for doing the verification testing of network infrastructure upgrades and new models, and telling hospitals when they can be installed (because they have been verification tested).

    To bring both threads together, FDA has had a growing concern about the impact of connectivity and device interoperability on patient safety in hospitals for years. For example, FDA instigated IEC 80001. Their concern is providers doing things that haven’t gone through a basic quality system, device reporting, and in cases of devices with higher patient risk, received a thorough review. There are two ways this can happen – installed medical devices are knowingly or unknowingly modified by providers, and when providers develop their own medical devices.

    One could argue that developing a MDDS is a systems integration role, and can be viewed as a natural task for a hospital IT department. It’s understandable that hospitals would want to create MDDS; with the ongoing automation of hospital workflow, this desire will only grow. This appears to be at the root of the FDA’s recent interest in perhaps regulating providers as manufacturers. (Sadly, they don’t usually announce things like this and one is left reading the tea leaves of enforcement actions against others, public announcements, what’s said at public meetings, etc.)

Trackbacks/Pingbacks

  1. When Cell Phones Become Medical Devices | Bob on Medical Device Software - [...] UPDATE (4/19/11): Navigating Regulatory Uncertainty for Smartphones [...]
  2. How Big a Loophole is “Wellness”? | Medical Connectivity - [...] discussed in our earlier posts on apps regulation (here and here), an app is a medical device if its meets …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>