We previously described some of the ways in which life sciences companies are exploring the potential of IBM’s supercomputer, ‘Watson®’, to assist with product development and disease treatment.  Such uses raise important questions about how Watson and other software are treated under medical device regulations.  These questions are particularly important as tech companies find themselves wading into the healthcare arena and may be unaware of the heavily regulated industry they are entering.

The regulation of medical software has been controversial and subject to the vagaries of guidelines and subjective interpretations by the regulatory authorities. We consider below the regulatory minefield and the circumstances in which a software is regulated as a medical device in the EU and U.S.

EU

How is software regulated?

In the EU, a medical device means any instrument or other apparatus, including software, intended by the manufacturer to be used for human beings for the purpose of, among other things, diagnosis, prevention, monitoring, treatment or alleviation of disease. There is no general exclusion for software, and software may be regulated as a medical device if it has a medical purpose, meaning it is capable of appreciably restoring, correcting or modifying physiological functions in human beings. A case-by-case assessment is needed, taking account of the product characteristics, mode of use and claims made by the manufacturer. However, the assessment is by no means straightforward for software, which is particularly complex because, unlike classification of general medical devices, it is not immediately apparent how these parameters apply to software, given that software does not act on the human body to restore, correct or modify bodily functions.

As a result, software used in a healthcare setting is not necessarily a medical device. The issue is whether the software can be used as a tool for treatment, prevention or diagnosis of a disease or condition. For example, software that calculates anatomical sites of the body, and image enhancing software intended for diagnostic purposes, is generally viewed as a software medical device because it is used as a tool, over and above the healthcare professionals’ clinical judgment, in order to assist clinical diagnosis and treatment. For the same reason, software used for merely conveying or reviewing patient data is generally not a medical device.

What about Watson?

The main benefit of IBM’s cognitive computing software is its ability to analyse large amounts of data to develop knowledge about a disease or condition, rather than treatment options for an individual patient. Currently, its uses are largely limited to research and development. On the basis of these uses, the software may not be considered as having the medical purpose necessary for it to be classified as a medical device.

However, uses of the software that aim to enhance clinical diagnosis or treatment of a condition may potentially alter the regulatory status, especially if the function of the software goes beyond data capture and communication. Similarly, some of the new partnerships recently announced, described in our previous post, are aimed at developing personalised management solutions, or mobile coaching systems for patients. These may be viewed as having a medical purpose in view of the health-related information they acquire to provide informed feedback to the patient on self-help, or decision-making relating to the patient’s treatment plan. As the uses for Watson increase, and become more involved in treatment decisions, this change in regulatory status is likely to increase.

Will there be any change under the new Medical Device Regulations?

The EU legislative proposal for new medical device Regulations, which have reached broad agreement by the EU legislature but have not yet been adopted, contain additional provisions that specifically address software medical devices. Of particular relevance, software with a medical purpose of “prediction and prognosis” will be considered as coming within the scope of the Regulations. This means that software and apps that were previously excluded from being regulated, may in the future be “up-classified” and be susceptible to being regulated as medical devices. Along with a number of initiatives in the EU, the EU institutions recognize the importance of mHealth in the healthcare setting, and are seeking to ensure it is properly regulated as its use increases.

U.S.

How is software regulated?

In the United States, the Food and Drug Administration (FDA) has regulatory authority over medical devices. FDA considers a medical device to be an instrument or other apparatus, component, or accessory that is 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 that is intended to affect the structure or function of any man or other animal but which is not dependent on being metabolized (i.e., a drug) for achievement of that purpose.   FDA has issued a number of guidance documents to assist in identifying when software or mobile apps are considered to be medical devices.

One type of software FDA has not issued guidance on is Clinical Decision Support Software (CDSS). CDSS is software that utilizes patient information to assist providers in making diagnostic or treatment decisions. Until recently, CDSS was approached in a similar fashion to FDA’s framework for mobile apps. In other words, CDSS was viewed as existing on a continuum from being a Class II regulated medical device, to being subject to FDA’s enforcement discretion, to not being considered a medical device at all. On December 13, 2016, however, the 21st Century Cures Act was signed into law, clarifying the scope of FDA’s regulatory jurisdiction over stand-alone software products used in healthcare.

The 21st Century Cures Act contains a provision – Section 3060 – that explicitly exempts certain types of software from the definition of a medical device. As relevant for CDSS, the law excludes from the definition of a “device” software (unless the software is intended to “acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system”):

  1. Displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);
  2. Supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and
  3. Enabling health care professionals to independently review the basis for such recommendations so that the software is not primarily relied upon to make a clinical diagnosis or treatment decision regarding an individual patient.

Thus the Act generally excludes most CDSS from FDA jurisdiction. However, it is worth noting that FDA may bring CDSS back under its jurisdiction if it makes certain findings regarding: (1) the likelihood and severity of patient harm if the software does not perform as intended, (2) the extent to which the software is intended to support the clinical judgment of a health care professional, (3) whether there is a reasonable opportunity for a health care professional to review the basis of the information or treatment recommendation, and (4) the intended user and use environment.

What About Watson?

Based on this regulatory framework, IBM’s Watson would not generally be regulated as a medical device if simply used as a tool to assist physician review of medical data. In many uses, Watson is still dependent on human intervention and therefore does not make independent patient-specific diagnoses or treatment decisions. Importantly, statements about Watson also show that it is intended to be used simply as a tool by physicians and it is not intended that physicians rely primarily on Watson’s recommendations.

As such, in many applications, Watson is likely to be the kind of CDSS statutorily excluded from the definition of a medical device. However, as Watson and other forms of artificial intelligence advance and become capable of making or altering medical diagnoses or treatment decisions with little input or oversight from physicians, or transparency as to underlying assumptions and algorithms, these technologies will fall outside of the exclusion. As the use of such forms of artificial intelligence becomes more central to clinical decision-making, it will be interesting to see whether FDA attempts to take a more active role in its regulation, or if other agencies — such as the U.S. Federal Trade Commission — step up their scrutiny of such systems. Additionally, state laws may be implicated with regard to how such technology is licensed or regulated under state public health, consumer protection, and medical practice licensure requirements.

Interoperability has been identified as one of the greatest challenges in healthcare IT. It is defined as the ability of organizations to share information and knowledge, by means of the exchange of data between their respective IT systems, and is about bringing to life fruitful collaborations between different healthcare environments, with electronic means.

With this in mind, the eHealth Interoperability Conformity Assessment for Europe (EURO-CAS) project launched on 26 January 2017. With a budget of €1 million (approximately $1.1m), it is one of the projects being funded under the European Union’s (EU) Horizon 2020 research and innovation program.  The launch of this project shows the EU’s recognition that eHealth has become increasingly important within healthcare, and that the use of such technologies needs to be streamlined.

The aims of the project are two-fold:

  1. to develop models, tools and processes to enable an assessment of the conformity of eHealth products with international, regional and national standards.
  2. to provide a method for manufacturers of conforming technology to demonstrate that conformity to the public. As set out in previous posts, a key concern with the proliferation of apps and eHealth products is how to demonstrate to patients and payers that they are safe, effective, and protect patients’ privacy. The hope is that the project will address these concerns and promote the adoption and take-up of eHealth products, and the use of the various standards that are being developed.

These aims will be achieved through the development of the ‘CAS’ scheme by a consortium led by IHE-Europe, and consisting of EU member state representatives, experts and international associations. Six ‘work packages’ have been set up to deliver the project, each focusing on discrete aspects of the project:

work packages

Fig 1: https://www.euro-cas.eu/work-packages

The project’s key deliverables (and corresponding timelines) have also been outlined, with the final scheme to be presented to the public in November 2018.

The overarching plan behind EURO-CAS is to pave the way for more eHealth interoperability in the EU. The project will build on the findings of a series of EU-funded projects concerning eHealth interoperability over the past years. The scheme also aims for consistency with the ‘Refined eHealth European Interoperability Framework’, which identified the importance of interoperability for eHealth to be truly useful in healthcare, and was endorsed by representatives from all EU member states in 2015.

EURO-CAS states that it is “committed to transparency and openness”. Interested parties are invited to partake in project events, to engage through the project’s Twitter channel (), or group, or to provide feedback on the deliverables that will be submitted for public consultation in due course.

Updating our earlier blog post, ‘Next Up: European Consultation on the Safety of Apps’ that consultation has now closed and the Summary Report was published on November 14, 2016.

As previously explained, the consultation is one of a series of consultations and draft guidance through which the European Commission is seeking to develop appropriate guidance on the development of mHealth apps. The objectives of the consultation were to gather input from the public, industry and public authorities on their experience relating to the safety of apps and other non-embedded software, with a view to better understanding the risks they may pose to users and how those risks can be addressed.

The consultation returned 78 responses from stakeholders both inside and outside the EU. The majority of respondents were members of the public (37) and the remainder comprised trade associations (12), businesses (10), public authorities (6), professional associations (5), academia (5) and civil society (3).

Nearly half of the respondents (33) identified health and wellbeing apps as the main category of apps that could pose risks to users’ safety. In line with previous comments from the public, the most common concern raised by respondents related to data protection (including the risk that apps could access or collect users’ sensitive data without their consent, see: Attention App Developers… Final Draft of Code of Conduct on Privacy for mHealth Apps  (17), followed by cyber-attacks (including for the purposes of data collection, financial operations or controlling another device) (12). The types of risks most frequently cited by respondents included economic damage (60) and non-material damage (pain and suffering) (55).

The Commission is analyzing the replies to the consultation, and a full report will be published in due course. The Commission has stated that while the results do not point to the need for a new Commission initiative, it will consider the responses in its ongoing review of the regulatory frameworks governing apps, medical devices, and product safety and liability.

Published in Privacy & Cybersecurity Law Report’s April 2017 issue.

In the closing days of last year, the FDA issued its final guidance on postmarket medical device cybersecurity. This guidance is a corollary to the previously issued final guidance on premarket cybersecurity issues, and the pre and post market pieces should be read, and fit, together. In both cases, the FDA sets out a comprehensive, and lifecycle approach to managing cyber risk. Under this guidance, the FDA is asking companies to operationalize a structured way to think through and act on these product, hardware, software, and network issues. Last year, we wrote about 5 things companies can do now to get ahead of the curve on the premarket guidance, and they still apply.

The final postmarket guidance follows much of the 2016 draft guidance, with a few important changes. We wrote a detailed piece on the 2016 draft guidance. The two big changes are:  a change in focus from possible cyber impact on the product (what was called the “essential clinical performance” of the device) to a focus on the health impact on the patient if a vulnerability were exploited (what is now called the “patient harm”); and a fleshing-out of the recommended vulnerability disclosure process and time frames. Focusing on the possible impact to the patient seems like a good change. Cyber risk is a function of threat, vulnerability and consequence, and with medical devices, the consequence surely revolves around the patient. It is the second change – around vulnerability disclosure, timing for disclosure, and required information sharing with an industry-wide “Information Sharing Analysis Organization (ISAO)” that will take real thought, work and finesse.

Under the final guidance, if there is an “Uncontrolled Risk” given the exploitability of the vulnerability and the severity of patient harm if exploited, that risk should be remediated “as quickly as possible.” As for notice to the FDA and customers, you must report these vulnerabilities to the FDA pursuant to part 806 (which requires manufacturers to report certain device corrections and removals), unless the manufacturer meets four specific requirements: (1) there are no known serious adverse events or deaths; (2) within 30 days of learning of the vulnerability the manufacturer communicates with its customers and user community describing at a minimum the vulnerability, an impact assessment, the efforts to address the risk of patient harm, any compensating controls or strategies to apply, and commit to communicating the availability of a future fix; (3) within 60 days of learning of the vulnerability, the manufacturer fixes the vulnerability, validates the change, and distributes the fix such that the risk is reduced to an acceptable level; and (4)  the manufacturer participates in the ISAO and provides the ISAO with any customer communications upon notification of its customers. If you meet these obligation and timelines, you do not have to report under part 806 – but if you don’t meet these obligations you do have to report and then are subject to the usual 806 reporting.

So, to avoid part 806, you want to follow the four conditions. But they are more complex than one might think at first glance. As a general matter, information technology companies do not like to notify users of a vulnerability until there is a fix. A known vulnerability without a fix can easily (and often are) exploited by adversaries. Customers are less secure. Therefore, generally companies announce vulnerabilities and fixes together, so that customers can protect themselves before bad guys can exploit. Usually, only on rare occasions, when there is a known active exploit, would you notify customers before you have a fix. The FDA and the medical device industry seem to be searching for the appropriate approach for medical devices, where there is potential for non-trivial patient harm, and an existing regulatory structure and overall public health mission.  The issue of vulnerability disclosure is complex, and subject to much debate (the U.S. Commerce Department just published the results of a year-long study, concluded there is still much work to be done to get it right). Similarly, the issue of information sharing about cyber threat and vulnerability information with others in industry, and with the government is still an area of much discussion. A year ago, Congress passed an information-sharing bill to help reduce potential barriers to information sharing, including provisions for some amount of liability protection for sharing cyber threat and vulnerability information with others. Today, companies are still finding their way around the business and legal issues , even under the new legislation.

Therefore, to meet the 30 and 60 day notice requirements, and the information sharing requirement, medical device companies will have to carefully craft their notices to both meet the specificity requirement in the final guidance, and not disclose enough that adversaries will be alerted to the possibility of a vulnerability, figure out what function, method, process or technology is implicated, focus on that topic and exploit it before a fix is developed, shared, and implemented. The same considerations hold for sharing vulnerability and notice information with the ISAO, whose members will include competitors and which information could (depending on the ISAO rules and information classification decisions) be further shared with government and security industry partners. Net-net, a clear understanding of the technical vulnerability, possible consequences, ability to fix, and appreciation of the line between notification and usefulness for exploit is required. It may also be true that no fix can be had in 60 days, and that if there are many reported vulnerabilities backed-up and in the queue to be fixed, a company may fix the priority tickets first, and then the least priority items may take longer than 60 days to address and fix as a matter of band-width and expertise. Consequently, over time, companies may be faced with decisions about whether to try to meet the 806 exception conditions, or file 806 notices with the FDA and deal with the potential implications. None of this is to say that the benefits of the 806 exception are not worth it, or are trivial, it just means that your approach has to be clueful and strategic.

One more issue, of course continues to be quite important – the global rules must be rationalized. Medical device companies build-once and sell globally, and the security, integrity, vulnerability, and disclosure rules and best practices have to work globally. As these new guidelines get rolled-out, significant education globally will be critical.

Over time, and most likely, like most things in security, this ‘final guidance’ will be a work in progress, as companies and the FDA and regulators globally begin to deal with specific use cases that push the boundaries of what situation is a “Controlled Risk,” an “Uncontrolled Risk,” and what 30 and 60 day notifications, and fixes, and ISAO information is required, helpful, and not helpful. As we always say – ‘security is a journey, not a destination’ – and so too will the postmarket cyber guidance be.

 

On January 23, 2017, the FTC released a long-awaited report regarding the increased incidence of cross-device tracking.  The report, which follows a November 2015 FTC workshop on cross-device tracking, sheds light on the privacy concerns raised by the practice and alerts companies engaged in cross-device tracking of certain best practices for avoiding potential violations of applicable law and regulations.

Background

Cross-device tracking is the practice of using deterministic and probabilistic techniques to associate multiple devices with the same consumer.  Deterministic techniques are used to track consumer behavior based on the affirmative use of a common identifying characteristic, such as log-in credentials.  For example, when a consumer enters his or her log-in credentials to access an online platform on a number of devices, the consumer’s behavior on one device can be used to inform targeted advertising through the same platform on the consumer’s other devices.

By contrast, probabilistic techniques are used to draw inferences about consumer behavior. As noted in the FTC report, a common probabilistic technique is IP address matching, through which devices using the same IP address at the same time—e.g., a smart television, mobile device and tablet on the same local network—are presumed to belong to the same consumer.  Because probabilistic tracking does not involve affirmative consumer action, and may not involve any direct relationship between the consumer and the company engaged in the tracking activity, the practice is less transparent for consumers than deterministic tracking.

The FTC report is based, in part, on a prior FTC staff study on cross-device tracking trends which involved the testing of 100 popular websites on two separate devices. The study found, among other things, that 96 of the 100 websites reviewed collected log-in or other authentication credentials from consumers, the domains of 87 companies known to use cross-device tracking technologies were embedded, directly or indirectly, in such websites, and that 861 third parties were observed connecting to both devices.

Findings and Recommendations of the FTC Report

The FTC report acknowledges that cross-device tracking can produce benefits for both businesses and consumers.  These benefits include enhanced fraud detection and account security (e.g., by requiring additional authentication when a new device is used to access a consumer’s account), an improved consumer experience on online platforms, the use of more targeted, less saturated advertising, and a more equal competitive arena for companies that do not have access to large amounts of deterministic tracking data.  However, notwithstanding these benefits, the FTC report expresses serious concern about risks to consumer privacy associated with such activities.  For example, the FTC found that:

  • Cross-device tracking is employed by a growing number of companies (including both consumer-facing and third-party tracking and analytics companies);
  •  Very few companies using such techniques have disclosed both the fact and scope of their tracking activities;
  •  Many consumers may be unaware that their activities on certain platforms are being tracked, while some consumers may have knowledge of companies’ tracking practices, but little to no ability to limit or opt-out of tracking and data collection;
  •  Data collected through cross-device tracking may include highly-private personal information which, if exposed through a security breach, could result in considerable consumer harm and could reduce the efficacy of knowledge-based authentication (e.g., answering pre-selected security questions); and
  •  Self-regulatory initiatives have improved transparency and consumer choice in the cross-device tracking arena, but many existing practices are not fully disclosed to consumers and may implicate the FTC Act.

Based on these findings, the FTC report makes a number of recommendations to companies engaged in cross-device tracking, including that:

  • Consumer-facing companies should disclose to consumers, fully and truthfully, their use of cross-device tracking practices and the extent of those practices, including the nature of any data collected;
  •  Third-party tracking companies should provide their tracking disclosures both to consumers and to the first-party companies with whom they transact;
  •  Companies should consider providing consumers with clear and conspicuous opt-out mechanisms or other means to limit how their activities are tracked;
  •  Companies should refrain from tracking sensitive information, such as financial, health, or children’s information or precise geolocation data without first obtaining the express consent of the consumers to whom the information belongs; and
  • Companies should track and collect only information that is necessary for their business purposes to reduce the risk of a security breach resulting in significant consumer harm.

Considerations for Companies Engaged in or Considering Undertaking Cross-Device Tracking

Companies engaged in or considering undertaking cross-device tracking—whether consumer-facing or without a direct consumer relationship—may wish to review their tracking and information-collection activities in light of the FTC report. In particular, such entities may wish to examine their practices involving information that is viewed as “sensitive” or which can be reasonably linked to consumer or his or her device(s), even if the information is hashed or is otherwise protected. Companies should also consider reviewing their privacy policies and relevant consumer disclosures to ensure that any cross-device tracking activities, as well as any related opt-out procedures, are described accurately and conspicuously therein.  As the FTC report highlights, consumer-facing companies, such as application developers and website operators, can be exposed to liability for allowing third parties to install tracking technology in their applications and platforms without providing notice to consumers (see our previous Seller Beware post for further reading on prior FTC action in this area).  Similarly, third-party tracking companies may be held liable for misrepresenting the nature or the extent of their tracking techniques to the consumer-facing companies on whose platforms those techniques are deployed.  These reminders of potential liability should not be overlooked by consumer-facing and third-party tracking companies. It can be helpful to review existing and future agreements, as well as all representations made to consumers, to limit the potential for claims of misrepresentation regarding tracking practices, policies and procedures.

The 21st Century Cures Act (Cures Act) was signed into law on December 13, 2016, following a multi-year, bipartisan, and bicameral legislative effort to accelerate the pace of the discovery, development, and delivery of new treatments and cures. The Cures Act packages a wide range of medical innovation measures − including increased research and Food and Drug Administration (FDA) funding and provisions aimed at accelerating FDA’s processes for reviewing and approving new drugs, biologics, and medical devices − with funding for the opioid abuse crisis, mental health reforms, and modifications to various Medicare payment policies.

The Cures Act also incorporates significant health IT policies, which generally aim to streamline and promote the use of interoperable electronic health records (EHRs) and support coverage of telehealth services. In addition to addressing FDA regulation of software, the law includes provisions to: reduce regulatory and administrative documentation requirements in the use of EHRs; promote the facilitation of secure, interoperable exchange of electronic health record data while protecting patient privacy; and require the Department of Health and Human Services (HHS) and MedPAC to submit reports to Congress on expanding Medicare coverage of telehealth services. Of note, an earlier version of the Cures Act would have gone a step further by expanding telehealth coverage.

One of the most significant health IT-related provisions included in the Cures Act would enforce the prohibition of information blocking on behalf of health IT developers and exchange networks. Health IT developers will be banned from interfering or preventing the access, exchange, or use of electronic health information to allow for greater data interoperability. In addition, the HHS Office of the Inspector General will be permitted to investigate complaints against the practice of data blocking and subsequently enforce monetary penalties.

For additional information and a comprehensive overview of the Cures Act, we recommend that you read Arnold & Porter’s Advisory or listen to our webinar on the topic.

The top antitrust enforcers in the U.S. — the Department of Justice Antitrust Division (“DOJ”) and the Federal Trade Commission (“FTC”) — are tasked with preserving competition in the marketplace, including the market for health care products and services.  Competition benefits consumers through lower prices, increased availability of products and services, higher quality, and greater innovation.  The DOJ and FTC pursue their competition missions by investigating potentially anticompetitive conduct, reviewing mergers and acquisitions, and advocacy before states and other federal agencies.

Last week, DOJ and FTC commented on the potential competitive effects of telehealth related regulations proposed by Michigan and Delaware.  The DOJ commented on a bill working its way through the Michigan legislature that would expand the scope of health care authorized to be provided through telehealth services.  The FTC submitted comments on regulations proposed by the Delaware Board of Speech/Language Pathologists, Audiologists and Hearing Aid Dispensers that would permit these service to be provide via telehealth, but would require initial evaluations be done in person.

Michigan

A bill introduced in the Michigan legislature, SB 753, would broaden the services health care professionals can provide remotely using telecommunications technologies to include not only direct clinical services, but also health education and administration.  The bill would also permit health care professionals to obtain consent for treatment via telehealth directly or indirectly, and would permit prescribing drugs through telehealth if the health care provider is authorized to proscribe drugs in person and the prescribed drug is not a controlled substance.

The DOJ supported all three proposals as having “the potential to facilitate more robust use of telehealth services and expand health care competition by limiting or avoiding certain unnecessary barriers.”  Specifically, by lowering barriers such as health care access and cost, consumers may be more likely to seek out care sooner and obtain care faster through telehealth.  Expanding the services that can be provided via telehealth “may facilitate more diverse and innovative uses of telecommunications technologies to improve health care offerings beyond direct clinical services.”  By giving health care providers flexibility in how they obtain consent for treatment, without changing the underlying consent requirement, the bill would “help health professionals compete to improve access and provide health care services to patients.”  Finally, authorizing health care providers to prescribe certain drugs would make telehealth a more competitive option versus in-person visits.

Delaware

Delaware’s Board of Speech/Language Pathologists, Audiologists and Hearing Aid Dispensers proposed changes to their regulations that would allow licensed practitioners to deliver speech/language pathology, audiology, and hearing aid services remotely using telecommunications technologies — “telepractice” under the proposed regulation.  The proposed regulations would ensure that telepractice meets the in-person standard of care.  However, the initial evaluation could not be done by telepractice.

The FTC generally supported the authorization of telepractice to deliver these services because it would likely “increase[e] competition, consumer choice, and access to care.”  Its comments detailed the shortages of speech/language pathology and audiology services in certain parts of Delaware and research showing that these services can be effectively provided via telepractice.  The FTC encouraged the Board to reconsider the in-person initial evaluation requirement because it “may restrict entry of qualified telehealth practitioners, potentially decreasing competition, innovation, and health care quality, while increasing price.”  Instead, the FTC recommended that the Board allow licensed practitioners to use their professional judgment to determine whether an initial evaluation through telepractice is appropriate, consistent with the in-person standard of care and the patient’s health and safety, just as they can do for subsequent sessions.

*          *          *

The agencies’ comments reveal a consistent approach to telehealth competition issues at the federal level.  Both agencies encouraged the states to reduce regulatory burdens on telehealth so that consumers can enjoy its potential benefits, including reduced health care costs and increased access to health care services.  Furthermore, in order to encourage the expansion of telehealth services, the agencies recommended that states narrowly tailor their regulations to directly address the regulation’s legitimate purposes, such as delivering the appropriate level of care and protecting patients’ health and safety.

Improvements in the efficiency of clinical development is the highest priority for the innovative industry. And yet, costs associated with clinical trials, and delays in patient recruitment and retention, persist. Companies are continually on the look-out for ways of addressing these issues, and mHealth may be the answer. Digital technologies, and the integration of wearable health monitors with smartphones and apps, offer new opportunities for expediting product development. However, there are challenges with the widespread use of such technologies, which we discuss below.

How is mHealth used in clinical trials?

  • Patient recruitment and retention: It has been reported that 27% of the cost of development of a medicinal product is associated with patient recruitment, and only 1 in 20 patients recruited provide results that can be included in a regulatory dossier. This highlights the extent of the challenge companies face. Certain apps claim to provide an effective means of tracking potentially eligible patients through capturing valuable data and improving patient recruitment. For example, , My Clinical Study Buddy, and Study Scavenger provide patients and physicians with the ability to search trial information. Similarly, apps such as  enables healthcare professionals to search clinical trials in the oncology field to aid referrals.
  • Patient engagement: Patients are increasingly recognized as equal partners in clinical trials and drug development. Further, some say that better patient engagement leads to better outcomes and greater retention rates. A real-life example of this comes from the comparative Mobile Diabetes Intervention Study of 163 patients, which found that adding a mobile patient coaching app to treatment, together with personalized feedback on blood glucose data and lifestyle behaviors via smartphones, substantially lowered glycated haemoglobin levels for more than a year.  Wearable technology and patient-centric apps provide a great opportunity for pharmaceutical companies to seek this engagement during clinical trials. For example, Clinical Trials Mobile provides patient-specific information about participating in trials, how to prepare for visits and instructions on the study product. provides similar information for investigators.
  • Real-time patient monitoring: The age-old process of having clinical staff and investigators recording patient information from various inputs on paper-based case report forms, then manually entering this information into a database, is fading into history. Electronic data capture (EDC) is rapidly becoming the new standard, yielding impressive productivity gains and helping to improve data accuracy. Continuous monitoring can also help researchers record treatment adherence. As a result, study sponsors can more accurately determine efficacy, and non-adhering patients can be filtered out. Continuous remote patient monitoring through apps also enables trial sponsors to more readily and accurately identify potential side effects. Such technologies are being integrated into trial designs. For example, Pfizer has developed a sensor-enabled remote patient monitoring system ahead of its planned use in a Phase III Parkinson’s disease trial in 2019. Wearables technologies can also be used to more easily integrate and collect quality of life data as part of the trial, and so support reimbursement decisions without conducting further studies.

Is it an app or a device?

As with any software used in the healthcare setting, it will be important to consider whether any such technology is a medical device under the relevant legislation and guidance.  In the EU, the new Medical Devices Regulations, when finalized, may change the classification of software used in the healthcare environment, which will mean more apps are classified as devices according to their intended medical purpose. The European Commission is also consulting on guidance to define the threshold for classification of a software medical device. Similarly, in the US, the FDA has recently published draft guidance on the evaluation of software as a medical device, and has issued final guidance on Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.

While some companies shy away from such regulation, others are actively developing apps that will be classified as medical devices, presumably with the aim of ensuring confidence in the product. For example, Google has developed a , which it plans to position as a medical device for use by patients and clinical researchers.

Can this really make a difference?

The true value of the use of apps and digital technologies in clinical trials will depend on ease of use, relevance and accuracy, all of which may raise important legal issues. In particular, it should be recognized that data monitoring through remote digitalized technologies, moves clinical trials from an internally-contained to an external-uncontrolled clinical environment. There are, therefore, concerns about their use:

  • System integration: the technological capabilities are not yet fully integrated between the hardware (wearables) and software (apps and servers), and there is a lack of support for the analysis of massive data collection within clinical trials.
  • Standardization of regulatory requirements: appropriate standards should be established to facilitate inter-operability. However, this is hampered by the fact that regulatory rules and policies for mHealth have not kept pace with the technological advancement. It is unclear how and against what regulatory standards data collected from such devices and apps should be validated to support regulatory review. In the EU, whilst there has been a flurry of activity in relation to the assessment of apps, their application in a clinical trial setting has not been addressed. Moreover, mobile technologies and digital health are not referred to in the Clinical Trials Regulation, which is expected to come into operation in 2018. In contrast, in the US, the FDA consulted on guidance on the use of mobile technologies in clinical trials at the end of 2015, and on the use of electronic health records in clinical trials earlier this year.
  • Data security: most importantly, patients need to have confidence in the technology, and in particular, the security of their personal data and the accuracy of the data collected.

Despite these limitation, proof on concept has been shown: a recent report by the US Department of Health and Human Services found that the key impact of the use of mobile technologies so far recorded is on study duration and total costs. The report noted up to a 30% decline in study duration, and costs savings of as much as $6.1 million (up to 12 percent of cost per study) in a phase III study. It seems, therefore, that the future will be digital.

The Food and Drug Administration (FDA) recently introduced a new webpage for reporting allegations of regulatory violations by medical device manufacturers or marketers. The new webpage, launched on October 21, 2016, enables any person—including current or former employees, competitors, or even plaintiffs’ attorneys—to submit a report to FDA regarding a broad variety of potential violations. Illustrating the types of allegations it expects to receive, FDA identifies:

  • non-FDA-approved promotion or advertising;
  • failing to submit required safety reports;
  • failing to comply with design or manufacturing responsibilities;
  • marketing a device without proper FDA clearance;
  • importing a device without satisfying the applicable legal requirements;
  • forging or falsifying an export certificate;
  • failing to register and list a device; and
  • knowingly deceiving FDA.

FDA encourages reporters “to include supporting information and contact information in case additional information is needed for FDA to understand the allegation and act on the report.” The agency also permits anonymous reporting and guarantees that it will maintain reporters’ anonymity unless legally required to do otherwise.

According to the new webpage, all reported allegations will be reviewed by the Center for Devices and Radiological Health (CDRH). CDRH is then charged with prioritizing its review based on the level of potential risks to patients. Following an assessment of the allegation, CDRH has the option of issuing a warning letter, conducting an inspection, or even requesting a recall. CDRH may also request additional information from or simply monitor the medical device manufacturer.

FDA implemented a similar reporting mechanism in 2010, the “Bad Ad Program,” which only addresses reports of potentially untruthful or misleading prescription drug advertising and promotion, rather than the broad array of violations addressed by the new website. Also, although anyone may submit a complaint to FDA, the Bad Ad Program “is focused primarily on health care professionals” and is “designed to educate health care professionals about the role they can play in helping FDA ensure that prescription drug advertising and promotion is truthful and not misleading.” Despite its comparatively limited scope, reports submitted through the Bad Ad Program led to the issuance of a number of enforcement letters. The new website is broader in scope and may have a similar, if not greater, impact. At any rate, whether or not this new website generates additional FDA actions against medical device manufacturers, records of inquiries and investigations completed by CDRH will potentially be available to plaintiffs’ attorneys through requests under the Freedom of Information Act.

On November 28, 2016, the US Department of Health and Human Services’ (HHS) Office for Civil Rights (OCR) issued a rare alert warning the public of an email scam masquerading as an official OCR audit communication. The alert addresses an emerging “phishing” scheme that targets employees of HIPAA covered entities and their business associates in an apparent attempt to market non-governmental cybersecurity services. Below we offer some brief guidance about the scheme and tips for what you can do to protect your company.

What the scheme is: “Phishing” emails are designed to steal money, information, or both from their targets. The emails usually appear to come from legitimate enterprises—in this case, OCR—but, when accessed, hyperlinks in the emails direct users to spoofed or fake websites designed to get users to divulge private information. Although the underlying goal of the scammers here is unclear, as a general matter, criminals who obtain such private information often attempt to commit identity theft or to sell obtained data to interested parties on the internet’s “black-market.”

What to watch out for: An email that appears to come from OCR, under cloned OCR letterhead, that prompts recipients to click a link regarding possible inclusion in the HIPAA Privacy, Security, and Breach Rules Audit Program. The hyperlink directs users to a non-governmental website that markets, ironically, cybersecurity services. OCR’s alert emphasizes that the cybersecurity web page and services are in no way affiliated with HHS or OCR.

What to do now: Inform your employees to be on the lookout for the OCR Phishing Scam email, and remind them to remain wary of these types of emails generally. Also remind employees about any policies in place regarding sharing sensitive information. Set up a point of contact for employees to consult if they are in doubt about what to do, or what information they can share.

What to do if you receive one of these emails: Do not respond to the email. Do not download any files or images in the email. Do not click on any hyperlinks in the email. Add the sender to a blocked senders list and delete the email. If you have any questions as to whether an email is an official agency communication regarding a HIPAA audit, contact OCR at .

What to do if you have responded to one of these emails or accessed hyperlinked material: If an employee has already responded to the OCR Phishing Email or accessed a hyperlink in one of these emails, we suggest you contact experienced legal counsel to aid in determining what information or systems may have been compromised, and what obligations, if any, you may have to notify impacted individuals and/or state or federal entities under various laws.