Quality Management System Documents
A well-written document with a comprehensive and well-designed Quality Management System (QMS) can be a manager’s best friend. They are our daily guidance and instructions for our staff, the ‘go-to’ during an audit or inspection, and the first reference point when inducting new staff. But getting to a ‘good’ document like a form or Standard Operating Procedure (SOP) can be a challenge.
I am routinely invited to perform usability and compliance assessments on quality management systems after regulatory inspections, especially with the heightened regulatory focus on Data Integrity. The observations are usually related to conflicting information within the Quality Management System, poor form design, or users finding it too hard to comprehend and follow procedures. These types of observations are generally common, systemic issues with the usability (how easily can people follow what is written) of core quality management system procedures and/or Work Instructions (WIs), ambiguous information which leads to conflicting requirements. What starts as poor technical writing can become a major compliance problem or worse, a mistake that affects the patient.
One of the challenges when remediating poorly written quality system SOPs and WIs is that quality management systems contain hundreds, if not thousands of documents. Changes to any of them must be considered with care.
A second challenge is that senior management needs to support these projects and this layer of the organisation do not generally need to rely on SOPs and WIs to perform their routine tasks. Often the business driver for well-written procedures is often not triggered until there is a compliance issue to facilitate change.
Where to start?
There are many actions that businesses can take to improve their quality systems documents.
1.How can you expect good document writing if your staff aren’t trained in what ‘good’ looks like? Establish standardised training for your technical writers:
- Ensure your writers have adequate literacy, computer and communication skills to be designated as a technical writer.
- Train your writers in process mapping so they understand the relationship between processes and writing logical sequential SOPs and WIs.
- Make writing in Plain Language a company policy, after all it is legislated in the US through the Plain Writing Act of 2010, this means the US FDA is subject to this international standard, why not your company too?
- Ensure your technical writers understand that unambiguous writing is a regulatory requirement. PIC/S PE 009 Chapter 4 on Documentation has a clause that states: “Documents containing instructions should be laid out in an orderly fashion and be easy to check. The style and language of documents should fit with their intended use. Standard Operating Procedures, Work Instructions and Methods should be written in an imperative mandatory style.”
2. Ensure you have a documented and defined document hierarchy clearly describing the function of each controlled document and the information expected in each. Standard must be common across the whole business e.g.
- SOPs describe the ‘what, when where and who’ and may cover several departments and the process may occur over time.
- A Work Instruction is intended to be used “on the job” and leads users step-by-step through actions to complete a task.
- Ensure you have clearly defined information types with clear direction for which information type goes into which document, without this your technical writers do not know which template they should be using when they sit down to write.
3. There should be a ‘single source of truth’ in your quality system. That means GMP information should only appear in one document hence reducing the likelihood of conflicting information over time.
4. Ensure you have controlled templates for all of your controlled documents including SOPs, WIs, forms, reports etc.
5. Develop a company Style Guide which leads your writers through the expected Styles including Fonts, use of bullets, tables and writing in active language. Provide examples of ‘good’ in the guide so people understand what is expected of them.
6. Train your document reviewers and approvers in the Style Guide so they can include readability and usability in their GMP review.
7. Ensure senior management (decision makers, document approvers) understand the difference between personal preference and the function of the quality system. How we are taught to write during Science, Engineering or Medical degrees may not be what is required in an SOP or WI. Remember that quality systems documents are written for the end-users which includes both regulators and our operators.
8. Ensure you have strong leadership to keep your writing standards in place. Often companies invest in improvement projects then the resources and focus fades over time. Your quality system leaders should be an ongoing champions for writing standards.
9. Use professional technical writers that can improve the quality of documents. This will free up your technical experts so they can provide input, but not lose manufacturing time while they are sitting, and Subject Matter Experts (SMEs) are not always the best people to write down what they do. Sometimes our SMEs are brilliant at setting up a filling line but not great with writing in plain language, or they are so close to the subject that hit ‘paralysis by analysis’ because they know so much where they can start.
10. Respect the role that your SOPs and WIs play in your organisation. Too many times periodic reviews are rushed through, or sentences are edited into SOPs to appease an auditor/inspector which render the document confusing. Do not forget that a well written quality management system is a key business tool helping to ensure compliance, speed up training time, reduce errors and waste.
If you looking for help with your Pharmaceutical or Medical Device Quality Management System read follow this link or why not give us a call to have a few minutes on the phone? We are happy to help.
If you want to read more on similar topics, the following blogs may also be of interest: