TBD or Not TBD

Thursday, February 26, 2009

Documentation errors can turn the most promising deliverable into an auditing nightmare.  This nightmare can be avoided if the manufacturer considers simple, common sense documentation suggestions.

The following is my Top 10 list of documentation considerations.  This list does not cover every documentation issue but highlights some of the more common errors that I have seen during my tenure as a regulatory/quality engineer.

  1. Use of TBD  The use of TBD (to be determined) is perfectly acceptable especially if document details are not completed until the end of the product life cycle.  However, if you choose to use TBD, be sure to include what needs to be determined, who is responsible for determining this information and when it is expected to be resolved.
  2. Use of N/A  Similar to TBD, the use of N/A (non-applicable) is very common especially when manufacturers are using templates that don’t always apply to every product development situation.  However, when using N/A, be sure to explain why it’s not applicable.  An auditor may think the information was not completed because the originator ran out of time.  Incidentally, one manufacturer tried to get away from explaining the N/As by removing them and shading the box.  Shading only works in hot weather.
  3. Referencing tables, graphs and page numbers  Spend some time looking at how the document is formatted.  If the text refers to Table A, make sure the table is not identified as Table 1.  If the header gives the number of pages, make sure it’s correct.  My favorite examples are documents that read Page 7 of 8, Page 8 of 8, Page 9 of 8, etc.
  4. Focus on facts not opinions  All too often I have read documents that included opinions such as “we were told to stop testing because of the schedule” and “the tests passed but I think we did them wrong.”  Issues should be resolved in a project team not in an auditable document. 
  5. Simple sentences  I think everyone has a bit of Hemingway in them. However, design and development documents are not the appropriate place to demonstrate this talent.  By using simple sentences, the quality of the document can improve substantially.
  6. Tell A Story  All good stories have a beginning, middle and end.  When writing a document, tell a good story.  On occasion, I have read documents that tried to cover too many issues and the reader got lost in the details.
  7. Determine number of approvals  Many people may have the responsibility of creating a deliverable but only a few should have the authority to approve it.  By keeping the number of signatures to a minimum, the documentation review process is faster and the approval process is consistent.
  8. What is a draft approval?  This is one of my favorites.  Some people thought if they wrote “draft” on their documents, it could not be audited.  They also have told approvers that there was no need to review the document in detail because it was only in “draft-form.”  If a documented is controlled in your document control system, it is not considered a draft.
  9. Pass/Fail/Pass  Nothing is perfect and it is very likely that certain tests will fail.  It is important to document these failures. However, when documenting the failure, include how the failure was resolved and how it was retested.  All too often, I have read reports that document the failures but conclude by saying the device passed all testing criteria.
  10. Next Steps  If a report shows next steps, be advise an auditor will ask how those next steps were resolved.  Next steps are similar to open issues and open issues are expected to be resolved.

The key to understanding good documentation practices is training and accountability.  Before documents are written, it doesn’t hurt for quality and regulatory personnel to spend time with the project team on how to write better documents.  Then once the documents are being written, it is important to work with the team to make sure common documentation errors are minimized.

By minimizing these errors, the look of the documents improve while the review will focus on the content rather than being distracted by the number of TBDs.

Tags: Best Practices, Documentation, QSR

Other Blog Authors

Mya Thomae
Dylan Reinhardt
Dave Kern
Steve Gutman

Recent Blog Posts

The Staple That Changed an Industry LDT regulation and the perils of challenging Eminem to a rap battle
FDA Releases the Kraken Whichever way this breaks, it's long past time to have this conversation in a meaningful way
Illumina Acquires Myraqa Acquisition Strengthens Illumina’s Clinical Readiness
The Spirit of GLP A Best Practice for IVDs
Process Performance Qualification (PPQ) Lots So, how many lots are required?
The Case for Risk-based Monitoring Better the devil you know...
Form Follows Function OIR Reorganizes to Meet the Advancing Wave of Molecular Diagnostics
CDRH Unveils New PMA Guidance Documents Attention shoppers, it's two-for-one day!