If you work in a regulated environment then the work you do will be guided by the policies and procedures outlined in your Quality Management System (QMS). Typically the QMS documents are embodied as a set of Microsoft Word or PDF documents stored on an intranet or (think of the trees!) printed and placed in a giant binder.

Word is a bad tool for maintaining QMS documents

At TrialGrid we knew from the start that using Word to author our QMS was not going to work for us. Here are some reasons:

• Link management. A QMS is highly inter-linked so that a policy document references an SOP which references a work practice which in turn references a form template. Word documents were not designed to maintain those kinds of links.

• Review management. Documents in a QMS need to be reviewed and while Word provides excellent review tools you mostly end up emailing around different versions which then have to be manually reconciled.

• Formatting and layout. The infinite customizability of Word means that you have to maintain strict control over Word Templates so that authors use the correct heading and bullet styles. Consistency is important but the cost of maintaining it with Word is too high.

• Lack of searchability. You can search an individual Word document but if you want to search your entire QMS then you'll need 3rd party tools that can index and search the documents.

• Versioning. It is typical for every document in the QMS to have its own version and version history. Are you using the version of the Work Form that goes with the version of the SOP you're using?

Our conclusion? Word is the wrong tool for the job and investing in a document management system like Documentum or Sharepoint to try to make up for its shortcomings just compounds the wrongness.

The TrialGrid Approach : QMS as a Software Project

Our approach is to treat the QMS as a Software Project. We write all our documents in a markup language called reStructuredText. This is plain text with the use of *'s and other symbols to denote bold, italic, headings etc:

1
2
3
4
5
6
7

A Heading
=========

1. A **bold** bullet item.
2. An *italic* bullet item.

Refer to :ref:`this Procedures Index reference <procedures_index>`

We use a document generation system called Sphinx to collate all these plain text files into a hyperlinked website just like compiling a software application.

Benefits

• Treating documents as source code files means we can use software tools we are familiar with to compare and review changes. This includes capturing review comments and history to prove that our QMS content is being scrutinized - something that is very hard to do with Word documents.

• The automated construction of documents from source code means that all files have exactly the same formatting applied. No fighting with margins, no arguments over heading styles or indents. Total consistency.

• The build process checks references between documents and fails if they are not consistent. We spend minimal time maintaining links.

• Constant values can be defined and applied across all documents. For example, we define the company name as part of the configuration. This is automatically substituted into all the documents. Should we change the company name or the product name then we can change in a single place and regenerate the entire system and it will be consistent.

• The resulting website has full text search built in which makes navigating it really easy.

• We can use automation so that when a new version of the QMS "application" is approved and has passed all tests (e.g. link checking) then the website can be automatically generated and deployed - removing the old version from circulation.

• The QMS is versioned as a single unit, just like a software application. There is no individual document versioning, the entire QMS is versioned (e.g. version 6) and released as a unit.

Checking for Errors

Nothing is perfect and in a recent audit it was noticed that the footer on all our QMS pages was showing "Version 6" when the version history for the website showed it was version 8. We had updated the text revision history table but forgotten to change a value in the configuration. A small finding but embarrassing.

This can be easily fixed but how could we prevent this from happening again in the future? In a traditional QMS management process you would add a new line to a release checklist: "[ ] Check version number" but adding a checkbox to a manual checklist doesn't guarantee that the task is done and these kinds of checks build up like scar tissue in your process, reminding you of past wounds and slowing you down.

In our process we can fix this with software. We added a 20-line program to our build process that checks the latest (manually entered) value for the version in the revision history text file against the configuration value for the version. If they don't match, the build fails with an error message and it's clear what to do to fix it.

Summary

Managing a QMS as source code may not work for every organization but it is working well for us. Auditors accept that we have the QMS under appropriate management controls and are grateful for the ease of navigation and searchability of the content so overall we are glad we avoided Word for this use-case.

How do you manage your QMS?