By Bradley Merrill Thompson
In response to my prior post on this topic, athenahealth’s VP of Government Affairs, Mr. Dan Haley took the time to write some very thoughtful-provoking comments. I appreciate him taking the time to do so. I think it probably helps everyone to have a thorough debate of these issues. So in the spirit of debate, I’d like to offer a few reactions.
As I said in my original post, it’s important for us all to keep in mind that FDA is already regulating mHealth and the purpose of this guidance is to reduce the scope of that regulation. So the question is– is it useful for FDA at this time to come out with a final guidance on mobile health?
I will explain further why I think it clearly is.
Mr. Haley offers the view that FDA guidance is unnecessary at this point because there will be a new statutory scheme within about a year. After consulting his blog that he referenced in his prior comments, it appears that Mr. Haley is a government affairs professional and an attorney, so I know that he well-understands the process for creating new statutes, but let me recite it for everyone’s benefit.
Step one — FDA drafts a report to Congress, with the input of ONC and FCC
In section 618 of FDASIA, Congress asked for a report from FDA, together with ONC and FCC, on “a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications.” At this juncture, because it hasn’t yet been written no one knows what that report will say, except perhaps FDA and the other two agencies that are working with FDA to write it. We in the public do not know, for example, whether the report will recommend a series of incremental improvements to the existing regulatory framework or an entirely new one.
Not to quibble, but in Mr. Haley’s comment he says we are “on the eve of a proposal for a statutory framework.” But we do not know at this juncture that it will be a statutory one. And even if there are statutory elements to it, we do not know that it will be a new, comprehensive statutory scheme, but perhaps fine-tuning of the existing statutory framework. Bottom line is, we just don’t know what the agencies will propose.
Step two – Congress may debate what to do
Presumably sometime in 2014 (the agencies aren’t always punctual in meeting deadlines), Congress will receive this report and if they are so inclined will debate it through the normal congressional channels. Now I know Mr. Haley understands that process much better than I do, but in my experience, Congress isn’t always quick to act, or decisive in its approach. And indeed, the timeline is influenced by other factors such as whether we are at war and generally other priorities of the moment.
If, and I emphasize if, Congress decides to move forward, Congress still has to draft a new regulatory program and presumably get input from all sorts of people. Here is where I see extreme uncertainty because there is no consensus as to how software should be regulated. I just participated in the summer long process of making recommendations among the FDASIA working group, and as I’m sure others already know, that process was a difficult one that produced a number of high level observations. It also revealed a number of differences that still need to be worked out.
I’ll give an example. As I study the work product of the Bipartisan Policy Center which is one of the leaders of the organizations that signed the letter to the HHS Secretary, one of the key recommendations of that group is that Congress ought to create a new category for clinical software with its own separate regulatory scheme. It seems to me and others that there’s a major problem with that approach. The problem is that technology is trending in the direction of systems that combine medical devices with health IT and to separate the two will cause confusion and result in duplication, which the agencies were tasked in avoiding. Consider:
- Medical device hospital beds becoming electronic hubs into which the various patient monitors and therapeutic devices such as insulin pumps are connected and coordinated, and through which data are collected for deposit into the EHR.
- Medical devices being electronically networked together to directly coordinate the delivery of care, for example an oxygen monitoring device might tell an intravenous device to stop delivering narcotics if hypoxemia is detected.
- Enhancements coming from the EHR side, including middleware to directly connect the EHR to medical devices so the data might be transferred automatically.
- In the later part of the 20th century, professional care basically stopped when the patient went home. Now we are seeing a whole slew of technologies that allow for connected health. These include cell phone apps that might extract data from a pacemaker or defibrillator and send it back to a cardiologist, as well as home-based hubs to which all sorts of medical devices might be connected, and the data ultimately relayed to a doctor and into an EHR.
- Now laboratory testing is getting into the act. There is a cell phone app that basically uses the camera to measure color changes in a test strip for urinalysis. Further, laboratory testing itself is now connected through middleware directly to caregivers and EHRs.
- Medical imaging is not to be left out, with ultrasound and other clinical images being transmitted to tablets and cell phones that the doctor can use at the bedside, or even at the doctor’s home. It seems reasonable to expect that these mobile monitors will get more sophisticated, and begin to apply computer aided diagnostic software to the images.
- Orthopedic implants can now have sensors attached that allow doctors to remotely monitor the wear and tear on the implant. All of this data then gets stored and trended in an EHR.
- Sensors can even be used preventatively, for example monitoring the environment for allergens and alerting a patient with asthma or his caregiver to potential danger. This data can get stored and analyzed in the EHR.
Given those and other technology trends, it will be increasingly difficult to separate out many categories of so-called clinical software from the connected medical device software. Developing a separate regulatory scheme for HIT that connects with medical devices represents a tremendous conceptual challenge to the design of an HIT regulatory scheme.
As I think everyone in this debate agrees, it is very difficult to serve two masters. If, for example, medical device manufacturers must satisfy FDA, and if in this example HIT developers must satisfy ONC, it is not hard to imagine complexities and duplications when the HIT is intimately connected to the medical devices. In many of these cases, the HIT might actually control the medical device, in other cases the safety and effectiveness of the medical device will be entirely dependent on the software accurately capturing and presenting the data generated by the medical device. This is not to say HIT, regardless of risk, should be regulated by the FDA. Certainly not. The point is simply that clinical software is not some isolated product category that can be regulated unto its own without implications for other technologies like the medical devices that are more and more interconnected with that HIT.
So if Congress is considering creating a separate a new regulatory scheme for clinical software, separate from FDA regulation of traditional medical devices, legislators will have their work cut out for them. This is not an easy challenge to resolve. Keep reading>>