IVD Technology Magazine
IVDT Article Index

Originally published November, 1997

The changing regulatory climate for blood establishments and their vendors

David F. Weeda, Stephen D. Terman, and Neil F. O'Flaherty

FDA's struggle to regulate device software could create headaches for vendors of blood and blood products—and for their customers.

With a single letter, FDA substantially changed the regulatory environment for blood establishments and their vendors of blood-bank software. Issued in 1994 by the agency's Center for Biologics Evaluation and Research (CBER), the letter states:

Facilities that manufacture and distribute these [blood-bank] software products are subject to the device provisions of the Federal Food, Drug, and Cosmetic Act [FD&C Act] and FDA's device regulations, including establishment registration, product listing, premarket notification or approval, current good manufacturing practices (CGMP), and adverse event reporting.¹

This sentence greatly increased FDA's regulatory control over blood-bank software. With it, CBER fully imposed medical device "general controls" upon these products and their vendors. More recently, in a legally questionable decision, FDA has required premarket submissions for, and applied its medical device quality system requirements to, certain blood-bank software developed internally by blood establishments for their own use.

The agency's regulatory oversight of blood-bank software has grown rapidly in a relatively short time, possibly outpacing the ability of blood establishments, vendors, and FDA itself to address it effectively. Although blood-bank software is regulated by CBER, clinical laboratory and other medical software (including components, accessories, and stand-alone devices) is regulated by the Center for Devices and Radiological Health (CDRH). Will clinical laboratory software be subjected to the same fate as blood-bank software? Time will tell as CDRH grapples with revising its current medical computer products policy.²

FDA's decision to apply device requirements to blood-bank software raises questions about the agency's expectations in this area of regulation. Some of the general controls traditionally used for medical devices do not apply neatly to blood-bank software, and the agency has not sufficiently elaborated on the requirements' application to it. Similar problems might occur with clinical laboratory software unless CDRH explains its expectations or limits the scope of the requirements' application. Blood establishments and vendors face many unanswered questions, placing them in the quandary of attempting to interpret what FDA requires. Clinical laboratories and their software vendors could face similar questions if CDRH is not thorough in its explanations.

This article will briefly discuss the history of FDA's regulation of blood-bank software and the present status of FDA policies in this area. It will also provide some insight into where FDA regulation of blood-bank and clinical laboratory software may be heading. Finally, it will discuss what the blood-bank software model may mean for clinical laboratory software.

History of FDA Regulation of Blood-Bank Software

As software technology has become increasingly prevalent in medical endeavors, including its use in blood establishments and clinical laboratories, FDA has asserted increasing regulatory control over it. Under the FD&C Act, FDA is responsible for the regulation of all medical devices manufactured, investigated, and marketed in the United States.³ A medical device, in relevant part, is defined under the FD&C Act as:

An instrument, apparatus, implement, machine, [or] contrivance . . . which is . . . (2) 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.⁴

This definition of medical device is broad enough to encompass medical software, including blood-bank and clinical laboratory software. Despite its apparent statutory authority, however, FDA did not pay particular attention to blood-bank software until the 1980s, when data integrity and problems sensitized the agency to safety and effectiveness concerns regarding such software. One case in particular heightened FDA's interest in actively regulating blood-bank software. It involved a prominent company that produced and distributed blood-bank software as part of its blood-bank and laboratory management system. FDA learned that program deficiencies in the software had led to inadvertent release and distribution of violative blood products for patient use, creating a public health risk. The incident led FDA to increasingly perceive defective blood-bank software as a threat to the nation's blood supply.

Until the 1990s, CBER regulated computerized blood-bank systems, including their software, as equipment. As regulated manufacturers, blood establishments were obligated to maintain such equipment as safe and effective under the drug and blood-product current good manufacturing practices (GMPs).^5,6

By FDA standards, the imposition of active regulation of blood-bank software as a device happened very quickly. As late as September 1992, CBER representatives stated that there was no need for blood-bank software vendors to comply with the medical device regulations. But in October 1993, a CBER guidance document sounded a different note:

Vendors who are developers that commercially distribute software intended for use by blood establishments should be aware of the federal regulations relating to the manufacture of blood and blood components. In addition, because blood-bank software products are devices, firms manufacturing and distributing such products must comply with statutory and regulatory requirements applicable to devices.⁷

With issuance of the CBER letter of 1994 quoted at the beginning of this article, there was no question the agency had decided to impose all medical device general controls upon blood-bank software vendors and their products. In addition, the agency has interpreted this to mean that blood establishments must comply with device quality system requirements even for computer systems developed internally for their own use. They must also file premarket notifications (510(k)s) or premarket approval (PMA) applications if the software for such systems is to travel interstate (even to an affiliate or satellite site) or if interstate electronic transfer of safety-critical data occurs.

Current Status of FDA Regulation

As outlined in its 1994 letter, CBER applies the following medical device general controls to blood-bank software vendors, requiring them to:

• Register as medical device establishments and list their products with the agency as devices.⁸

• Follow device good manufacturing practices (now quality system requirements).⁹

• File reports of certain adverse events involving their products under the medical device reporting (MDR) regulation.¹⁰

• File 510(k)s or PMA applications for their products.¹¹

Premarket notifications or PMAs for previously marketed blood-bank software products were due on March 31, 1996, unless CBER granted a filing extension. To date, the vast majority of such filings—if not all of them—have been 510(k) submissions. While it did not say so in the 1994 letter, the agency would also expect compliance with medical device labeling requirements.¹²

Guidances. In April 1996, CBER issued its "Reviewer Guidance for a Premarket Notification Submission for Blood Establishment Computer Software."¹³ This guidance discusses many issues related to blood-bank software, including proper labeling; submitting information on the product's design, development, and functional specifications; preparing a hazard analysis for the product; and supplying information on product verification, validation, and testing. The guidance is intended as a supplement to CDRH's "Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review," first issued in 1991.¹⁴

Besides recent guidance specific to blood-bank software, the agency has issued new draft guidances applicable to medical software generally. In the last year, CDRH has issued drafts of several software-related guidance documents that relate to blood-bank software, clinical laboratory software, and software used in in vitro diagnostic devices (e.g., software-controlled clinical analyzers). In September 1996, the device center released for comment its draft "Guidance for the Content of Premarket Submission for Medical Devices Containing Software."¹⁵ When finalized, it will replace the 1991 reviewer guidance. The new guidance is intended to apply to all types of premarket device submissions: 510(k)s, PMAs, and investigational device exemptions (IDEs). Among other things, the revision discusses the key data elements that FDA reviewers should look for in a premarket device software submission. It is also intended to further industry's understanding of FDA views on software engineering practices, quality, reliability, and safety, and especially to explain the agency's expectations for verification, validation, and testing of software devices.

Software-controlled clinical analyzers currently requiring 510(k) clearance are now subject to the 1991 guidance and will be subject to the new guidance when it is finalized. Moreover, since CBER's 510(k) guidance is a supplement to CDRH's 1991 guidance, CBER will most likely incorporate the revised guidance by reference. If CDRH calls for 510(k) submissions for all or a subset of stand-alone clinical laboratory software products, the new guidance would most likely also apply to them.

This past June 4, FDA distributed for comment a draft "Guidance for Off-the-Shelf Software Used in Medical Devices."¹⁶ When finalized, this document could affect blood-bank or clinical laboratory stand-alone software products as well as software-controlled IVD devices. Its purpose is to describe the information that should be provided in a medical device application involving off-the-shelf software. The agency states that "many of the principles outlined herein may [also] be helpful to device manufacturers in establishing design controls and validation plans for use of off-the-shelf software in their devices."

Most recently, on June 9, CDRH issued for comment a new draft guidance entitled "General Principles of Software Validation."¹⁷ The guidance is applicable to all medical device software, including blood-establishment software and software used to design, develop, or manufacture medical devices. It discusses how the general provisions of the quality system regulation apply to software, as well as the agency's current approach to evaluating a company's or establishment's software validation system.

Compliance Issues. Imposition of device controls on blood-bank software vendors significantly affects the regulatory landscape. If a vendor is noncompliant, the agency would view its software as adulterated or misbranded, making its distribution illegal under the FD&C Act.^18,19 The agency could possibly take enforcement action against the software, such as instituting a seizure of the product, an injunction against its use, or civil or criminal actions against those responsible for its manufacture and use.²⁰

Additionally, FDA has authority to issue an order requiring immediate cessation of distribution of a device it considers unsafe.²¹ Such orders also require immediate notification to relevant health professionals and user facilities, informing them of the order and directing them to stop using the device. Following an administrative hearing, the order can be upheld, amended to include a mandatory recall, or vacated. Thus, significant legal problems can result if FDA perceives that a particular blood-bank software product is violative under the FD&C Act.

Under the scenario described above, a blood establishment may be temporarily without use (or have only restricted use) of its software until the software vendor makes corrections. The establishment might even be forced to change to a new software product, suffering great business disruption and expense in the process. Even if the establishment could use the software in the interim, procurement and use of noncompliant software could leave a poor impression with the agency. IVD manufacturers that use human blood products sourced from blood banks as components in their products could find their component supply cut off or recalled as a result of such software problems.

510(k) Issues

As mentioned above, active regulation of blood-bank software comes with many unanswered questions, including premarket issues. Clinical laboratory software could face similar questions. In the area of 510(k) submissions, the role of programming bugs still needs further clarification by the agency.

Technically, a new 510(k) submission is required every time a legally marketed device is changed or modified in a way which could significantly affect its safety or effectiveness.²² This regulatory provision has often proved nebulous and difficult to apply, especially with regard to software changes. Recognizing this, FDA has published a guidance document attempting to better define when changes would or would not require the filing of a 510(k) submission.²³

Medical software products, such as blood-bank and clinical laboratory software, change continually to account for programming bugs as well as to reflect enhancements desired by customers. Addressing a bug or enhancement could be a change that the agency would view as raising new and significant safety or efficacy issues. It would not be unusual for a software vendor to make numerous product changes each year. In light of such numerous changes, an unmanageable number of 510(k)s could become necessary if the agency too conservatively defines what constitutes a significant software change. To what extent FDA will require 510(k) submissions for software bug fixes and enhancements is an open question. If it requires them too frequently, the results could be devastating for industry and the agency alike:

• Vendors would have to reallocate finite resources to prepare many 510(k) submissions for software changes. Such resource diversion could detrimentally affect day-to-day operations of blood establishments and clinical laboratories.

• Blood establishments and clinical laboratories would have to do without solutions to problems, or beneficial enhancements, until vendors obtained 510(k) clearance.

• FDA would bring upon itself an unmanageable number of 510(k) submissions which, given the agency's already stretched resources, could result in major time delays for 510(k) clearances.

Internally Developed Software

Blood establishments must also be cognizant of device controls when they are developing in-house software. In a highly controversial decision, CBER has announced that blood-bank software developed in-house at blood establishments is subject to medical device regulation, including when vendor-supplied systems are significantly modified by establishments after procurement. In addition to meeting drug and blood-product current GMPs, establishments developing such software are expected to comply with the applicable device quality system provisions, with special emphasis on design controls. This assumes no interstate movement of the software or interstate electronic transmission of safety-critical data, including, among other things, donor deferral/suitability, viral marker testing, compatibility testing, labeling, and product quarantine/release data.

Under current CBER policy, where internally developed software itself moves across state lines or where safety-critical data from the software system are electronically transmitted across state lines, the blood establishment would need premarket clearance for its software—even if the receiving site is an affiliated or satellite facility under the same corporate ownership. Some notable problems exist with this in-house blood-bank software policy:

• Relative to interstate transmission of data, it is inconsistent with the spirit and basic intent of the FD&C Act to regulate medical devices that themselves have not been shipped in interstate commerce. However, it must be noted that interstate shipment under the FD&C Act can be presumed for purposes of device enforcement actions.²⁴

• Under the FD&C Act, 510(k) requirements apply only when the device has been commercially distributed. CBER's policy appears to overlook the intracorporate transfer exception to commercial distribution.²⁵

• The policy appears somewhat at odds with FDA's current draft policy on the regulation of medical software products (including clinical laboratory software) as written by CDRH. Under CDRH policy, computer products manufactured by licensed practitioners for use in their practice are exempt from registration, listing, quality systems requirements, MDR obligations, and premarket review. The policy states that:

A medical institution where a computer product is developed will be treated similarly, provided that the product is intended only for use in that institution. This exemption applies only where there is no commercial distribution. For example, exchange of information on public "bulletin boards" would not result in a requirement for manufacturers of the software to register or list their devices.²

An apparent exception to the need for 510(k) clearance when safety-critical data travel across state lines electronically occurs when the following criteria are met: the user owns and controls the entire system (including software development and data loop); data movement does not alter the software database (e.g., satellite download to disk or read-only access); systems and controls are sufficient to identify inaccurate data and mitigate related risks; and system validation is sufficient to ensure process control and data integrity.

While current CDRH software policy does not control blood-bank software, CBER's in-house policy seems to create a potentially significant disparity between the treatment of medical software products generally (including clinical laboratory software) and blood-bank software specifically, to the detriment of the latter.

The Future of Software Regulation

CDRH is presently revising its medical computer products policy. It remains to be seen whether the device center will maintain its own position on the in-house development of software or adopt CBER's view. CDRH has stated that, at CBER's discretion, blood-bank software could be regulated under any revised device policy.

In the future, if CDRH maintains its present position and CBER follows any new CDRH software policy, internally developed blood-bank software may avoid full active regulation. Moreover, CDRH is considering means to reduce or eliminate the need for 510(k) submissions under its revised policy. If such means are instituted, blood-bank software might not require a 510(k) submission as a prerequisite to marketing.

However, if the device center adopts CBER's view, in-house clinical laboratory or other medical software could become subject to some or all of the medical device controls, despite a traditional lack of commercial distribution.

Conclusion

Obviously, FDA's active regulation of blood-bank software as a medical device raises many complex regulatory questions for blood establishments and blood-bank software vendors. In today's regulatory environment, blood establishments and commercial manufacturers must know what their regulatory obligations are in light of CBER's regulation of blood-bank software as a medical device.

Moreover, clinical laboratories and their vendors should monitor FDA regulatory developments regarding clinical laboratory and other medical software and account for possible increased regulatory scrutiny by FDA in their strategic planning.

References

1. Letter from Kathryn C. Zoon, director, FDA Center for Biologics Evaluation and Research (CBER), to blood-bank software developers and marketers, March 31, 1994.

2. "Policy for the Regulation of Computer Products," Rockville, MD, FDA, Center for Devices and Radiological Health (CDRH) 1989.

3. 21 USC 301 et seq.

4. 21 USC 321(h).

5. Memorandum from Paul D. Parkman, director, FDA's CBER, to blood establishments, September 8, 1989.

6. Code of Federal Regulations, 21 CFR 210, 211, and 606.

7. "Draft Guideline for the Validation of Blood Establishment Computer Systems," Rockville, MD, FDA, CBER, p 7, 1993.

8. 21 CFR 807.

9. 21 CFR 820.

10. 21 CFR 803.

11. 21 CFR 807 and 814.

12. 21 CFR 801.

13. "Review Guidance for a Premarket Notification Submission for Blood Establishment Computer Software," Rockville, MD, FDA, CBER, 1996.

14. "Reviewer Guidance for Computer-Controlled Medical Devices Undergoing 510(k) Review," Rockville, MD, FDA, CDRH, 1991.

15. "Guidance for the Content of Premarket Submission for Medical Devices Containing Software," Rockville, MD, FDA, CDRH, Office of Device Evaluation (ODE), 1996.

16. "Guidance for Off-the-Shelf Software Used in Medical Devices," Rockville, MD, FDA, CDRH, ODE, 1997.

17. "General Principles of Software Validation," Rockville, MD, FDA, CDRH, Office of Compliance, 1997.

18. 21 USC 351 and 352.

19. 21 USC 331(a).

20. 21 USC 332, 333(a) and (b), and 334.

21. 21 USC 360h(e)(1).

22. 21 CFR 807.81(a)(3).

23. "Deciding When to Submit a New 510(k) for a Change to an Existing Device," Rockville, MD, FDA, CDRH, ODE, 1997.

24. 21 USC 379a.

25. 21 CFR 807.3(b)(1).

David F. Weeda, Stephen D. Terman, and Neil F. O'Flaherty are partners in the law firm of Olsson, Frank and Weeda (Washington, DC).