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):
A medical device data system (MDDS) is a device intended to provide one or more of the following uses:
- The electronic transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices. For example, this would include software that interrogates a ventilator every 15 minutes and transfers information about patient CO2 levels to a central patient data repository;
- The electronic storage and retrieval of medical device data, without altering the function or parameters of connected devices. For example, this would include software that stores historical blood pressure information for later review by a healthcare provider;
- The electronic display of medical device data, without altering the function or parameters of connected devices. For example, this would include software that displays the previously stored electrocardiogram for a particular patient;
- The electronic conversion of medical device data from one format to another format in accordance with a preset specification. For example, this would include software that converts digital data generated by a pulse oximeter into a digital format that can be printed.
- Examples of medical device data systems that would be used in the home are systems that periodically collect data from glucose meters or blood pressure devices for later review by a healthcare provider.
Medical device data consist of numerical or other information available from a medical device in a form suitable for processing by computer. Medical device data can represent many types of information (e.g., clinical values, alarm conditions, error messages). MDDS are not intended or designed to provide any real time, active, or online patient monitoring functions. Medical device data systems can deliver and store alarm data but do not have the capability to display, create, or detect alarm conditions, or to actually sound an alarm. In particular, a MDDS can record the fact that an alarm sounded, but cannot by itself sound an alarm in response to patient information. Medical device data systems cannot create alarms that are not already present from the connected medical devices. By themselves, MDDS do not provide any diagnostic or clinical decision making functions. Medical device data systems can transmit, exchange, store, or retrieve data in its original format or can be used to convert the medical device data from one format to another so that the arrangement or organization of the medical device data is in accordance with preset specifications.
From the definition above, products from Capsule Tech, Sensitron, Cerner, Cardiopulmonary Corp., GlobeStar Systems, LiveData, Global Care Quest, iSirona and many more, fall under the MDDS definition. Emergin may not meet the definition if they do not take data directly from the medical device (they use Capsule Tech for at least some of their device connectivity). Also falling under this MDDS definition are the proprietary APIs for integrating medical devices into physician office EMRs from Midmark, Welch Allyn, Cardiac Science, AllScripts and others.
Further down in the proposed ruling, it says, "A manufacturer of a MDDS device that is indicated for use by anyone other than a healthcare professional or that performs irreversible data compression would need to submit a premarket notification..." And at the end of the rule (emphasis mine), "When the device is indicated to be prescribed by a healthcare professional for use by a lay user, or performs irreversible data compression, or for over-the-counter use by a lay user, the device requires the submission and clearance of a premarket notification." The Microsoft HealthVault Connection Center is software intended to acquire data from medical devices for use by patients, and will apparently be a Class III device.
The whole "reclassification" issue is a bit of a red herring. As William Hyman explained on the Biomed Listserv, "...all medical devices unknown prior to 1976 are automatically Class III. Thus if the FDA defines something as a new medical device, it is Class III [by default], unless it is reclassified to some other class." Up until now, the FDA was not been particularly aggressive in regulating what will from now on be called medical device data systems. One might draw the conclusion that, with the advent of this new rule, the FDA will be more aggressive in regulating these devices (one can hope).
Besides the obvious question of whether the FDA is really serious about regulating MDDS, a few things jump out as areas that need clarification. Medical device interoperability is clearly a step beyond MDDS, as is continuous monitoring functions like surveillance. But the differences between handling alarms that is part of an MDDS and that which is a Class III device are less clear.
Software that can, "display, create, or detect alarm conditions, or to actually sound an alarm" does not qualify as a MDDS and is thus a Class III device. But, "Medical device data systems can deliver and store alarm data." The text goes on to state, "In particular, a MDDS can record the fact that an alarm sounded, but cannot by itself sound an alarm in response to patient information." So does a system that effectively repeats an alarm received from a medical device, as opposed to sounding an alarm based on "patient information," fall under Class III? Is the alarm generated by the medical device "patient information" or must the software generate its own alarms based on physiological data received from the medical device (e.g., like OBS Medical) qualify as Class III? Just what does "patient information" really mean?
This ambiguity around alarms threatens to end the current exemption for "secondary" alarm notification systems and pull them under FDA regulation. Based on the proposed rule, it seems safe to say that an alarm notification delivered with a physiological waveform will be a Class III device (i.e., a monitoring function). And from the text, "to actually sound an alarm," and "sound an alarm," any software that delivers alarm notifications will be a Class III device. Vendors like Emergin, Global Care Quest, GlobeStar Systems, and LiveData could be impacted by this new rule.
During HIMSS this week, I asked many vendors about their take on this proposed rule. Responses fell into 3 groups: the clueless (or in denial), those that don't do alarm notification and are regulated or preparing to become regulated, and those that do alarm notification and hope that the FDA won't close the door on "secondary" alarm notification. An outlier is Cardiopulmonary Corp who received premarket approval for their alarm notification features years ago.
The effective date for these changes will be 60 days after the date of the publication of the final rule. Here is the FDA's schedule:
FDA intends to continue to exercise enforcement discretion after publication of any final rule so that manufacturers who are already on the market with MDDS devices may have sufficient time to come into compliance as follows: FDA expects manufacturers who are already marketing a MDDS device before publication of a final rule and who meet the criteria for list under part 807 within 60 days after publication of the final rule. If a premarket notification is required, FDA expects manufacturers who are marketing an MDDS device without FDA clearance to submit a premarket notification within 90 days of the effective date of a final rule and to obtain final clearance of a premarket notification within 180 days after publication of a final rule. FDA expects manufacturers who are required to obtain clearance of a premarket notification to register and list within 30 days after receiving a substantial equivalence order for their device. Manufacturers who are not already marketing an MDDS device will be required to comply with any final rule as of the effective date.
So, if you end up as a Class I MDDS or Class III device you have between 60 and 90 days after the final rule to get your act together. This is clearly not the time to delay action.
For a vendor who has never been regulated or faced the prospect of a Class III designation, this new rule can be intimidating. But things are not as bad as they seem; note that when the FDA regulated MDDS as Class III devices, they waived the most onerous and expensive parts of Class III regulatory requirements resulting in what was equivalent to a Class II regulatory burden. The point here is that those looking at a potential Class III designation are not as bad off as they likely imagine.
Depending on your situation, the biggest regulatory requirement is probably supporting the Quality System regulation, or QSR. This is a basic safety engineering framework intended to maximize product quality and safety. We all know that product defects are significantly less expensive to fix the earlier in the development process they are addressed. Most any software vendor - in our outside of health care - would benefit from the kind of checks and balances the QSR brings to the design process. If you write code first, do the design later and maybe document everything if you have time (or feel like it), implementing the QSR will be an expensive and character building process. If you operate at a software Capability Maturity Model level of 3 or higher (there are 5 levels), implementing QSR will be relatively painless.
If you're a vendor, go ahead and get a legal opinion on the likelihood you're product will be regulated and become a Class I or Class III medical device. Note that actually developing a regulatory strategy after classification is determined is where things get complicated.
Like life, regulatory strategy is neither black or white, but shades of gray. The job of regulatory attorneys is to identify regulatory risk. It is the role of management to determine the level of risk to be assumed by the company. Set that risk level too low and men with badges show up muttering, "adulterated product." Set the level of risk too high and you place your firm at a competitive disadvantage against vendors who strike a better risk/benefit balance. Letting regulatory law firm define your regulatory approach is a mistake.
Implementing the QSR is not rocket science, although it can be mind numbingly detailed. Look for a reputable regulatory consulting firm who can provide a template product development process (PDP) that is QSR compliant. Keep things simple - I've seen PDPs defined in tens of pages and those that span 2 or 3 binders. The FDA does not grade you on the complexity of your PDP, they grade you on how well you follow your own PDP - one that's easy to understand and follow is best.
After the QSR, you need to develop a regulatory strategy for each of your products. Developing the strategy is an iterative process that balances various aspects of the product definition and the regulatory process. My approach to is entails a holy trinity in regulatory strategy: the intended use of the medical device, how your product is specified, and the risk analysis done during the design phase. Where a product falls regarding regulatory requirements is heavily influenced by how these key factors are managed and applied. (There are many other factors, of course, but these 3 can serve as guideposts.) The optimal balance results in the most competitive product at the lowest cost with the shortest time to market that is in full regulatory compliance.
Regulated software that automates workflow through the integration of medical devices with information systems is different from straight embedded devices or software applications. For firms new to all this (i.e., the majority) you should get advice and guidance that span both device and software regulatory perspectives. The most common vendor mistake that I see is the application of embedded system regulatory strategies to software products - a very expensive error.
If you need any help - finding regulatory attorneys or consulting firms, let me know. I can help personally with overall guidance and in developing regulatory strategies for product lines or individual products.
Hat tip: Bob on Medical Device Software and Dave Shaver at NeoTool.
UPDATE: I forgot to link to these two previous posts on the subject of FDA regulations - here and here.
UPDATE: Here's a nice summary of the proposed rule from CIMIT (here).
UPDATE: You can read a new blog post on the proposed MDDS rule here.
Good reminder that “Regulated software that automates workflow through the integration of medical devices with information systems is different from straight embedded devices or software applications”.
What is the latest FDA ruling on these device integration products?
Linda, there really is no “ruling.” The proposed MDDS rule in this post is their most recent treatment of the issues. Otherwise one must fall back on the legal definition of a medical device (of which much of the device integration products fall under) and the FDA’s regulatory framework (QSR, crafting regulatory strategy, etc.).
The real wild card here is the FDA’s regulatory discretion. They have every right to look the other way until they decide to look very closely - and change their focus without any notice. Oh, and they can charge folks with violations after the fact. The FDA is really being quite reasonable with the MDDS rule, giving everyone plenty of advanced warning that regulatory discretion is shifting and providing compliance deadlines so they can avoid violations.
Vendors who have convinced themselves that they’re outside the scope of FDA regulatory authority, simply because other vendors are doing it and getting away with it, are kidding themselves. They are at risk - especially if the FDA increases enforcement due to bad patient outcomes.
Thanks for the article. If medical devices like patient monitors, connects directly and transfer data (waves and/or alarms) over WLAN or Cell Service, would a network vendor (eg CISCO, or Verizon) be impacted ?
Narciso
Tim - to Linda’s citation: “Regulated software that automates workflow through the integration of medical devices with information systems is different from straight embedded devices or software applicationsâ€.
This could also cover healthcare organizations who do this themselves - i.e. use products that have a ‘legos’ approach to building with the in-house resources providing that end-integrated design. This will be an interesting ride and I would say it is getting a lot of attention across all parts of the industry, not just the manufacturers.
Narciso,
In your example, the network is like any other off the shelf component in the medical device. The FDA QSR provides different ways to do this. A vendor can buy from vendors who themselves are registered with the FDA and follow the QSR. Alternatively, the vendor can verify that the component meets specific requirements for safe and effective operation.
Networks are a special case in that they are not a static component controlled by the vendor. Consequently, the vendor must not only specify and test to their own internal requirements, but must also provide customers with requirements and the means to monitor the network to ensure continued safety and effectiveness.
In general, this isn’t being done - passing specs and the means to monitor them to customers. That’s why the FDA and others are involved in IEC 80001, which will impose a risk management framework on providers who connect medical devices to their network. Much more on that in the future…
The article states: “Also falling under this MDDS definition are the proprietary APIs for integrating medical devices into physician office EMRs from Midmark, Welch Allyn, Cardiac Science, AllScripts and others.”
If a medical facility were to license an EMR then write API’s to automatically collect and integrate data to that EMR, does the EMR vendor now fall under FDA guidelines for MDDS?
Whoever writes the API will certainly fall under MDDS.
The FDA focuses on what someone does, and not what kind of organization they are. Thus, in your example the EMR vendor would fall under the FDA’s regulatory oversight.
The regulatory burden for an EMR vendor should be next to nothing if they use any kind of accepted quality system and/or write code at a CMM level 3 or higher. The vendor has to register with the FDA and apply the Quality System regulation to all regulated products.
We are a DICOM solutions engineering firm. Our products include archiving for medical imaging and migration of data (image studies) from legacy archiving systems to new systems. How might the proposed rules affect us. Thank you.
Alan, if you or your clients don’t provide FDA regulatory compliance for your DICOM software, the MDDS clearly mandates it.
Data migration products and services are less clear regarding MDDS. There is a clear patient safety requirement - if the migration results in poorly translated DICOM tags, an image could be rendered “undiagnostic” or cause a clinician to misdiagnose.
Whether you submit your migration product for FDA pre market approval or not, you should be following the FDA’s QSR (or something very close to it) just to mimize your liability.
Tim,
I am trying to determine if our devices fall into the MDDS grouping. We have devices that remotely display, store, print and can on-forward selected information to other systems relating to patient information and billing. These devices are purpose designed by us for our treatment devices and are classified as class II. The information displayed is used by Doctors to decide on any steps needed to correct the treatment the device is delivering, this can be done by remotely sending instructions to the device to alter the treatment or cause the Doctor to contact the patient to return with device for further assement.
If I read the proposed FDA ruling, it could be easy to inturpret that our devices fall into the MDDS category (if we removed remote settings). But my feeling is that our device do not fall under the MDDS group as the FDA have cleared our device as an accessory to a medical device.
Any comments please.
Thanks
Greg
Greg, the proposed MDDS rule is of particular interest to third party vendors, because medical device vendors like you include those functions under their product’s overall regulatory umbrella.
Medical device vendors could position thier MDDS as a separate product and submit it as an MDDS when the rule is promulgated. How the overall solution is packaged, the intended uses, and development cycles represent major factors in such a determination.
Hi Tim,
I’m trying to understand the current status of this rule. Is it still proposed? Do you have any visibility as to when it will be approved? Is it enforcable while it’s proposed?
Cheers,
Tim
Tim,
What about an EMR itself? If the EMR is just providing some patient data and links to test results would it be affected? There is no manipulation of test data, no alarms just links to say PDF files.
Don.
Don, based on marketing claims an EMR is not a regulated medical device. However, certain EMR components could become regulated in the future — I’m thinking the decision support systems used in things like CPOE.
Sadly, very few EMR vendors even follow a basic quality system to ensure product quality, like ISO 9001. Carrier, the maker of airconditioners, has been 9001 certified for 20 years.
HAPPY ANNIVERSARY! Today, February 8, 2011 is the 3rd anniversary of the posting of the proposed MDDS rule. Perhaps some further information will be forthcoming “soon”.
It is important to note here that the absence of further action on the Rule does not mean that an MDDS, as defined, is free of regulation. On the contrary it means that an MDDS is still a Class III device because the essence of the proposed Rule was to reclassify MDDS’s from their automatic Class III status to Class I. Class III has the most stringent FDA requirements while Class I has the least.
The inaction on MDDS may be an example of a phenomenon well known in at least academia. All new initiatives are much more interesting and important than all old initiatives, no matter how important the old initiative had been claimed to be, or actually is.
The 3rd anniversary must have been the charm! The MDDS Final Rule has just been announced (2/14/11) for Federal Register Publication on 2/15/11. See http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm243283.htm for the 2/14 press release and an advance copy of the rule.
Bill, it seems you were prescient. I’ll have a post up later today about the final rule and will include a link in an update at the end of this blog post above.
So then, would an integration engine that passes vital signs from one system to another be considered an MDDS?
This should effect all software that receives data from a medical device including EHR, PHR, Smartphone Apps. Unless it is classified as a “Tool” by the FDA. I have been talking to some high ranking individuals in commercial and regulatory Health care and they do not believe this is the final round. Many jobs would be lost if this proceeds as written. We will see.
Jeff Brandt
April 19, 2011 - The FDA has posted the new MDDS Rule and associated explanation and comentary at its website.
http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospitalDevicesandSupplies/MedicalDeviceDataSystems/default.htm
or
http://tinyurl.com/3uowlpb
We have a DICOM solution that is attaches to a network, similar to a network printer. This archives DICOM medical images that can later be retreived if needed.
Is this considered a medical device per the FDA guidleines and does it nee to be registered?
Thank you for your help.
Tim, your question can’t be answered quite so simply. An “actual” answer would require that we discuss the details of your situation and a review of relevant documentation.
However, in general, the answer to your question depends on two factors. First is whether the product is a general purpose IT subsystem or whether it is sold including special DICOM software on the device.
The second factor is whether your company makes any medical device claims for the product. If you market the product as a DICOM archive for diagnostic images, those are medical device claims. If it is sold as a generic IT storage subsystem that someone can purchase for a variety of uses, including storing medical images, you are not making medical device claims (as long as you don’t explicitly mention the medical device use).
If the answer to factor one and/or two is yes, then it is a regulated medical device.
I am nurse and we document the data displayed via the medical device. However, the MDDS actually get the data and normally there is a difference in the display and actual output.
For example incubator will display a temp of 75 degrees. However, the output from the device via MDDS is 74.55. The MDDS manufacture say they can’t round and must document what is displayed. Does rounding in these types of case violate the rules?