FDA Addresses Mobile Medical Apps
As medical applications for mobile devices have proliferated, regulatory questions have proliferated nearly as fast, at least in some quarters. The key questions are what kinds of apps are medical devices, and among those, which will the FDA focus on for regulatory action. To date these apps range from home use adviser’s, guides and “toys”, which may or may not have real health care implications, to serious medical devices which have clear health care functions, despite in at least some cases, pretending they do not really, perhaps in an attempt to avoid the FDA.
On July 19, 2011 the FDA announced its proposed official action in this regard, including defining “mobile medical applications” that are the subject of this action. (I will use the acronym MMA, although the FDA did not.) . This includes a new FDA web page for mobile apps (here), with links to a new Draft Guidance, information for consumers, and a press release. This action by the FDA has a parallel to the recent final rule on Medical Device Data Systems (MDDS), discussed by Tim here, which also addressed what is it, what is it not, and how that which is will be regulated.
Storms From the Cloud
Given the analogy between actual clouds and computer clouds, it now seems appropriate to extend the concept to storms that those clouds may bring. This was illustrated recently (April 21, 2011) when Amazon had a cloud outage (a mixed metaphor no doubt) in their Amazon Web Services business. This situation was covered by the NY Times (here), and the professional computer press (here) among others. As a result of Amazon’s problems some Web sites were reported to be down for as long as 11 hours, although actual loss of previously stored information has seemingly not been part of the problem–this time. However there is a related question for any new data that was or should have been generated during the outage. Where is it, and will the gap be properly filled in retroactively?
The Amazon postmortem explanation has to be what will be a classic, if it is not already a classic. In fact I can picture a pull down menu of explanations where this would have to be one of the choices. The explanation in short: a configuration error was made during a network upgrade. A far more detailed explanation was posted by Amazon here. From a Web page perspective an interesting aspect of the posted explanation is that while it is clearly on the amazon.com Web site, it is not easily found, if it all, by starting at amazon.com, or at least I didn’t find it from there.
Meaningful Use Stage II
My February, 2010 discussion of Meaningful Use (MU) (found here) addressed the then proposed 25 elements by which an EMR/EHR (hereafter EMR) would be judged in order to determine if it met the funding standard for MU under the U.S. federal incentive program regulations. Note that in this regard an EMR must be capable of MU, and then MU must be actually achieved by the end user. Capability is established by vendor certification.
As is perhaps common in the sequence of proposed and revised federal regulations, that the scope of the 25 elements received a degree of adverse response that centered on the assertion that they were overly demanding, i.e. we want the money, we just don’t want to work that hard to get it. As a result the 25 required elements were reduced to two sets of requirements in what is now called Stage 1. The first set is 15 required elements while the second is a “menu” of 10 additional elements of which 5 must be chosen.
FDA/FCC on Wireless Medical Devices
A public meeting on Converged Communications and Healthcare Devices Impact on Regulation (see here) was convened by the FDA and FCC on July 26-27, 2010. The major topics addressed by panels were (1) Current State of Wireless Health & Lessons Learned, (2) Innovator Perspective, (3) Healthcare Provider, Clinician & Patient perspective, (4) Investor and Research & Development perspective, (5) Reliability – How to Define Quality of Service, and (6) Electromagnetic Compatibility – How to Promote EMC. A complete transcript of the meeting will be forthcoming at the conference link given above, or at www.regulations.gov using the docket number FDA-2010-N-0291. The docket folder currently includes about 35 written comments made in advance of the meeting including from concerned citizens, professionals and professional groups, and major medical device and communications companies.
The stated motivation for this meeting included concern for the proliferation of devices using radio technology as well as reliance on consumer grade communication devices. In part this reflects potentially overlapping regulatory areas with the FCC on the spectrum side and the FDA on the medical device side. In addition to the usual array of medical device performance issues, the radio arena presents the additional challenges of the shared spectrum space, and the suitability of general purpose devices and systems for medical applications.
The major questions addressed at the meeting included data integrity and reliability, medical device and system security issues, allocated and unlicensed spectrum utilization, joint regulatory requirements, and risk management. The latter included the need to define levels of device criticality (which may then correspond to device FDA classification), and potential performance issues in multiple environments.
The FDA and FCC issued an associated joint press release (here) in which they reiterated the generally held belief that innovations in medical device communication “holds significant promise for enhancing health and reducing cost.” They further reiterated that these applications require agencies to assure that such devices operate in a safe, reliable and secure manner, while also encouraging innovation and affording the public the potential benefit of such devices. In part this will benefit from clarity and predictability with respect to the regulations as the agencies fulfill their mandate to protect the public from unsound devices and/or unsound device performance. In this regard it is certainly a challenge to the FDA to both tighten regulations (e.g. with respect to infusion pumps, and likely with respect to the 510(k) process), while also trying to be pro innovation.
Two issues that will have to be resolved here, and for some wired applications as well, are distinguishing real medical devices from health related toys, and where an integrated and regulated medical device ends and a less regulated general purpose communications or computer network begins. The commercial health toy arena has a strong element of regulatory avoidance, which might be acceptable with clear and honest marketing, and some way to exclude date from such devices from being confused with actual medical device data. It should also be clear that a medical device performing a critical function cannot operate at the whims of smart phone and internet performance when we have ample demonstration that these systems are not in fact reliable. Being unable to make a simple phone call, blog or text is one thing while being unable to send important information to a healthcare provider, who is in turn relying on being able to receive such information, is quite another.
Progress (?) on Clinical Decision Support
The AHRQ has released a report (available here) on the implementation of clinical decision support (CDS) software within the context of an EMR. This report reviews the work to date of two AHRQ demonstration grant recipients, Brigham and Women’s Hospital and Yale University School of Medicine. In each of these projects the intent was, at least in part, to implement two or more existing practice guidelines as on line and integrated component of the EMR.
In the context of these projects CDS means the provision of clinical knowledge and patient-specific information to help make decisions that enhance patient care. While this type of general statement remains somewhat vague as to what constitutes such help, the report comments further that in a CDS “the patient’s information is matched to a clinical knowledge base, and patient-specific assessments or recommendations are then communicated effectively at appropriate times during patient care”. Therefore, as used here, CDS is more than just the effective presentation of integrated patient information, as might be done by a Medical Device Data System (as discussed here) for example. Instead it is knowledge based and the relevant knowledge is used to compare a patient to a predefined pattern in order to “suggest” or “advise” (or “tell”) the clinician what course of treatment is to be followed.
In this regard a CDS is, in older and somewhat forgotten terminology, an expert system. Introduced in the late 1990′s,the idea of an expert system was that the knowledge and expertise of one or more human experts could be captured and implemented as a computer code. Once this code was written (and perhaps verified), it would be possible to enter a new situation within the domain of the expert system, and the expert system would then provide the same result as the original expert or experts. It was further believed that some expert systems could be written that could “learn” such that it actually became more expert than the original experts whose knowledge was tapped (by a knowledge engineer) in its original creation. Of course such learning could only occur if the expert system was given controlled feedback along with having a coding scheme that was self adjusting. Neural nets was one of the popular approaches to such learning.
