On February 14, 2011 the FDA published notice (PDF version [link fixed] and press release) of the long awaited final rule for medical device data systems (MDDS). The real news behind the final MDDS rule is not the less-burdensome path to market trumpeted by many news stories, but the FDA's stated intent to exercise "enforcement discretion" with regard to those who create MDDS. For the MDDS vendors who are already regulated (Capsule Tech, Cardiopulmonary Corp, Dawning Technologies, Nuvon and others) this final rule is an easing of the regulatory burden. For those that aren't (e.g., Bridge-Tech Medical, CareTrends, iSirona and others - I currently track 16 companies in the MDDS category) this final rule signals that FDA enforcement actions will be forthcoming for manufacturers that don't meet FDA's implementation deadlines (more on that later).
The final rule reclassifies MDDS from a Class III postamendment device to Class I (general controls). Device reclassification has been used before to signal industry that FDA is transitioning from "regulatory discretion," where the FDA takes a wait-and-see approach to nascent markets, to pursuing "enforcement discretion" to actively regulate new market segments.
The FDA did the same thing in the early 90s, with the development of fetal monitoring surveillance and archiving systems from QMI/Corometrics/Marquette/GE, WatchChild and others. These systems that acquired data from fetal monitors and provided remote surveillance, bedside documentation, event review and a long term archive, were also postamendment devices in which manufactures sought to avoid FDA regulation. The FDA watched the market for these systems develop over a number of years without interference and eventually reclassified them from postamendment Class III to Class II devices. That announced the shift to enforcement discretion and, like with the MDDS final rule, provided time frames in which manufacturers had to come into regulatory compliance.
A Bit of Regulatory Inside Baseball
Before we get into the meat of this, let's get a few terms like "postamendment devices" out of the way. By law, devices that were not actively manufactured and sold prior to May 28, 1976, are termed postamendment devices, and are automatically classified as Class III devices - the highest risk classification with the most onerous level of regulations. A device that was labeled, promoted, and distributed in interstate commerce before May 28, 1976 is a "preamendment device." The magic date is from an amendment to the Food, Drug and Cosmetics Act. Most Class II devices require premarket notification - also known as a 510(k) - where the device is cleared by FDA prior to selling or delivering the device to customers. (Here's a good summary on the regulatory frameworks for Class I, II and III devices, where you can quickly see that Class III is the most burdensome.)
Legally, to qualify for the 510(k) process, the medical device must be a preamendment device. Many Class II devices today don't qualify directly as preamendment devices, but have been accepted by FDA on the basis of "substantial equivalence." A new device that claims substantial equivalence with a preamendment device (called the "predicate device" in this case) must have the same intended use.
Since the May 28, 1976, electronic medical devices have gone from analog circuits to digital devices, often incorporating off the shelf computers and networks. Consequently, a device designed today, especially one including connectivity, is likely to have very different technological characteristics compared to the predicate device. So besides the same intended use, the manufacturer must provide objective evidence that the technological differences do not raise new questions of safety and effectiveness, and demonstrate that the device is as safe and as effective as the legally marketed predicate device.
A big part of regulatory strategy for some new medical devices is determining whether to seek a 510(k) and then how make a case for substantial equivalence to a preamendment device, or to engage the FDA in discussions about how they might want to regulate the new device as a postamendment device. While postamendment devices are automatically classified as Class III devices, typically the manufacturer presents their case on which classification and related regulatory framework they think should be applied to the device, and the FDA tells them what they're going to do. Regardless of whether the device qualifies as pre or post amendment, it will most likely be regulated based on the inherent risk of patient injury or death.
Often the FDA takes the "least burdensome approach" to regulating a device (postamendment or otherwise) that ensures safety and effectiveness. Not surprisingly, both Capsule Tech and Cardiopulmonary's products are regulated as Class II devices with premarket clearance (in the form of a 510(k)). So if a MDDS manufacturer had approached the FDA a year or 6 months ago, their MDDS would probably be regulated as a Class I or Class II device anyway (although the MDDS classification removes uncertainty for both maker and regulator). This is why the reclassification of MDDS is not the big news - the real news is that the FDA's put a number of stakes in the ground and signaled their intent to begin enforcing regulations they have chosen not to enforce up to now.
The final rule imposes "general controls" on manufacturers. This term refers to the Quality System regulation (QSR) and, "governs the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation and servicing of devices and is intended to ensure that finished devices will be safe and effective."
Finally, let's briefly look at the term "regulatory discretion." This concept allows the FDA to chose whether or not to enforce regulations whenever they want, without giving up any enforcement claim in the future. An important feature of regulatory discretion is that it can be exercised sporadically and change without notice, and enforcement can be applied retroactively.
Often FDA does not provide notice to industry that they are exercising regulatory discretion regarding a certain area or topic, but refers to regulatory discretion as it relates to past actions or inaction. Regarding an action that falls under the FDA's purview - say meeting the legal definition of a medical device manufacturer - one might anticipate that if all goes well the FDA will not become interested, but if something bad happens they will be interested. In that latter case they could find you out of compliance even though they had no previous interest in your activities. FDA often applies regulatory discretion to emerging medical device market segments, like MDDS.
Final Definition of MDDS
Since the proposed rule from 2 years ago, FDA has made some changes. Here's the definition of an MDDS from the final rule:
An MDDS is a device that is intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. An MDDS acts only as the mechanism by which medical device data can be transferred, stored, converted, or displayed. An MDDS does not modify the data or modify the display of the data. An MDDS by itself does not control the functions or parameters of any other medical device. An MDDS can only control its own functionality. This device is not intended to provide or be used in connection with active patient monitoring. Any product that is intended for a use beyond the uses (or functions) identified in this final classification rule is not an MDDS and is not addressed by this rule.
The definition of a MDDS at § 880.6310 further states:
An MDDS may include software, electronic or electrical hardware such as a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol. This identification does not include devices intended to be used in connection with active patient monitoring.
According to the published notice (page 14 of the PDF), "A system that performs any other function or any additional function is not an MDDS." The above is in pretty plain language and the message is clear: don't try reading anything into the definition of an MDDS or stretching it in an attempt to score a Class I classification for a device that is really higher risk. There's some interesting things in the FDA's responses to the public comments that were submitted in response to the draft rule that we'll get into later.
As the FDA sees it, "the risks associated with MDDSs are generally from inadequate software quality and incorrect functioning of the device itself. These failures can lead to inaccurate or incomplete data transfer, storage, conversion according to preset specifications, or display of medical device data, resulting in incorrect treatment or diagnosis of the patient." It's their opinion that general controls (i.e., the adoption of the QSR by manufacturers), "will provide a reasonable assurance of safety and effectiveness of MDDSs." The application of risk analysis required under § 820.30 (g) is also called out in the final rule. This is sort of like when your teacher says, okay listen up, this will be on the exam, indicating that when FDA inspects manufacturers, they will look for sufficiently robust risk analysis for MDDS devices.
Section II, Overview of this Rulemaking (page 6 in the PDF) describes in detail what's changed from the draft rule. We won't go into the minutia here, except to note a couple of important changes about intended users of MDDS and the use of irreversible data compression.
Based on comments received and a review of data compression features in MDDSs and similar device types, FDA has determined not to require premarket notification for MDDSs that feature irreversible data compression. In addition, the limitation on the scope of the premarket notification exemption to use by health care professionals has also been removed. Based on comments received and information FDA has gathered, FDA does not have reason to believe there is a potential unreasonable risk of illness or injury from an MDDS, even when used by someone other than a health care professional.
In a nod to the growing interest in mHealth, the reference to "intended user" means that a patient or layperson caregiver can be the intended user of a MDDS, as opposed to limiting MDDSs to use by health care professionals.
Who Is Impacted by the Final Rule?
Obviously manufacturers selling products labeled as a MDDS are impacted by this rule, like the 16 companies I track in this product category - they and their customers know what business they're in. Note that this group currently includes at least one EMR vendor, Cerner.
Another group of manufacturers, targeting the physician office market, also fall under the MDDS rule. These products are intended to acquire medical device data and automatically incorporate it into the appropriate patient's EMR record. This market segment is dominated by proprietary APIs offered by market leaders (the only ones with sufficient clout to get others to write to their APIs).
These companies include Cardiac Science, Midmark and Welch Allyn on the device side, and a small number of EMR vendors who've decided they can play that game too and created their own proprietary medical device connectivity APIs, such as Allscripts' Helios. Certainly the intended use of these manufacturer's APIs matches that for a MDDS; should the functionality in the API match that described in the final rule (whereby medical device data can be transferred, stored, converted, or displayed) FDA will likely come a knockin'.
Another group received a surprising amount of attention in the final rule notice, health care providers. From a regulatory perspective, any entity that makes a medical device is a "manufacturer." Hospitals and even physician practices can be designated manufacturers by FDA and regulated as such. For the most part, the FDA has used its regulatory discretion to not treat providers as manufacturers. The final MDDS rule seems to strongly signal FDA's interest in regulating providers who assume the activities of a manufacturer. In the draft rule (PDF here), providers barely got a mention - and then only in the context of a user of MDDSs.
During the public comments period after the publishing of the draft rule, FDA received a comment that asked, "whether a health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, and that then subsequently utilizes the software or hardware for functionalities within the scope of this MDDS regulation, will be considered a manufacturer." Here's FDA's response:
A health care facility or other purchaser that buys software or hardware that has not been labeled or otherwise denoted as an MDDS, but is used as an MDDS, is not considered to be a manufacturer. If, however, the purchaser adds to or modifies any hardware or software such that the software is intended to provide the transfer, storage, conversion according to preset specifications, or display of medical device data (or otherwise modifies the product to render it a medical device) and uses it in clinical practice, the purchaser becomes a device manufacturer in accordance with § 807.3(d). If a third-party company or hospital develops its own software protocols or interfaces that have an intended use consistent with an MDDS, or develops, modifies, or creates a system from multiple components of devices and uses it clinically for functions covered by the MDDS classification, then the entity would also be considered a device manufacturer.
If you're a provider, read that paragraph again. Since the data protocols coming out of virtually all medical devices are proprietary, and you can't buy a general purpose product that includes those protocols, creating a system that acquires medical device data will necessitate actions that will render you a manufacturer.
In a following comment about medical device reporting (MDR), FDA stated that, "Manufacturers, including hospitals that develop custom systems that meet the definition of an MDDS, must comply with the MDR requirements in part 803." So there are two gotcha's for providers that can get them sideways with FDA: by doing things that make them a manufacturer, and by not reporting deaths and serious injuries to which the MDDS may have caused or contributed. As a hospital, if you meet the definition of a manufacturer, you also must establish and maintain adverse event files, and submit summary annual reports to FDA.
Manufacturers with products similar to MDDSs are also addressed in the final rule. Both alarm notification and surveillance are mentioned specifically in the draft rule as falling outside the MDDS classification. Two market segments that fit the comments in the draft rule are alarm notification or messaging middleware systems (I track 13 companies here, like Ascom, Philips/Emergin, GlobeStar Systems and Extension) and what I call data aggregation systems (less than a handful companies like, LiveData and Global Care Quest/Storz). The final rule streamlines the text around these applications and simply states, "A device intended to be used for active patient monitoring (or decision support) is not an MDDS," and, "This identification does not include devices intended to be used in connection with active patient monitoring. There are existing classifications for patient monitoring devices."
Obviously, alarm notification and surveillance of near real time waveforms are functions related directly to active patient monitoring. The proposed MDDS rule generated a lot of comments about whether or not alarm notification is part of a MDDS. Certainly an MDDS acquires alarms along with other physiological data from a medical device and passes it on to other devices or systems. And the MDDS system itself will likely have alarm notification covering the operation of MDDS itself - if an important parameter or component in the MDDS fails, some sort of notification is needed so the failure can be addressed. All true agrees the FDA in the final rule (page 26), and they even removed, "sound an alarm” from the final regulation.
It's clear from the final rule that alarm notification or messaging middleware systems are not MDDSs. But FDA goes even farther: "Any device that transmits, stores, converts, or displays medical device data that is intended to be relied upon in deciding to take immediate clinical action or that is to be used for continuous monitoring by a health care professional, user, or the patient is not an MDDS." This means that alarm notification systems that rely on MDDSs for alarm and other medical device data have a problem. They'll either have to shoulder the MDDS component themselves, or go with a manufacturer with premarket notification.
All this mentioning of alarm notification and surveillance indicates that the FDA expects the manufacturers of these devices that are not regulated to get with the program. Conversations with many of the alarm notification vendors indicates that they are preparing to become or are already in the process of becoming regulated. Interestingly, Philips received 510(k) clearance on Emergin as an Event Management system on January 4, 2011. And just for comparison, here's the 510(k) for Welch Allyn's Clinician Notifier that was issued in 2007.
In summary, FDA is signaling the manufacturers in market segments related to MDDS that they too are facing enforcement discretion and better get with the program.
Manufacturer Responsibilities and Timing
The rule becomes effective 60 days after the data of publication of the final rule in the Federal Register. The magic publication date was February 15, 2011. Here's a listing of key milestones:
- All MDDS manufacturers have 90 days after the date of publication (May 16, 2011 by my counting) to electronically register and list with FDA as a medical device manufacturer.
- Manufacturers have a generous 12 months (February 15, 2012) to implement a compliant quality system, including Medical Device Reporting. FDA also states that, "FDA expects all MDDS manufacturers to establish and maintain adequate design controls as part of their quality system."
- FDA is also pretty generous regarding the adoption of design controls: "FDA does not intend to enforce design control requirements retroactively to any currently marketed device that would be classified as an MDDS under this rule; however, FDA does intend to enforce design control requirements for design changes to a currently marketed device once there is a design change."
What To Do Now
If you are or want to be a MDDS manufacturer (and you know who you are), and you're not presently regulated, you need to put together an initial roadmap. After that comes more in depth planning and budgeting. If you're a MDDS manufacturer and already regulated, an analysis of your regulatory options is called for. For example a manufacturer's product that's regulated as a Class II device has a number of options: shift to Class I, stay at Class II with the same intended use, or perhaps adjust the intended use to address specific market opportunities.
If you're an EMR vendor how even might meet the definition of a MDDS manufacturer, and haven't already put together your roadmap and plan, don't wait any longer. Sixty days will be up before you know it, and you really don't want to learn first hand the meaning of the term "adulterated device."
If you're a health care provider - a hospital or large group practice - and you too might meet the definition of a MDDS manufacturer, and haven't already put together your roadmap and plan, don't wait any longer. Sixty days will be up before you know it, and you really don't want to learn first hand the meaning of the term "adulterated device." In your case, an adulterated device finding will keep you from using your own system.
If you're a health care provider and you're looking to purchase a MDDS, alarm notification or data aggregation system, seek some expert advice. Things are changing relatively quickly (for health care) and this final rule will have a ripple effect on manufacturers.
If you're an unregulated manufacturer in a market segment close to MDDS, like alarm notification or data aggregation, you too need a roadmap and plan. Many of your competitors are already down this path, some quite a ways.
There's still some issues in the final MDDS rule that we've not reviewed, some interesting comments and FDA responses, and analysis. I'll be posting more on this, and responding to comments. I will also be doing an updated version of the Compliance Online webinar on the MDDS rule (here's a link to the original).
If you found this post entertaining, you might like the article in this month's Patient Safety & Quality Healthcare magazine, The Case for Regulating EMRs, by yours truly.
Here are some other sites with posts on the final rule:
- MorganLewis blog post by Beth Bierman offers a very high level summary and some interesting observations
- The inestimable Brad Thompson as another of his great posts on regulatory issues at mobihealthnews with some great analysis
- Health IT Exchange has a post focused on the FDA's apparent intent to regulate hospitals who act like manufacturers
- And here's my post on the draft rule from 2 years ago
DISCLAIMER: Nothing in this blog post, or in any of the content in this site, is intended as legal or regulatory advice, and is provided as opinion and commentary on current events.
UPDATE: I revised the blog post title to make it easier to find in search engines.
UPDATE: William Hyman was kind enough to pass on this information:
April 19, 2011 – The FDA has posted the new MDDS Rule and associated explanation and comentary at its website.
As I read the ruling, I also see that a mobile phone being used in remote monitoring to display, archive and send medical device data somewhere can also be thought of as an MDDS. Would be great if FCC and FDA clarified this-could be an inhibitor in the remote monitoring market.
Bridget, I don’t see any need for clairification as the rule is unambigous.
A remote monitoring system is not a MDDS because it exceeds the intended use for a system classified as a MDDS. Remote monitoring systems will be regulated as something other than a MDDS.
Tim,
A thorough discussion. I am just sorry it did not include the fact that Nuvon’s VEGA platform is already 510(k) cleared as was announced last year.
Cathleen
Cathleen, thanks for the additional information. There are other systems that have received clearance besides Nuvon and the others I listed. Like Nuvon, they weren’t excluded for any reason other than this post is about the MDDS rule and not MDDS manufacturers (beyond the few mentioned as examples).
I’m planning a comprehensive review of MDDS and similar systems after HIMSS and will include all vendors at that time.
The Nuvon VEGA system was cleared under product code LNX, Medical Computers and Software, which is identified as an unclassified pre-amendment device that requires a 510(k) route to market. If the VEGA is indeed an MDDS as now defined, it would now be able to follower the easier Class I route which does not require a 510(k). Thus their regulatory burden would have in fact been eased, as it will be for future comptetitors.
There is another seemingly related code NSX named “Software, transmission and storage, patient data” with a definition of “Non-alarming software that captures patient data from patient monitoring devices and transmits the data to the patient electronic medical record, where the data is stored.” This is curiously similar to at least some functions of a possible MDDS, but was never mentioned as far as I know by the FDA in its defining and launching of the MDDS. NSX is an unclassified device showing “enforcement descretion” under submision type. NSX also shows two recalls by the same vendor, demonstrating perhaps that such systems are not always benign. For one of these the reason may be an example of what will I suspect become an interface
classic: “overwritten with incomplete data or blanks by the interface…if that interface is not configured properly”.
Tim,
Although the rule clarifies in Comment 8 that a LIS would not fall under MDDS regulation, I have not found any question or reference about ‘POCT Data Managers’. These middleware share some functionality of a LIS in the POCT environment. Examples of products from non-device vendors are AegisPOC from LDS in US and POCcelerator from Conworxs in Europe. I understand that a POCT DM does not fit the MDDS rule. However, should these systems be classified in the same way as a LIS, under § 862.2100?
Javier, you are correct that POCT middleware does not meet the definition of MDDS. This is because the intended use of a POCT middleware product clearly exceeds that defined for a MDDS. For example, a good POCT solution provides workflow automation and an important QA function that are not included in a MDDS.
You note that some (perhaps all) POCT middleware products are not listed with FDA, and after a quick check, that is true. These products meet the definition of a medical device and are clearly postamendment devices.
I suspect the FDA is exercising regulatory discretion while observing the development of this market (it still has quite a ways to develop). If that’s the case, at some point FDA will likely issue a reclassification for POCT middleware products as they did for MDDS, signaling a shift to enforcement discretion.
Another question implied by your comment is whether FDA is signaling enforcement discretion regarding POCT middleware systems at this time. I think not. While FDA can exercise enforcement discretion whenever they want, this market segment was not mentioned in the final MDDS rule, while many other potential targets of enforcement were.
I would imagine that if a POCT middleware vendor approached FDA to be regulated, their product could be classified similarly to a LIS, a combination device (when a manufacturer makes an integration claim to a specified analyzer) or perhaps as an accessory to a POCT device.
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. A number of EHR companies (400+) might find themselves out of business.
We will see.
Jeff Brandt
Jeff, it is true that any thing in any situation or market that meets the definition of a MDDS faces potential enforcement.
And there are additional HIT software products that meet the legal definition of software, and are currently targets for future enforcement discretion. See this article for more: http://www.psqh.com/januaryfebruary-2011/738-the-case-for-regulating-emrs.html
I can appreciate your trepidation towards possible regulation by the FDA. And it does add *some* costs, but not at the level that will drive companies out of business or the market. Most of the FDA regs are equivalent to a basic quality system like ISO9001.
The biggest challenge FDA regulation presents for small to medium companies is not knowing the “inside baseball” of the regulations, that can result in higher regulatory costs and potentially, delays in getting to market.
Companies close to the boarder between regulated and unregulated devices (including software) should get expert advice. And they should develop clear regulatory objectives and tangible plans for achieving those goals - whether they want to come under regulation or avoid regulations.
Regarding: “Companies close to the boarder between regulated and unregulated devices (including software) should get expert advice.”
Where’s a list of experts for advice ? thanks
Coincidentally, this blog is written by a well known consultant who’s knowledgeable in this area (wink), and you can call me at 503-481-2370. To round out your requested list, I also personally recommend Bradley Merrill Thompson at Epstein Becker & Green, and George Samaras at Samaras & Associates. Both are knowledgeable in this area. And both are easy to find via Google.
(Comment 19)…..Other comments suggested that “real time, active, or online patient monitoring” was confusing and would exclude from the MDDS classification devices intended to transmit medical device data to a physician for the purpose of performing remote patient examinations.
FDA agreed with the above comments, and has excluded “active patient monitoring” devices from the MDDS. Real-time audio/video patient surveillance, e.g., a physician performing a telemedicine consult, and using his/her observations to issue immediate orders, appears to be outside of the MDDS. Is this a reasonable extrapolation from the rule?
Dan, I’m not sure what you’re asking regarding any extrapolations from the rule. The definition of an MDDS is very narrow. A product that does not meet that narrow definition is clearly not an MDDS - especially if the intended use is broader than that for an MDDS.
I see your product was cleared by FDA in 2008, so I’m not sure what answer you’re looking for. Feel free to give me a call with your question.
My company has developed a data collection system for steam sterilizers that records and transfers alarms that may happen while instruments are being sterilized. It seems that the MDDS rule has been interpreted as applying to systems that collect and transfer “patient data”. However, the statement from the FDA only uses the term “medical device data”. Do you think that MDDS applies to my company’s product and if not, how would I defend the decision not list it as a MDDS to the FDA?
Jay, you are very much in a gray area. Your sterilizer is a Class II device and your software could easily be considered an accessory - and thus also a Class II device. Your question can best be answered by a close assessment of your products, existing regulatory materials, a review of competitors, and a comparison with the regs.
In fact, I wrote a blog post yesterday describing one way to clear up these questionable areas: http://medicalconnectivity.com/2011/03/30/charting-your-regulatory-course/
Let me know if you need any help, or a second opinion.
Hi Tim,
We have developed an aggregator box to collect real time data from the patient monitoring system and upload the same to EHR. Will my device fall under MDDS Classification. Can you please explain me the definition of active patient monitoring.
Please provide me with the Federal Register publication of February 14, 2011
If I go to the Federal Register, it does not provide the actual MDDS ruling officially released on 2-14-2011.
Thank you
Andre, at the beginning of the post, the first link is to the online version of the Fed Reg. The link to the pdf version of the paper-based Fed Reg was broken, but is now fixed. This pdf link will allow you to download the Fed Reg text and print it out.
My company is a manufacturer of non-medical equipment (computer carts, wall mounted computer holders) that is considering incorporating computers, equipment and codecs to fascilitate telemedicine. We are considering use of POCT’s and software from other manufacturers on our cart in accordance with thier requirements. What responsibility do think we have to comply under MDDS or FDA in general or would that fall completely on the POCT manufacturer since we are simply providing a ‘holder’ for the equipment? We also will supply a UPS power source which may complicate things.
Tim,
So if I have an MMDS can I connect it to a device that is being used as an active patient monitoring?
Thanks,
Rob,
An MDDS can connect to, and acquire data from, any type of medical device, including an active patient monitor. What an MDDS can’t do itself is perform like an active patient monitor, e.g., doing near real time surveillance (especially waveforms), alarm notification or remote control of patient monitors (such as remotely silencing alarms).
An MDDS is intended to acquire medical device data and pass it on to another system for use. Such a system can provide active monitoring capabilities like those described above. A system receiving medical device data from an MDDS and doing active monitoring functions would be a Class II medical device, and regulated by FDA.
What you’ve described is more than likely a Class II medical device and would be considered an alarm notification system. You might be able to avoid that depending on the marketing claims you make and the features of your system.
In any event, no MDDS vendor should concern themselves with what a customer is doing with their product as they are not responsible for any customer use or misuse. And what you’ve described clearly fits the intended use of an MDDS — to acquire data from a medical device and serve it up for use by another system.
Thank you for the article, Tim. I have a question about what you said: “In any event, no MDDS vendor should concern themselves with what a customer is doing with their product as they are not responsible for any customer use or misuse. ” I was wondering if you are not referring here to MDDS vendors who are performing ISO 14971 risk management, since they do consider both intended uses and reasonably foreseeable misuses.
Hans, you are correct that during the product development phase, potential misuse of a device should be anticipated as part of a quality system risk assessment. And clearly, any anticipated misuse that results in patient risk should be mitigated and addressed through a warning in the device labeling. However, once the product is sold and in use, off label uses of the device are not the manufacturer’s concern — unless the off label use results in patient harm or a complaint. Should this happen, you go back to risk management and mitigation as directed by your corrective and preventive action system. My quote above was more from the perspective of a product manager or someone in sales and marketing rather than someone in regulatory affairs.
Thanks Tim, this is a very informative article.
Do you think that the policy statements reflected in this Final Rule signal a significant departure from the FDA’s previous regulatory focus? It appears that, as you mentioned several times, the rules have not changed, it is just that FDA is switching from a regulatory mode to an enforcement mode.
Also, a few commenters asked this question, for an iphone app that helps to store patient data as part of the patient’s health records (without any modification to the data), such an app would be classified as a Class I MDDS?
John, I do not thing FDA has changed their regulatory focus. The MDDS rule is an example, of which there are many in the past, of the FDA’s shift from regulatory discretion to enforcement. This is a natural progression for new medical device markets or categories as they mature. A key factor is patient safety; the perceived risks drive the speed and rigor of FDA’s move to enforcement.
Your second question about iPhone apps is hard to answer because the response depends on numerous details. If the app meets the definition of a MDDS, then yes, it would be a Class I medical device. A mobile app could also be an accessory to the medical device that the app is integrated with (in which case it would most likely be a Class II).
Tim - reviving an old discussion here - am trying to get a straight answer and having trouble. If I connect a 510(k) approved video otoscope to an un-altered videoconference device and sell it for telemedicine purposes, does FDA consider this a new device needing its own 510(k) premarket or registration as an MDDS?
Thanks.
Daftar Situs Judi Online Terbaik in Indonesia
Situsalternatif are a new collection of listings of the
greatest online gambling internet sites from all well-known bookies / brokers in Indonesia.
Home elevators online gambling internet sites listed on this specific page is always altering,
because we just provide sites of which get good evaluations.
Each site offers some informative regarding the games
obtainable, deposit transaction alternatives, and alternative backlinks.
Collection of Situs Alternatif and Daftar Taruhan online Terbaik
Enjoying on gambling websites is not really completely clean, one of the problems often through players will be difficulty accessing the particular
site best places to enjoy due to web site blocking. Therefore,
the choice Site collects option links here which usually are incredibly useful to help gamblers in order to easily login in addition to daftar judi online.
Inside addition, you avoid need to worry about the link jalan keluar judi
that all of us provide, obviously you can access that easily and with regard to free.