So the Validation Department generate the protocol and the Quality Department are involved in reviewing the protocol. Having worked on various different projects it has become quite apparent that the quality review on any protocol is a very important review as it irons out all of the documentation mistakes that occur when the document is being generated.

Quality Vs Validation  - Good Vs Evil
Quality Vs Validation - Good Vs Evil

On the other hand I often wonder if quality takes this review too far, and if they do why?

Quality Review

For example if you have a quality person reviewing an IQ or OQ protocol on a computer application, is it acceptable for them to review it having little knowledge of the application.

Does this lead to the quality person reviewing the protocol with an overly cautious approach to the point where the validation engineer is ready to pull their hair out in frustration.

A Simple Scenario

Lets take a very simple scenario. A test protocol usually has the following fields:

  • Test Procedure
  • Acceptance criteria
  • Meets Acceptance Criteria Yes/No
  • Performed by /Date

The column to take note of in this scenario is the Acceptance Criteria and the Performed by/Date field.

Lets discuss the acceptance criteria field first, this field usually contains the criteria that must be met in order to pass a test section. If the test is carried out and the acceptance criteria are not met then this usually results in a deviation or an event being raised.

I don’t think anyone has an issue with this scenario, but in terms of acceptance criteria what is acceptable?

Let take a simple example:

Test Procedure: Click the Yes radio button
Acceptance Criteria: Deviation message is displayed
Meets acceptance criteria: Yes
Performed by: Joe Soap 12/12/09

Is this acceptable from a quality perspective though, I mean when you sign the performed by section do you mean that the test has been completed or do you mean that the deviation message was displayed and the test was completed.

Screenshots

If the quality department are not happy with the latter then they will require a screenshot as evidence that the deviation message was displayed.

Do you see what I am getting at here; does this mean that screenshots are required for all acceptance criteria?

If so then your protocol will contain numerous attachments and a long review time.

Before your protocol is approved you really need to work closely with the quality department in order to understand what is acceptable from an acceptance criteria view point.

If you would like further assistance with protocol generation please feel free to contact Premier Validation

0
shares

  • maryacton

    Nice post – Yes we have the same issues with quality, they are important to the overall process but it is important that validation and quality work together and not think they are on different teams.

  • maryacton

    Nice post – Yes we have the same issues with quality, they are important to the overall process but it is important that validation and quality work together and not think they are on different teams.

  • S. J. D’Souza

    Documentation corrections do not equal spelling mistakes. There is more to a quality review that just spell check. On the surface it seems so much easier to have to review a document than having to create it in the first place. Having to write a protocol for anyone to understand decreases the efficiencies of the risk based approach or quality by design. IMHO it is incumbent of the quality approver to educate him/herself of the application in question before/while approving. Approval should be an iterative process to deliver the best qualification document.

  • S. J. D’Souza

    Documentation corrections do not equal spelling mistakes. There is more to a quality review that just spell check. On the surface it seems so much easier to have to review a document than having to create it in the first place. Having to write a protocol for anyone to understand decreases the efficiencies of the risk based approach or quality by design. IMHO it is incumbent of the quality approver to educate him/herself of the application in question before/while approving. Approval should be an iterative process to deliver the best qualification document.

  • gokeeffe

    Hi S. J. D’Souza,

    Thanks for the comments, in your experience could you provide a list of other aspects of a quality review?

    Cheers

    Graham

  • gokeeffe

    Hi S. J. D’Souza,

    Thanks for the comments, in your experience could you provide a list of other aspects of a quality review?

    Cheers

    Graham

  • snaranjo

    Quality involvement on Computer validation is essential to success, but also to concentrate on relevant testing and documentation. We can take tons of screenshots as evidence of standard functionalities (hardly tested by the supplier) and miss the opportunity to test critical or risky configuration. Then we have a very nice but useless documentation. In other words, validation effort should be focussed on demonstrating that system (or system configurations) meet the user processes without compromising electronic records. Documentation is a part, not the goal of validation, and quality people not always has this view. In my opinion, testing must be done by a well-trained or experienced user who write “pass/not pass” and sign the execution. A second user (witness or not) review the results and take part on resolution of fails/non conformities. We use to involve QA as final test reviewer (and protocol/report approvers).

    Regards

  • snaranjo

    Quality involvement on Computer validation is essential to success, but also to concentrate on relevant testing and documentation. We can take tons of screenshots as evidence of standard functionalities (hardly tested by the supplier) and miss the opportunity to test critical or risky configuration. Then we have a very nice but useless documentation. In other words, validation effort should be focussed on demonstrating that system (or system configurations) meet the user processes without compromising electronic records. Documentation is a part, not the goal of validation, and quality people not always has this view. In my opinion, testing must be done by a well-trained or experienced user who write “pass/not pass” and sign the execution. A second user (witness or not) review the results and take part on resolution of fails/non conformities. We use to involve QA as final test reviewer (and protocol/report approvers).

    Regards

  • http://www.validationplusinc.com jeff gassman

    Several interesting points should be clarified:

    1) prior to writing a protocol, I recommend that a team be established including the writer, the system owner, and the quality reviewer. This allows the team members to learn their strengths, weaknesses, and personality traits (if the quality reviewer is weak in computer validation the others can diplomatically provide suggestions, learn that the quality reviewer is not open to suggestions, or learn what the quality reviewer expects). Having written over a hundred protocols, I highly recommend this.

    2) prior to writing a protocol, I recommend that the writer generate an outline of what will be tested and identify the template to be used (to achieve team consensus). For example, I recommend that you include columns for “Expected Results” and “Actual Results” so that the reviewer can determine if actual results met expected results.

    3) getting to know the team members before writing the protocol improves the likelihood of it being right-first-time (minimizing protocol approval time and protocol review time after execution).

    4) it is important that a protocol be written such that execution and review is not open to interpretation (the team, including the executor, knows what is expected as does the reviewer). As an example, state when a screenshot is required (attach printout demonstrating that ….). Screenshots are required to demonstrate tasks have been performed successfully. As a rule of thumb, one or two, per test case.

    If you have any questions, you can reach me via email at: jeffreygassman@validationplusinc.com

  • http://www.validationplusinc.com jeff gassman

    Several interesting points should be clarified:

    1) prior to writing a protocol, I recommend that a team be established including the writer, the system owner, and the quality reviewer. This allows the team members to learn their strengths, weaknesses, and personality traits (if the quality reviewer is weak in computer validation the others can diplomatically provide suggestions, learn that the quality reviewer is not open to suggestions, or learn what the quality reviewer expects). Having written over a hundred protocols, I highly recommend this.

    2) prior to writing a protocol, I recommend that the writer generate an outline of what will be tested and identify the template to be used (to achieve team consensus). For example, I recommend that you include columns for “Expected Results” and “Actual Results” so that the reviewer can determine if actual results met expected results.

    3) getting to know the team members before writing the protocol improves the likelihood of it being right-first-time (minimizing protocol approval time and protocol review time after execution).

    4) it is important that a protocol be written such that execution and review is not open to interpretation (the team, including the executor, knows what is expected as does the reviewer). As an example, state when a screenshot is required (attach printout demonstrating that ….). Screenshots are required to demonstrate tasks have been performed successfully. As a rule of thumb, one or two, per test case.

    If you have any questions, you can reach me via email at: jeffreygassman@validationplusinc.com

  • http://etech-group.com/index.php?page=ServicesWeProvide&textsec=8 Validation Specialist

    Excellent comments – particularly the detail from Jeff.

    Something to keep in mind is that there are several common rationales or approaches to validation. These can typically vary by company, by division within a company, or even by the project that you are representing. Understanding the validation approach for your particular project is critical if you expect to be successful when it comes time for a quality review. Deliverable types that were acceptable on your last project may no longer apply, even for the same type of system.

    For example, if your project follows a risk-based approach there will be specific criteria that quality uses as a measuring stick. You may have a full suite of system lifecycle documentation, such as User Requirements, Functional Specifications, and/or a Design Specification of some sort. Depending on how the risk-based approach is structured, quality may expect your protocol to include verifications of specific elements from within these lifecycle documents. Your role in a project may be focused on protocol development, however, it’s critical that you understand validation rationales that may already be planned for your project. This is in alignment with comments by Jeff that you should familiarize yourself with quality’s expectations.

    To summarize, while it’s crucial that protocols and test cases be structured in a manner that eliminates ambiguity, understanding the rationales for testing and the appropriate deliverables that feed into the qualification effort are foundational when it comes time for a quality review.

    As a caveat, there are clearly organizations who don’t require indepth planning or advanced rationales when planning a validation effort. Whereas understanding a risk-based approach to protocol writing is critical if you want to be successful in a risk-based environment, communication of expectations is equally critical in a less rigorous business environment. In either case, the key to successful protocol development is understanding the basis that quality will be using when it’s time to review your work.

  • http://etech-group.com/index.php?page=ServicesWeProvide&textsec=8 Validation Specialist

    Excellent comments – particularly the detail from Jeff.

    Something to keep in mind is that there are several common rationales or approaches to validation. These can typically vary by company, by division within a company, or even by the project that you are representing. Understanding the validation approach for your particular project is critical if you expect to be successful when it comes time for a quality review. Deliverable types that were acceptable on your last project may no longer apply, even for the same type of system.

    For example, if your project follows a risk-based approach there will be specific criteria that quality uses as a measuring stick. You may have a full suite of system lifecycle documentation, such as User Requirements, Functional Specifications, and/or a Design Specification of some sort. Depending on how the risk-based approach is structured, quality may expect your protocol to include verifications of specific elements from within these lifecycle documents. Your role in a project may be focused on protocol development, however, it’s critical that you understand validation rationales that may already be planned for your project. This is in alignment with comments by Jeff that you should familiarize yourself with quality’s expectations.

    To summarize, while it’s crucial that protocols and test cases be structured in a manner that eliminates ambiguity, understanding the rationales for testing and the appropriate deliverables that feed into the qualification effort are foundational when it comes time for a quality review.

    As a caveat, there are clearly organizations who don’t require indepth planning or advanced rationales when planning a validation effort. Whereas understanding a risk-based approach to protocol writing is critical if you want to be successful in a risk-based environment, communication of expectations is equally critical in a less rigorous business environment. In either case, the key to successful protocol development is understanding the basis that quality will be using when it’s time to review your work.

  • waynem

    Nice Post! As I work for a large company with many branches, I have had to work closely with the various Responsible Head of Quality. My experience has shown that one has to understand the Quality “Person” to be able to understand their individual needs. Some are more prone to checking the basic fundimentals such as the font,size, shades of grey, etc of the documentation while others are extremely stroppy with spelling and grammer and yet have no idea of the various tests that are to be performed. Others ignore this and show a keen interest in the why, when, and what’s of the script that one is bombarded with so many questions that one starts to question your own protocol writing skills!! lol.

    As every person has a different outlook/way of doing something such as protocols, as a Protocol writer/executioner (grin..) at least ones life will never be boring.

    Keep the posts rolling. Tx

  • waynem

    Nice Post! As I work for a large company with many branches, I have had to work closely with the various Responsible Head of Quality. My experience has shown that one has to understand the Quality “Person” to be able to understand their individual needs. Some are more prone to checking the basic fundimentals such as the font,size, shades of grey, etc of the documentation while others are extremely stroppy with spelling and grammer and yet have no idea of the various tests that are to be performed. Others ignore this and show a keen interest in the why, when, and what’s of the script that one is bombarded with so many questions that one starts to question your own protocol writing skills!! lol.

    As every person has a different outlook/way of doing something such as protocols, as a Protocol writer/executioner (grin..) at least ones life will never be boring.

    Keep the posts rolling. Tx

  • R Hess

    Interesting that there seems to be such animosity between validation teams and quality teams. I work for a very small company and the quality and validation duties overlap as far as responsible personnel.
    I have had to do much educating here on what the purpose of validations are in order to be able to work well with all departments. And truthfully, the manufacturing departments are the most resistant to performing validations.
    Maybe this is a strange question, but don’t validation teams want their documents to meet all of the quality standards too? If a question the quality reviewer brings up cannot be answered easily, then maybe the quality reviewer has a point…?
    In our company, the quality department handles most of the external audits and must assist in defending documents to customers, ISO auditors, and government auditors. As both a quality and validation position, I definetly don’t want to be caught in a position with an auditor of any kind where I cannot defend or explain any part of a validation document…

  • R Hess

    Interesting that there seems to be such animosity between validation teams and quality teams. I work for a very small company and the quality and validation duties overlap as far as responsible personnel.
    I have had to do much educating here on what the purpose of validations are in order to be able to work well with all departments. And truthfully, the manufacturing departments are the most resistant to performing validations.
    Maybe this is a strange question, but don’t validation teams want their documents to meet all of the quality standards too? If a question the quality reviewer brings up cannot be answered easily, then maybe the quality reviewer has a point…?
    In our company, the quality department handles most of the external audits and must assist in defending documents to customers, ISO auditors, and government auditors. As both a quality and validation position, I definetly don’t want to be caught in a position with an auditor of any kind where I cannot defend or explain any part of a validation document…

Similar articles:

Changes to equipment and documentation is an integral part of the whole GMP process in any regulated facility. In this article we will discuss how equipment is designed in a GMP facility and how good documentation practices are an essential part of quality assurance and GMP.

The content of this article has been taken from module 7 of our eLearning module on Good Manufacturing Practices (cGMP) within the life sciences.

You can view this module in full by viewing the video below.

cGMP eLearning Module – Compelling, Engaging and Interactive

 

Equipment

All equipment is designed, constructed and located to suit their intended use and to facilitate easy maintenance and cleaning.

Equipment is installed in such a way as to prevent any risk of error or of contamination, and cleaned according to detailed and written procedures and stored only in a clean and dry condition.

Production equipment should be designed in such a way as not to present any hazard to the products.

The parts of the production equipment that come into contact with the product must not be reactive, additive or absorptive to such an extent that it will affect the quality of the product and thus present any hazard.

Any defective equipment should, if possible, be removed from production and quality control areas, or at least be clearly labelled as defective. When not in use, equipment should be covered to ensure it remains clean.

Balances

Balances and measuring equipment of an appropriate range and precision should be available for production and quality control operations.

All measuring devices are required to be calibrated and checked at defined intervals by appropriate methods, and adequate records of such tests should be maintained.

Utilities

Fixed piping should be clearly labelled to indicate the contents and where applicable, the direction of flow.

Water pipes used in production (e.g. Purified Water, Water for Injection) are sanitised according to written procedures that detail the action limits for microbiological contamination and the measures to be taken.

Electrical circuits should be identified, and a record maintained of the load on each circuit to prevent inadvertent overload.

Documentation

Good Documentation Practices are an essential part of quality assurance and GMP.

It is important for a manufacturer to get the documentation right in order to get the product right.

GMP Documentation e.g. Site Master File, Specifications, Batch Manufacturing Formulae, Batch Manufacturing Records, Processing, Labelling, Packaging, Testing Instructions, Standard Operating Procedures, Protocols, Technical Agreements, Records, Certificates of Analysis, Reports etc. should contain the following attributes of a good document:

They should be:

  • Attributable
  • Legible
  • Contemporaneous
  • Original
  • Accurate
  • Complete
  • Durable
  • Corroborated
  • Version Based
  • Accessible
  • And Authorized

Change Control

Change to GMP documentation, equipment, processes, systems, instrumentation, test methods, etc. are required to be controlled under a formal change control program.

This program must consist of Quality oversight to review the proposed changes, evaluate the potential impact of the change, determine any potential risk to product quality, and to establish the required level of supplemental validation/documentation required for the change.

In many instances, changes will also require submission to the Health Authority for approval of the change.

For example, changes impacting the submission documentation are subject to post approval change guidances according to the Health Authority regulations.

Change Control is a critical aspect of the GMP systems.

If you want to learn more about cGMP or if you want to evaluate our eLearning module for your company you can find more information here.

0
shares

Similar articles:

The enduring assets of a laboratory’s work are the records that document those activities. When laboratory records are used to support a regulatory function, they are considered to be legal documents.

Laboratory Data Integrity – eLearning Course

 

For records to be considered reliable and trustworthy they must comply with the following criteria:

  • Legible and Understandable – they must be able to be read and understood for the lifetime of the record, without having to refer to the originator for clarification. The information may be needed in five, ten or twenty years’ time, perhaps after the originator is no longer available
  • Attributable – who made the record or created the data and when?
  • Contemporaneous – the record must be made at the time the activity was performed
  • Original – the information must not be written on a post-it, piece of scrap paper, sleeve of a lab coat etc. and then transcribed.
  • Accurate – no errors or editing without documented amendments
  • Complete – All the information and data associated with the analysis is included
  • Consistent – All elements in the sequence of analysis must be date & time stamped and must be in the expected order
  • Indelible – Records are made on to controlled documents, such as laboratory notebooks or controlled worksheets, or saved to electronic media
  • Available – over the entire lifetime of the record for review, audit and inspection

1. Legible and Understandable

A record that cannot be read or understood has no value and might as well not exist. All records should be composed so they conform to grammatical convention which should be consistent throughout.

It is best to avoid buzzwords, cliques and slang as these are prone to change with time and are often not understood outside a particular locality. It is always good practice to have any record reviewed by a second person as this can often highlight any ambiguities.

2. Attributable

The identity of the person creating a record should be documented. For paper records this is normally done by the individual signing and dating the record with their signature.

As the record you may be signing may be a legal document, you should clearly understand the implication of your signature. A signature should be individual to a specific individual and the practice of signing someone else’s name or initials is fraud, and is taken very seriously.

3. Contemporaneous

All records must be made at the time an activity takes place. Delaying writing up, for example until the end of the day, will inevitably affect the accuracy of that record as details can be forgotten or miss-remembered.

4. Original

All records must be original; information must be recorded directly onto the document. This avoids the potential of introducing errors in transcribing information between documents.

If information from an instrument is printed out, by the instrument, that printout is the original record and should be signed, dated and attached to the record.

5. Accurate

The record must reflect what actually happened. Any changes should be made without obscuring or obliterating the original information, the use of whiteout or correction fluid is prohibited.

Any changes made to a record should be signed by the person making the change and dated to show when it was made and a written explanation should also be provided. Remember, the record may be needed after you have left the company and cannot be contacted for clarification.

6. Complete

The record must contain all information associated with the analysis of the sample, including system suitability tests, injection sequences, processing methods, sample preparation procedures and results.
This must also include any reinjections or repeat analysis performed on the sample.

Remember the position of the regulatory authorities for something that needs to be done is – ‘if it isn’t documented it’s a rumour’. However, failing to disclose reanalysis or reinjection of samples will undermine confidence in the reliability of the records.

7. Consistent

Consistency in this context refers to the sequence of the component events, which the analytical method comprises, being performed in a logical order.

For example it is not possible to commence the HPLC run before the samples have been prepared, therefore the balance printout for the sample weights should be date/time stamped at least one or two hours prior to the sample injection time, to allow time to prepare the samples. Therefore all date/time stamps should be in the expected sequence.

In order to avoid confusion in this respect, it is worth ensuring all instruments that produce date/time stamped printouts are time synchronised. This is best done by reference to a standard reference time, such as a national online time server.

8. Indelible

Indelible means the record must be legible for the lifetime of the record and once it has been made it cannot be removed.

Hand written entries of information should be made in ink and not pencil which can be erased

If printouts are made on thermal paper, which darkens with time, a photocopy should be made; this should be certified as an accurate copy of the original print and attached

If print outs are attached to a page they should be

  • Secured to the page with acid free glue and industrial strength Sellotape
  • Signed and dated across the attachment and the page
  • Annotated with a reference to the document

9. Available

All records should be available for inspection, audit and review for the lifetime of the document. If a document is requested during a regulatory audit, it should be produced within thirty minutes.

Therefore, the laboratory should establish an easy to reference archive system. Records should be archived so as to preserve their integrity, such as

  • Secure facility with restricted access
  • Effective fire suppression
  • Protection from dampness or humidity
  • Controlled access to Document

Check Out Our Laboratory Data Integrity eLearning Module

If you are looking for a way to train your staff on the importance of data integrity in a regulated environment check out oureLearning Course.

0
shares

Similar articles: