Image from the office of Senator Deb Fischer (R-Neb.)
Longtime MobiHealthNews columnist Bradley Merrill Thompson, a member of the lawfirm Epstein, Becker & Green, and one of the founders of the mHealth Regulatory Coalition and the CDS Regulatory Coalition, sent over a few examples of the types of apps that a bill in Congress, called the PROTECT Act, would instruct the FDA to stop regulating. The PROTECT Act is a companion bill in the Senate to the House's SOFTWARE Act, which also seeks to limit the FDA's regulatory scope for mobile medical apps.
Here are a few thoughts from Thompson on which types of apps would no longer be regulated:
When reading the list below of examples of software that the PROTECT Act would remove from FDA regulation, it’s important to understand that the items on this list are presently regulated by FDA, and have been so since they were first marketed in some cases many years ago.
High Risk CDS
Many of the following examples flow from one simple principle. A good indicator of risk for CDS is when the user is substantially dependent on the software for clinical decision-making. Those situations can arise in many different contexts, but generally involve a serious or life-threatening disease or condition.
The following list is illustrative of types of software that are (1) CDS and (2) would become no longer regulated by FDA under the PROTECT Act.
Apps and other software that guide untrained users to make very complex medical decisions.
Example 1: Consumer Use Melanoma Apps. There are software apps being introduced that claim to allow ordinary consumers to spot moles that are potentially cancerous. With one of these apps, a consumer might take a picture of a mole on her skin with her cell phone camera, and then take a picture again in six months, and the app is supposed to say whether the mole has changed in a way that could suggest melanoma, in which case the app would recommend the consumer go to the doctor. But what happens if the app misses a potential melanoma?
Example 2: Sports Concussion Injury Apps. There are mobile apps that use the built-in motion sensors of a mobile device to analyze postural sway, a key factor in assessing, managing, and monitoring concussion symptoms and orthopedic dysfunction. These apps can be used by football coaches to assess whether a player has been hurt such that he needs to be taken out of the game and seen by a doctor. But what happens if the app suggests a player is fine when he is not?
Example 3: Drug dose calculators. Long used by physicians to help them calculate drug dose, more recently physicians are recommending that patients get drug dosage calculators configured to a particular drug. For example, for a person with diabetes, the calculator will allow them to calculate the proper amount of insulin to take considering all of the various factors such as blood glucose level.
Example 4: Disease managers for patients. A diabetes manager guides a person with diabetes to manage the various factors that influence the disease. Based on patient input this software recommends course of action for the patient to take , including drugs or food or drink, and based on longitudinal analysis provided by the system, the app recommends to primary care physicians how to titrate medications for diabetics.
Software used in a setting that does not allow the doctor sufficient time to second-guess the software.
Example 5: Emergency Care Predictive Analytics Software. Emergency room physicians and first responders are rushed to quickly consider all the facts and make first a diagnosis and then a therapeutic decision. More and more we are exploring ways to assist these physicians and EMTs operating under extreme pressure to consider all of the relevant information as they reach a decision. This category of software may process and analyze large amounts of both structured and unstructured healthcare data and vital sign data to recommend and adjust a treatment in an emergency care setting. Specifically, the software analyzes the information using a multi-factorial algorithm and issues treatment recommendation, which may include medication dose values and instructions. Considering the volume of information that the software considers and the little time available to the doctor or EMT, there is no practical way for the physician or EMT to read, understand and critically evaluate the basis for the computer’s recommendation. But what happens if the software gets it wrong, and rather than follow his own instincts, the doctor/EMT goes along, nervous that the computer has thought of something that he hasn’t?
Example 6: Hospital patient monitoring software. For years, hospitals have struggled with how to help nurses be vigilant in watching the patients under their care. In the early days, many vendors of specific monitors included alarms to alert nurses to a critical level. The problem is, those alarms are generally over inclusive, going off so often that nurses no longer treat them as truly indicative of an emergency. So now there is an emerging category of software using sophisticated analytics to assess the various data related to a monitored patient, giving nurses a more meaningful notification when a patient’s health is deteriorating. As nurses and other caregivers become more dependent on these higher level analytics, what happens when one doesn’t work, a patient crashes and the caregiver is alerted too late?
Software that takes a very complicated calculation and presents a result without transparently revealing the basis for the calculation.
Example 7: Radiation dose calculator. Radiation treatment planning is generally performed on dedicated computers using specialized treatment planning software. Depending on the radiation delivery method, several angles or sources may be used to sum to the total necessary dose. The planner will try to design a plan that delivers a uniform prescription dose to the tumor and minimizes dose to surrounding healthy tissues. Many factors are considered by radiation oncologists when selecting a dose, including whether the patient is receiving chemotherapy, patient comorbidities, whether radiation therapy is being administered before or after surgery, and the degree of success of surgery.
Example 8: Burn Victim Fluids Assessment. The software could, for example, use an advanced algorithm that learns how each patient responds to fluid therapy each hour.
The algorithm could use fluid in and out trend data to predict the fluid rate for the next hour that will best achieve the urine output target range.
These are just meant to be a few examples, but it isn’t hard to imagine many others in each of the categories. For example, one can imagine software being devised to help patients make decisions about any number of diseases and whether they ought to visit their doctor or take a specific action. Further, the practice of medicine is getting ever more complicated and requires examination of huge amounts of data. Software offers an obvious ray of hope, but what happens when software ends up making very complex decisions and the physicians, either because time does not permit or because the software does not reveal enough to be evaluated, end up deferring to the software?
