The data are entered manually; they are not inputted directly from any machine that touches the patient or a patient specimen. That’s important to avoid becoming an accessory to a medical device.
Depending on how inputted, the output amounts simply to providing the stored data back to the patient or professional. The system does not automatically guide the diagnosis, nor does it guide any other instrument. In other words the software does not contain any algorithms that provide clinical-like functions that go beyond what FDA often refers to as library functions. It merely displays the data for the user to read and interpret.
Many mobile device apps do indeed fit this category of unregulated software. But it is important to remember to conduct an honest evaluation of the intended use of your product. The evaluation should focus on the clinical intended use of the product and less on the technical characteristics of your software or your system. In FDA’s eyes, your software product does not have to provide a complete cure, mitigation, treatment, or prevention of disease to meet the legal definition of a device. If your software is intended to provide any part of cure, mitigation, treatment, or prevention of disease, FDA will probably consider it a device. Understanding the limits on the unregulated category is probably best explained, though, by looking at the other two categories.
Regulated Software Exempt from Premarket Clearance
Since the late 1980s, FDA has been publicly declaring that there exists a category of software that technically qualifies as a medical device but for which FDA has no intention of requiring the submission of a premarket notification or approval application. For those who are really interested in this topic, it probably makes the most sense to start with the “FDA Policy for the Regulation of Computer Products, 11/13/89 Draft”.
In that policy, there are two categories of software products that were technically regulated but also considered exempt from the major requirements: (1) general purpose articles as defined in a regulation and (2) software that involves competent human intervention. Unfortunately FDA never got around to actually codifying the competent human intervention exemption. In its classification process, FDA has adopted certain general purpose or low risk exemptions that cover software, such as laboratory information management systems (LIMS) (21 CFR 862.2100) used as calculators or data processing modules for clinical use.
About 7 years after FDA published the 1989 draft policy, it appeared FDA was moving toward formalizing its computer product policy. In addition to publicly announcing that intention, FDA hosted a large meeting in Washington and invited many stakeholders to discuss what the policy should be. In preparing for that meeting, FDA drafted a summary of what it considered to be its then existing policy on computer products. Those workshop materials explained that much of the software the agency was seeing constituted accessories to medical devices, and the competent human intervention concept was only intended to apply to truly standalone software. The agency also argued that the concept of what constitutes competent human intervention had become increasingly complex and difficult to administer. FDA observed:
In general, to permit competent human intervention, the software decision process must be completely clear to the user, with a reasonable opportunity for challenging the results. There must also be adequate time available for reflection on the results.
But again, FDA never followed through to adopt a new regulation or policy.
Navigation: ( ←Previous | 1 2 3 4 5 6 7 | Next→ )