What (if anything) can the recent Sidekick problem teach us?
On October 12 the NY Times headline read “Some Users May Lose Data On a T-Mobile Smartphone”. Those phones use software and support from Microsoft/Danger for their data applications. According to the article a “technical glitch” had resulted in customers losing personal information held on at least in part an associated cloud computer service. Another story here by Eric Savitz, led with the question: “So how sure are you that you want all of your data to live in the cloud?”
The precursor to the Times story had appeared earlier in a number of places including here on October 5th. At that time the issue was reported as a loss of data service as opposed to a loss of data, although it was noted that a reset could cause loss of the user’s contacts and calendar. On the 11th it was reported here that the data may be lost for good, but then on the 13th it was said here that maybe not all of the lost data was permanently lost. Apparently Microsoft/Danger was being run on a single server.
While there is no direct association of this situation with medical information (unless your doctor’s contact information was among the stored data), it should serve as yet another reminder that the connected world, and its operational software and hardware, is not without its own issues. When new medical applications are being discussed there seems too often to be a suspension of reality with respect to system functionality, data reliability, and data availability. Whether it is “just” an EMR/EHR, or it is more direct functionality (e.g. an alarm or communication system), or even a single device, it must be remembered that software anomalies (a nice word meaning it sometimes doesn’t work) are more common than rare, and that reliance on “the network” to perform as imagined can often be a false reliance.
In case there was any doubt of this, software is a fairly common cause of FDA mediated medical device recalls. The FDA’s recall datebase has a Simple Search function. Entering “software” without date limits brings up 500 hits, the systems maximum. Limiting the search to 2009 (through 10/21/09) on the Advanced Search produces 62 hits. The most recent of these involves a “software bug” cryptically reported as “The … flag is configured incorrectly. The flag is not generated according to system requirements.” A “software update” is said to be forthcoming.
As I have noted elsewhere, the software industry really needs to be congratulated for its use of the term “upgrade” to mean fixing something that was never right in the first place. The second most recent recall had an equally cryptic explanation: “There is a potential safety issue with … 3.0.x software where study split operations are not correctly replicated to a secondary ‘shadow’ archive”.
Impact of Modifying FDA Regulated Devices
Off Label Use
In a previous post, Medical Device System Network Install Issues, I suggested that when health care providers don’t follow medical device manufacturer’s specifications when installing medical device systems they were using the system “off label.” This site’s latest contributing author, William Hyman, provides an alternative perspective:
My interpretation of off-label use has been that it pertains to the actual use of the medical device, not the way it is set-up. Thus it isn’t off-label use until it is actually used, and use here is with respect to the Indications for Use, which do not generally address set-up and configurations as opposed to what the device is for.
Therefore a set-up or installation that is different from the manufacturer’s recommendations/specifications may be a modification rather than an off-label use. Other types of reconfigurations and changes would also be a modification.
Practice of Medicine Doctrine
Off label use is unregulated per the “practice of medicine doctrine,” but comes with some risk management issues. Also please note that this doctrine applies to physicians, not health care provider organizations. According to Hyman:
This is more than a semantic distinction. Off-label use of a medical device, at least by physicians, is legal and unregulated. This of course does not necessarily mean it is safe, smart, or well justified. The defense of an unsafe off-label use (if necessary) would be an after the fact liability matter, not a regulatory matter. However hospitals might be wise to have their own controls on off-label uses and require appropriate justifications.
After some research, I found that there’s very litte published — by the FDA or others — about the issue of post-market regulated device modification, especially by health care providers. Hyman delivers more:
Canada Posts “Medical Device Data System” Rule
On August 31, 2009 Health Canada, Canada’s medical device regulatory authority, posted classification information for Patient Management Software (pdf). This action is similar to the FDA’s proposed rule for the regulation of Medical Device Data Systems (MDDS), nearing finalization. The Canadian announcement begins with a reminder of its definition of “medical device” which is similar to although not identical to the U.S definition. This definition includes Patient Management Software as a medical device. In addition, Canada defines an “active” device as one that requires an energy source, and “active diagnostic device” as one that is intended to supply information for the purpose of detecting, monitoring or treating a physiological condition, state of health, illness or congenital deformity. Based on these definitions patient management software is declared to be first a medical device, and then an active medical device.
The next question is the appropriate classification of this type of active medical device under the Canadian classification system. The Canadian system has four device classifications which is similar to the European system. The U.S., of course, has three classifications.
Patient Management Software that is used only for archiving or viewing information or images, and is not involved in the primary acquisition, manipulation or transfer of data is deemed to be a Class I device. This definition is somewhat more restrictive than that for a U.S Class I MDDS. Any Patient Management Software that goes beyond these restrictions is a Canadian Class II device. Furthermore such software is categorized as an active diagnostic device. This includes software involved in data manipulation, graphing, flagging of results or performing calculations. Workstations that interface with such software are then also in Class II. The inclusion of the work station appears to directly address the illusive question of when does a computer become a medical device. As a result of these new distinctions some software that was previously Class I (in Canada) will now be Class II. The manufacturers of such systems sold in Canada have been granted a one year transition period to meet those aspects of Class II regulation that are different from or in addition to those for Class I. This defined transition period is a more explicit statement than the FDA has provided in the draft MDDS rule.
The distinctions between system functions made in Canada are somewhat different from those initially defined by the FDA for MDDS. None-the-less they reflect essentially the same issues and concerns which are that (1) any software that receives and manipulates patient data is a medical device, and (2) that the appropriate classification depends in part on exactly what the software does with the data. Only minimal data handling activities are in the least stringent regulatory classification, while classification and therefore regulatory scrutiny will increase along with the sophistication of what the software does.
Market Trends Series #2: Patient Safety
This is the second post as part of an ongoing series that discusses the market trends that are affecting the evolution of medical device connectivity (MDC) technology. I received some good comments from my previous post – please consider sharing your thoughts, ideas, and experiences.
The second trend I’d like to discuss is the shift towards patient safety as one of the key market drivers for connectivity. It is probably not news to anyone that patient safety has become one of the key drivers for many healthcare IT initiatives. But what is the relationship between patient safety and MDC? Ever since the often referenced IOM report, To Err is Human: Building A Safer Health System, hospitals and vendors alike have increased their focus on driving towards significant reductions in medical errors. The industry as a whole has made great strides, but still lots of work remains.
With device connectivity, my experience has been that for at least the past 15+ years, the key driver has been making the nurse more efficient by eliminating the manual transcription of device data into the patient’s chart. One of the related benefits is a more come complete and legible patient record. However, one could argue that the more legible patient record could be achieved if the vital signs from medical devices were simply typed into the charting application manually (something that many hospitals are actually doing today). So I believe that the nursing efficiency argument holds as the primary driver – but that is starting to be challenged by the focus on patient safety as it relates to connectivity.
