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
Developing and launching a competitive product, and getting initial traction in the market are not inconsiderable milestones. And yet for the entrepreneur and their investors, this is just the beginning. What was record setting last quarter is barely acceptable this quarter, and next quarter had better be back on track.
Developing a solid plan for growth depends on two things: a good understanding of the basic means to drive growth, and a deep understanding of the market. This post seeks to combine both of these in a brief survey of the key factors to drive messaging middleware revenue growth in health care. We’re going to consider three basic growth strategies: organic growth, product line extension, and the roll-up strategy.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