Category Archives: Quality Validation Process

System Configuration Documentation: Don’t release to production without one

System Configuration Document: a key component of validation that should be in place before system release

 Designs via MS Clipart

Overview

 

A System Configuration Document captures the final state of configuration of the system being validated.   This state should be reflective of the initial usage environment that will be in place at the time of system release.   Some of the key areas to be aware of are as follows:

  • Timeframe
  • Reflection of Usage
  • Level of Detail
  • Change Control
  • System Restore
  • Audit Impact

This post is relevant to anyone performing an equipment or system validation.

 Timeframe

 When should a System Configuration Document be completed?  Some might argue that it should be developed in parallel with the User Requirements Specification (URS) after initial system identification or development.  Others would argue that it should only be in place prior User Acceptance Testing (UAT) / Performance Qualification (PQ) testing.  The bottom line is that is should be in place once the system is developed/identified and the URS is approved.  At a minimum, a draft version of the System Configuration Document should be in place prior to any usage testing.  This document will be utilized to provide the defined configuration of the system necessary for testing.  It can and should be updated to reflect the outcome of usage testing as necessary if issues are discovered with the current configuration.

DO NOT wait until after release of the system to create this document.  Further details of why this is not appropriate will be discussed during the Change Control section.

 Reflection of Usage

It seems pretty obvious that the System Configuration Document would reflect the actual usage of the system.  It is important to mention here that accuracy is the key to a success.  Make sure that the System Owner is involved in this process as a final check to confirm the document matches what is current within the system.  It may be necessary to include other individuals within the process for a complex system with boundaries that may impact other systems or groups (i.e. IT Staff, Engineering, QC/QA, system SME, system vendor, etc…). 

 

 Level of Detail

 My opinion is the more details, the better.  It will take a bit more effort up front to capture all the details of the initial configuration of the system but it is critical information that can be utilized during change control, system restore, and system audits.  Include diagrams, screenshots, tables, and pictures as necessary.  The document should allow a user with basic system knowledge to reproduce the configuration of the system.

 Change Control

 A mentioned earlier Change Control is an important reason for the proper creation of a System Configuration Document.  Change Control captures all changes to validated systems.  A System Configuration Document provides the initial starting point or baseline of the system.  It should be possible to track all changes to a released system back to the System Configuration Document.  The System Configuration Document can be formally revised once the system is released to reflect the current state of the system per Change Control.

 System Restore

 Another important and overlooked function of a System Configuration Document becomes apparent when it is necessary to perform a system restore.  This easily applies to software but should also apply to equipment if it becomes necessary to replace equipment or a system due to disaster or other reason.  A well-written document can help to restore the system to its previous configuration in a much shorter timeframe with a high level of confidence and minimal production disruption.

Audit Impact

 Audits are perhaps the main reason for proper System Configuration Documents.  Effective System Configuration Documents show an auditor that quality planning were part of system validation.  Change Control is often a central part of any system audit.  As stated earlier, it is easy to trace the history of the system back to system release with a quality System Configuration Document.  And with an updated System Configuration Document, it is easy to show the current configuration state.

 I welcome any and all feedback on my posts.

 If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com (this format is to prevent auto spammers).

Dangers of using ‘deviations’ during a validation

via flickr by megapiksel

via flickr by megapiksel

Never report incidents as ‘Deviations’ during a validation

 

   This is a common mistake encountered during a validation when an error is discovered in the system, method, equipment, software (or whatever item is being validated) is that the incident / error is documented as a ‘Deviation’.  I can’t stress this enough…you should NEVER write a deviation during a validation.  Only in a single instance would I consider using a deviation during this process which I will discuss as part of this post.  This post is relevant if a validation is being performed and for those companies, organizations, and consultants learning about the proper way to perform a validation for a quality perspective.

 

Case Study of Software Validation:  Why deviations are a bad idea during validation

 

While working for a previous employer during a software validation for a State-run laboratory, I was required to document all errors encountered during the process using a combination of deviation forms and their deviation process.  I was unsuccessful in my repeated attempts to explain the Risk involved with capturing all errors within the client’s deviation process.  Unfortunately, the EDMS software vendor  had some OQ protocols that were poorly written (this incident finally convinced them to improve their quality process) coupled with the client’s strict interpretation of deviations, led to over 100 deviation entries into their production system and 50-75hours worth of downtime processing these records.  If I was an inspector, this would definitely raise a red flag.   I told them that when they utilize their deviation system (within their live, production process); they will encounter the following:

 

1)      It artificially increases the importance of the encountered errors beyond what they should be for a non-validated system.

2)      Adding non-validation systems to the deviation process greatly increases the overall number of deviations within the system.

3)      Large delays occur during the validation as the deviations are handled in a time consuming, formal process versus an incident report process.

4)      Deviations are a common inquiry and therefore will lead inspectors directly to the validation process for the system which might have otherwise been ignored during the audit/inspection.

5)      Questions arise about the system selection process if there are many formal deviations during validation.

6)      It greatly increases the cost of the validation project when formal deviations are entered into the system under strict guidelines versus an informal incident process which typically takes less time to process.

 

Costly Outcome

 

The overall outcome was a significant delay of the validation process, and a huge cost in terms of employee hours from IT, QA, System Owner, and client personnel involved in testing process.  Because of the lengthy and formal deviation process, the number of individuals involved in the process was typically five or more, including myself, System Owner, IT, QA, and the client personnel assisting me (and some meeting that were required to close the deviations).  Calculating all the individual’s salary costs and our per hour costs, at least 10K was wasted during this process.  Sadly, this might not be the most costly part of the project.

 

Regulatory Impact

 

The regulatory impact of entering deviations encountered in the process for non-validated system may be more costly that the immediate monetary impact.  As stated earlier, many validations entered into the deviation system will flag that system as a potential problem (even if these are merely validation related errors).  Again, deviations always targeted by inspectors from regulated agencies, your regulated customers, and your internal QA audits.  The best ways to avoid these issues are to report system errors during validation as ‘Incident Reports’ instead of deviations.

 

Incident Reports

 

Incident Reports are segregated from the deviation process.  Incident Reports are similar to Deviation Reports where the issue is identified, root cause discovered, and issues documented and resolved.  Incident Reports differ in the way these are resolved versus Deviations.  Typically, Incident Reports do not require the same level of documentation or formal process to address.   Errors encountered as part of the execution of validation testing should always be handled using this method.  There is never a need to include this type of issue within the deviation process for a non-validated system.  I have yet to be a part of a validation where issues did not occur. In fact, it is not only typical but expected to see many more incidents early on during the validation process when the ‘bugs’ are being worked out of the system.  The one exception to handling these issues in Incident Reports would be if there is a need to deviate from the validation process in terms of already approved procedures.  For instance, if a different validation method was to be utilized or a new protocol was to be issued during validation, a deviation against the process would be justified.  Again, this would best be positioned against the validation procedure, not the specific system being validated.

 

 Segregation of Validation is Vital

 

Once again I want to stress the importance of keeping your validation documentation separate from your ‘live, production’ system.  There is no need to make an auditors life easier by giving them a clear path into your validation process via your deviation system.  Equally, you should not spend all the time, money, and effort on performing a proper validation only to have the efforts questioned because of a simply lack of quality process understanding.  Keep Incidents Report contained within each validation project and make sure that deviations are NEVER part of your validation process.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.

Risk Assessments for Computerized Systems in the Blood Industry

Risk Assessment for Computer System Validation in Blood Establishments

 

via MS Clipart

via MS Clipart

 

Overview

 

Having previously performed numerous Risk Assessments on Computer Systems for many Blood Centers, I wish to share the importance of performing a proper Risk Assessment.  Now that I am an independent consultant and no longer limited by prior employer policies and politics, often driven from a cost (not quality perspective), I can freely state the correct methodology for Risk Assessments.  The main focus for a Risk Assessment should be to define the level of testing required for system validation based upon the risks to patient and quality of product.  It is imperative to perform Risk Assessments early in the process to help define the validation activity before the validation plan or test cases are developed.  Risk Assessments should be utilized throughout the process and post implementation (separate or integrated within Change Control).  My recommendation is to utilize a worksheet to capture this process and thus established a specific timeframe.  Further information on this topic can be attained from http://www.fda.gov/cber/gdlns/becsvalid.htm (FDA/CBER guidance doc) and http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview (GAMP5 publication).  This post will be relevant for companies within the blood industry (and most other regulated industries) for compliance with computer system validation.

 

 

Define Critical Quality Attributes

 

Critical Quality Attributes (CQA) are central to developing a proper Risk Assessment.  CQA are best defined as those attributes that have the greatest impact upon patient safety and product quality.  Once these are defined, specific system standards and requirements can be developed which further define testing methods and risk focus.  This is the basis for making science and risk based decisions that will ensure that the system is designed or configured and meets its intended use.   Make sure that as part of this CQA definition, your regulatory requirements are indicated. 

 

 

Risk Assessment

 

I cannot stress enough how important a Risk Assessment is for proper system validation.  Once the basic system requirements of the system have been identified, this Risk Assessment is done to help define the validation plan and what validation test will be required for the system.  Without doing a proper Risk Assessment, key CQA areas might be omitted or unnecessary testing may be done.  One important thing to keep in mind is that the total elimination of all risk is not the focus; it is justification of residual levels of risk.  Risk may simply not be able to be eliminated or the cost associated with total elimination may not be justified by the business.   Risks identified may change over the course of the system validation.  It is possible to perform ongoing Risk Assessments during the course of validation as additional items are identified.  I have found that the best method for capturing this information is to utilize a Risk Assessment based worksheet.  This worksheet should capture the following information:

 

  • Initial Risk Level Classification
  • Identified Issue (what is causing the risk)
  • Identified Risk Component(s) (specific risk or risks from the Identified Issue)
  • Likelihood of Detection
  • Likelihood of Occurrence
  • Severity of Impact
  • Mitigation Strategy
  • Corrective Actions
  • Final Risk Level
  • Justification of Final Risk Level

 

In circumstances where the Severity of Impact is high, assume that the Likelihood of Occurrence is high if there is no way to determine this outcome.  This should be noted in the Final Validation Report and increased auditing of the system should occur until a level of confidence is established.

 

Frequency of Risk Assessments

 

To keep things simple, this is the basic guidelines for when to perform a Risk Assessment:

  • Prior to the start of validation but after the System Requirements have been defined
  • During the course of validation, especially when changes to the process occur or when additional issues are discovered that would warrant a Risk Assessment
  • Prior to implementation of the system when all testing has been completed
  • Periodically during system audits
  • During every change to the system via Change Control or as a separate Risk Assessment
  • Prior to decommissioning of the system

 

 

I welcome any and all feedback on my posts.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.

 

Validation Documentation Errors (grammar/spelling): Correct them?

Reader Question:  Is it worth correcting errors within validation documentation if it is technically correct?

 

spelling-via-flickr-by-rathianspkie

spelling-via-flickr-by-rathianspkie

 

  

 

 

Overview

I received an email from reader of my blog who has hired a validation consultant to write part of his validation documentation but received deliverables that were less than ideal.  Here is the actual email:

 

I would be grateful if you would provide an opinion on this matter: Within a project group, the project manager has assigned a developer to author user requirement specifications (after interviewing the users) and functional specifications. The project is modular, so there are many specifications. The specifications typically contain grammar errors, as English is not the author’s native language.
What is the risk presented by a specification that is technically correct but grammatically of poor quality? Is it worth the effort to correct every sentence if the meaning is discernible, even though the language may be inelegant?

 

 

 The short answer is ALWAYS correct the errors.  I’m not saying that the entire document has to be revised for a few minor spelling mistakes.  In the following sections I will tell you why.  This post is relevant to companies who have hired validation consultants or companies to perform part of all of the validation activities.

 

Compliance Issue

 

The first major concern would be the potential issue of a grammatical or spelling error that causes an actual compliance issue.  If the meaning or intent doesn’t reflect what actually happened, an astute auditor will pick up on this error and require clarification or consider the test as invalid.  This observation will most likely occur months or years from the actual validation event and may be difficult for someone to reconstruct even if the most likely event is obvious to the System Owner or Quality Reviewer (assuming that those people haven’t left the company).

 

Proper Review

 

Technical errors may not be discovered if an auditor is not a subject matter expert in your system.  With grammatical/spelling errors, almost anyone can identify these issues without any system knowledge.  Furthermore, all of these documents require a quality review and approval from the quality unit of the company, not the consultant (remember responsibility cannot be outsourced even if the validation tasks were).  The assumption is that the person performing the review of the validation documentation is a native/expert in the English language (and it should be) and that the errors should have been identified and corrected as part of this review process.  If I was the auditor, I would assume that these documents were given a ‘rubber stamp’ review.

 

GDP and Document Control/QA

If there are documents presented to auditors that are in obvious need of revision, this may lead to further questions on the company’s understanding of Good Documentation Practices (GDP) and Document Control/QA practices.  A good auditor will take this opportunity to dig into the GDP which may lead to further questions for Document Control and QA.  Additional question may arise regarding the validation of other systems, review policies, and other documentation within your company.  At a minimum, the auditor may spend additional time reviewing the validation documentation of the current system due to these initial findings.  

 

Lack of Understanding

 

Another concern I would have when selecting a consultant who may be technically savvy but grammatically challenged is their potential lack of understanding.  If they cannot product a well written document, do they actually have a proper grasp of the language?  I’ve worked with many different consultants from countries who have a significant understand of the language and are technical experts in their fields. 

 

On the other hand, I’ve worked with some individuals who were able to BS their way through the vetting process and clearly do not understand the language well enough to function as expected.  What makes this worse is that they will usually not admit the misunderstanding if confronted but rather state that they can do the work and understand what is required.  The last thing bad a consultant will admit is that they don’t understand the request.  This is paramount to a dismissal in their mind.

 

Don’t Sacrifice Quality

 

In the realm of quality/compliance related documentation, you really don’t want to sacrifice quality.  As the person who sent in the request has probably already discovered, it cost time and money to fix a problem that could have been corrected up hiring a person with a solid grasp of the language (and understanding of validation/quality). 

 

It happens to all of us in this current economic environment when every dollar counts.  My previous company hired workers from overseas to create software and validation PQ templates related to the software.  It turns out that the templates were loaded with errors resulting from an obvious lack of understanding of the requirements and therefore required additional re-work before utilization.

 

Ask for a writing sample, contact previous references, and conduct an interview prior to hiring a consultant to perform any validation activities.  If you are only concerned about costs, you’ll often get what you pay for.

 

Finally, validation testing doesn’t have to be perfect.  There have been many incidents in the systems that I’ve tested which were captured and well documented.  Auditors aren’t expecting that a new system will be perfect right out of the box.  Validation is the time where these issues should be discovered and corrected by following sounds policies and procedures.  However, a fully controllable event like validation documentation should be as close to perfect as possible to show control over the process.

 

 

I welcome any and all feedback on my posts.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.

Software: medical device or aid/tool?

FDA guidance:  Is your software a medical device?

 

via flickr by john-norris

via flickr by john-norris

 

 

Overview

I’ve recently been in contact with Mr. Joseph Tartal, Technical Branch Chief, DSMICA, CDER, FDA, in regards to comments I had on the 2007 Guidance for Industry Computerized Systems Used in Clinical Investigation. The topic discussed was clinical software and its status as a medical device versus a tool or aid.  This post is relevant to companies who plan to create or utilize critical software within their regulated operations.

 

 

2007 Guidance for Industry Computerized Systems Used in Clinical Investigation

This is the 2007 Guidance which covers computerized systems used within clinical trials.  I provided some feedback on this guidance to Mr. Tartal on the related documentation that should be part of implementation of this type of system (see my previous post).  The feedback I got led to discussion of when a computerized system becomes more than just a tool or aid.  The next section is the actual e-mail response from Mr. Tartal.

 

 

Mr. Tartal’s e-mail response March, 6th 2009

 

 

Dear Mr. Salomon,

 

Clinical computer systems, both utilized in clinical trails and to make health care decisions, are becoming a lot more prevalent and are expanding with regards to applications and data management.  They are no longer just record retrieval systems.  As this software evolves so does their status as medical devices.  One of the terms currently in the mix is diagnostic software; where does the line exist between a tool or aid and a medical device?  What are the requirements as they apply to software as a medical device: lots of guidance has been put into place to help explain this.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTopic/topicindex/topindx.cfm?alpha=s (Topic Index: Software Guidance)

 

If you have specific questions on the guidance I would recommend that you contact the centers software expert, John Murray, at (240) 276-0284.

  

Thank You,

Joseph Tartal, Technical Branch Chief

DSMICA

This response represents to the best of my judgment how the device should be regulated, solely based upon a review of the information you have provided. This communication is consistent with 21 CFR 10.85 (k) and constitutes an informal communication that represents my best judgment at this time but does not constitute an advisory opinion, does not necessarily represent the formal position of FDA, and does not bind or otherwise obligate or commit the agency to the views expressed.

 

 

Again, it is important to state that this was informal feedback from an e-mail exchange and does not constitute an advisory opinion, formal position of the FDA or bind or otherwise obligate or commit the FDA to the views expressed.

 

 

Software as a medical device

Although the comments from Mr. Tartal were related the use of software within the clinical environment, I believe that this reach will extend beyond the realm of diagnostic tools within the clinical environment to cover other areas where quality related decisions are made by software systems.  The question is at what point does the computerized system become more than a tool or aid?

 

 

I welcome any and all feedback on my posts.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.

21 CFR 1271 and Computer System Validaiton: Does it apply to you?

 

 

via flickr by joel mark witt

via flickr by joel mark witt

Overview

I’m writing this post in response to a computer systems validation I performed. The client I was working with utilized human tissues to create their tissue-based product. During the validation, the client ask me what regulations required them to validate their computer system. The answer is found in the link to the FDA’s website for 21 CFR Part 1271. In particular, within Subpart D: Current Good Tissue Practices requires computer system validation under, 1271.160 (d) Computers. To understand which companies are governed by this requirement is a bit tricky to follow at first but easy to understand after reading my blog. This post is relevant to companies that deal with human cell, tissues, and cellular and tissue based products within their process or as part of their product (HCT/P’s).

 

First Step: Understanding Subpart A: General Provisions 1271.1 (b) Scope

This section of the regulation defines which establishments that manufacture human cells, tissues, and cellular and tissue-based products (HCT/P’s) fall into either of two categories: solely regulated under section 361 of Public Health Services (PHS) Act (see section 1271.10) or those HCT/P’s that are regulated as drugs, devices and/or biological products under section 351 of PHS Act and/or the Federal Food, Drug, and Cosmetic Act, Secs. 210.1(c), 210.2, 211.1(b), and 820.1(a) will require compliance with current good tissue practices under Subpart D.

 If you are within the former group, further determination must be done to see if you are governed by Subpart D,current good tissue practices, by examining section 1271.10.

 If you are in the later, Subpart D already applies. Later on, I will address computer validation requirements.

 

If you don’t meet the requirements of 1271.10 and don’t fall under the exceptions of 1271.15, you fall under the scope of these requirements including Subpart D.

 

Subpart A: Section 1271.10

I copies this link directly from the FDA hyperlink above. Basically, if you meet the requirements of this section, only Subpart A of 1271 applies.

 Sec. 1271.10 Are my HCT/P’s regulated solely under section 361 of the PHS Act and the regulations in this part, and if so what must I do?

 (a) An HCT/P is regulated solely under section 361 of the PHS Act and the regulations in this part if it meets all of the following criteria:

(1) The HCT/P is minimally manipulated;

(2) The HCT/P is intended for homologous use only, as reflected by the labeling, advertising, or other indications of the manufacturer’s objective intent;

(3) The manufacture of the HCT/P does not involve the combination of the cells or tissues with another article, except for water, crystalloids, or a sterilizing, preserving, or storage agent, provided that the addition of water, crystalloids, or the sterilizing, preserving, or storage agent does not raise new clinical safety concerns with respect to the HCT/P; and

(4) Either:

(i) The HCT/P does not have a systemic effect and is not dependent upon the metabolic activity of living cells for its primary function; or

(ii) The HCT/P has a systemic effect or is dependent upon the metabolic activity of living cells for its primary function, and:

(a ) Is for autologous use;

(b ) Is for allogeneic use in a first-degree or second-degree blood relative; or

(c ) Is for reproductive use.

(b) If you are a domestic or foreign establishment that manufactures an HCT/P described in paragraph (a) of this section:

(1) You must register with FDA;

(2) You must submit to FDA a list of each HCT/P manufactured; and

(3) You must comply with the other requirements contained in this part.

  Subpart A: Section 1251.15 -Exceptions

If you meet the criteria below, you fall under exceptions and do not need to meet the criteria in Subpart A. Again, this is directly from the FDA hyperlink above.

 

Sec. 1271.15 Are there any exceptions from the requirements of this part?

 

(a) You are not required to comply with the requirements of this part if you are an establishment that uses HCT/P’s solely for nonclinical scientific or educational purposes.

(b) You are not required to comply with the requirements of this part if you are an establishment that removes HCT/P’s from an individual and implants such HCT/P’s into the same individual during the same surgical procedure.

(c) You are not required to comply with the requirements of this part if you are a carrier who accepts, receives, carries, or delivers HCT/P’s in the usual course of business as a carrier.

(d) You are not required to comply with the requirements of this part if you are an establishment that does not recover, screen, test, process, label, package, or distribute, but only receives or stores HCT/P’s solely for implantation, transplantation, infusion, or transfer within your facility.

(e) You are not required to comply with the requirements of this part if you are an establishment that only recovers reproductive cells or tissue and immediately transfers them into a sexually intimate partner of the cell or tissue donor.

(f) You are not required to register or list your HCT/P’s independently, but you must comply with all other applicable requirements in this part, if you are an individual under contract, agreement, or other arrangement with a registered establishment and engaged solely in recovering cells or tissues and sending the recovered cells or tissues to the registered establishment.

 Subpart A: Section 1271.20

So if you don’t meet the criteria in Section 1271.10 and don’t fall under the exceptions of 1271.15, you are governed by all requirements listed below and Subpart D. Therefore, you need to follow the computer system validation guidelines which falls under Subpart D, 1271.160-Establishment and maintenance of a quality program.

 

Sec. 1271.20 If my HCT/P’s do not meet the criteria in 1271.10, and I do not qualify for any of the exceptions in 1271.15, what regulations apply?

 

If you are an establishment that manufactures an HCT/P that does not meet the criteria set out in 1271.10(a), and you do not qualify for any of the exceptions in 1271.15, your HCT/P will be regulated as a drug, device, and/or biological product under the act and/or section 351 of the PHS Act, and applicable regulations in title 21, chapter I. Applicable regulations include, but are not limited to, 207.20(f), 210.1(c), 210.2, 211.1(b), 807.20(d), and 820.1(a) of this chapter, which require you to follow the procedures in subparts B, C, and D of this part.

 

Subpart D: Section 1271.160 Establishment and maintenance of a quality program (d) Computers.

This is the actual requirement found within 1271 that directly addresses the need to validate computer software. I copied only section (d) from the page.

 

(d)Computers . You must validate the performance of computer software for the intended use, and the performance of any changes to that software for the intended use, if you rely upon the software to comply with core CGTP requirements and if the software either is custom software or is commercially available software that has been customized or programmed (including software programmed to perform a user defined calculation or table) to perform a function related to core CGTP requirements. You must verify the performance of all other software for the intended use if you rely upon it to comply with core CGTP requirements. You must approve and document these activities and results before implementation.

 

Note the following from above as it relates to software utilized to meet CGTP in its intended use:

 

  1. Validation is required for software in its intended use.

  2. Validation is required of any changes to the software for its intended use.

  3. Customized, commercially available both require the same validation.

  4. User defined calculation or table actions apply.

  5. All software you rely upon for core CGTP requirements fall under this category.

  6. You must APPROVE and DOCUMENT these activities and results before implementation.

 

The FDA database was updated April 1, 2008 according to the FDA website. Check the FDA Website often to confirm the most current version of the regulations are available.

 

Additional Guidance for Computer Systems and Validation Activities

There are many software providers and consultants that assist companies with meeting the requirements of 1271. It is important to make a good selection after an informed decision. I recommend reviewing the FDA Guidance Document on the subject of Computer System Validation as well as GAMP5 guidelines, among others. Make sure that any software vendor or validation consultant has a good understanding of your process, quality system requirements, and is willing to meet your internal standards. Always consult with professional QA/RA personnel before making any quality/regulatory decisions.

 

I welcome any and all feedback on my posts.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.

AABB, FDA, and 2001 Draft Guidance: Validation Plans

 

AABB’s comment on the FDA’s Docket No. 00D-1538 Draft Guidance for Industry; Electronic Records; Electronic Signatures, Validation; Availability as it relates to Validation Plans.

via Flickr by romanlily

via Flickr by romanlily

 

 

 

 

Overview

I’ve recently reviewed a post from the American Association of Blood Banks (AABB) regarding the FDA’s Draft Guidance for Industry; Electronic Records, Validation; Availability (FDA Document No. 00D-1538). The FDA guidance document and AABB response were both dated back in 2001. However, I feel part of the response from AABB was important to note since I believe this will not change in any future guidance and in my opinion would be considered ‘best practices’ for validation. I’m speaking about the need for the creation of Validation Plans prior to starting the validation activity for a computer system and the need for management’s understanding of the computer system and operational process before review and approval of a Validation Plan.

 

FDA Docket No. 00D-1538: Section 5.2.1 – Validation Plan

This is the 2001 Draft Guidance which addresses Computer System Validation (CSV) activities among other topics. The section I will focus on is Section 5.2.1, Validation Plan, which gives very general guidelines for the creation of a validation plan. Among the items to be considered are scope, approach, tasks, responsibilities, and review/approval by management.

 

AABB’s response (December 2001)

I discovered this article while performing a google search for the draft guidance document. Here is the link to AABB response. AABB’s response to Section 5.2.1 calls for tighter controls over the Validation Plan requirements specifically calling for facilities to create the validation plan prior to execution for the purpose of catching the areas of weakness and critical function prior to actual commencement of testing activities. Furthermore, they go on to state that management responsible for approval and review of the Validation Plan be knowledgeable of the systems being validated and related operational process.

 

 

Again, it is important to state that this was feedback on a draft guidance document.

 

Validation Plan Overview

 

  • Create Validation Plans Prior to Validation – Don’t let the cart pull the horse. Creation of a Validation plan before the actual validation activities shows that the process is not an afterthought but actually part of a well planned and executed validation. This process will help drive the importance of critical functions and identify areas that need attention. You wouldn’t create your standards for QC release after you performed the release testing, why would you create the Validation Plan after validation?

     

  • Review and Approval by Knowledgeable Management – Management involved in the review and approval of all elements of the validation process should understand both the computer system and related operational process. At a minimum, all review personnel should be at the basic system user level. For the operation process, management should be very familiar and have a solid understanding.

 

I welcome any and all feedback on my posts.

 

If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.