The Health Law Resource

Copyright 1996 William L. Manning, except where noted. All rights reserved.

Food And Drug Administration & National Library of Medicine

Software Policy Workshop

September 3 and 4, 1996

Reprinted below are handouts prepared by the FDA for the workshop participants. Medical device manufacturers, government managers, software industry representatives, health care workers and attorneys attended this workshop to discuss the FDA's role in regulating software applications as a medical device. Although it is clear that software which is designed for or impacts patient care is a medical device subject to regulation by the FDA, it is unclear exactly how to effectively regulate the myriad technologies and software developed for patient diagnosis and treatment. The materials below present background on the FDA's general role viz. medical devices and raise questions for workshop participants relating to:
  1. Risk Classifications and the attendant regulatory mechanisms
  2. Commercial distribution of software, and
  3. Software Quality Audits as an alternative regulatory mechanism

Download the FDA materials in ASCII text format

Background and Topics for Discussion in Breakout Sessions

1. FDA Regulation of Medical Software (Background)
2. Classification and Risk-based Criteria
3. Commercial Distribution
4. An Alternative to Current Premarket Notification (Software Quality Audit)

Warning: This paper and these discussion topics have been prepared to aid participants in considering, discussing, and providing input on issues relating to the regulation of medical software. This document does not reflect FDA or CDRH policy and does not indicate or suggest any position or approach that will be taken in the future.

FDA REGULATION OF MEDICAL DEVICE SOFTWARE

Purpose

The purpose of this section is to describe the regulatory framework within which medical software is currently regulated, and to promote discussion of possible changes to the Food and Drug Administration's (FDA) regulation or control of medical devices employing software.

Background

Development of an FDA software policy began in 1985. In September 1986, then FDA Commissioner Frank Young noted in a speech that FDA's policy toward software would be the "least regulation consistent with the requirements of public health and safety." A written draft policy was developed in 1987, and was revised in November 1989. FDA has operated within the framework of that draft policy for the past seven years. During that time, medical software has become increasingly complex, and prevalent in many medical devices. In addition, many manufacturers, health care practitioners, and FDA staff have misunderstood or misinterpreted the provisions and exemptions in the 1989 draft software policy. The regulatory framework proposed seven years ago needs to be re-examined and revised.

Medical Device Definition and Regulatory Requirements

A [medical] device is any "instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is ... intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease ... or intended to affect the structure or any function of the body..." [Ref: Section 201(h) of the Federal Food, Drug and Cosmetic Act (Act)].

Software which meets this definition is (by law) a device subject to applicable FDA medical device regulations (Code of Federal Regulations, Title 2 1, Parts 800 - 895). Software can be a device by itself (standalone), or it can be incorporated into another device (as a component or part), or distributed separately for use (as an accessory to) with another device. A device software component or a software accessory to a device is itself also a device, and the software is subject to applicable FDA device regulations. Unless otherwise separately classified, FDA regulates components and/or accessories in the same way and to the same degree as the parent device.

Non-devices and Exemptions from Active Regulation

The FDA's device regulations and authorities do not apply to:

In addition, a number of medical software devices are currently exempt (by regulation) from most of the general controls under the Act, except for prohibitions against adulteration and misbranding. These exempted software products include:

  1. General purpose software (e.g., spreadsheet, database and word processing software) intended for broad general use (which could include medical practice), as long as it is not labeled or promoted for medical use (21 CFR 807.65(c)).
  2. Software manufactured or altered by a medical practitioner solely for use in his/her own practice (21 CFR 807.65(d)),
  3. Software solely for use in non-clinical research, teaching and analysis (21 CFR 807.65(f)). This exemption applies to research and development efforts that have not progressed to the stage of human experimentation.

Unless their software is specifically exempted, device manufacturers must comply with all applicable requirements of the Act, including but not limited to: registration of the device establishment, listing the device, premarket submissions, designing and producing devices under good manufacturing practices (GMP), reporting device adverse events through Medical Device Reporting (MDR), and other prohibitions against adulteration or misbranding of the device. For example, 21 CFR 807.20(a)(5) specifically requires establishment registration and device listing by any person who "manufactures components or accessories which are ready to be used for any health-related purpose and are packaged or labeled for commercial distribution for suchhealth-relatedpurpose." Further (except as provided under 21 CFR 807.81(b) and 807.85), section 807.81(a) requires that any person who must register, must also submit a premarket notification to the FDA and receive a substantially equivalent determination from the agency, prior to commercial distribution of the device in interstate commerce.

Software as a Component

A software component is "any ... software ... which is intended to be included as part of the finished, packaged and labeled device." [Ref: July 1995, Working Draft of the CGMP Final Rule]. Most of the medical device software in use by health care practitioners is incorporated into medical devices as software components. Software is frequently incorporated as a component of an ever-increasing number of devices, including:

- infusion pumps,
- pacemakers,
- ventilators,
- magnetic resonance imaging devices,
- diagnostic x-ray systems,
- clinical laboratory instruments,
- blood grouping instruments,

and many others. Such software and associated software development practices are actively regulated, and are evaluated by FDA in the course of evaluating the parent device.

Software as an Accessory

A software accessory, on the other hand, is a software "unit which is intended to be attached to or used in conjunction with another finished device, although an accessory may be sold or promoted as an independent unit." [Ref: FDA publication # 92-4173, entitled: Everything You Always Wanted to Know About Medical Device Requirements...,] Software accessories are typically marketed as finished devices, and may or may not be marketed by the same manufacturer who produces the device(s) with which the accessory is used. Software accessories and their associated software development practices are frequently evaluated by FDA separately from the evaluation of the parent device.

In determining whether software is an accessory, FDA has looked at several factors to determine intended use: Is the software specified or otherwise intended for use with a classified device? Is the software directly interfaced with another device for transfer of data to and from the other device? If the answer to either of these questions is "Yes", FDA has generally ruled that the software is an accessory, subject to the same level of regulation as the parent device. A few examples of such actively regulated accessories include software for:

- radiation treatment planning,
- conversion of pacemaker telemetry data,
- conversion, transmission or storage of medical images,
- off-line analysis of EEG data,
- digital analysis and graphical presentation of EEG data,
- calculation of rate response for a cardiac pacemaker,
- perfusion calculations for cardiopulmonary bypass,
- calculation of bone fracture risk from bone densitometry data,
- statistical analysis of pulse oximetry data, and
- calculation of refractive power of intraocular lenses.

For some software accessories, the inherent risk of the software product is significantly less than that of the parent device. For example, a calculator programmed to automate simple calculations used with a Class III device might not itself pose a risk that would warrant a premarket approval application.

In other cases, the software may introduce new capabilities for a device for which there may be no predicate device. In such cases, premarket approval and/or clinical data may be needed to prove the safety and efficacy of the new device application.

Standalone Software and Competent Human Intervention

A standalone medical software device is medical software which is neither a component nor an accessory to another device, and which is intended to receive medically related data as input, and to output (relay) the results to a health care practitioner or other user. A few examples of standalone software include:

- blood bank software systems which control donor deferrals and release of blood products,
- software designed to assist a health care practitioner in arriving at a diagnosis of a particular patient,
- software which analyzes for potential therapeutic interventions for a particular patient,
- software which records medical information for later recall, analysis, or action by a health care practitioner (e.g., hospital information systems, prescription ordering and drug interaction information systems, emergency room triage software, and various calculators which automate calculations of drug doses).

For the past seven years, certain standalone software has been excluded from active regulation. The draft "FDA Policy for the Regulation of Computer Products", dated November 13, 1989, was intended to exempt certain unclassified software products from active regulation. One of the most frequently misunderstood aspects of the 1989 draft policy is that "Previously unclassified information management products ... such as expert or knowledge based systems, artificial intelligence and other types of decision support systems intended to involve competent human intervention before any impact on human health occurs" were proposed to be exempted from active regulation. Numerous manufacturers and their attorneys have seized upon the term "competent human intervention" and argued that their medical software is exempt from active regulation. However, in the vast majority of cases that have come to FDA's attention, this exemption was not applicable because the device was, in fact, an accessory to a classified device, and therefore subject to the same level of regulatory control as that parent device. Manufacturers and others have been advised that for software that is determined to be an accessory to a device, competent human intervention is not a factor in the regulatory decision. This position has not been well understood or accepted by some software device manufacturers, and in a few cases has resulted in Agency regulatory action.

The issue of what constitutes competent human intervention has also become increasingly complex and difficult to administer. For the relatively few standalone software devices that are not accessories, it is sometimes difficult to establish that there is competent human intervention. For software which simply automates a complex calculation, competent human intervention can be achieved by providing the algorithm to the user to allow for manual verification or challenge of the software results. Expert software which assists in disease diagnosis can provide decision criteria, Bayesian decision trees, or text references by which the decision support software reaches its recommendations. 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. For example, surgery or intensive care may not be settings wherein there is adequate time to challenge the results of decision support software. Moreover, medical software is becoming increasingly complex, such that it is frequently questionable whether a practitioner can reasonably exercise competent human intervention. For example, neural networks provide no simple algorithms that can be examined and easily understood by the user. These and other factors are reasons to re-examine FDA's criteria for exemption of software from active regulation.

Questions and Considerations for Future Software Policy

  1. What is the best approach for future regulation of standalone (software only) systems, while still providing the needed degree of public health protection?
  2. To what degree do new GMP design control requirements mitigate the need for 510(k) submissions for standalone and accessory software devices?
  3. Are the above referenced definitions of standalone and accessory software accurate, and if not, how should they be changed?
  4. Which modules of hospital information systems (e.g., PACS interfaces, prescription ordering systems, blood banking, laboratory interfaces, etc.) should be regulated and at what level?
  5. Which modules of laboratory information systems should be actively regulated?
  6. What are reasonable criteria for replacement of competent human intervention, in determining which software devices do or do not need to be actively regulated and reviewed by FDA prior to marketing?
  7. What standalone software should be classified/reclassified based on its own level of risk?
  8. What software device accessories should be classified/reclassified based on their own level of risk as opposed to the level of risk of the parent device?

CLASSIFICATION AND RISK-BASED CRITERIA

I. Introduction

The Medical Device Amendments of 1976 and the Safe Medical Devices Act of 1990 (SMDA) base the classification and reclassification of pre-Amendments devices upon the level of regulatory control necessary to provide a reasonable assurance that a device is safe and effective for its intended use. The Act establishes three classes of devices.

A. Types of Medical Device Classification

Section 513(a) of the Federal Food, Drug, and Cosmetic Act, (the Act) describes the following classification scheme for medical devices.

Class I includes devices for which general controls alone are sufficient to provide reasonable assurance of safety and effectiveness for their intended use. General controls include Good Manufacturing Practices (GMP's), registration and listing, premarket notification (or 510(k)) submissions, record-keeping, restrictions as to use, sale or distribution, prohibition of adulterated or misbranded devices, and prohibition of banned devices. Class I devices are subject to premarket notification requirements unless exempt. Class I devices can be classified exempt from the premarket notification process or the GMP requirements if they meet the following criteria:

  1. No significant history of false or misleading claims;
  2. No significant history of risks;
  3. Characteristics of device necessary for safety and effectiveness are well established; and;
  4. Anticipated changes that could affect safety and effectiveness are readily detectable visually or by routine testing, do not materially increase risk of injury, incorrect diagnosis, or ineffective treatment, and are not likely to result in a change in classification.

Class II includes devices for which general controls by themselves are insufficient to provide reasonable assurance of the safety and effectiveness of the device, and for which there is sufficient information to establish special controls including performance standards, postmarket surveillance, patient registries, guidelines (including guidelines for the submission of clinical data in premarket notification submissions, known as 510(k)s), recommendations, user checklists, specific labeling, and other appropriate actions. Class II devices are subject to premarket notification requirements.

Class III devices, which require premarket approval applications are devices for which insufficient information exists to assure that general controls (Class I) and special controls (Class II) provide reasonable assurance of safety and effectiveness, that are represented to be life sustaining or life supporting, or for a use which is of substantial importance in preventing impairment of human health or that present a potential unreasonable risk of illness or in injury. New post-amendment devices, which cannot be found "substantially equivalent" to a legally marketed device are automatically placed in class III by section 513(f) of the Act.

B. Classification procedures

FDA has been given the authority to classify preamendments devices according to section 513(a) of the Act. The Act states that devices should be classified in the class with the lowest level of control that will provide a reasonable assurance of the safety and effectiveness of the device. An advisory panel recommendation is required for the initial classification of a device. The agency publishes a proposed rule to classify in the Federal Register which includes the scientific justification to support the proposed classification, serves as notice and affords a period for comment. Subsequently a final rule is published in the Federal Register to effect the classification.

C. Reclassification Procedures

As experience and knowledge about a device increase, the original classification can be adjusted via the process of reclassification. Section 513(f) of the Act provides FDA with the authority to reclassify post-amendment devices. Reclassification under section 513(f) can be initiated by FDA or by a reclassification petition. Section 5139f) provides FDA with the option, but not the requirement, to obtain an advisory panel recommendation for reclassification. Again the FDA publishes a proposed rule to reclassify in the Federal Register which includes the scientific justification for reclassification and which affords a period for comment. Subsequently a final rule is published in the Federal Register to effect the reclassification.

II. Alternatives to Classification

A. Not a Device or a General Purpose Device

Not all software used in medical facilities will be subject to classification by the FDA. Some software programs may be considered either "not a device" or as a "general purpose device". FDA does not extend regulatory authority over an item that is considered not a device. "General purpose" devices are items which although they may have direct medical application actually are designed for a broad spectrum of uses, medical use only being one of thern. General purpose devices are those whose use is generally known by people trained or instructed in its use and are not specifically labeled or promoted solely for medical use. General purpose devices are exempt from the registration regulations (21 CFR 807.65(c)). This exemption results in a general purpose device not being subject to the premarket notification requirements. The provisions of the Act concerning adulteration, misbranding and medical device reporting do, however apply to these items. Some examples of what will qualify for one of these two categories are:

Programs that regulate and control computer hardware and are not specifically designed for medical applications are not considered to be devices. Such programs could include operating systems and utilities for managing files or backup operations.

General purpose devices could include off-the-shelf word processing, spreadsheet and database programs which are not designed solely for medical applications. Templates, database forms, or letterheads designed using the applications included in the original general purpose software programs that are applied to medical use and intended for the use of its owner or employees/coworkers/managers of the owner could also be considered general purpose.

B. Other Federal Agencies

In situations in which an item is jointly regulated by the FDA and another Federal agency, FDA may defer authority over that item to the other agency when it determines the safety and effectiveness of the product can be assured.

III. Some Possible Criteria for assigning risk to medical software devices

Classification or reclassification requires the identification of the risks presented by a device and the designation of controls if possible, to mitigate those risks. Additional risks and examples that are brought to FDA's attention at this Workshop will contribute to a more efficient classification process. Intended use, conditions of use, the population for which the device is intended an impact to health must be considered in identifying the potential risks of the device.

In an effort to develop some criteria that might be useful for assigning measures of risk to public health, agency representatives contacted and spoke with representatives of a number of professional organizations whose members either use or develop medical software devices. These organizations included the American Medical Association, the National Medical Association, the American Hospital Association, the Society for Critical Care Medicine, the American College of Radiology, the Society of Nuclear Medicine, and the American Medical Informatics Association. In addition, FDA staff have spoken at professional and industry forums discussing the regulation of medical software devices and eliciting suggestions for criteria to be used in associating a risk factor to a medical software device. The result of these discussions is summarized in the criteria listed below:

  1. The seriousness of the particular disease or condition which the medical software device is intended to diagnose, cure, mitigate, treat or prevent and how the software contributes to the user's decision-making for diagnosis or clinical management of the patient.
    Example: Is it software designed to call attention to imminent hazard conditions in an ICU or is it software that provides long-term storage for diagnostic radiologic information ?
  2. The amount of time available before using the information provided by the medical software device, i.e., the time until a therapeutic or additional diagnostic intervention must be implemented by the health care provider after the results of the software have been provided.
    Example: Is the device an EKG reading and analysis package whose output is "SHOCK NOW" or does it provide a proposed reading with notation that the rhythm itself should be checked?
  3. Whether the data output is provided or manipulated in a novel or non-traditional manner, or whether decision trees within the software depart from customary use.
    Example: Do the system's algorithms, parameters, internal decision trees, or other output manipulations depart from customary use or traditional data presentation?
  4. Whether the medical software device provides individualized patient care recommendations, e.g., whether the software suggests or recommends specific treatment for a specific patient.
    Example: How specific is the software output with regard to particular patients? Is the software providing general advice or information, like a library, article, or textbook, or is the software designed to provide a specific recommendation for a specific patient whose individual data have been entered as input?
  5. Whether the mechanism by which the medical software device arrives at a decision is hidden or transparent,, i.e., does the product use undisclosed parameters or internal decision trees or other mechanisms that are not available for review by the health care provider.
    Example: How transparent is the software manipulation to the intended user community? Included in transparency is the extent to which limitations on the process are made known to the user, such as data contraction, deletion, editing, or simplification. Also, how are comparisons made to normative databases and how are normative databases created?
  6. Does the product provide new capabilities for the user ? Although the above criteria should aid in a determination of potential patient risk, the agency has not yet determined how to apply them in an objective and consistent way. Several issues remain to be addressed before trying to use these criteria to classify medical software devices. The agency would therefore like to pose here those issues for comment and suggestions.
  7. Are the criteria necessary to assess risk? That is, are all of the criteria pertinent to the task of assessing risk? Also, are there any redundancies in the criteria that need to be removed before applying them?
  8. Are the criteria sufficient to assess risk? That is, are there additional criteria that should be used? For example, how could the seriousness of disease or condition be determined?
  9. How exactly should the criteria be combined in a model whose output is the potential risk to the patient?

COMMERCIAL DISTRIBUTION

Background

Computer software intended for use in the course of medical diagnosis, treatment, or prevention is a device within the meaning of Section 201(h) of the Food, Drug and Cosmetic Act (the Act) [21 U.S.C. 321(h)] which states that a device is:
"...an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is ... 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..."
For a software product to fall within the meaning of this definition, it is sufficient that it is intended to be used in the process of diagnosing, preventing, or treating medical conditions, and it is not necessary that the software actually make or recommend a final diagnosis.

Software products, which may eventually become medical devices, may be shared between users or developers, similarly to the sharing of research results in the form of preprints of articles or informal status reports. Such sharing of software provides all the benefits of the sharing of research results that accrue from other scientific/technical endeavors and should be encouraged. The problem that FDA faces is that once a software entity makes the transition from a product of research to a device, i.e., it begins to undergo testing prior to marketing, regulatory controls must take effect. The difficulty lies in drawing a distinction between software that is a product of research and software that is a device intended for marketing.

In trying to draw a clear distinction, FDA needs to use objective criteria. Two such criteria are the intended use of the software entity and whether any evidence exists to suggest that commercial distribution of a finished product is intended. Note that, in evaluating intended use, FDA considers all factors surrounding the software's promotion and distribution, including labeling claims, advertising material, and oral or written statements as well as its actual use. Note also that commercial distribution does not require that a device or other regulated article be sold. All articles held for purposes other than for personal consumption are deemed held "for sale" under the Act.

Distribution of Software as a Product of Research

Establishments or individuals with research and development efforts that have not progressed to the stage of human experimentation are not viewed as device manufacturers. This may also apply to an individual researcher who distributes software as a product of research. The difficulty that FDA faces is determining the intent of the individual distributing the software. One objective piece of evidence for evaluating whether a software product is intended for distribution as a medical device or as a product of research is whether the distributed software is in executable or source code format. The rationale for this distinction is that source code is not readily usable on any computer unless it is translated into executable code. It is also capable of being changed by the user for further research and development. Software in source code format could be viewed as being analogous to a set of specifications and not a "finished device." Software distributed in source code may be more analogous to research results distributed as a preprint.

On the other hand, software distributed in executable code is more like a finished device. It can be run on computers with no translation or further action on the part of the user except perhaps minor adjustment of the computer operating systems or interfaces. Thus, software that is in executable code format has greater likelihood of being intended for diagnostic, therapeutic, or investigational use in humans or animals and would be a device within the meaning of the Act. Any distribution of such finished device software outside an establishment, with or without payment, would constitute commercial distribution of a finished device. For example, an organization that develops and distributes that device to multiple establishments, whether or not corporately linked, is a manufacturer subject to full regulation under the Act. It has also been argued that software used to transmit certain types of data used in the diagnosis or prevention of disease would also be subject to regulatory controls.

Using the above arguments, software in the form of source code might not be viewed as a finished medical device. It requires further action by the user before it can be used as a medical device for purposes including but not limited to diagnostic, therapeutic, or investigational use on humans. Therefore distribution of software in source code format rather than executable code would not be considered distribution of a finished medical device. Dissemination in source code could occur then in a variety of ways, including publication as an appendix to an article or reprints of such an article, distribution of computer disks, or display over the Internet.

In addition to the foregoing, the Agency considers whether the device is being commercially distributed in exchange for an express or implied payment in determining whether software is objectively intended to be used as a device. Determining whether there is an express or implied payment can be a difficult matter. Generally speaking, however, if software source code is disseminated at no cost beyond the cost of the media, postage, and handling, the free distribution would be only one piece of objective evidence in evaluating whether the software is intended for educational or research purposes or intended for distribution as a device.

Questions and Considerations

  1. Does the distinction between source code and executable code work well in establishing when a finished device exists and thus when regulatory control must be exercised?
  2. What should FDA's role be in devices that are intended to transmit electronic data for medical purposes? Should FDA's role differ when the intended use of the data is diagnosis as opposed to prevention of disease?

AN ALTERNATIVE TO CURRENT PREMARKET NOTIFICATION (SOFTWARE QUALITY AUDIT)

Introduction

Any product that fits the definition of a medical device must meet all applicable requirements of the U.S. Federal Food, Drug, and Cosmetic Act (the Act), unless specifically exempted by regulation. This means, in particular, that all medical software devices are subject to premarket notification (510(k)) and good manufacturing practices regulations (GMPs), unless specifically exempted by regulation.

Background

It is well known that final-stage testing of software is ineffective at demonstrating that the software is free from errors and safely can accomplish its intended purpose. Because of this, software engineering practices have been established for developing software that seek to minimize the number of errors designed into the product. Such software development models or processes are generally accepted as being necessary for assuring the safety of any type of software product. Current FDA guidance on premarket notification for devices containing software (Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review, August 29, 1991) recognizes this fact and outlines an appropriate premarket notification as a description of the software development process and its application to the device in question.

For many medical software devices that would be subject to premarket notification, the content of that notification would be primarily just the description of the software development process employed and documentation of how that process was applied to the specific device as described in the above mentioned guidance. Because of this, it may be possible that for such devices the Agency could rely on independent certification of the process and its application to the device in question as all or part of the 510(k) for the device, or even in place of a 510(k) for the device.

This certification would be, in effect, a "special control" established for medical software devices. A convenient term for this certification is a "Software Quality Audit" (SQA). The SQA would be a critical review of the software quality assurance system, performed by a qualified and independent third-party quality auditor, to provide documentary evidence that a particular medical software device was developed in accordance with appropriate industry standards or according to a recognized quality process, specification, and procedure established by the developer.

Two possibilities exist for use of such a certification. First, the Agency could regard an SQA-certified software product as having met all applicable 510(k) requirements and accept the auditor's certification as the technical portion of the submission required by Section 510(k). A second possibility would be to allow the use of this special control in lieu of a 510(k) submission. In either case, the medical software device would still be subject to all applicable general controls such as registration and listing, GMPs, etc.

The intent of the SQA process would be to reduce or eliminate unnecessary paperwork for both the agency and the device manufacturers and, thereby, allow more rapid introduction of products, without compromising the safety and effectiveness of medical software devices. Details such as how the SQA would fit into the existing regulatory scheme, what it should consist of, and how the agency should qualify independent certifying bodies to perform SQAs have not yet been established.

The purpose of this paper is not to propose the S QA as a replacement for the 510(k) but to initiate a discussion among FDA, industry and other concerned parties as to how the SQA might be defined, what problems might occur if it were to be used as part or all of the 510(k), and how these problems might be overcome. The following are some of the issues that the agency has identified so far in considering the use of the SQA as part of the 510(k) process.

Issues Pertinent to SQA

  1. What should be the components of an SQA? Is it merely a paper review of the software development process? How prescriptive should FDA be in defining the content of an SQA?
  2. Should the SQA be device-specific? The SQA is at least a measure of whether an adequate software development system is in place. Should the SQA be completed for each device that is to be marketed?
  3. Should the SQA be an option or an requirement? That is, can a manufacturer choose to file a full 510(k) and have FDA review it instead of seeking an independent SQA certification? If the manufacturer has such a choice, will there be sufficient incentive for manufacturers to utilize the SQA alternative?
  4. Most quality audits are performed on a periodic basis. Should the same be necessary for an SQA?
  5. How will the agency accredit third-party certifiers? Should FDA be the accreditor or a private sector organization? If a private sector accreditation body, what level of oversight should FDA provide? How should conflicts between certifier and device manufacturer be resolved?

Explore these relevant links:

Comments, questions, errata, submissions, E-mail William L. Manning, Esq.

Back to the Health Law Resource