As the FDA grinds through the comments submitted in response to their proposed rule for medical device data systems (MDDS), the market awaits the final rule. Regardless of changes between the proposed and final rules, vendors who may be regulated under the new rule will have limited time to prepare.
Awhile back, I was contacted by ComplianceOnline to author a webinar on the FDA’s proposed MDDS rule. After some discussion, we agreed on the following pithy title: The FDA’s proposed Medical Device Data System (MDDS) rule and its implications for currently regulated and unregulated vendors and providers. The key objectives for the webinar are to provide clairification on the proposed rule and explore the consequences for those involved with MDDS – vendors and hospitals.
You can read a description and register for the webinar here. Attendees are encourage to submit questions – which I will answer during and after the webinar.
Alas, the webinar is not free. But compared to what it would cost in my time to lay out the proposed MDDS rule and its implications in detail, the price is a bargin.Read More
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
When I do presentations on the use of standards, I invariably have a slide which defines interoperability as “the ability of a system or a product to work with other systems or products without special effort on the part of the customer.” My second slide then defines syntactic and semantic interoperability.
Syntactic interoperability occurs when there are two or more systems capable of communicating and exchanging data and this is usually attainable with the use of physical standards, data standards, and messaging structures. Semantic interoperability is defined as the ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems.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