Aarthi Iyer

by Aarthi Iyer

Privacy and Security Challenges Facing mHealth App Developers in Clinical Research

Rapid proliferation of smartphones, tablets, and other such mobile technology has put over 165,000 mHealth applications (mHealth apps) directly in the hands of the consumer, not only empowering consumers to manage their own health and wellness, but also opening new channels of communication between consumers, health care providers, researchers, and even regulatory agencies.

However, this technology raises significant privacy and data security challenges that requires serious due diligence by innovators.

What are these challenges, and how can mHealth app developers and researchers overcome them?

 

Lack of Uniform Guidance for Ensuring Appropriate Safeguards

In the U.S., regulatory agencies evaluate mHealth apps based on whether they are considered medical devices, with the FDA having established a distinction between:

  1. apps that are not medical devices;
  2. apps that are medical devices but over which FDA will exercise enforcement discretion not to regulate them; and
  3. apps that are medical devices and require regulatory oversight.

It is this last category of mHealth apps where the FDA offers much of its data protection and security guidance in requiring medical device manufacturers to create risk management plans and procedures emphasizing usability, vulnerability, assessment, and design security.

But what of apps in which the FDA exercises enforcement discretion, or others that are not even considered medical devices at all? These modalities still collect individual-level health information and often feature complex data storage and sharing pathways. With only a small fraction of apps subject to regulatory oversight and even fewer tested for efficacy in any meaningful way, app developers are largely out-to-sea and as such are often subject to vague consumer protection laws, which can come with harsh penalties.

Overseas, the U.K.’s National Health Service (NHS) recently launched the latest re-boot of its Apps Library, a four-year platform in the making, to host agency-vetted healthcare apps, ‘so they are accessible and trusted by the public.’1 However, only one of those apps is marked as “NHS Approved” to-date, again illustrating the lag between product innovation and regulatory guidance on safeguards.2

For easier navigation amongst this uncertainty and delay, developers are encouraged to confer with consultants and technical experts in order to stay informed of the shifting regulatory landscape. Plus, developers have the option to contact oversight agencies for determinations and feedback on their specific mHealth apps, regardless of whether the app is currently under regulatory enforcement.

 

HIPAA Privacy Rule Compliance

HHS has recognized that many mHealth app developers may not be familiar with HIPAA rules and how the stringent security and breach notification requirements would apply to their products. While HIPAA only applies to covered entities (health plans, health care clearinghouses, and most healthcare providers), manufacturers of mHealth apps may be subject to the Privacy Rule as business associates. A business associate is a person or entity that creates, receives, maintains or transmits protected health information (PHI) on behalf of a covered entity or another business associate. As such, most third-party vendors or contractors (which may include app developers) that provide services to or perform functions for covered entities that involve access to PHI are business associates.

To help app developers understand where their products fall under HIPAA, HHS has created an online forum through which app creators, users, and researchers can send and receive feedback about their particular product.

 

Utilization of Third-Party Vendors

Pharmaceutical companies or healthcare institutions often cooperate with third-party developers of mHealth apps, adding further complexity in the attempt to adhere to relevant safeguards, regulations, and policies. Beyond development, these third parties often provide additional services such as appointment reminders, data storage, and analysis—engaging in the collection and transmission of large volumes of both personally identifiable information (PII) and PHI.

As these vendors typically provide services behind the scenes, control over their approach to handling sensitive patient-level data may present challegnes and can be at risk of being overlooked.

 

The Cloud

With large volumes of data being collected and shared via mHealth apps, developers and manufacturers forego storage in their own server rooms, instead outsourcing data services to external cloud-based systems. The data is either processed and stored in third-party data centers or combined within mobile apps.

Ensuring the security and privacy of data stored in the cloud brings with it a new set of complications. Syncing to the cloud often means that data is duplicated (in some scenarios, several times over) and may not be easy to wipe or destroy, even if an app has been deleted from a mobile device or is no longer on the market. Additionally, syncing information with a phone service provider would imply that data could be transferred beyond the dedicated cloud for the app. While clouds provide flexible data hosting and sharing capabilities, app developers need to be sensitive to quality and compliance practices to guarantee the quality and integrity of their cloud-hosted systems.

Strategies for success

MHealth app manufacturers should engage in early dialogue with industry experts for technical and regulatory insights in developing and releasing mHealth applications. At the least, strategies to ensure successful deployment include:

  • Implementing proactive and regular risk analysis audits throughout the lifecycle of a mHealth app, allowing for accurate identification and triage of any gaps in data privacy and security.
  • Ensuring that all service-level agreements, (including business associate agreements) between developers, vendors, manufacturers and researchers, offer ample data protection safeguards as well as procedures for reporting and addressing data breaches.
  • Validating mHealth apps and engaging in regular end-user testing. A sound and verifiable validation file, including specification of user requirements, demonstrates that an app is built according to stable design, quality, and data protection principles. End-user testing further ensures replication of such validation and highlights any gaps that did not arise during development phase.

Mobile technology is radically transforming the healthcare system to a more patient-focused landscape. The biggest challenge will continue to be balancing consumer privacy, data security, and overall regulatory compliance with rapid innovation and improvements in health services delivery. But with sound design and regular audits throughout the life of an app, plus partnerships with knowledgeable mHealth regulatory experts, developers will have the capacity to realize these innovations while advancing data protection and security standards.


Mitchell Parrish, JD, RAC, CIP, VP of Legal and Regulatory Affairs

Executive Insight

Mitchell Parrish, JD, RAC, CIP, VP of Legal and Regulatory Affairs

 

There are considerations for every mobile health app: FDA regulated? Subject to privacy and security regulations? Required agreements? The key with app development is to ask (and answer) these questions early.

Developing an app with these requirements in mind is much more efficient than going back and filling in the compliance gaps.

Tags: , , , , , , , , ,