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
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
It’s useful to segment and analyze markets for developing company and product strategy or analyzing competitor’s actions. Such an exercise helps illuminate why companies and markets do what they do – and what they might do in the future. In getting ready for this year’s HIMSS in Orlando, I’ve been thinking about the point of care (PoC) market. At the first Medical Device Connectivity conference in 2009, I defined the PoC market as the workflow and data associated with direct patient care in nursing units, the ED, surgery and related areas. This contrasts with EMRs managing orders, diagnostics, capturing charges and generally documenting things for the medical/legal record. (You can download a PDF of the presentation here.)
Many devices and software applications used at the PoC are FDA regulated medical devices because they are directly used in the diagnosis or therapy of patients. Because the PoC is where direct patient care is delivered, most PoC solutions meet the FDA’s definition of a medical device. Imagine a layer cake:Read More