(I would like to thank Tim Gee of Medical Connectivity Consulting and Mike Robkin for their comments on a draft. The views expressed, right or wrong, are only the author’s and should not be attributed to anyone else.)
At mHealth meetings, I keep hearing representatives from hospitals and other healthcare caregivers say they don’t believe FDA regulations extend to them. They seem to believe that an institution must have a smokestack and an assembly line before it needs to worry about FDA regulation beyond clinical research. But that's just not true. FDA can regulate even those engaged in the practice of medicine, if they are also engaged in FDA-regulated activities.
FDA regulation covers making “devices,” regardless of who engages in that activity. In this series of articles, I've described the types of hardware and software FDA might regulate as “devices,” and provided some background on what the regulatory framework looks like. In my last article, I noted that recent activity at FDA suggests the agency is preparing to expand its scope to most areas of HIT, and by implication into both the patient-end and the caregiver-end of mHealth. In fact, as revealed by the Huffington Post, in February of this year, FDA sent a letter to 350 hospitals inviting them to voluntarily report problems with HIT systems (including EHRs and hand-held devices), as a part of FDA’s MedSun program.
In this article, I review examples of where FDA has regulated caregivers to identify the factors that lead the agency in that direction, and provide a high-level overview of the relevant law. With that as background, I also examine some mHealth care provider practices that might end up FDA-regulated, and offer suggestions for how care providers can avoid FDA regulation if that prospect doesn't excite them.
FDA Care Provider Regulation Examples
If, as an example, a large hospital were to buy a medical device company, FDA would not all of a sudden lose authority over the products the medical device company sells. In fact, it's actually somewhat common for FDA to regulate activities of healthcare providers and professionals who tread into product waters. I'll give four examples.
First, over the last couple of decades, in FDA's view some pharmacies went beyond the traditional practice of pharmacy services into the production of new drugs. Pharmacies have always compounded drugs, which can include mixing various ingredients to make them taste better or easier to digest. But according to FDA, in some cases pharmacies started to basically make their own versions of commercially-available drugs. Apparently some of those pharmacies also did so in advance of receiving a prescription, and in large quantities unrelated to any one patient. So FDA adopted an enforcement policy declaring those activities to be regulated drug manufacturing.
Second, some clinical laboratories develop their own chemical reagents and software for conducting tests on blood and other specimens. FDA declared it has the right to regulate those chemical products just as if they were made by commercial manufacturers. Indeed, FDA has proposed to regulate a subset of laboratory-developed tests that combine multiple variables (e.g. gender, age, and weight) using an interpretation function (i.e. algorithm) to generate a patient specific result.
Third, physicians and other clinicians sometimes directly sell drugs to, or use medical devices on, patients. When they do so, these clinicians also might promote their services. If they promote uses the FDA has not approved for the products, FDA may enforce its regulatory requirement on the caregivers. In the 1960s and 70s, FDA took several clinics to court that were hawking various remedies for cancer and all sorts of other maladies. As recently as last year, FDA went after a clinic that was offering hyperbaric chambers to treat conditions like stroke, coma, and multiple sclerosis. When the clinicians stand to directly gain financially and use aggressive promotion beyond the cleared label, FDA tends to get involved.
Fourth, and perhaps most analogous to mHealth, FDA regulates the hospital reprocessing and reusing of “single use devices.” Manufacturers of disposable products do not validate cleaning and re-sterilization of their products. So when hospitals decide, as a matter of saving money, to reuse devices intended to be thrown away, FDA says in industry guidance that the reuse is a new use beyond what the original clearance contemplated. As the promoter of the new use, the hospital needs to satisfy FDA regulatory requirements just as any other manufacturer, securing approval and following good manufacturing practices.
The point of these examples is FDA has shown no reluctance to impose its requirements on any type of healthcare organization that engages in what the agency believes to be manufacturing. Smokestacks are not required.
Legal Overview
A warning to lawyers: this is not a law review article. These issues are complicated, but I'd like to distill these complex laws down to an executive summary.
Being a math nut, I developed the following formula to describe how FDA jurisdiction is established:
In its simplest terms, FDA regulates medical devices that have an adequate connection to commerce. As already mentioned, in my first article I described what it takes to be a medical device. The definition includes both a tangible device such as software and an intended use for a medical purpose. In my most recent article, I explained how FDA may be treating even the back-end HIT systems of mHealth providers as regulated articles.
So the question becomes whether these articles in the hands of hospitals and other providers satisfy the connection to commerce necessary for FDA jurisdiction. One piece of that required connection is the interstate element. While I won't bore you with a dissertation on interstate commerce, most lawyers realize that almost any commerce now is connected enough to interstate commerce to give the federal government jurisdiction. Indeed, in medical device law, that connection is presumed.
The Federal Food, Drug & Cosmetic Act says that if an organization, when holding a device for sale, does anything to cause it to be “adulterated or misbranded”, including promoting for an unapproved use, the organization has committed a prohibited act. So in this case the issue really comes down to whether an article is “held for sale.” Broadly speaking, there are a variety of judicial cases over the last 40 years which suggest that healthcare providers may be holding devices for sale if they resell the device to the patient, or even use the device on a patient. When enforcing this particular provision, FDA seems to look for instances where the caregiver is in the distribution chain and engaged in promotion.
Upon learning this, many doctors will quickly point out that they are engaged in the practice of medicine and section 906 of the Act says that FDA will not regulate that. That is true. But there is a line the doctors can cross leaving the practice of medicine behind and entering the business of selling devices. The statute contemplates giving freedom to those who are regulated by state boards of medicine under professional standards, with regard to the activities traditionally within that realm. The statute does not contemplate giving freedom to software engineers working away from patients, developing software and hardware configurations.
It is also true that manufacturing custom devices falls within an exemption from most FDA regulations. While the exact scope of that exemption has been the subject of much debate, most agree the custom device exemption is directed to the practice of tinkering with approved devices to make them suitable for individual patients or individual doctors or other professionals. It does not contemplate producing HIT systems used by multiple patients or multiple caregivers.
The bottom line is that the Act can quite comfortably be read as applying to hospitals and other caregivers engaged in the development and production of software and hardware configurations that support mhealth.
Implicated Hospital Activities
So what mhealth hospital activities might fall within FDA regulation? The following are just hypothetical and broad categories of activities that under certain circumstances FDA might decide to regulate.
Let's say a hospital wants to use mhealth to better manage the care of people with diabetes. Let's also say there are commercial products that allow people with diabetes to download their glucose readings into an app on their smart phones. As I've explained before, that app is quite likely to be FDA-regulated itself. Let’s further say the plan is for that app to transmit the data back to a hospital.
Now here is where it gets interesting. What if the hospital wants to develop its own proprietary system that sits on its own servers to collect the data from patients and manage a database into which physicians can tap? Let's say the hospital pursues this route because either it's simply not satisfied with the commercially-available software products, or there's some need to develop a better, more integrated approach that fits the hospital's legacy systems.
That proprietary system might be FDA-regulated. Even though the system is one-of-a-kind, in this hypothetical it is used for each and every patient enrolled in the program. If that system hiccups and switches the identities of two patients, care can be affected.
Compounding this, hospitals are apparently starting to sell access to their own HIT systems to smaller hospitals and physician practices. HealthLeadersMedia described this recent trend. In these cases, the hospitals risk even more likely becoming resellers of the software. That practice frankly makes it easier for FDA to assert jurisdiction.
Avoiding FDA Regulation of Caregivers
As before, I'm not giving advice on the evasion of detection, but rather on staying outside of the regulated territory. The following is merely my personal list of eight factors that may keep FDA from deciding to regulate a hospital’s software or hardware development.
First, it would help if some regulatory authority stepped in and oversaw this area of hospital activity. In the examples above, FDA was most likely to stay away from regulating a given activity if the agency felt another agency already was doing the job. FDA avoids duplicating the efforts of the state boards of pharmacy, state boards of medicine, and federal and state regulators of clinical laboratories. If hospitals work with an accrediting organization or some other body that could oversee this activity, they may well keep FDA from getting involved. However, it’s unlikely the current CCHIT certification is demanding enough to give FDA much comfort.
Second, these hospitals and clinics may wish to avoid mhealth applications that involve too much public health risk. That includes the disease or condition being treated (cancer compared to sinus infections) and the clinical role of the technology, as well as the novelty of the software applications. FDA is much less likely to regulate software applications that merely embody tried and true algorithms than those that advance novel approaches. Further, the more proactive a hospital is in conducting quality assurance of the kind a manufacturer would pursue, the less likely FDA will regulate.
Third, the hospital should stay as far away as possible from the actual parent medical device. FDA is more likely to regulate software or hardware that more directly accessorizes a blood glucose meter or other traditional medical device. Further, the less tailored the software or hardware is to the particular medical device, the less likely FDA will regulate. These factors all revolve around close functionality, not the physical proximity of the hardware or software to the medical device.
Fourth, FDA will be less likely to regulate hospitals if the hospital is filling an important void. If there are already commercially-available products and the hospital is making its own either to save money or because of some other idiosyncratic preference, FDA may view the activity as trying to skirt its authority. In a fast-moving area like mHealth, the question is not only whether there already is a product available commercially, but whether there could be a commercial product. FDA would not want to see hospitals jump in simply because they are impatient with commercial manufacturers conducting a more diligent but time-consuming development process.
Fifth, in all of the examples above where FDA chose to regulate, the agency was responding to aggressive promotion. The more aggressive the promotion and the more outside of traditional FDA clearances, the more likely FDA is to regulate.
Sixth, scale is a big factor. In nearly all of the examples above, FDA only got interested when the practices grew big. That's a practical factor in the sense the technology starts to affect more patients, and commercial manufacturers could actually supply that need.
Seventh, sharing the hardware and software with others makes it easier for FDA to assert the hospital is in the business of reselling.
Eighth, and perhaps moist obviously, if the hospital is engaged in modification of commercial systems, staying within any existing FDA clearance avoids FDA interest. Obviously “modification” can encompass a wide range of activities from life-critical changes to changes in the user interface, and configuration changes to hardware and network design and support. The regulatory risk of each type of change needs to be considered on a case-by-case basis.
Conclusions
At the end of January 2010, FDA held a public meeting on the interoperability of medical devices. At that meeting, many of the speakers talked about the need for systems integrators. The favorite analogy was the aircraft industry where two primary manufacturers are big enough to set specifications for individual component suppliers to assure interoperability. By analogy, some people at the meeting suggested hospitals and other end-users play that role with medical devices.
For mHealth, that's problematic if neither the systems integrator nor the individual component suppliers secure the necessary FDA clearance for the system as a whole. FDA regulates systems as systems. So if the individual component companies don't take on the responsibility of FDA compliance for the system, it's up to the integrator. Perhaps some hospitals want to take on that role and secure the necessary clearance from FDA. That could make some sense. But frankly it seems far more likely that an independent third party would play the systems integrator role, securing FDA clearance, and then selling that system to multiple hospitals and other caregivers. Either way, FDA will want to make sure the systems are safe and effective.
There are probably many different ways FDA can assure the safety and effectiveness of the systems. In my next article, I'll offer some suggestions for where I personally think all of this is heading.
