"Under the Federal, Food, Drug, and Cosmetic Act, HIT software is a medical device." That's according to Dr. Jeff Shuren, the new director of the Device Center within FDA. Yikes. Dr. Shuren testified yesterday at a hearing of the HIT Policy Committee, Adoption/Certification Workgroup. The workgroup invited numerous speakers from different sectors to discuss the safety of HIT, and possible regulatory approaches.
Dr. Shuren's conclusion portends a new and perhaps more demanding regulatory environment for mHealth. Over the last several months, I've written a series of articles in MobilHealthNews to outline FDA requirements that might apply, depending on the circumstances, to the hardware and software used in mHealth. Notice how I qualified that. I've suggested that manufacturers should be aware of certain nuances in FDA law related to intended use claims and other limits on the scope of FDA regulation.
But in his written statement, Dr. Shuren did not equivocate. He did not limit his conclusions, for example, depending on the specific intended uses for the HIT. He just swept it all into FDA regulation and moved on. I don't know whether Dr. Shuren and I would truly disagree on the scope of FDA regulation if we discussed it, but he seems to want to move quickly past that to talking about how FDA should regulate this area.
On the eve of the hearing, Sen. Grassley, the ranking Republican on the powerful Senate Finance Committee, sent out letters revealing his interest in FDA regulating HIT. The events of this week are significant enough that I want to depart from the planned schedule of articles to discuss what happened, and its implications for mHealth.
What happened?
At the hearing yesterday, after expressing his view that HIT software is a medical device, Dr. Shuren observed FDA has "largely refrained from enforcing our regulatory requirements with respect to HIT devices." That, Dr. Shuren suggests, is about to change. In explaining the change of heart, he revealed FDA has received 260 voluntary reports of HIT-related malfunctions with the potential for patient harm. Of those reports, 44 included injuries and six even reported deaths. In a table attached to his written testimony, he provided de-identified examples of these reports, several of which involved one patient's data being substituted for another's. Since FDA at this juncture only relies on voluntary reports, Dr. Shuren asserted this might be the tip of an iceberg.
In talking about how these products operate, Dr. Shuren observed that HIT software applications typically do not operate as standalone devices. Instead, they are interconnected with one another into networks of varying degrees of complexity. Sounds kinda like mHealth software.
Dr. Shuren's bottom line: while HIT software has the potential to improve patient care, given the reported safety issues, federal regulation is needed and FDA is the right agency to provide that oversight.
As to what that oversight should look like, he seemed very open to a range of possible solutions. Dr. Shuren described three different possible regulatory strategies. At the lowest level of oversight, HIT vendors could register with FDA and be required to file reports on adverse events associated with their products. In the middle tier of oversight, on top of that FDA could require compliance with its quality system regulations. These regulations operate similar to ISO standards, but can be more demanding in that they require such things as rigorous design controls. As the highest level of possible oversight, these HIT software products could be subjected to the premarket clearance or approval scheme used for other medical devices. That approval scheme is itself a tiered approach based on risk.
Just before the hearing, anticipating FDA's testimony, Sen. Grassley sent HHS Sec. Sebelius a letter asking her to explain the Department's approach to assuring the safety of electronic health records, subsidized by the $20 billion investment in the stimulus package. He recited concerns he's heard from the public about HIT products that don't function properly, and hospital administrators and HIT vendors who turn a deaf ear to complaints. Sen. Grassley suggests FDA revisit its responsibilities in regulating HIT products.
In his letter, quoting from a 1997 article in the Journal of the American Medical Informatics Association, Sen. Grassley points out that industry groups developed a consensus approach to regulation 13 years ago. He asks what progress the Department has made in evaluating those recommendations. Those recommendations included FDA regulation of higher-risk HIT products, the adoption of industry codes to allow for self-regulation, and the use of so-called local or regional software oversight committees to provide additional protection. The article suggests these committees would be patterned after institutional review boards which monitor clinical research at hospitals and other such institutions.
Sen. Grassley, that same day, sent a letter to HIMSS, asking for the society's position on these issues. The Senator also had sent letters earlier to hospitals and others trying to gather information. He would appear to be on an earnest campaign.
What does all that mean for mHealth?
I'll offer seven observations.
First, when electronic stuff directly impacts health, the folks at White Oak get interested. It's really that simple. They take the public health very seriously, and any IT people new to the health industry need to appreciate that.
Second, when confronted by a situation such as this, FDA's natural reaction is to interpret the scope of their authority very broadly, and then propose a tiered approach based on risk. So they want everything in the tent, but once in the tent they're willing to make distinctions. A lot of people back in 2008 thought FDA's proposed regulation on Medical Device Data Systems was expansive, but Dr. Shuren's declaration that HIT software is a medical device is orders of magnitude broader in scope.
Third, FDA is not deterred simply because a regulatory task is complex or the technology is important to the point where speedy innovation is desirable. If that were the case, FDA would've abandoned regulating pacemakers long ago. Actually, high complexity and high public-health importance are archetypal circumstances for FDA to get involved.
Fourth, prior to yesterday, our orientation was to think about traditional medical devices as the stuff that touches the patient, and then to believe that the software and hardware that moves farther and farther away from that patient contact is less likely to be regulated. But the conclusion that FDA can even regulate the electronic health record (in many cases the point farthest from the patient) means that we now need to rethink the agency's view on all the stuff that connects those two points. We must think about the various hardware and software tools used for the communication between those elements.
Fifth, from there, it is a short hop to looking at the hardware and software that typifies mHealth applications. If the sensor that collects the data from the patient is a medical device, which we always knew if the use was medical, and if the EHR that is the ultimate repository of that information might also be a regulated medical device, we need to seriously think about whether FDA intends to regulate cell phones that are anything other than generic communication instruments. In my first article, I described how FDA might indeed regulate cell phones based on the claims made about them. That was theory, which now seems more likely to materialize as reality. As I did in that article, I would argue that a phone for which the seller makes no special medical claims is not a medical device in the hands of that seller. But any move toward suggesting that the phone is a specialized tool useful for medical communication apparently means FDA might get interested.
Sixth, frankly I interpret Dr. Shuren's comments as the beginning of a conversation. I did not hear him dogmatically say what the future will look like. Quite the opposite, I heard him reaching out to stakeholders for input. While he was fairly emphatic on the point that these software products are within their legal authority, he was expressly inviting comments on the degree of regulation required. I did hear him put a stake in the ground on the issue that something should be done, and I think industry needs to respond. The FDA public meeting on interoperability held during the last week of January similarly showed a willingness by FDA to collaboratively discuss the best approach.
And seventh, however the HIT and mHealth industries respond, as with anyone who participates in the health industry, the approach will need to meet one critical criterion. As a wise, old food and drug attorney once told me (please don't tell my Dad I called him "old"), it all starts and ends with concern for the patient. Whatever approach emerges, whether it's FDA regulation or a voluntary industry code that allows for self-regulation, it needs to have as its essence a focus on protecting the patient.
In my last article in this series, I will offer some views on specifically where I think the regulatory environment is going for mHealth. But before I get there, my next article will focus on FDA's relationship with hospitals and other users of the technology. I'll be examining what discretion users have to modify the stuff they buy. Hopefully, you'll find it useful.
