Managing Pharmacovigilance in Digital Health Initiatives

This article analyzes adverse event reporting obligations and identifies ways to reduce regulatory risk and cost associated with digital health initiatives.

The pharmaceutical industry, most would agree, has been slow to embrace the use of digital technologies, such as the cloud and mobile devices, in delivering healthcare. As with social media, pharmaceutical company involvement in digital health presents many difficult questions, making executives uneasy. Among those questions is which adverse event reporting obligations companies would assume by pursuing digital health strategies. This article analyzes those reporting obligations and, more importantly, identifies ways to reduce regulatory risk and cost associated with digital health initiatives.

More specifically, this article focuses on issues of legal responsibility. Some interesting debates are going on at pharmaceutical companies: lawyers who want to minimize legal responsibilities are arguing with physicians and other scientists who want to aggressively mine any or all data to learn how to improve patient care. At the heart of the debate are ethical and business issues beyond the scope of this article.

Pharmaceutical Digital Strategies

Industry-Wide Trends

While there are many different ways the pharmaceutical industry can participate in digital health, several companies are pursuing what PricewaterhouseCoopers (PWC) calls “patient engagement platforms.”¹ In its 2013 report, “Digital Health: A Way for Pharma Companies to be More Relevant in Healthcare,” PWC expressed a vision where a pharmaceutical company creates a technology platform by pulling together information needed to care for patients, including information on the correct use of the company’s drug. The platform allows data collection, for example, downloaded directly from smart devices. The platform also has tools guiding patients to manage their own care, as well as ways for physicians to interact more effectively with patients. Moreover, the platform can include functionality useful to payers and opportunities for social engagement.

Such a platform, PWC suggests, offers value to physicians by providing tools to help manage their patients. While there are obvious marketing benefits to pharmaceutical companies, more directly, these systems offer public health benefits by driving medication adherence. Fundamentally, digital platforms can help pharmaceutical companies redefine their role in the healthcare system by providing more direct value to the patient and opportunities for expanded collaboration with physicians, as well as demonstrating value to payers and reimbursement help.

Hypothetical Case Study

As mentioned previously, the pharmaceutical industry has been slow to pursue digital strategies because of the many unanswered questions regarding adverse event reporting obligations. Since it is hard to discuss these questions in the abstract, this article focuses on a hypothetical case study.

A drug company, PharmCo, designs a mobile app to perform a dosing algorithm for a branded insulin product, FastAct. The patient inputs a blood glucose level and the app recommends the next mealtime insulin dose. The app also transmits information from the patient’s mobile device to the prescribing doctor via a cloud-based database. This functionality allows the doctor to track the patient’s blood glucose levels and FastAct doses after the initial titration/dosage. PharmCo launches this entire system: it owns the app as well as the data stored in the cloud.

The PharmCo marketing team wants to retain the ability to mine the data stored in the cloud. The company, therefore, crafts a relatively broad privacy statement asserting both PharmCo and its information technology vendor shall have access to Patient Identifiable Information (PII). The policy further states PharmCo may access such data in the event of follow-up for safety reasons, for example, if a patient calls PharmCo’s technical troubleshooting hotline to complain the app is malfunctioning and suggests unusual dose adjustments. The PharmCo team wants to ensure access to the patient’s records under such a product complaint scenario.

In this hypothetical, it is reasonable to anticipate instances where patients will have either very high or very low blood glucose readings. The issue is whether such blood glucose levels constitute an adverse experience requiring follow-up and/or reporting pursuant to safety reporting regulations.

This hypothetical is offered not to limit the scope of this article, but simply to make the analysis more concrete. It would be easy to envision other similar use cases, such as a drug company making products for patients with asthma creating a similar platform for monitoring peak flow levels or a drug company making products for congestive heart failure creating an elaborate platform for collecting and analyzing CHF symptoms. This article’s analysis should apply to any instance where a pharmaceutical company creates a patient health information database.

Drug Adverse Experience Reporting Requirements

General Framework: US Law

Applicants holding an approved New Drug Application (NDA) are required to submit postmarket safety reports to the US Food and Drug Administration (FDA) for approved human drug products.² More specifically, upon becoming aware of a reportable adverse drug experience, the applicant is responsible for preparing a postmarket safety report and submitting it to FDA.³ As required vigilance, the applicant must “promptly review all adverse drug experience information obtained or otherwise received by the applicant from any source, foreign or domestic, including information derived from commercial marketing experience…”⁴

An adverse drug experience is any “adverse event associated with the use of a drug in humans, whether or not considered drug-related,” including the following:

• an adverse event occurring in the course of use of a drug product in professional practice
• an adverse event occurring from drug overdose whether accidental or intentional
• an adverse event occurring from drug abuse
• an adverse event occurring from drug withdrawal
• any failure of expected pharmacological action⁵

The deadline for reporting these events depends, in part, on whether the adverse experience is serious and unexpected. Such alert reports need to be submitted within 15 days, a shorter deadline than for other adverse events.

While this article focuses on US law, many pharmacovigilance principles have been harmonized globally and the analysis would be similar in other jurisdictions.

Reporting Requirement Triggers

Four Required Elements

This article addresses the question of whether a patient database needs to be monitored for possible reportable events. Since the goal is to determine whether a pharmaceutical company can ignore the database for reporting obligation purposes, the article focuses on what triggers the obligation, even to consider reporting information potentially in a patient database. If a pharmaceutical company does not have an obligation to consider reporting that information, it can safely do nothing.

The first question is what exactly is a reportable event? FDA has defined the minimum information required for an event to be reportable.

Before considering any clinical incident for submission to FDA, applicants must have, at a minimum:

1.  an identifiable patient
2.  an identifiable reporter
3.  a suspect drug or biological product
4.  an adverse experience or fatal outcome suspected to be due to the suspect drug or biological product

If any one of these basic elements remains unknown after being pursued actively by the applicant, a report on the incident should not be submitted to FDA because reports without such information make interpretation of their significance difficult, at best, and impossible, in most instances. Instead, the applicant should maintain records of its efforts to obtain the basic elements for an individual incident in its corporate drug or biological product safety files.⁶

Indeed if a report does not include those four elements, FDA will return it to the applicant.

What Exactly Triggers the Need to do Something?

After understanding the four elements required to constitute a reportable event, a pharmaceutical company needs to learn what triggers the obligation to report. The draft guidance describes the trigger as “knowledge” of those four elements. FDA guidance describes knowledge in a couple of different ways.

First, in the context of the need to report serious and unexpected adverse experiences within 15 days, the FDA guidance describes the trigger as “initial receipt of the information by the applicant.” This information can be orally transmitted, not necessarily written.⁷ The guidance is not very specific about the minimum information required to trigger the obligation.

Another section of the guidance states, “The date the company has knowledge of these four basic elements should be entered...”⁸ That date starts the 15-day clock for reporting serious and unexpected adverse events. This is a little more specific because it refers to the four basic elements.

Both descriptions broach the essential issue of when a company acquires adverse experience “knowledge,” but there is a challenge. It appears the “knowledge” does not need to be complete with regard to all four required elements to trigger the requirement for some company action. Instead, the guidance suggests if the company only receives partial information, it may be obligated to investigate whether there is a reportable adverse experience. The real question is what triggers the pharmaceutical company’s obligation to investigate information collected as part of a patient database?

What Triggers the Duty to Investigate?

FDA guidance states, “The applicant should exercise due diligence to acquire all the information for an individual case safety report immediately upon receipt of a suspected serious, unexpected adverse experience...”⁹ The concept of a “suspected” adverse experience apparently is based on less information than an established adverse experience. To answer the question of what triggers the need to investigate, applicants need to consider whether their patient databases would contain even “suspected” adverse experiences. Unfortunately, there is no precise definition of a suspected adverse experience in FDA guidance, so this discussion addresses the hypothetical PharmCo database in the analysis below.

How Should Drug Companies Acquire the Information?

Companies must have affirmative plans in place for collecting suspected adverse drug event information methodically. FDA guidance explains, “Each applicant must develop written standard operating procedures for the surveillance, receipt, evaluation and reporting of adverse experiences to the FDA...The FDA will consider an applicant responsible for information known to its employees, affiliates and contractors.”¹⁰ 

Spontaneous Reports and the Issue of Causation

Applicants are required to consider suspected adverse experiences obtained from a wide variety of data sources, including postmarket clinical investigations, epidemiological/surveillance studies, reports in the scientific literature and unpublished scientific papers.¹¹ In each instance, the applicant must report the adverse experience as long as all four data elements are present, without regard to demonstrated causation. In other words, it is enough, for example, for an author to claim an adverse experience was related to the use of the drug; the applicant does not need to agree before the event is reportable. The report’s source acts as a surrogate for demonstrated causation. Importantly, the manufacturer has a duty and an opportunity to investigate whether, for example, there was a factual error, such as the drug’s identity. However, on the issue of causation, the manufacturer needs to show some deference to the reporter.

The same is true for the category referred to as “spontaneous” reports. Spontaneous reports are unsolicited communications from individuals (e.g., a healthcare professional, a consumer) to applicants concerning adverse experiences.¹² FDA says the applicant should assume an adverse experience or fatal outcome is due to the suspect drug or biological product (implied causality).¹³

So, the question is whether data collected passively in a patient database need to be analyzed to determine whether they meets the reporting threshold requirement. To be clear, causation does not need to be determined conclusively to make the event reportable. Instead, FDA uses the information source as a surrogate for determining whether there is sufficient connection to make the event reportable. The relevant question is whether a database comprised of the type of data collected by PharmCo needs to be analyzed for potential reportability.

The Need for Conservative Interpretation

FDA suggests companies need to be conservative in interpreting the agency’s guidelines. In its draft guidance (which, at the time of publication, has been in draft form for 14 years), FDA explains:

“…in some cases, it may be difficult to interpret specific criteria used for reporting. Examples include determining whether an adverse experience is expected or unexpected or whether a patient is identifiable or not. For these and any other ambiguities, the applicant should use a conservative approach and err on the side of reporting the adverse experience to FDA. Thus, if there is doubt, consider an adverse experience to be unexpected, consider a patient to be identifiable, and so on...”¹⁴

At the same time, FDA has said it does not want companies to over-report because the whole purpose of adverse event reporting is to identify problems. To identify problems by examining data, it is essential to distinguish the signal from the noise. If manufacturers over-report, the sheer volume of data masks the signal. It makes it more difficult to discern what the data are saying. Thus, FDA’s admonition to be conservative should not be over-applied.

Applying Those Requirements to the Pharmaceutical Company Patient Database

The following three general questions should be considered to decide whether PharmCo’s FastAct database needs to be monitored for potentially reportable adverse experiences:

Does PharmCo Have Access to the Data?

This first question is pivotal and, frankly, one of the best ways to discern whether PharmCo needs to worry about analyzing the database for adverse events. If a pharmaceutical company does not have accessible data, it cannot know the data, and therefore cannot be held responsible for knowing what adverse events the data set might contain. To determine this, PharmCo needs to ask itself two more specific questions.

Who Controls the Data?

Often, a patient platform under a pharmaceutical company’s sponsorship is developed by collaborators, including technology companies, and the pharmaceutical company may not be the one with direct access to the database. The question then becomes how FDA perceives the relationship between the pharmaceutical company and the database management company, and whether it expects the pharmaceutical company to be able to obtain the data. This FDA statement from FDA’s guidance is important: “The FDA will consider an applicant responsible for information known to its employees, affiliates and contractors.” On one hand, FDA cannot hold a pharmaceutical company responsible for anything a contractor knows. However, FDA may not look kindly on deliberate ignorance, such as telling a contractor to keep information to itself it normally would be expected to share. Thus, PharmCo has to decide whether, because of its relationship with the contractor, the contractor would be expected to share adverse experience information with PharmCo.

Typically, manufacturers include contractual obligations to report adverse events in agreements with third parties likely to come into contact with adverse event information while performing contracted services. Exactly what the law requires currently is the subject of much debate. Some regulators seem to be pushing pharmaceutical companies to include such provisions in contracts with not only traditional commercial partners but also contractors involved in disease-support programs, reimbursement, compliance monitoring and marketing surveys. A company would need to decide whether its patient database  information technology vendor is in such a position, which is difficult, because the company first has to decide whether the database itself is likely to include any adverse drug experiences needing to be analyzed.

In the hypothetical example, PharmCo indeed does have sufficient ownership in the database to be held responsible for knowing what it contains.

Are the Data Technologically and Legally Accessible?

In most cases, data in a patient database are accessible technologically. For this example, assume PharmCo has no problem digitally accessing the data.

The more interesting question is whether the data legally are accessible. The answer depends on the privacy policy. PharmCo was pretty aggressive in its privacy policy in demanding access to the data. According to the summary above, the privacy policy broadly allows access to patient-specific information, implying PharmCo has legal access to the information.

On one hand, it is easy to understand why a pharmaceutical company would want access to this wealth of data. On a population basis, such access facilitates medical research helping the company improve its products and develop others. However, access comes with a cost and, in this case, the necessity to monitor the data for adverse events.

In contrast to the earlier point indicating the pharmaceutical company should not deliberately try to remain ignorant regarding contracting partners, there is a legitimate reason to write privacy policies on a more limited basis. Most patients really want to protect their privacy, and drug companies simply could acquiesce. Unfortunately, FDA has issued no guidance on this particular issue.

Another interesting question is whether a privacy policy could be construed to allow visualization of the data only at a population level. There is a difference between the right to view population level data versus the right to look at individual patient data. If a pharmaceutical company only could view population level data and not the individuals, it would not have access to individual patient data per se. FDA might consider, even though the pharmaceutical company would not be aware of a reportable event, a population-based trend would trigger a need for further due diligence. Like the others above, this is an open question with FDA. And, as discussed more below, there may be duties other than adverse event reporting triggered by detecting those trends.

Notice PharmCo’s language about follow-up on a complaint has a much more limited effect than the broader privacy statement. If someone complained about the product and, in the course of investigating the complaint, PharmCo’s staff determined an adverse experience had occurred; they would have a duty to report it. But, that is a much more constrained obligation than the duty to be vigilant as to any data submitted to the database.

Concluding the company does have access to the data, PharmCo must proceed to the second major question.

Would the Pharmaceutical Company be Deemed Knowledgeable About the Data?

The fact data are available physically and legally is not enough to determine whether PharmCo actually is responsible for knowing about them. Fortunately, pharmaceutical companies are not responsible for knowing everything available. In a sense, huge amounts of data around the world accessible through the Internet are available technologically and even legally to a pharmaceutical company; however, FDA has not chosen to make pharmaceutical companies responsible for all they might be able to find. Instead, FDA limits companies’ responsibility to information:

• known to pharmaceutical company representatives
• contained on pharmaceutical company sponsored websites

The question is whether PharmCo’s patient database meets either of those two criteria. Specifically, FDA advises:

“…applicants should review any Internet sites sponsored by them for adverse experience information, but are not responsible for reviewing any Internet sites that are not sponsored by them. However, if an applicant becomes aware of an adverse experience on an Internet site that it does not sponsor, the applicant should review the adverse experience and determine if it should be reported to the FDA...”¹⁵

Applying these principles to the hypothetical case, PharmCo will be responsible for any adverse event information in the patient database. Indeed, in the hypothetical case study, PharmCo actually owns the database and needs to go to the third question.

Do the Data Trigger an Obligation to Report or Even Just to Investigate?

Since the company can access the data physically and legally the data fall within the zone for which FDA wants to hold the company accountable (i.e., sponsored websites), PharmCo needs to determine whether the data themselves trigger any obligatory action on its part.

To be clear, before PharmCo can ignore the database for adverse experience reporting purposes, the company needs to determine whether the database contains information that even would lead to a duty to investigate, if not report. Beyond stating a pharmaceutical company has a duty to investigate adverse experience reports it receives either spontaneously or through a programmatic process, FDA has never been clear about the minimum amount of information to constitute such a report. The minimum amount of information required to trigger the duty to investigate further needs to be identified. As explained, the report to the pharmaceutical company need not be complete when initially received. But, how incomplete can it be and still constitute a report triggering an obligation?

To answer the question left unanswered by FDA guidance, this article proposes the pharmaceutical company may have a duty to investigate when it receives information suggesting, to a reasonable person, an adverse experience has occurred. If the company possesses that information, it likely is obligated to investigate. To be precise, this article is not proposing a pharmaceutical company must receive information suggesting a “reportable adverse experience” has occurred, just information suggesting to a reasonable person an “adverse experience” has occurred. An adverse experience is only one of four elements of a reportable adverse experience.

At this point, it is necessary to review the four elements comprising a reportable adverse experience.

An Adverse Drug Experience

Existence of an adverse drug experience is key to determining whether PharmCo even has an obligation to investigate. PharmCo must determine whether the data in its insulin-related database would suggest to a reasonable person an adverse event has occurred.

This is an intensely factual question. Medically speaking, there are various questions about whether an insulin product such as FastAct is the cause of low or high blood sugar and whether a blood glucose reading, in and of itself, constitutes an adverse experience.

Any pharmaceutical company selling insulin typically would know, or would need to determine, the history of how FDA has treated blood glucose readings in the context of insulin adverse event reports.

Apart from regulatory history, this is an instance where a company should seek good medical advice. To do a thorough job and truly understand the data’s significance, the company needs to put them in proper medical context. Offering medical advice is beyond the scope of this article, but what if a medical expert said a mere high or low blood glucose reading does not suggest any adverse experience with FastAct? What if the doctor said there are far too many potential causes of high or low blood glucose for drug companies to attribute any particular relationship between the event and the drug? The regulations do not require actual causation. FDA’s goal is broader than identifying a drug’s adverse events.

Depending on the facts and expert medical advice, PharmCo could construct a written medical opinion analyzing the data in the database and concluding the information likely to be submitted could not, in and of itself, constitute evidence of an adverse experience. Obviously, PharmCo would need to consider the entire adverse experience definition, including “Any failure of expected pharmacological action.” With a medical expert advising the company, PharmCo rationally could conclude it does not expect to receive the kind of information in its database constituting an adverse experience, to support a written company policy stating PharmCo will not scrub the database for potential reportable events.

In addition to medical experts, PharmCo may need others such as statisticians and computer scientists to help evaluate the data’s true scientific significance or meaning, leading to the next reportable event required element.

An Identifiable Patient

The reason PharmCo might need a statistician or computer scientist is to discern population trends versus individual data. To be a reportable event, a patient must have suffered an adverse experience. A data set as a whole could suggest some patient subpopulation had suffered adverse experiences, but the data would be insufficient to indicate whether any one patient in suffered an adverse experience. If PharmCo recognizes a trend among the population, it may have a duty to investigate and address it under FDA’s 2005 guidance on Good Pharmacovigilance Practicesand Pharmacoepidemiologic Assessment (for example, the discussion on registries),¹⁶ but the analysis would not trigger an adverse experience report because PharmCo could not tie it to a particular patient.

This is different from simply observing patients de-identified in the database and arguably makes no difference. FDA wants to know whether specific patients are affected, but not those patients’ identity. FDA only asks for coded reports to mask patient identity. At a higher level, FDA does not seem to care whether a manufacturer knows patient’s name. The regulators just want to know whether a patient was affected negatively and receive information concerning the patient’s reportable adverse experience.

At the same time, simply knowing some patient was affected negatively does not mandate a report. Indeed, there would be no way to complete the required fields if the company did not have in mind a specific, de-identified patient.

In the hypothetical scenario, PharmCo probably could discern an individual patient event if the information qualifies as an adverse experience.

An Identifiable Reporter

What does FDA’s requirement for an identifiable reporter mean and, importantly, what is the policy behind requiring a reporter? On one hand, it gives FDA an identifiable person with whom to follow up; however, it really plays a more important role. It means a human being found an issue worth reporting.

Remember an adverse experience does not mean the drug caused the experience. FDA is clear about that. If reporting does not rely on actual evidence of causation, how does a drug company draw the line between suspected adverse experiences needing to be investigated and those not requiring investigation or reporting? The answer depends, at least in part, on someone finding information worthy of reporting due to a suspected link to the drug, even absent evidence establishing that link.

As discussed above, a spontaneous report by either a doctor or a patient legally is sufficient to show connection, if not causation, for an adverse event to be reported. But in PharmCo’s case, the database information might be uploaded from a medical device like a blood glucose meter with no human involvement. In such a case, it cannot be said any human has offered the view an adverse event somehow is somehow caused by or related to the drug’s use. Indeed, even if the information is entered manually by the patient, it cannot be said the information is being “reported” to PharmCo concern about an adverse experience is associated in the reporter’s mind with the drug’s use. The question involves intent. Did a human being reach the conclusion an adverse event occurred and should be reported? Did the patient intend to “report” total experience with the drug, both good and bad? Even that argument would not mean the patient concluded an event was worth reporting as an adverse experience. This is an area where better FDA guidance would be extremely useful.

A Suspected Drug

Patient databases may be unclear regarding which drug was used. In the PharmCo case, there is insufficient information to determine whether some other company’s insulin or even another drug could be involved. In its Draft Guidance, FDA offers specific instructions for adverse drug event reporting where the drug may be manufactured by a different applicant or more than one drug may be involved, but very little guidance when there is uncertainty regarding which drug might be involved (except, of course, for the general recommendation to report whenever in doubt).¹⁷

Solutions

The analysis of the hypothetical case study is rather indeterminate, in part because the medical questions become the company’s greatest hope for excluding the database from adverse event reporting. In hindsight, PharmCo probably could have done more to avoid having to scrutinize the database for potential adverse experiences. This article offers suggestions to optimize database design and management and avoid triggering adverse event reporting analysis.

Checklists Based on Case Study

As a starting point, the analysis above provides factors to consider as a pharmaceutical company develops a patient engagement platform. For example, a company should carefully consider:

Privacy Policy

This is one of the easier issues to address if the company is willing to cede access to the data. Obviously, there is a lot at stake, and the company must think carefully about the advantages of accessing the data for research versus the burden of scrubbing the data for adverse events.

Collaborative Relationships Structure

Responsibility for analyzing data can be delegated to other companies; however, FDA would not look kindly on deliberately ignoring reports, i.e., telling a contractor to keep adverse events quiet. At the same time, in some instances, it would be commercially unreasonable to expect an IT vendor to identify and communicate adverse events to the pharmaceutical company. For example, if an IT vendor with no clinical knowledge or background owned and managed the database, it could be difficult for FDA to expect the vendor to recognize and report adverse events to the pharmaceutical company. Of course, FDA might argue even a pure IT vendor would be expected to collaborate with the pharmaceutical company’s clinical experts. For this delegation strategy to work, the privacy policy must limit the circumstances in which the IT vendor examines patient data.

Medical Significance of the Data Collected

It is possible the data sets collected might be insufficient to establish the presence of even a “suspected” adverse event. Here, the pharmaceutical company should consider text fields where patients or physicians can enter adverse event information. The pharmaceutical company might choose to avoid using free text fields in its database if the existence of user-input text could transform the database legally into one mined for adverse events.

Absence of a Reporter

Data downloaded from a smart device to a database may lack the reporter’s identity, needed to trigger an adverse experience reporting obligation.

Communicating With the Patient

Including language stating the data set is not intended for collecting adverse events in the terms of use and noting the company has no intention of monitoring it for adverse events is another way to help manage the risk of regulatory responsibility for a digital patient platform. In addition, the user interface might be designed to give patients a very explicit way of communicating adverse events outside the database itself. Indeed, this route might direct any issues of concern the patient has to the healthcare provider who can assess them in the first instance, and report them to the pharmaceutical company if merited.

This could help in two ways. First, it would support the company’s case stating the data set is not something it is monitoring for potential adverse experiences. FDA might appreciate the company’s effort to provide a separate vehicle for reporting those experiences. Of course, FDA also might view the disclaimer as self-serving. This is another area where FDA guidance would be very helpful.

Second, the terms of use help protect the company from potential product liability claims. The disclaimer and the associated mechanism for reporting adverse events indicate the company is not scouring the database, helping to deflect claims it had an obligation to look for problems. In the face of effective warnings, an injured person would have a much weaker claim the pharmaceutical company negligently failed to monitor the data. Disclaimers and warnings are never perfect by themselves, but they help.

The downside of this approach is relinquishing access to the data. A company cannot have it both ways. If the company says it has no intention of monitoring the data set for adverse drug experiences, it may not monitor the data set in a way to identify adverse drug experiences. Lack of monitoring may be unacceptable to individuals atither the company or the agency who want the drug’s impact vigilantly assessed. Further, this strategy reduces the incentive for FDA to complain about non-reporting,  but the agency still expects companies to report adverse events it receives through nontraditional means.

Communication With FDA

A company always has the option to ask FDA for guidance. It might petition for a waiver under 21 CFR Section 314.90. Given the ambiguities about patient database monitoring and an effective channel for physicians and patients to report adverse events, FDA might be willing to grant the waiver.

Further Questions for Another Day

More Complicated Factual Questions

This article focused on a relatively straightforward factual scenario: insulin and its relationship to blood glucose. It would be easy to come up with much more complicated situations. For example, what about tracking wellness for a patient taking a prescription drug? If the drug’s approval (e.g., for rheumatoid arthritis) did not entail wellness, but the database shows an overall worsening trend for wellness, does that decline constitute an adverse event?

Alternatively, the pharmaceutical company may want to collect the data to see what can be done to improve patient satisfaction. Such data also may help the company target future patients best suited to take the drug. For existing patients, a particular parameter in the database could trigger distribution of educational material to the patient. Would this patient satisfaction data potentially constitute an adverse drug event?

Limiting What Needs to be Reported

If a company finds itself having to monitor a database for potential adverse experiences, the next question is: how frequently would the company be required to search the database? A company may decide, even though there could be adverse experiences in the database, those adverse drug experiences are unlikely to be serious and unexpected, requiring 15 day reporting. Thus, the company would not have to monitor the database frequently, but could monitor it on perhaps a quarterly or annual basis and report what it finds in quarterly or Annual Reports. This is a complicated question beyond the scope of this article.

Issues Regarding Reporting Timeliness

This article did not tackle the issue of exactly when data found in a patient database trigger the need for prompt reporting as a serious and unexpected event. One of the interesting legal questions is whether a manufacturer can control the frequency of database analysis for potential reportable information by disclosing this frequency to the patient and the world.

Medical Device Regulatory Compliance

Interesting questions arise if the database is part of an electronic system, for example, which includes analytics software. In such cases, the software might be considered clinical decision support. FDA plans to publish a guidance document soon defining when such software crosses the line and becomes regulated. If it is regulated, what does that do to the adverse event reporting analysis? Further, if the scenario involves a regulated medical device, combination product issues also may have to be considered.

Intentional Scouting for Adverse Events

As explained in the introduction, many in the pharmaceutical industry feel some mining of patient databases would benefit both patients and companies. Regarding mining, the question becomes whether FDA will be practical and not require what could be called excessive compliance simply because the company chooses to cross the threshold and examine data in the data set periodically. For example, how often would the company need to conduct its data analysis? How reliable would the analysis need to be in identifying true adverse events?

Beyond avoiding impractical requirements, FDA would need to guard against overreacting just because improved tools mean more adverse events are reported. One of industry’s greatest fears is increased FDA burdens (e.g., requiring additional warnings) if tools to identify adverse events improve and many more events are reported. Certainly, many at FDA are quite sophisticated in their approach to the proper interpretation of pharmacovigilance data, but industry always fears the potential for overreaction.

Conclusion

Patient engagement platforms can provide tremendous value to the healthcare system, and pharmaceutical companies are positioned uniquely to offer platforms focusing on drug therapy. Healthcare should not suffer simply because these platforms trigger potentially extraordinary costs associated with data mining and reporting adverse events.

These issues are attracting worldwide attention. Indeed, the rules are changing in the EU, in the Good Pharmacovigilance Practices adopted in 2012, and in other locations.¹⁸ Right now in the US, there simply is too much uncertainty about adverse experience reporting requirements. The principal guidance has been in draft form since 2001 and a proposed regulation¹⁹ has been on the table since 2013. If finalized, the regulation would revamp the adverse event reporting system completely to bring it into greater harmony with international standards. FDA guidance in this area would help unlock great potential for pharmaceutical companies to provide valuable services to patients and caregivers alike.

References

1. Gupta A, Sinha S, Schumacher J. Digital Health: A Way for Pharma Companies to be More Relevant in Healthcare. PricewaterhouseCoopers. Published 8 November 2013. http://www.strategyand.pwc.com/global/home/what-we-think/reports-white-papers/article-display/digital-health-pharma-companies. Accessed 28 July 2015
2. 21 CFR Section 314.80.
3. Ibid.
4. Ibid.
5. Ibid.
6. Draft Guidance for Industry, Postmarketing Safety Reporting for Human Drug and Biological including Vaccines, US Food and Drug Administration. Published March 2001. FDA website. http://www.fda.gov/BiologicsBloodVaccines/GuidanceComplianceRegulatoryInformation/Guidances/Vaccines/ucm074850.htm. Accessed 28 July 2015
7. Ibid.
8. Ibid.
9. Ibid.
10. Ibid.
11. Op cit 2.
12. Op cit 6.
13. Ibid.
14. Ibid.
15. Ibid.
16. Guidance for Industry: Good Pharmacovigilance Practices and Pharmacoepidemiologic Assessment. Published March 2005. FDA website. http://www.fda.gov/downloads/RegulatoryInformation/Guidances/UCM126834.pdf. Accessed 28 July 2015.

     

17. Op cit 6.
18. Guideline on Good Pharmacovigilance Practices (GVP) Module I – Pharmacovigilance Systems and Their Quality Systems. Published 22 June 2012. EMA website. http://www.ema.europa.eu/docs/en_GB/document_library/Scientific_guideline/2012/06/WC500129132.pdf. Accessed 28 July 2015
19. Federal Register, Vol. 68, No. 50. FDA Proposed Rule on Safety Reporting Requirements for Human Drug and Biological Products. 14 March 2011. http://www.gpo.gov/fdsys/pkg/FR-2003-03-14/pdf/03-5204.pdf. Accessed 28 July 2015.

     

About the Author

Bradley Merrill Thompson is a shareholder in the law firm EpsteinBeckerGreen, practicing in the firm’s Washington office. He focuses on FDA regulation of drugs and medical devices, specifically in the context of digital health. In addition to representing individual companies, he serves as general counsel of the Combination Products Coalition comprised of drug, biological product and medical device manufacturers, as well as the CDS Coalition, a group of companies that make standalone software used to guide healthcare decision-making. He can be contacted at [email protected].

Cite as: Thompson B M. “Managing Pharmacovigilance in Digital Health Initiatives.” Regulatory Focus. August 2015. Regulatory Affairs Professionals Society.