Over the last couple years, FDA has clarified the scope of its regulation over mobile health. In the agency’s September 2013 guidance, FDA spelled out its oversight for some of the most common mobile medical apps. Then, last month, in two separate draft guidances FDA explained the limits on its oversight of apps used for general wellness like fitness trackers, as well as apps that may be accessories to a medical device. And already in February, FDA published a final guidance deregulating medical device data systems, a category that includes numerous mobile apps. The agency has been busy.
But one area FDA has yet to clarify is apps that guide the appropriate use of drugs. Many of those apps potentially fit the category of clinical decision support (CDS) software, an area that FDA has been planning guidance since 2011, but so far has not addressed.
To be fair, this is undoubtedly one of the most difficult guidances to write. Frankly, the number of use cases for CDS is mind-boggling. Compounding matters, creative people are coming up with new use cases on almost a daily basis. For policymakers this is both exciting and challenging.
To help pharmaceutical companies during this period while FDA drafts its proposed guidance, I’d like to summarize what we already know from previous FDA communications, and also offer some thoughts on what the upcoming guidance should address.
Pharmaceutical App Categories
Before talking about FDA’s regulatory guidance, I’d like to explain what I mean by the term “pharmaceutical app.” Generally speaking, I’m referring to apps developed by pharmaceutical companies for use in conjunction with that company’ drug product. Frankly, pharmaceutical apps have a wide variety of potential uses including the following eight categories:
1. Patient information collection and storage
Collect family history and other pertinent information to form the basis for drug prescribing
Serve as electronic health records for drug therapy
2. Pharmaceutical shopping
Locate pharmacies that carry a particular drug
Help with price comparisons
Remind consumers to refill their prescriptions
3. Research and education
Provide electronic versions of the drug labeling
Allow consumers to research information on a drug using public or proprietary sources of information
Allow physicians to research drugs, including electronic versions of the physician’s desk reference
Help identify drug formulary guidelines or professional society treatment guidelines
Flag drug-drug interaction or drug-allergy lookup
4. Physician management of drug-prescribing information
Facilitate e-prescribing
Facilitate computerized physician order entry (CPOE) as it relates to drugs
Collect and manage information on adverse drug events
5. Patient-focused drug administration and compliance management
Remind patients to take their medicines or otherwise help patients with the scheduling of their medications
Serve as an electronic logbook for patients to record when they take their drugs
Control of medical device used in dispensing drugs, for example controlling an insulin pump or other drug delivery mechanism
Work with smart pills or smart injectors to record drug administration to help determine compliance
6. Clinical decision support, for either patients or professionals
Identify the proper drug to treat a particular disease or condition
Guide or calculate dosage calculation or decision-making
Calculate prediction rules and risk and severity of illness assessments (e.g., APACHE score, AHRQ Pneumonia Severity Index, Charlson Index) used to inform drug prescribing;
Help the patient self-manage their own drug treatment by guiding their decision-making broadly
7. Patient testing and assessment
Use, for example, a cell phone to perform some direct physiological measurements such as an audiology test or eye test that could lead to drug treatment
8. Clinical trial management
This category includes several subcategories (borrowed from Opportunities: Advancing the Pharmaceutical Industry through Mobile Technologies, an ArcStream Solutions White Paper), including:
1. Tracking
Creating forms (e.g., screening and enrollment, drug regimens, ordering supplies, etc.)
Creating labels and handling information for biological samples
2. Data Collection
Prompting patients to record required clinical data and information in prescribed, common, electronic formats
3. Communication
Synching and transmitting data and documentation (CRFs, drug logs, etc.)
Sharing notes and calendars
Scheduling appointments
Management Providing monitors and investigators with to-do lists and other guides to trial rules and management, as well as audit trails through data and time stamping
4. Storage
Storing a variety of trial documents on investigators' mobile devices for easy reference, including:
Protocols and potential violations
Clinical practice tutorials
Rules for sample handling
Inclusion/exclusion criteria
Annotated CRF templates
These potential apps for use in clinical trials raise special questions that I’m not going to try to address in this post. There are very specific regulations that cover how clinical trials must be conducted, and mobile apps used in that context need to meet those standards. Instead, the rest of this post will address the first seven categories.
FDA’s General Approach to the Regulation of Pharmaceutical Apps
In the free ebook I wrote for MobiHealthNews, I included chapter VI on FDA’s Regulation of Pharmaceutical Apps. I don’t want to repeat all of that here, other than to observe that many pharmaceutical apps are regulated by FDA as drug labeling. As pharmaceutical manufacturers know well, anything that a drug company distributes to help physicians and patients know how to use its drug will be regulated as drug labeling. In fact, even materials that are very general in nature, given out for promotional purposes, may be regulated.
So if the developer of the app is the manufacturer of the drug, chances are very good that FDA would consider the app to be drug labeling. If the developer is a payer or provider, the app is not likely to be considered drug labeling. Legally, we focus on the use of a drug intended by the seller of the drug. Bystanders can typically say whatever they want. At times, that doesn’t seem fair because third parties can say some pretty outrageous stuff and get away with it. But the law chooses to focus on the claims made by the companies that profit from the sale of the drugs.
The question I want to discuss here is whether FDA might instead regulate the software as a medical device, and this question is much less sensitive to whom the developer is. As you know from other posts on MobiHealthNews, software can qualify as a medical device if it is used in the cure, mitigation, treatment or diagnosis of disease or other conditions in man. Obviously that’s very broad language, so we need to investigate how FDA has applied that language with regard to specific categories of pharmaceutical apps.
FDA’s Recent Statements Regarding Pharmaceutical Apps
While FDA has been clarifying its approach to mobile apps generally, fortunately for the pharmaceutical industry, the agency has sprinkled in a few examples of pharmaceuticals apps. Let’s look at a few.
1. Mobile Medical App Guidance
In FDA’s final guidance on mobile medical apps, FDA created a category the agency called “enforcement discretion” to include the borderline products that FDA did not wish to regulate. In that list, FDA included several examples of pharmaceutical apps. They include:
Apps that provide simple tools for patients to log, track, or trend their events or measurements (e.g., drug intake times) and share this information with their health care provider.
Apps that coach patients with chronic conditions, and promote strategies for adhering to pre-determined medication dosing schedules by simple prompting [By the way, prior to this guidance, FDA had regulated these drug reminders.]
Apps that match patient-specific information (e.g., diagnosis, treatments, allergies, signs or symptoms) to reference information routinely used in clinical practice (e.g., practice guidelines) to help assess a patient. Examples include:
Apps that use a patient’s diagnosis to provide a clinician with best practice treatment guidelines for common illnesses or conditions such as influenza; and
Apps that serve as drug-drug interaction or drug-allergy look-up tools.
Mobile apps that prompt a user to enter which herb and drug they would like to take concurrently and provide information about whether interactions have been seen in the literature and a summary of what type of interaction was reported;
Mobile apps for providers that help track or manage patient immunizations by assessing the need for immunization, consent form, and immunization lot number
Those are borderline cases that FDA decided are so low risk they do not merit FDA oversight. There also are some categories of apps that are not even borderline, and clearly don’t merit FDA regulation, including apps that:
Provide general patient education and facilitate patient access to commonly used reference information;
Allow users to input pill shape, color or imprint and displays pictures and names of pills that match this description;
Provide and compare costs of drugs and medical products at pharmacies in the user’s location.
However, perhaps suggesting what the upcoming CDS guidance will say, the MMA guidance explained that to stay outside of FDA regulation these may not be intended to aid “clinical decision-making (i.e., to facilitate a health professional’s assessment of a specific patient, replace the judgment of a health professional, or perform any clinical assessment).” At this juncture, I think we need to be careful not to read that sentence too broadly. I think it was probably added by some FDA lawyer wanting to cover his bases. I will be anxious to read the CDS guidance when it comes out.
The MMA guidance is a long document, and includes many other examples not particularly related to pharmaceuticals. For example, the guidance indicates that most common medical calculators that teach calculations learned in medical school are not regulated. Further, FDA will not regulate apps that merely embody common guidelines used as checklists to help the professional remember factors she should consider for screening purposes. So if you are making an app that is associated with pharmaceuticals, you’d best read the whole guidance. You might find something else useful in there.
2. FDASIA HIT Report
In 2012, Congress passed the Food and Drug Administration Safety and Innovation Act (FDASIA). Section 618 of that act required that FDA, together with ONC and FCC, develop a federal strategy for regulating health information technology. Since then, the agencies have been working toward that goal, and published a draft of their strategic plan in April 2014. The plan represents an important step forward in getting clarity around pharmaceutical apps.
The plan tracks the earlier MMA guidance, but goes a bit further in specifying some categories of apps that FDA will not regulate. With regard to pharmaceutical apps, in addition to the categories already identified, the draft strategic plan says that FDA will not regulate:
Most drug dosing calculations;
Drug formulary guidelines;
Most clinical decision support software
It’s the word “most” that I find unsettling, used with regard both to drug dosing and CDS. “Most” implies that some is regulated and some is not, so until we get more detail, all that tells us is that there is an issue here that we need to watch.
3. IMDRF Paper
In my opinion, one of the more useful sources of information on this topic is a document that FDA did not publish. The International Medical Device Regulators Forum (IMDRF) is a collaboration among FDA’s counterparts throughout the world. Over the last couple of years, the IMDRF has been working to come up with a harmonized approach to regulating software that all member countries can implement.
In September 2014, IMDRF published a consensus document entitled Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations. The document is instructive for our purposes because FDA was heavily involved in drafting it. To be sure, it is also the product of compromise among international regulators. But I also can’t see FDA ignoring the document when the agency’s fingerprints are all over it.
At a high level, the IMDRF document explains that assessing risk in software is really a function of two factors:
1. The significance of the information provided by the software to the healthcare decision, and
2. The seriousness of the patient’s condition.
Some software merely provides useful background. Other software plays a more critical role, such as automating a very complex dosing calculation that the physician is likely to rely upon. The risk presented by the software vary significantly depending on its role in the decision-making.
Further, software that guides a doctor in treating the common cold presents a different risk profile from software that guides an emergency department physician as she assesses head trauma.
The IMDRF document is fairly long, and way too complicated to explain here. It presents a complicated algorithm for assessing various combinations of those two factors. Further, the document offers dozens of examples to show how the algorithm works in specific instances. I would recommend reading it if you are trying to figure out how FDA is likely to treat your particular pharmaceutical app. I do, however, want to mention an example that involves a pharmaceutical app.
The IMDRF document analyzes software that helps diabetic patients by calculating bolus insulin doses based on carbohydrate intake, pre-meal blood glucose, and anticipated physical activity reported to adjust carbohydrate ratio and basal insulin. In the United States, FDA has regulated this kind of calculator as a class II medical device. Last fall, FDA held a meeting to discuss whether it should change that classification. The agency has made no decision yet.
But in the IMDRF document, the authors explain that the software deserves a relatively low classification because it “is used to aid in treatment of a condition not normally expected to be time critical in order to avoid death, long-term disability, or other serious deterioration of health.” Based on the context of the document, a rough translation into US law would place such software more likely into class I. At the FDA public meeting, however, there were those who earnestly argued that insulin bolus calculators can be dangerous in the hands of untrained consumers. We will have to wait to see what FDA actually does.
Proposals for Clarifying FDA Regulation of Pharmaceutical Apps
Over the last six months or so, I’ve been talking with numerous pharmaceutical companies about the apps they are developing. We’ve been looking at what FDA has published so far, and identifying the key questions FDA should address in upcoming guidance. Indeed, based on FDA’s guidance so far, my proposals are in line with what I can discern of FDA’s current thinking, but also go into areas FDA has not yet addressed.
I think FDA should not regulate as a medical device software that:
1. For professional use, calculates a drug dosage using the principles set out in the drug labeling or in published guidelines so long as the source of the calculation method is clearly identified.
2. Likewise for professional use, calculates future risk associated with a disease or condition according to published guidelines so long as the source of the calculation method is clearly identified.
3. Provides reminders to patients regarding when they should take their medicine, according to guidelines either set out in the drug labeling or prescribed by the patient’s physician.
4. Records information as to when a patient took his or her medication, using either manual entry or smart dispensing devices.
5. Guides a physician or other professional with prescribing privileges in assessing which, if any, drug therapy is appropriate for a given disease or condition so long as:
The guidance is based on published guidelines or other public reference materials, and
The software is transparent.
You might be wondering what the heck makes software “transparent.” Transparency means the ability of the end user to see past the software to examine for herself the underlying data and clinical logic the software is using. If the software is transparent, the user does not have to depend on the software to reach her decision. Rather, through examining the same information the software considers, she can apply her own expertise to determine whether she agrees with what the software recommends.
Next Steps
While FDA is developing its guidance on clinical decision support software, Congress is also debating at least two different bills – the SOFTWARE Act in the House and the MEDTECH Act in the Senate-- that would help clarify the rules for pharmaceutical apps. That clarification would allow the pharmaceutical industry to help doctors and patients make more appropriate use of drugs.
There is, for example, a growing body of scientific literature that suggests that mobile apps offer great potential to increase medication adherence. Non-adherence is estimated to cause approximately 125,000 deaths per year in the United States. Given FDA’s responsibility to oversee the safe and effective use of drugs, it would seem that encouraging the development of mobile apps to improve the safety of pharmaceuticals would be a high priority.
