Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.Read More
Some time ago Tim Gee pointed out that a major vendor for an in hospital communication system included the following statement in its documentation:
“This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.”
Of course “primary communication” was exactly why the product was being purchased, and arguably what it was being sold for.
When discussing Clinical Decision Support (CDS) (here) I have pointed that it is common for CDS creators to in essence say that one should not rely on the output of the product, but instead always second guess the advice provided. This perhaps approaches a warning that I proposed for a product that I thought was seriously defective: DO NOT USE THIS PRODUCT. Maybe I was being facetious.
These examples may pale in comparison to the following disclaimer for medical image processing software:Read More
On July 21, 2011 the FDA released its “Draft Guidance for Industry and Food and Drug Administration Staff – Mobile Medical Application.” We have discussed this draft and mobile apps generally here, here, and here. As with all draft guidance documents, following the release of the draft the FDA is supposed to receive and review comments (reported to be about 130), and then issue a revised draft, a final guidance document, withdraw the draft, or do none of these for an extended period, just letting the draft sit. The latter appears to be the fate of many drafts. The two years that this draft has been out probably qualifies as an extended period. However the FDA did tell Congress, and the public, that the guidance would be released by the end of this fiscal year. Outsiders cannot tell if the appropriate FDA people are hard at work on this item, or if they are distracted in part by other issues. The FDA’s claimed devotion to transparency does not include being able to see how such things are progressing.Read More
The FDA has issued a draft guidance document on the expected content of premarket submissions with respect to medical device cybersecurity. This guidance targets individual medical devices rather than the network they may be resident on, and it also includes non-networked devices. The FDA notes that both networking capability and portable media increase vulnerability. The latter issue might be called intermittent or remote connectivity.
Guidance documents tell interested people what the FDA’s current thinking is relevant to its regulatory authority, in this case the review of 510(k), PMA and related submissions. A draft guidance is in effect what the FDA is thinking about thinking. Drafts go through a comment period (90 days in this case) after which the FDA contemplates the comments and, after an unspecified time, either issues a guidance document, issues a revised draft, withdraws the draft, or just lets it sit there. Since guidance documents are not requirements, there is standard language that you can use an alternate approach if you can justify it. An open question for me is whether even a draft sufficiently establishes an FDA expectation that should be followed in the interest of a smooth submission review.There are many draft guidances currently under comment or post-comment review, including the long awaited guidance on medical apps discussed here.Read More
There are currently several private entities that seek to certify medical apps, connectivity solutions, EHR record exchange, and other products, services and people in our sphere of interest. Given the ongoing proliferation of private certifications, there is a growing need to evaluate them, judge their relative costs and benefits, and determine which – if any – are worth adopting as either the one certified or as the consumer of certified products or services.
These private activities are usually distinct from governmental requirements (e.g. FDA or FTC compliance, or state licensing), although in the case of EHR Meaningful Use (MU) certification, private entities function on behalf of the federal government to certify compliant EHRs. Note here that compliant EHRs are those that are capable of achieving MU. Purchasing a product that is thus certified is a prerequisite for a provider then achieving MU.Read More