The FDA has proposed to reclassify Medical Device Data Systems (MDDS) from a default class III to class I. (You can read the proposed rule here, and the public comments here.) This is based on the belief that “risks to health from this device would be caused by inadequate software quality. Specifically, the risk to health would be that incorrect medical device data is stored, retrieved, transferred, exchanged, or displayed, resulting in incorrect treatment or diagnosis of the patient.” In my opinion, this is insufficient. Consideration must also be given to the risk of interactions between MDDS and devices.
Until now MDDS has not been a term that was widely used in the medical device or health care information industries. The FDA has proposed a definition that can be summarized as “a device that provides one or more of the following uses: electronic transfer, exchange, storage, retrieval, display or conversion of medical device data without altering the function or parameters of any connected device” (emphasis mine).
First, it is important to point out that even though MDDS’ currently default to class III, the FDA has been operating under their discretionary enforcement policy and has not been enforcing the class III requirements for MDDS. Products that currently meet the MDDS definition have in effect been operating without classification or enforcement; thus the reason for the proposed re-classification. In principle, I agree with the FDA that these types of devices should be regulated, but the question I pose is “why go from class III to class I?” Shouldn’t the classification for MDDS’ be class II?Read More
UPDATE: This post discusses the proposed MDDS rule that came out in 2008. If you’re looking for the final MDDS rule that came out in early 2011, look here.
On February 8, 2008 the FDA published a proposed new rule for public comment (pdf version). The new rule provides some definitions of connectivity software and proposes to reclassify some types of connectivity software. The rationale for the proposed rule is as follows:
Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist.
Up to this point the FDA has relied on their “Draft Software Policy” published in 1989 (link – pdf). This software policy recognized that software could (and did) meet the definition of a medical device and extended the FDA’s purview from conventional devices to software. This was not a bureaucratic land grab, but a recognition that the legal definition of a medical device could and had been met by software.
What is an MDDS? From the proposed rule (emphasis mine):Read More
A while back I had the opportunity to chat with Todd Dunsirn, the CEO of True Process. True Process provides products and services to both hospitals and various manufacturers. The company is focused on the point of care market offering a medication administration solution and a medical device data system.
What was the genesis for starting True Process?
I started the company in 2004. I have an engineering background, and had several other companies doing IT consulting and then web development, and application development. Then I had a friend contact me to develop a bar-code point-of-care simulation so that sales reps that were selling infusion pumps could demonstrate the five rights process with the pump. So, of course he said, “Hey can you do this? It’s gotta be done in three months.” And keep in mind, I had never heard of bar-code point-of-care [chuckle] prior to this, so I’d really never thought about infusion pumps.Read More
The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case.” It was further noted that, “Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,Read More
The HIMSS conference is so big, with so many different kinds of attendees and exhibitors that it’s almost impossible to have one big theme for any given year. Yet the question of theme for any given HIMSS is something we all talk about. The themes one perceives are at least partially defined by our own interests and area of focus. Consequently, the #HIMSS14 themes for me were:
- The shifting product and value proposition focus of many of the vendors I track,
- The tension between spot solutions and enterprise solutions, and
- The big buzz word of the show, population health.
Two of the market segments that I track with big shifts in value proposition were medical device data systems (MDDS) and messaging middleware. We’ll talk about specific shifts in a moment, but I think it worthwhile to consider why this change in value propositions has occurred. One obvious factor among MDDS vendors is acquisitions. Capsule Tech (registration required), Accent on Integration and iSirona have all been acquired. Acquisitions are major events when everything about a company is reevaluated in an effort to wring greater value from the acquired company. The other factor I think is the growing adoption of MDDS for clinical documentation into EMRs may have caused sales growth to temper a bit, causing vendors to look beyond clinical documentation and explore for ways to add value and differentiate. Let’s look at some examples.Read More