A growing number of organizations -- large and small, within health care and outside of it -- are facing regulation by the FDA. Those potentially affected fall into 3 camps. All of the examples I'm going to talk about deal with multi vendor systems (or systems using lots of off the shelf components) that become the regulated medical device.
Just what is a medical device? The legal definition of a medical device is,
an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:
- recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, [i.e., a drug]
- intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
- intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it's primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.
According to the New Oxford American Dictionary, a contrivance is "a thing that is created skillfully and inventively to serve a particular purpose." So a medical device can be made out of anything, as long as it falls under at least one of the three bullets above.
Who Is Impacted?
The first group are those targeting remote monitoring and Healthcare Unbound applications, many of which are facing the FDA for the first time (see the membership roster of the Continua Health Alliance for examples). These companies include wireless carriers, cell phone and consumer electronics manufacturers.
The FDA's proposed rule on Medical Device Data Systems (MDDS) impacts a different group. This rule signals the market that the FDA is going to pursue enforcement against those that don't comply with the regulations for certain types of medical devices. This includes any company that acquires data from medical devices that are used in the diagnosis and treatment of patients (health and wellness does not apply, but chronic disease management does). Also impacted by the MDDS rule are "secondary" alarm notification vendors and vendors providing surveillance and/or data integration of medical device data with data from other sources.
A brief email exchange with a contact at the FDA last week hinted that they're busy working on either the final rule or another draft -- either way the rule seems to be moving forward. You can read more about the proposed MDDS rule and what it means here.
The third major group potentially facing new regulatory hurdles are infrastructure vendors. Here the issues are mostly about how FDA regulations impact sales and marketing. Getting computers, networks and other products approved by the FDA is also an issue in some cases.
Amongst the first and second groups, there is a divide between vendors and health care provider organizations. The FDA can only regulate "manufacturers." Qualifying as a manufacturer depends on what you do, rather than what you call yourself. Health care providers who do certain things risk being defined a manufacturer by the FDA.
Provider organizations sometimes "rolling their own" solutions. They write software from scratch, modify existing hardware and software products they've purchased, and sometimes modify or create medical devices. When these are unregulated systems (i.e., not medical devices), like patient accounting software, there's no risk the FDA might show up for an impromptu inspection. But when those activities center around regulated medical devices, that's a whole different story.
To date, the FDA's used their regulatory discretion to ignore much of what providers do that might otherwise full under the FDA's purview. Providers who make minor modifications or develop modest devices for their own use are at least risk of stirring up the FDA. A provider who heavily modifies life critical systems is at greater risk. Providers who make medical devices that they then sell or distribute in some way can expect a knock on the door. The big risk here is that the FDA can change their mind at any time and pursue enforcement actions against a provider -- even retrospectively.
The Problems
Manufacturers facing the prospect of FDA regulatory oversight have two main choices: get with the FDA's program or withdraw their product. If their products are part of a multi vendor system they may find a third party who's already regulated that can get regulatory approval. This third party must promote and sell the regulated system, although the original manufacturer could become a distribution channel for the regulated manufacturer. This third way results in lower regulatory costs and risk, but also lower revenue. Finding the right partner and structuring a deal that's acceptable to everyone is the challenge.
If you provide just part of the solution, say a gateway, mobile phone, or network, what are your risks in being part of a regulated device, and what can you do to make yourself a more attractive supplier? Dealing with this scenario also means getting pretty deep into the FDA's world. You may not submit products for regulatory approval, but your component customer will have other hoops for you to jump through.
A secondary but important problem revolves around the FDA's regulations on how approvals are granted. Under the law, only one manufacturer can gain regulatory approval and sell the resulting solution. If you're providing part of the overall solution that's regulated, who assumes the regulatory burden and also gets to sell the solution? It is currently not possible to get regulatory approval as one part of a total solution. For example, in remote monitoring there are 3 market segments: sensors, gateway and information management system. The "product" is a system made up of all three. Some vendors do all three, and others specialize in just one or two segments. The ways out of these kinds of conundrums are neither obvious or straight forward.
Besides the fact that multi vendor solutions can only be sold by the manufacturer who gets regulatory approval, a similar requirement applies to promotion and labeling. Labeling includes what's affixed to the product, product packaging, directions for use (DFU or user/service manuals) in addition to printed and electronic sales and marketing materials. Labeling can even extend to emails to customers and what comes out of sales reps mouths.
The regs state that only the vendor that gains regulatory approval for a medical device can market and sell it. Now this becomes an issue when the "device" is in fact a complex system using products as components from a multiplicity of manufacturers. Only one of those vendors that make up the regulated system can get approval to market and sell the system. If you're a wireless LAN infrastructure vendor and want to market a (soon to be) regulated device like medical device connectivity or alarm notification, you can't. Period. Not even as part of an "industry solution."
Is your head spinning yet? While all of the above can be figured out for any given company or situation, the biggest problem here is that first timers to the FDA regulatory party lack lack both detailed knowledge of the regulations and a frame of reference for developing a regulatory strategy and making decisions on risk.
Solving the Regulatory Puzzle
Regulatory people, whether consultants or employees, are like lawyers. In fact many regulatory affairs folks are lawyers (not that there's anything wrong with that). Presented with a problem, lawyers strive to formulate a solution that minimizes risk for their clients -- with little or no regard for, you know, running a profitable business. Once you have your legal opinion, it is up to senior management to determine the level of risk the business is willing to accept in that situation. Sadly, there is no such thing as a risk-free world, even if you let lawyers run your company.
Regulatory affairs folks will seek solutions in much the same way as lawyers. Their goal is to minimize regulatory risk as much as possible. For example, one company facing FDA regulations has a large factory where only a very small portion is used to manufacture a product that may get regulated. They were told by a regulatory consultant that they would have to apply GMPs (good manufacturing processes, a part of the FDA regs) to the entire manufacturing plant -- all the production lines, for every product line. That is a legitimate minimum-risk proposal, if not a very practical one.
Like legal risk, regulatory risk must balance compliance with the law and the practical demands of running a business. "The law is the law!" you may say. But like much of the law, regulatory risk is not black and white. Nor are the FDA's regulations prescriptive. The FDA is all about systems and process that ensure safety and effectiveness, and not telling you how to run your business. How you meet the FDA's regulatory requirements is variable. The FDA Modernization Act of 1997 includes provisions for supporting the "least burdensome approach" to major sections of the regulations.
Consequently, regulatory decisions require a frame of refererence that can balance risks to arrive at a decision that allows profitable operations without unduely risking the company. Organizations new to health care and FDA regulations lack the information necessary to make those risk trade off decisions.
It is important for companies to have someone who can identify the "absolute minimal risk." This can be an outside consultant, an employee, or a contractor. Just as important, a company needs someone who can bring the company to a realistic balance between risk and practicality. In the example above, there is no explicit regulation that requires an entire factory floor conform to the regs because a part of that factory is used to make medical devices. An alternative solution (with little increase in risk) is to apply the GMP to just the production line that makes the regulated device, leaving the rest of the facility unchanged.
So how do you bring that balance between risk and practicality into the regulatory equation? These are clearly senior management level decisions. With experience running a regulated business, division or product line, this skill will accrue to your management team. Until you build up that experience, you can rent this skill. Any prospective regulatory consultants for this role must be experienced in "combination products," systems made up of embedded devices, software running on general purpose computing platforms, and connectivity.
There are two temptations here to avoid. First, don't place your regulatory affairs manager in both positions of defining "absolute minimal risk" and the approach that is the best balance between risk and practicality. The responsibilities of regulatory affairs will always steer them heavily towards the absolute minimal risk position (and that's a good thing). It is also a temptation to hire a connectivity product manager and give them responsibility for ensuring regulatory decisions reflect the optimal risk/practicality balance. Because product managers have no real authority, these decisions will always end up with senior management who, when lacking sufficient regulatory experience, will take the safe route and side with regulatory affairs. Both of these approaches will increase your R&D costs and time to market, placing your company at a competitive disadvantage.
Regulatory Strategy
There's a somewhat involved process in becoming regulated. You have to do things like register with the FDA as a manufacturer. Then you must define and then implement a bunch of specific policies and procedures throughout your company. If you already support some international quality system standard like ISO 9001, you're probably more than halfway there. Regardless, you will need a business plan, budget, training, and monitoring to be ready for your first FDA inspection. These steps lay the foundation for doing business in a regulated environment.
While you're laying your foundation, you're going to need a regulatory strategy for each of your products. These strategies are implemented on top of your company wide regulatory foundation mentioned in the preceding paragraph. Product regulatory strategy is the balance between intended use (or marketing claims), product specifications, risk analysis and design approach. Product regulatory strategy has a big impact not just on regulatory costs, but also overall product development costs and time to market.
Until things are worked out to better support the regulation of multi vendor system products (like the sensor/gateway/information system example above) you will need to work with your development partners or suppliers to craft a strategy that conforms to the current regulations. If you want a fancy name for this process, I like calling it a "regulatory business development strategy." Here you work among the partners/suppliers of your system solution to shift the regulatory burden around and get alignment between that and your promotional plan. Whoever gets the regulatory approval is who gets to promote and sell the solution. But there is some wiggle room in certain situations where some of the marketing claims can be spread along with the regulatory burden.
UPDATE: According to mobihealthnews, the FDA's Don Witters presented at TEPR+ this past February. Witters started the session with a definition of medical device. This was an early exchange as reported by Brian Dolan:
At times during the session, the tension in the room was palpable. Witters declared that the FDA has jurisdiction over any device that diagnoses, treats or prevents a disease. This led to one question from the audience: “So an MRI app for an iPhone is a wireless medical device? Or a patient reporting their blood glucose level by text messaging their physician who then adjusts their insulin dosage with a return SMS?” Witters initial response was “No, I think that’s getting into information exchange–that’s different.” After the questioner thanked him and said that people probably just breathed a sigh of relief, Witters doubled-back. “Well, I think the real answer is ‘We don’t know.’ That’s why I’m here today to begin this dialog and see where [the FDA] fits.” So, the FDA could really be interested in inspecting iPhones for use as “wireless medical devices”? You bet.
A determining factor for whether a device a regulated medical device is the intended use. Software that is intended to display and process MRI images for a radiologist to use to make a diagnosis are regulated medical devices. The ability to squirt a representative image to a referring physician (the doctor that order the exam) just for their info or for them to show their patient is not a medical device.
If a patient uses their cell phone to create and send an SMS to their doctor, the phone is clearly not a medical device, but a means for "information exchange." But if the patient has a glucometer integrated with an iPhone where the software generates and sends data to the physician, the entire system is a medical device -- including the software running on the iPhone. You can see more examples of how regulations might apply to the iPhone here.
Brian closes his post with this quote from Witters:
“When it comes to the FDA people think of us more like the IRS,” Witters said. “You don’t talk to the IRS unless they call you and then you call your lawyer or accountant or somebody. That’s not really the way systems work or ought to work. It should be a much more open process. It goes over the edge, though, when you start marketing [an unapproved wireless medical device] and it’s a money-making proposition and it has real issues with it. That’s where bad things start to happen.”
Hi Tim,
What would this change mean to us as customers of medical device vendors?
We’ve spent millions putting in the latest state-of-the art infrastructure. We hope we would be able to run all our medical devices on the same infrastructure. But now it appears we need to step back and go with the technology of the last decade, where each medical device had its own infrastructure.
There are a number of possible scenarios where vendors may decline the opportunity to be regulated by the FDA, thus impacting hospital customers. Networking, however, is a different situation.
Medical device vendors with networked products include the network in their regulatory submittals as part of their medical device. These guys are used to being regulated and have included networks in their medical device systems for years.
This becomes an issue when a hospital wants to deploy a networked medical device in a way that differs from how the medical device vendor conceived it when they designed their system. Hence vendor requirements like dedicated SSIDs and VLANs.
To stay within the confines of the medical device vendor’s regulatory framework, the customer must ensure their network environment meets vendor specifications — at installation, and thought the life of the installation. At issue is that most providers aren’t aware of just exactly what those specifications are, and what they need to do to stay in compliance. If you don’t do this, you’re using the system “off label” and you assume greater liability for the use of the system. You can read a more in depth discussion of medical device networking issues here.
The complexity of ensuring the safety of wireless medical devices is the principal reason for the development of IEC80001, which should be finalized next year.
As more medical devices are deployed house wide, going back to dedicated networks for each type of medical device becomes impractical. This is especially problematic for wireless networks. Also, the simple days of channelized analog telemetry systems of limied size are quickly passing as well. Just because a vendor designs their medical device system to use a dfferent frequency (e.g., WMTS) or a proprietary network on the ISM band (e.g., ZigBee, Bluetooth), don’t think there won’t be complications — some of them will just be different from those you have with WiFi.
You’re right Pete, this is a big mess. But it’s our mess, and we’re going to have to work through it.
Tim,
You wrote a wonderful and thorough article. I would just like to add two points.
First, I think it is important for people to understand the difference between a component and an accessory as those terms are used in the definition of a medical device. They are both included in the definition as examples of “devices” to make it clear that a product need not be a finished medical device to qualify as a regulated article. As most people use those terms, a component is purchased and assembld into the final device by the manufacturer, while an accessory is sold directly to the customer for use with the parent device system.
The distinction makes a fairly big difference in how they are regulated. A component is simply incorporated into the clearance or approval application by the finished device system manufacturer, while an accessory may be addressed by a separate submission that merely identifies the parent device. The accessory will be placed in the same regulatory classification as that parent device, which as I explain below, determines the level of regulatory requirements imposed. Further, because the accessory is sold directly to the customer, the accessory manufacturer is directly responsible to FDA for compliance with the agency’s good manufacturing practices, while component manufacturers are not directly accountable to FDA but are rather accountable contractually to the finished device system manufacturer.
The second point is that knowing whether an article is a medical device does not tell us much about whether the regulatory requirements will be demanding or quite modest. The medical device regulatory system is stratified into three different classifications based generally on risk. Class III devices are either very novel or very risky or both, and must undergo the most rigorous of the agency’s device approval requirements. On the other hand, class I devices are most often exempt from premarket approval and need only comply with some very basic general controls such as appropriate labeling and in many cases the good manufacturing practice requirements.
I think your article is a great primer for those companies trying to understand whether they need to think about FDA compliance. As you aptly point out, the claims they make drive that analysis. Thus, they need to be strategic in deciding how to promote their products. I’ve seen many companies lately gratuitously making claims that would trigger FDA interest, probably without the company realizing it and perhaps unnecessarily.
Brad Thompson
Brad, great distinctions. Component manufacturers like Cisco, Apple or Microsoft are not subject to FDA regulations — although frequently vendors in this situation would benefit from advice on how FDA regulations impact the promotion and distribution of regulated products, including components. (I’m thinking of the “Cisco phone with a waveform” example.)
Regarding regulatory costs, there are 3 big components: implementing and maintaining a quality system (required for virtually all medical devices), premarket notification — a 510(k) — and possibly special controls (required for Class II devices), and premarket approval where you must demonstrate scientifically the safety and effectiveness of your device (Class III). Of course there are exceptions for specific devices.
The biggest cost are the clinical trials required for Class III devices. The next biggest cost is a toss up. Certainly implementing a quality system is not quick and easy. But the benefits in improved quality are their own rewards. The cost to get 510(k) approval for a medical device system is modest: often under $10,000 *if* you’ve already implemented your quality system and the product was developed following that system. If you have to “back fill” a quality system on a product that’s fully or partially developed, costs can meet or exceed the cost of implementing a quality system.
So, what does it cost to implement a quality system? Depending on the size of your company, and they types of products you manufacture, it can range from $100,000 to well over $500,000. These costs include an outside consultant, hiring or contracting a regulatory employee, and internal labor costs for meetings, training, etc.