New FDA Regulation for Medical Device Data Systems (MDDS)

Written By Elise Miner - Validation Manager, QPharma

Earlier this month, the FDA proposed a regulation that will reclassify certain hardware and software products used with medical devices.  The new regulation defines these products, known as Medical Device Data Systems (MDDS), as systems that are intended to provide one or more of the following uses:

• The electronic transfer or exchange of medical device data from a medical device, without altering the function or parameters of any connected devices
• The electronic storage and retrieval of medical device data, without altering the function or parameters of connected devices
• The electronic display of medical device data, without altering the function or parameters of connected devices
• The electronic conversion of medical device data from one format to another format in accordance with a preset specification

Previously, MDDS were categorized as Class III, high-risk and requiring pre-market approval.   This was the case because all medical devices unknown prior to 1976 were automatically placed in Class III by default.  However, according to the new rule, MDDS will now be Class I, low-risk and subject to general controls and quality standards.   The rationale behind this reclassification stems from the amazing growth and development of the use of medical devices and MDDS over the past decade.   Such expansion has led to new risk factors that did not previously exist.

But the changes the FDA are making to the MDDS rule affect both sides of the spectrum.  It simultaneously enlarged the MDDS category to include more software that might have been thought to be unregulated, but also now captures products that might otherwise have been placed in higher risk categories.  

Manufacturers finding themselves with products that fit the MDDS description must now adhere to all Class I requirements including registering with the FDA, listing their MDDS products, reporting adverse events and complying with FDA’s Quality Systems regulation.  By the same token, manufacturers that had previously categorized their MDDS as high –risk now stand a less taxing path to market.

The rule is set to become effective on April 14, 2011.  By May 14, 2011, companies that make MDDS must have registered with FDA and listed the MDDS product. By April 2012, companies making MDDS must have fully functioning quality systems and be in compliance with the medical device reporting rules.

Is this measure a preview of more to come?  It proves to clarify the boundaries around this one particular class of products, but begs the question - When the FDA will take steps to further define and reclassify more software and hardware.   At the very least, it’s a step in the right direction.

FDA Proposed Rule:  http://www.fda.gov/OHRMS/DOCKETS/98fr/E8-2325.pdf

 

Best Practices for Validation of a Software as a Service (SaaS) Customer Relationship Management (CRM) Solution - Part 2

Part 2: Best Practices for the Validation of a SaaS Application

Written by Gregg Mauriello - Validation Manager, QPharma

In Part 1, I gave an overview of what Cloud Computing and SaaS are, and I promised more information in the coming months. Part 2 is here, and now I can discuss the best practices for the validation of a SaaS application.   I will look at the methodology for the validation of a SaaS CRM Application and compare it to the conventional methodology for the validation of a CRM Application. 

Since all customers utilize the same instance of a SaaS application, the core functionality of the application can be validated just once.  Also, the vendor may perform a baseline configuration of the application to meet best practices for a CRM application.  This baseline would also be validated just once.  The customer validation, therefore, can be limited to the customer-specific configuration of the application that deviates from the pre-validated baseline.   The validation of the core application and baseline configuration will follow the conventional methodology for validation, including installation and operational qualification.  The vendor must develop business requirements and functional specifications against which to test including the definition of the baseline configuration.  Note: The focus of validation testing will be on functionality of the system with regulatory impact.

Deliverables:

• The Vendor Validation Plan will document the process, activities, and deliverables required for the validation of the core application and baseline configuration. 
• An Installation Qualification will be developed to document all core software and hardware required for the application. Note: The vendor IQ will not address the field device used for the sales force as this will vary greatly by customer. 
• An Operational Qualification will be developed to test the functionality of the core application and baseline configuration. 
• A Performance Qualification will not be developed as the system will not be utilized in a production environment until it is deployed for a particular customer. 
• All validation activities will be summarized in a Validation Summary Report and a Release Memo will be generated, which will document that the application has been validated and is ready for customer configuration and implementation.

All customers utilizing the application will be able to leverage the validation of the core system and baseline configuration, allowing for a lean validation to be performed by the customer.  It is recommended that the customer perform a vendor audit of the core configuration validation package to determine two factors:  

A) If the validation documentation is in line with their internal quality processes and 

B) How much validation of their specific configuration will be required.  

The vendor will also provide a service level agreement which will define the vendor’s role in maintenance and the administration of the system and data.  All procedures that are performed by the vendor, such as backup and recovery, change management (for code and infrastructure), disaster recovery, physical and logical security, system administration, and training, will be documented by the vendor.

Still interested in hearing more? I will be presenting information on this subject during an interactive workshop, at IVT’s 16th Annual Validation Week on October 26th (Session 4 on Day 2!).  The workshop will be presented along with my colleague, Elise Miner.

If you are not attending Val Week, stay tuned for Part III, where I will discuss customer responsibilities in the validation of a SaaS CRM system.

Don't Validate That Software! Part II

NOTE: This discussion is a continuation of Monday's post by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma. To read the 1st part of this post, please click here.

INTEGRAL SOFTWARE

Suppose I have three autoclaves. They’re used to sterilize final product for human implantation: major potential for serious health consequences (and remember, you don’t get to say “it doesn’t matter because we wind up testing our product”—it matters). All three of these autoclaves use software.

The first one has a separate PC connected to it, and the software resides on that computer’s hard drive, interfacing with the autoclave through a serial port. The PC is a general-purpose computer that can interface with a number of different autoclave models, and allows the user to set up specialized cycle profiles and alarms. Does that software need to be validated? You bet!

The second one sounds different, but in most ways, it’s not. That autoclave has a computer built right into it, running software with a user interface that permits customized cycles and alarms. Now there is indeed a difference: it is not designed to be disconnected from one autoclave and hooked up to another. Clearly there is some amount of scale-down that is appropriate in not needing to check that the computer can be reliably moved from one autoclave to another. But the core expectations remain the same: not only does the software, as it is configured right now, run the autoclave in such a way that it consistently works (OQ = correct temperature/pressure/cycle profiles, PQ = actually sterilizing loads); it also must demonstrably provide confidence that a range of different parameters and program sequencing will be reliably translated into actual machine operation and that those profiles are consistently implemented. That’s a qualification that goes beyond simply how the machine itself operates: it is software validation. We may have used a risk assessment to scale down the amount of testing needed, but there is definitely a separate software aspect to this.

Now consider the third example. This autoclave is computerized, but the software is programmed for one specific cycle profile; it is not customizable. There are a couple of ways this could be done: the autoclave could truly be a one-trick pony, with the computer no more customizable than a four-function calculator; or more and more commonly, the software is customizable, but the manufacturer has decided that the configuration will be “locked down” and never changed, at least not outside formal change control (which includes, of course, a process for evaluating changes for the need to perform re-validation).

I contend that in this last example, the whole concept of “software validation” goes out the window. If indeed the system has any potential for changing settings and parameters, then certainly you must both explain the measures used to preclude anyone from making unauthorized and unvalidated changes, and then demonstrate the effectiveness of those controls; and if the autoclave electronically captures or transmits any digital records that are used for GxP purposes, then validation for Part 11 may still apply. Those could include actual cycle monitoring records, any data input by users such as batch identification, or confirming the identity of authorized users.

But provided you have covered these Part 11 items, there is no regulatory obligation to...

Don't Validate that Software!

Written by Jeff Boatman - CQA and Sr. Subject Matter Expert, QPharma

BACKGROUND

General software validation became an official part of U.S. regulated Life Sciences in 1996 with the finalization of the Quality System Regulation. Contained within that Rule is 21 CFR 820.70(i), which states when computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. It is important to note that while Part 820 is a Medical Device regulation, another section [21 CFR 820.1(b)] gives FDA the authority to apply this requirement to other companies as well.

Prior to this, there was no specific regulation dealing with software validation; the closest was 21 CFR 211.68, which since 1964 has stated that if a manufacturer uses an automated system to produce a drug product, it shall be routinely calibrated, inspected, or checked according to a written program designed to assure proper performance. Bear in mind that computers were practically a novelty when that Rule was finalized, and modern validation practices were only beginning to emerge; the first software inspectional guidance wasn’t issued until 1983.

In 1997, FDA followed up with 21 CFR 11, which states that systems that create, store, process, or transmit electronic records used to satisfy regulations must include validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records [21 CFR 11.10(a)].  Shortly after, the Center for Devices and Radiological Health published Guidance for Industry: General Principles of Software Validation, which has since gone through several draft and Final revisions. While that guidance is from FDA’s Medical Device division and does include sections on the validation of software which is, or is used within, a Medical Device, it also has broad applicability to other Life Science firms as well.

The broad applicability of 21 CFR 820.70(i), the virtually universal applicability of Part 11, and the adoption of the standards in FDA’s software validation guidance make it clear that FDA has very high demands for software validation at Life Science firms, and indeed consulting firms like QPharma rely upon FDA’s comprehensive expectations to stay in business. It must be obvious to the reader that the problem that we see most often is too little software validation, too poor software validation, and too poorly executed software validation. Further complicating this is the latest move by CDRH to vastly increase the scope of what FDA considers to be "Medical Device Software" into areas that traditionally have been considered outside CDRH’s (and even FDA’s) jurisdiction.

THE USUAL...AND THE UNUSUAL

When we do audits, our comments are usually: you need to validate this...you forgot to validate that...you didn’t consider this. But once in a while, our comment is: why did you validate that?

Let’s hit some of the basics.  First, you need a Traceability Matrix (TMX), which shows all of your requirements, all of your testing planned (and performed), and linking them together. Traceability of requirements to testing is always a good idea, but for software validation, it’s mandatory: the FDA guidance mentions it repeatedly.  The most important purpose of a TMX is to ensure that every requirement actually gets validated or otherwise verified. But it also goes the other way: if you are testing something and it is not traceable back to a requirement, then why are you testing it?

Another low-hanging fruit is risk assessment. If you take the validation requirements of 21 CFR 11.10(a) and 820.70(i) literally, you’ll probably never manage to make any product for sale: all you will ever do is validate, validate, validate. (As an example, if you literally accept 820.70(i)’s obligation to validate all software changes prior to implementation, can you imagine the potential implications for daily antivirus definitions and Microsoft Windows patches?) In both its software validation guidance and the 2003 Guidance for Industry: Part 11, Electronic Records; Electronic Signatures – Scope and Application, FDA has been putting increasing emphasis on doing risk assessments of systems to determine exactly what truly needs to be validated. In particular, the Part 11 guidance offers companies the possibility of exempting broad swaths of functionality from validation provided that you can back that up with documented risk assessments. FDA may object to lesser validation based on a risk assessment they disagree with, but they will object to lesser validation without a written risk assessment at all.

In both of these examples—validation of functions that aren’t required, and validation of functions that a risk assessment could have exempted—we would caution our client that they are going overboard and that their validation dollars are better spent elsewhere. But how about software that runs a manufacturing process, and that process (and therefore that software) really does have a significant impact upon product quality, and even public health?

More on this topic and the answer this Wednesday, September 29th!