This is all in the public record, so I have no problem providing the specifics.
The letter, dated May 29, 2009, is addressed to UltraRad Corporation, a provider of picture archiving and communication systems (PACS). PACS are regulated by FDA as medical devices, because they are "intended for use in the diagnosis of disease or other conditions or in the cure, mitigation, treatment, or prevention of disease, or is intended to affect the structure or function of the body." As a medical device, UtraRad's products must comply with the Quality System Regulation (21 CFR Part 820) or QSR for short.
The Violation
FDA's warning letter, based on an inspection carried out in February and March of this year, points to a number of violations of the QSR. From the perspective of enterprise software, however, the most interesting citation is the one concerning software validation:
4. Failure to validate computer software for its intended use according to an established protocol when computers or automated data processing systems are used as part of production or the quality system as required by 21 CFR § 820.70(i). This was a repeat violation from a previous FDA-483 that was issued to your firm. For example:Implications for ITA) Your firm uses off-the-shelf software (HEAT Help Desk) to manage customer support service calls and to maintain customer site configuration information; however, your firm failed to adequately validate this software in order to ensure that it will perform as intended in its chosen application. Specifically. your firm's validation did not ensure that the details screen was functioning properly as intended. The details screen is used to capture complaint details and complaint follow-up information which would include corrective and preventative actions performed by your firm when service calls are determined to be CAPA issues.
B) Off-the-shelf software (Microsoft SharePoint) is being used by your firm to manage your quality system documents for document control and approval. However, your firm has failed to adequately validate this software to ensure that it meets your needs and intended uses. Specifically. at the time of this inspection there were two different versions of your CAPA & Customer Complaint procedure, SOP-200-104; however, no revision history was provided on the SharePoint document history. Your firm has failed to validate the SharePoint software to meet your needs for maintaining document control and versioning.
Note that the two software packages--HEAT and Sharepoint--are widely implemented across various industries. HEAT, from Front Range Solutions, is a commonly-used system for help desk support. Sharepoint, of course, is Microsoft's collaboration and content management server. Neither of these systems are specific to the medical device industry. As such, IT professionals--especially those without a background in regulatory affairs--may not recognize the risk they incur when implementing these systems in a regulated environment. In fact, the software vendors themselves may be unfamiliar with the compliance needs of their customers in regulated industries.
One common misunderstanding is that the customer's responsibility for compliance can be met by the vendor somehow "validating" its software. Vendor claims notwithstanding, vendors cannot sell you "compliant software" or "FDA validated software." Terms like this in vendor marketing literature should be a red flag that the vendor does not have a clue.
Technically, it is not the software itself that is validated, it is the software in its intended use that should be validated. One customer may be using the software in a way that is altogether inappropriate in a regulated environment, while another customer may be using the software in a way that fits its intended use. Although a software vendor can support its customers' compliance--by providing evidence of software quality, for example--ultimately it is the responsibility of the user of the system to ensure that the system itself, and how it is implemented and used, are appropriate. UltraRad, according to the FDA warning letter, failed to do so.
FDA warning letters citing failure to validate commercial off-the-shelf software (COTS) are not an everyday occurrence. This one, which so clearly cites this violation is a good reminder of the responsibility of regulated organizations that implement such systems.
For more guidance on this subject, see Validation of Software for Regulated Processes (TIR-36) from the Association for the Advancement of Medical Instrumentation (AAMI). I served on the AAMI committee that wrote this report in 2007, and it provides a good overview and recommendations to industry on an approach to comply with FDA regulations for these types of systems.
Related posts
Turning software validation into a meaningful exercise
A quality systems view of 21 CFR Part 11
Oracle unveils new electronic signature functionality for FDA regulated manufacturers
FDA finalizes guidance for 21 CFR Part 11
FDA drops the other shoe on Part 11
FDA signals change in approach to Part 11
Possible solution for FDA electronic record audit trail compliance
Business success is more than regulatory compliance
Buzzword alert: "Part 11 compliance"
4 comments:
I wonder what the new commissioners announcement on Thursday (tomorrow) will lead to for reinvigorating compliance. Will Part 11 be back at full strength before long?
=== One common misunderstanding is that the customer's responsibility for compliance can be met by the vendor somehow "validating" its software. Vendor claims notwithstanding, vendors cannot sell you "compliant software" or "FDA validated software." ===
Does this imply that Open Source(tm) software is not at as much of a disadvantage in the medical marketplace as is often assumed? If an entity designs and executes its own validation tests against an Open Source product, is the resulting system then acceptable under the regulations?
sPh
Beltway: my own opinion is that FDA has many issues to deal with that are much higher profile that Part 11 compliance. I don't think appointment of a new commissioner changes that.
Sphealey: I like your question.
I don't know that FDA has taken a position on open source, per se. If anyone knows more about this, I would welcome the feedback.
In the meantime, I don't see why open source would be a disadvantage in terms of suitability in an FDA-regulated environment. This assumes that the user does a proper risk assessment up front, that the system is validated to ensure that it is fit for its intended use, and that the system is under strict configuration management to ensure that all changes to the system are controlled. This is needed regardless of whether the software is open source or proprietary.
Post a Comment