Photo of Erin M. Bosman

“My Google Home Mini was inadvertently spying on me 24/7 due to a hardware flaw,” wrote a tech blogger who purchased Google Inc.’s latest internet of things (IoT) device. Following the incident, a pact of consumer advocacy groups insisted the U.S. Consumer Product Safety Commission (CPSC) recall the Google smart speaker due to privacy concerns arising when the device recorded all audio without voice command prompts.

The CPSC is charged with protecting consumers from products that pose potential hazards. Traditionally, this has meant hazards that may cause physical injury or property damage. But as internet-connected household products continue to proliferate, issues like the “always-on” Google Home Mini raise an important question: Where does cybersecurity of consumer IoT devices fit within the current legal framework governing consumer products?

The Explosion of IoT

Forecasts predict that by 2020 IoT devices will account for 24 billion of the 34 billion devices connected to the internet. According to a recent Gemalto survey, “[a] hacker controlling IoT devices is the most common concern for consumers (65%), while six in ten (60%) worry about their data being stolen.”

The rapid growth of the IoT market and continued integration into daily life raises the question of which regulatory body or bodies, if any, should be responsible for consumer safety when it comes to cybersecurity for consumer IoT devices.

The Intersection of Consumer Product Safety, Privacy and Cybersecurity

The CPSC’s jurisdiction has traditionally been limited to physical injury and property damage. It is “charged with protecting the public from unreasonable risks of injury or death associated with the use of the thousands of types of consumer products under the agency’s jurisdiction.” Continue Reading Connected Devices Bring New Product Liability Challenges

Blue Touchscreen Smart phones with colorful medical application icons

Health care apps are one of the most important and growing segments in the ecosystem known as the Internet of Things (IoT). After the recent amendments to the Health Insurance Portability and Accountability Act (HIPAA) that—among other things—broadened the definition of a “Business Associate,” many technology companies found themselves wondering whether they were, or were not, subject to HIPAA. Health and Human Services (HHS) recently issued some guidance, Health App Use Scenarios & HIPAA, that attempts to provide some clarity on these issues for app developers.

HIPAA, while broad in some ways, is actually somewhat narrow in its application. It does not apply to all medical information. Instead, it primarily focuses on “Covered Entities,” or CEs. A CE is a health care provider that conducts certain transactions in electronic form, a health care clearinghouse, or a health plan. If your company does not meet those criteria, then it is not a CE, and not subject to HIPAA as a CE.

While that analysis is an important step, it is not the final step in assessing whether HIPAA impacts your app. A company that does not meet the definition of a CE can still be a “Business Associate,” or BA—in essence a service provider for a CE—if it receives, maintains, or transmits Personal Health Information (PHI) on behalf of a CE. As we will see, the “on behalf of” language is critical.

In the emerging realm of health care apps, another distinction with its own set of acronyms is also important—the difference between an EHR and a PHR. Electronic Health Records (EHRs) are electronic records that are, in essence, created or maintained by a CE or a BA. They are official records that facilitate medical treatment, and they are subject to HIPAA and other medical record requirements. At their core, they are provider-centric records.

Personal Health Records (PHRs) are a related but distinct concept. PHRs are medical records that typically are electronic, but consumer-facing and not necessarily part of a patient’s medical file. While related to EHRs and interoperability (that is, the ability of all necessary health care providers to be able to review and place a patient’s medical information into an electronic chart), the purpose of PHRs is to inform patients rather than to serve as the basis for treatment, which is the purpose of an EHR. This distinction is important in understanding the guidance that HHS recently provided.

The first scenario that HHS evaluates in its guidance is one that is becoming increasingly common:

A consumer downloads a health app to her smartphone. She populates it with her own information. For example, she inputs blood glucose levels and blood pressure readings that she obtained herself using home health equipment.

In this scenario, HHS concludes that the app developer is not a BA, and therefore HIPAA doesn’t apply, because the consumer is using the app to create a PHR, and the health care providers are not involved. This scenario is common in the personal health space, and likely applies to some of the health and fitness trackers on the market.

The second scenario is also a common one, but it has more of a connection to health care providers:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. She downloads data from her doctor’s EHR through a patient portal, onto her computer and then uploads it into the app. She also adds her own information to the app.

Despite the connection to an EHR, HHS does not believe that the app developer is a BA within HIPAA, even though it is receiving PHI from a CE. In this case, the app developer was not hired by the CE to “provide or facilitate” the service; hence, it is not operating “on behalf of” the CE, and in essence the EHR information becomes a PHR once transmitted to the app.

The third scenario moves closer to the HIPAA line, but still does not cross it:

A doctor counsels a patient that his BMI is too high, and recommends a particular app that tracks diet, exercise, and weight. The patient downloads the app to his smartphone and uses it to send a summary report to his doctor before his next appointment.

Despite the transmission of medical information to a CE, and the doctor’s recommendation of the app, HHS does not believe this app developer is a BA. This is again due to the “on behalf of” language in the definition of a BA. In sum, the transmission of information to a CE, by itself, does not make the app developer a BA.

Interoperability is a key issue with EHRs, and at times entities will enter into Interoperability Agreements, as explained by HHS in the next scenario:

A consumer downloads a health app to her smartphone that is designed to help her manage a chronic condition. A health care provider and the app developer have entered into an interoperability arrangement at the consumer’s request that facilitates the secure exchange of consumer information between the provider EHR and the app. The consumer populates information on the app and directs the app to transmit the information to the provider’s EHR. The consumer is able to access test results from the provider through the app.

Despite the transmission of medical information to a CE, as well as an interoperability agreement, the app developer in this case is still not a BA because the agreement was initiated by the consumer. Therefore, even in this scenario, the transmission is not “on behalf of” a CE.

The next scenario presented by HHS moves past an agreement initiated by the consumer, and into a scenario that does trigger HIPAA, according to HHS:

At direction of her provider, a patient downloads a health app to her smartphone. The provider has contracted with app developer for patient management services, including remote patient health counseling, monitoring of patients’ food and exercise, patient messaging, EHR integration and application interfaces. Information that the patient inputs into the app is automatically incorporated into provider EHR.

The key factor for HHS in this scenario is that the provider contracted with the app developer for patient management services that involve creating, receiving, and transmitting PHI, and the app is part of those services.

Finally, HHS provided a scenario that is essentially a split or hybrid scenario:

A consumer downloads to her smartphone a mobile PHR app offered by her health plan that offers users in its network the ability to request, download and store health plan records and to check the status of claims and coverage decisions. The app also contains the plan’s wellness tools for members, so that they can track their progress in improving their health. The health plan analyzes health information and data about app usage to understand effectiveness of its health and wellness offerings. App developer also offers a separate, direct-to-consumer version of the app that consumers can use to store, manage, and organize their health records, to improve their health habits and to send health information to providers.

In this case, the portion of the app that is offered by the health plan triggers HIPAA and the developer is a BA, but this does not extend to the direct-to-consumer side of the business. If the app developer keeps the data separate, then, according to HHS, “the developer does not need to apply HIPAA protections to the consumer information obtained through the ‘direct-to-consumer’ app.” It appears that HHS is unofficially recognizing a hybrid designation for app developers, though the concept is, in actual terms, one more appropriately applied to CEs.

HHS offered a series of questions that app developers who are not CEs can ask to determine whether they are a BA:

HHS offered a series of questions that app developers who are not CEs can ask to determine if they are or are not a BA:

  • Does your health app create, receive, maintain, or transmit identifiable information?
  • Who are your clients? How are you funded?
    • Are your clients covered entities?
      • e.g., hospitals, doctor’s offices, clinics, pharmacies, or other health care providers who conduct electronic transactions;
      • health insurance issuers; health or wellness program related to a health plan offered by an employer
    • Were you hired by, or are you paid for your service or product by, a covered entity? Or another business contracted to a covered entity?
    • Does a covered entity (or a business associate acting on its behalf) direct you to create, receive, maintain or disclose information related to a patient or health plan member?

Even though an app developer may not be covered by HIPAA, HHS notes other existing guidance regarding apps, including direction from the Federal Trade Commission. This guidance, as well as any applicable laws, should be considered if HIPAA is not applicable.

As the IoT becomes more ubiquitous, novel apps will appear allowing us to gather and process more health information. App developers who wish to create health-related apps should factor this guidance in early so that they can understand the rules of the road and determine whether HIPAA applies.

The HHS guidance can be found here.

Last week the Food and Drug Administration (FDA) promulgated two much-anticipated draft guidance documents on using social media to present information about prescription drugs and medical devices. The draft guidance documents, which were originally promised by the FDA in 2010, represent the FDA’s latest attempt to provide direction for drug and device manufacturers concerning how and when they may use social media.


Drug and device labeling and promotion are highly regulated activities, subject to onerous approval requirements enforced by the FDA under the Federal Food, Drug, and Cosmetic Act (the “Act”). Under the Act, “labeling” includes “all labels and other written, printed, or graphic matter” that “accompany” a drug or device. 21 U.S.C. § 321(m); 21 C.F.R. § 1.3(a). This definition has been broadly interpreted by the courts to include materials that supplement or explain a drug or device, even when there is no physical attachment to the drug. See Kordel v. United States, 335 U.S. 345, 350 (1948).

Rapidly growing Internet-based technologies have made it quicker and easier for both manufacturers and independent third parties to disseminate information about drugs and devices. This has led to a host of issues including (1) what drug companies can say online about their drugs without violating the “misbranding” regulations; and (2) what drug companies can do with what third parties have said online about their drugs. The guidance documents attempt to answer both of these questions.

The Twitter Guidance: “Internet/Social Media Platforms with Character Space Limitations – Presenting Risk and Benefit Information for Prescription Drugs and Medical Devices”

The FDA’s position concerning manufacturers presenting “benefit information” for regulated drugs on electronic platforms with character space limitations is laid out in the Twitter Guidance. This Guidance instructs companies on the steps to take to avoid inadvertently “misbranding” a drug by providing information about a drug’s benefits without disclosing accompanying risks. With that in mind, the Twitter Guidance provides the following direction for drug companies seeking to use space-limited social media platforms:

  • Include the brand and established name, dosage form, and ingredient information;
  • Ensure that any benefit information provided is accurate;
  • Accompany benefit information with risk information;
  • Provide direct access to a more complete discussion of the risks associated with the drug or device. Notably, the Twitter Guidance says the link should lead to a page devoted “exclusively” to risk information; and
  • If both benefit and risk information cannot be communicated within the space limit, consider using a different platform.

To prove that it is not impossible to provide the required information within Twitter’s 140 character limit (just very difficult), the Twitter Guidance provides the following – entirely fictional – example of an acceptable tweet:

Notably, this example from the FDA might not prove helpful in reality, especially considering that many drugs would be required to list more than one risk.

The main take-away from the Twitter Guidance is nothing new: to avoid enforcement, provide “truthful, accurate, non-misleading, and balanced product promotion.” If a company cannot achieve this delicate balance within Twitter’s space limitations, it should “reconsider using that platform for the intended promotional message.”

Continue Reading Drugs and the Internet: FDA Distributes New Draft Guidance Regarding Social Media Platforms and Prescription Drugs

In late May 2013, the U.S. Food and Drug Administration (FDA) sent an enforcement letter to a mobile medical app developer for failing to obtain a 510(k) clearance before marketing the app, which the FDA said appears to be a “device” under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FDCA). The mobile app—the uChek Urine Analyzer developed by Biosense Technologies Private Limited and available through the iTunes App store—allows a user to read urine dipsticks using a camera phone to screen for diabetes and urinary tract infections. The FDA’s letter signals the type of oversight the FDA intends to exercise over mobile medical app developers, although the agency has not released final guidance in this murky area.

FDA Previously Indicated Light Regulation of Medical Mobile Apps

In March, Congress urged the FDA to clarify the regulation of mobile medical apps in three days of hearings before the House Energy and Commerce Committee. The FDA generally relieved concerns raised by the mobile communications industry, which had feared heavy regulation of mobile phones and tablets as medical devices. Christy Foreman, the Director of the Office of Device Evaluation in the Center for Devices and Radiological Health (CDRH) at the FDA, testified before the committee that the FDA intends to limit regulation to a small subset of apps, in accordance with the FDA’s July 2011 draft guidance on mobile medical apps.

The FDA proposed a narrowly tailored approach focusing on apps that could threaten patient safety if they do not work as intended. These include apps that either: (1) affect the performance or functionality of a currently regulated medical device or (2) have traditionally been considered medical devices. Consistent with this philosophy, the agency does not intend to regulate mundane apps that help people achieve a healthier lifestyle, such as pedometers or calorie counters. Nor does the agency plan to regulate apps that track medical data but otherwise do not meet the definition of “device” in section 201(h) of the FDCA because they are not intended to diagnose, treat, or cure conditions or diseases.

Specifically, the 2011 draft guidance indicated that the FDA will regulate mobile apps that qualify as medical devices under section 201(h) and that are intended to perform one of two functions: (1) serve as an accessory to a regulated medical device—for example, an app that allows doctors to diagnose patients by viewing medical images on a tablet; or (2) transform a mobile platform into a regulated medical device—for example, an app that allows a patient to measure blood glucose with a smartphone. The FDA’s recent enforcement letter to Biosense falls squarely in line with this proposed regulatory scheme. As the FDA noted in its letter, the uChek app is intended for use with urinalysis dipsticks that have received 510(k) clearance for “direct visual reading.” However, the app allows a mobile phone to analyze the dipsticks and that means “the phone and device as a whole functions as an automated strip reader” that requires new clearance.

FDA Does Not Intend to Regulate Other Mobile Technology

In a prepared statement released on the day of her testimony, Foreman laid out the boundaries of the FDA’s proposed mobile medical app policy. The statement made clear that the FDA does not intend to regulate mobile technology apart from the medical apps themselves. Thus, the FDA will not regulate the sale or general consumer use of smartphones or tablets. Entities that solely distribute mobile medical apps (such as owners and operators of the “iTunes App store” or the “Android market”) will not be considered medical device manufacturers. And mobile platform manufacturers will not be deemed medical device manufacturers simply because their platforms support mobile medical apps regulated by the FDA. Based on these statements, smartphone manufacturers and app distributors can put to rest for now any concerns they might have had about FDA oversight regarding health-related mobile apps.

FDA’s Statements on Mobile App Regulation Ease Uncertainty in Industry

Congress held the recent hearings in response to uncertainty among mobile app developers, which the House Energy and Commerce Committee voiced in a letter to the FDA Commissioner in early March. The letter relayed industry fears of widespread regulation by the FDA and concerns over the lack of final guidance on the regulation of mobile medical apps. At the hearing, the committee also inquired whether the FDA intends for smartphones, tablets, and other devices that display mobile medical apps to be taxed as medical devices under the Patient and Protection and Affordable Care Act (PPACA). Foreman deflected these questions, noting that the IRS, not the FDA, has the authority to impose taxes on medical devices.

Though the mobile medical app market has been growing, Foreman’s testimony showed that the industry is still in its infancy. Foreman stated that the FDA receives fewer than 20 submissions per year for mobile medical apps, which amounts to approximately 0.5% of all medical device applications the agency reviews each year. All mobile medical apps cleared thus far have gone through the 510(k) process, which in 2011 and 2012 took an average of 67 days to complete. The agency has not yet deemed any mobile medical apps to be Class III medical devices.

Further Guidance Expected Later This Year

Mobile medical app developers should look for a final guidance from the FDA on regulation of mobile medical apps later this year. Though Foreman initially projected that the guidance would be published in “the coming months,” when pushed to be more specific she narrowed her projection to the end of the FDA’s fiscal year in September. Technological developments in mobile medical apps have far outpaced the FDA’s sluggish timing in releasing its final guidance. Congress and mobile app developers will be watching closely to see if the FDA’s final guidance brings the clarity and light regulation of mobile medical apps that the agency has proposed. In the meantime, developers whose apps work in tandem with regulated medical devices should pay attention to the FDA’s enforcement letter to Biosense and consider whether FDA clearance is appropriate. We will continue to monitor this topic and provide relevant updates.