In an off the record conversation couple months ago I was assured by an FDA contact that they were indeed working on a final version of the MDDS rule. Then this past Friday, David Bowerman with VisICU said that he'd heard that the FDA was going to publish the final draft in a few months.
After some poking around, I came across this page on SoftwareCPR (by the time you visit the page, the 4/7/09 entry may have scrolled off the page). At the top was this intriguing bit:
At public conferences representatives of the FDA have indicated that the draft Medical Device Data System Classification rule was returned from FDA legal review for clarification of how public comments were addressed. This will delay release of the final rule perhaps 3 - 6 months but it is hard to estimate.
On the same page of news, I saw that John Murray, with the CDRH Software Compliance office, gave a presentation at the recent AAMI Standards Conference on what software is a medical device, how such software is classified, and whether pre market submissions are required or the quality system regulation applies. (An interesting presentation (pdf) that you can download here.) Thinking this may be one of the "public conferences" where "the FDA have indicated" the status and not too distant release of a final rule, I give John a call. Here's what he said:
- FDA legal had indeed come back with a request to more fully address the public comments in the final rule.
- He described the majority of comments as focused on wanting a better understanding the proposed rule's definitions.
- Consequently, the preamble will be expanded to include better definitions.
- That the basic rule itself will be unchanged.
- And yes, the final rule is close to being published.
When asked about the 3 to 6 month time frame to finish tweaking and publish the final rule, John declined to site a specific time frame.
Compliance Requirements
The proposed rule includes specific time frames for manufacturers to come into compliance. The draft MDDS rule states that vendors have 60 days after the final rule is published to register with the FDA as a medical device vendor and provide a list of their products. Manufacturers who fall under premarket notification (510k) have 90 days to submit, and 180 days to obtain final clearance. This is not a whole lot of time.
Since the draft rule was published, vendor reactions have ranged from "wait and see," to accepting the MDDS rule as a foregone conclusion and moving towards compliance. This puts some vendors facing FDA regulatory scrutiny in a bit of a pickle. The ideal scenario is to register as a medical device manufacturer after fully implementing the Quality System regulation (QSR). Ditto for listing Class I devices; they should include the completion of full QSR documentation. And certainly before one submits premarket notification for a 510k, QSR must be implemented and applied to the product that's being submitted.
Adopting QSR in a way that minimizes cost and interruption (think of it as direct and indirect or opportunity cost) would take about a year. The effort to take an existing product that was not developed under the QSR and rehabilitate it, completing the required quality processes and documentation, can vary greatly. Poorly documented "spaghetti code" developed years ago is a considerable challenge -- and a worst case scenario if none of the original engineers are still with the company. Documented and structured code is much easier to rehabilitate.
One should not mistake past regulatory discretion for lackadaisical enformcement on the part of the FDA. When the regulation of a relatively new product category is publically announced, often though a reclassification rule, the FDA gets serious. Should the FDA site a manufacturer for noncompliance, they can legally seize product and force the cessation of sales of the product until the manufacturer is back in compliance. A common vehicle for serious enforcement is the concent decree. A google of the term shows how agressive the FDA can be.
Compliance Strategy
The short compliance strategy is, "just do it." But with a compressed time frame, things are more complicated. Some manufacturers may have to suspend normal operations (or most of them) and devote staff to adopting the QSR. Manufacturers will also need to engage a consultant and hire a regulatory manager. The costs for consultants varies. A white-shoe regulatory law firm could could cost hundreds of thousands or over a million dollars. Smaller more specialized firms can cost under $100,000. Your internal regulatory person can be an existing employee with quality experience (possibly supplemented by a consultant), you can hire a contract regulatory "employee" to work as needed on a monthly basis, or you can hire an actual regulatory affairs person (salaries start at $100,000).
Most think about regulatory submittals for premarket notification, or 510k's, as the big regulatory hurdle. That's really not true -- in fact the draft MDDS includes estimates of compliance costs. Adopting the QSR for company operations undertaken to support the regulated medical device (that's the entire company for most manufacturers) likely entails the highest costs. As noted above, rehabilitating a released product to comply with the QSR can vary greatly, and possibly exceed the cost to adopt the QSR for company operations.
To minimize time to compliance, you'll have to do more than one thing at a time. First should be an audit of your operations and products that will be regulated in order to gauge the scope of effort required to bring them into compliance. Another initial step is developing a regulatory strategy for your product. This strategy determines exactly how the QSR is applied to your product -- more on this later.
Next comes sequencing events properly to minimize the time until you achieve compliance, hopefully within the time frames stipulated in the MDDS rule. If you fall outside of the MDDS rule's time frames, you'll need to see what you can arrange with the FDA. The FDA is not in the habit of compromising patient safety for mundane things like profit or solvency. However it may be possible to arrive at a solution that provides the manufacturer some wiggle room in a way that does not unduly compromise safety. Such a compromise is very iffy, so don't count on this.
All of this gets complicated very quick, and the best advice is to start sooner rather than later.
Describing the Quality System Regulation
The QSR defines a process, and is not proscriptive in how that process is applied. What's important to the FDA is that you develop policies and procedures that are consistent with the QSR, and that you follow them. A company can implement the QSR in a way that is unnecessarily expensive and time consuming and the FDA won't make a peep -- as far as they're concerned, how you implement the QSR is your business. Alternatively, you can implement the QSR in a simple straightforward way. There's even the concept of "least burdensome approach" where you can drop certain parts of the regulations, provided you can justify those changes to the FDA.
Unlike the FAA who tests and certifies specific finished products, airplanes, the FDA regulates the process by which medical devices are designed and manufactured.
Let's look briefly at a product strategy example, wireless patient monitors. Most patient monitoring vendors build in off-the-shelf radios into their products. A few have even designed their own component radios. Draeger took a different approach with OneNet. Rather than select a specific radio, they chose to build a PCMCIA slot on their patient monitors. They developed a regulatory strategy where their product could use any Wi-Fi Alliance certified radio card in their devices. Vendors with built in radios have to deal with parts obsolescence and getting customers to accept the features of the radio they've built into their product. Draeger let's customers choose whichever radio they want, as long as it is Wi-Fi certified.
Now each of these approaches to radios has strengths and weaknesses. The point is that both of these radically different approaches to wireless enablement are in conformance with the QSR.
One more example: the product development process (PDP). I've seen vendors spend man-months creating "special" PDPs for their company that include additional complexity and steps beyond those defined in the QSR. And in fact the FDA doesn't really care what bells and whistles are added to a manufacturer's PDP, as long as the requirements in the QSR are met. Most PDP additions to the QSR that I've seen don't improve quality or reduce time to market -- they just make everyone feel special. On a more practical note, there are manufacturers that have taken PDP methodologies like Agile, Spiral and applied them in a way that's consistant with the QSR (here's an interesting paper on the topic).
As workflow automation systems move closer to the actual point of care -- where diagnosis is made and therapies delivered -- the ability to skirt the legal definition of a medical device is increasingly difficult. At some point, crossing the line into regulated territory is inevitable. If your company needs help, give me a call.
Another great post.
Two quick thoughts:
1) I don’t think you can overemphasize the importance of being able to prove that you actually follow your own processes. Developing the QSR processes is one thing, but incorporating them into your day-to-day life is another. This requires a significant cultural change in the way a company operates and can be very difficult for some.
2) RE: “rehabilitating†legacy code. Reverse engineering design documentation is only the tip of the iceberg. Companies without a quality system will typically have no detailed product specifications (design input) and very little or no formal verification (which requires traceability to requirements) and validation. These are big tasks.
The thing about the QSR is actually following the quality system, rather than just doing the paperwork. Certainly a company with a product developed before they became regulated as little choice. When regulated vendors do this, they can get in big trouble.
A large percentage of my product development consulting work ends up revolving around requirements (and the frequent inadequacy of same). Many struggle with how to gather workflow requirements beyond their embedded device. And some want to rush to market with something developed in the feasibility phase.
Tim,
As always, interesting and thought provoking. One area that I think deserves special attention with respect to the QSR is risk management. Unlike ISO-13485 which mandates the use of documented risk management throughout the product development lifecycle, the QSR is less dogmatic and only mentions the use of risk analysis during Design Validation “where appropriateâ€. However, this is inconsistent with my experience with the FDA and inconsistent with their pronouncements of late about following GHTF recommendations and working with ISO to incorporate ISO-13485 and other standards into the QSR.
What this means for anyone establishing a QSR is that they will need a risk management program, preferably one compliant with ISO-14971 that includes clinical evaluation. Application of such a program is the appropriate means of understanding the possible harm that is associated with interconnected medical devices. And, it is the proper means for mitigating those risks to ensure that the devices are safe and effective. After all that is why the FDA requires a QSR for medical device companies.
Peter Kelley
Director of QA/RA
Capsule Tech Inc.