The White Paper in the Quality System

Eventually there will be a thorny topic that needs to be teased out, directed at an audience beyond those involved. This isn’t quite a technical report, or a risk assessment or a program document. It is that chameleon, the white paper.

A white paper can play several important roles in a quality management system:

Establish standards and best practices: White papers can outline recommended procedures, methodologies, and standards for quality within an organization or industry. They can provide detailed guidance on implementing quality processes.
Educating stakeholders: White papers serve as educational tools to inform employees, management, and other stakeholders about quality principles, new technologies, or approaches to improving quality. They help build a shared understanding of quality objectives.
Problem-solving: White papers often follow a problem-solution structure, identifying quality issues and proposing detailed solutions backed by research and data. This can help organizations address specific quality challenges.
Documenting processes: As part of a quality management system, white papers can provide in-depth documentation of complex processes, procedures, or systems. This documentation is crucial for consistency and compliance.
Promoting continuous improvement: By presenting research findings and innovative approaches, white papers can drive continuous improvement efforts in quality management.
Supporting decision-making: The authoritative and data-driven nature of white papers makes them valuable resources for informed decision-making about quality initiatives.
Demonstrating expertise: For organizations, publishing white papers on quality topics can establish thought leadership and demonstrate expertise to clients, partners, and regulatory bodies.
Compliance support: In regulated industries, white papers can help explain how an organization’s quality system meets regulatory requirements or industry standards.
Change management: When implementing new quality processes or technologies, white papers can help communicate the rationale and benefits to stakeholders, supporting change management efforts.
Benchmarking: White papers often include industry data and best practices, allowing organizations to benchmark their quality performance against peers or industry standards.

White Papers and Standards

A standard in a quality system is a documented set of requirements, specifications, or guidelines that define the criteria for quality in processes, products, or services. They offer precise descriptions that serve as an objective basis for organizations and consumers to communicate and conduct business globally. Standards provide organizations with shared procedures, terminology, and expectations to meet stakeholder requirements.

A white paper usually defines what will end up being in a standard, or defends the decision making of the standard. It is a why document.

White Papers and the Program Level

The program is a document that maps requirements to show the various ways to interpret the requirements to specific needs. Program documents, like a validation master plan or contamination control strategy, define the strategic plan that tie the entire program into a pretty package. A white paper then provides more in-depth justification of the rationale.

White Papers are Outward Orientated

When we write a white paper we are usually taking all the decision making a team made and the rationale behind them. It is a place to draw together all those articles and consensus standards we utilized, all the internal technical studies and risk management. White papers are written often aimed for health authorities, auditors, clients and partners.

How to Write a White Paper

Clear goals and target audience

A well-defined purpose is crucial for any white paper. Ask yourself:

What do you want to achieve with this document?
Who is your primary audience? Common ones are health authorities, clients, other parts of the organization.
What action do you want readers to take after reading? Usually it answers questions, but other times there is a translation necessary (e.g. update SOPs)

Concise summary

The executive summary or abstract should:

Be no more than 200-250 words
Highlight the main problem, solution, and key takeaways
Entice the reader to delve into the full document

Strong introduction

A compelling introduction should:

Provide context for the topic
Establish the relevance and importance of the issue
Outline the structure of the paper
Hook the reader with an interesting fact, statistic, or scenario

Problem statement

When defining the problem:

Use data and real-world examples to illustrate its scope and impact
Explain why existing solutions were inadequate
Highlight the consequences of not addressing the issue

Well-researched content

To ensure credibility:

Use a mix of primary and secondary sources
Link to requirements and obligations (i.e. regulatory regulations, consensus standards, industry best practices)
Include recent data
Reference industry reports and academic studies
Conduct original research and risk management as appropriate

Solution(s)

When presenting solutions:

Explain the rationale behind each option
Discuss pros and cons objectively
Provide evidence of effectiveness, such as case studies or pilot results
Clearly state why the recommended or chosen solution is superior

Logical flow and structure

Organize your content with:

A clear, logical progression of ideas
Subheadings and sections for easy navigation
Transitional phrases between sections
A balance of text, visuals, and white space

Visual elements

Effective visuals can include:

Infographics summarizing key data
Process diagrams explaining complex concepts
Comparison charts for different solutions
Relevant photographs or illustrations

Conclusion and call-to-action

A strong conclusion will:

Recap the main points without introducing new information
Reinforce the urgency of addressing the problem
Provide clear, actionable next steps for the reader, as appropriate
Include contact information or resources for further engagement

References

Properly cite sources by:

Using a consistent citation style (e.g., APA, MLA)
Including a bibliography or reference list at the end
Using footnotes or endnotes for additional context if necessary

Objective tone

Maintain credibility by:

Using a professional, authoritative voice
Avoiding overly promotional language
Acknowledging potential limitations or challenges
Presenting a balanced view of the topic

Should Have, Could Have, and Would Have

Avoiding the Word Should in GxP Documents

Generally, it’s best to avoid using “should” in a GxP document (e.g., SOP, plan, report, etc.). The word “should” can come across as non-committal or indicate a preference rather than a firm intention or goal.

GxP Documents are meant to be clear, concise, and direct. A more definitive language and active voice are preferred.

When writing about your goals and plans, it’s better to use more confident and assertive language rather than tentative words like “should.”

If you need to express a goal or aspiration that isn’t mandatory, consider rephrasing it more directly or using alternative constructions that show commitment and motivation.

Focus on using active voice and present tense verbs to describe your experiences, goals, and reasons for applying to the program.

Remember that a GxP Document, like a plan or SOP, is your opportunity to demonstrate your clarity of purpose and commitment. Using more decisive language can help convey this.

In summary, while “should” might be appropriate in some contexts, it’s generally best to avoid it in a GxP document in favor of more direct and confident language that propels into action.

Modals of Lost Opportunity

The term “modals of lost opportunity” refers to the modal verbs should have, could have, and would have. These modals express regret or hypothetical scenarios about past events that did not occur. They allow speakers to reflect on what might have been different if specific actions had been taken. They can be used in business and technical writing to express regret, hypothetical scenarios, and constructive feedback. But they should be used very carefully in GxP writing.

Should have indicates that a different action was recommended or expected in the past. It often implies a sense of regret or criticism about what was done or not done.

Example: “I should have left my house earlier.” This implies that leaving earlier would have been the better choice, possibly to avoid being late.

Could have is used to talk about possibilities or abilities that existed in the past but were not realized. It often reflects on missed opportunities or potential outcomes that did not happen.

Example: “If I had gone to college, I could have gotten a better job.” This suggests that attending college was a possibility that could have led to a better job, but it did not happen.

Would have is used to imagine a specific result that would have occurred if a different action had been taken. It often expresses a more certain outcome compared to “could have.”

Example: “If we had arrived earlier, we would have caught our flight.” This indicates that arriving earlier would have definitely resulted in catching the flight.

Usage in Sentences

Should Have: “You should have completed your training.” This implies that training was the recommended action that was not taken.
Could Have: “She could have won the race if she hadn’t fallen.” This suggests that winning was a possible outcome if not for the fall.
Would Have: “I would have called you, but I didn’t know your number.” This indicates a definite action that would have occurred if the number was known.

Documents and the Heart of the Quality System

A month back on LinkedIn I complained about a professional society pushing the idea of a document-free quality management system. This has got to be one of my favorite pet peeves that come from Industry 4.0 proponents, and it demonstrates a fundamental failure to understand core concepts. And frankly one of the reasons why many Industry/Quality/Pharma 4.0 initiatives truly fail to deliver. Unfortunately, I didn’t follow through with my idea of proposing a session to that conference, so instead here are my thoughts.

Fundamentally, documents are the lifeblood of an organization. But paper is not. This is where folks get confused. But fundamentally, this confusion is also limiting us.

Let’s go back to basics, which I covered in my 2018 post on document management.

When talking about documents, we really should talk about function and not just by name or type. This allows us to think more broadly about our documents and how they function as the lifeblood.

There are three types of documents:

Functional Documents provide instructions so people can perform tasks and make decisions safely effectively, compliantly, and consistently. This usually includes things like procedures, process instructions, protocols, methods, and specifications. Many of these need some sort of training decision. Functional documents should involve a process to ensure they are up-to-date, especially in relation to current practices and relevant standards (periodic review)
Records provide evidence that actions were taken, and decisions were made in keeping with procedures. This includes batch manufacturing records, logbooks and laboratory data sheets and notebooks. Records are a popular target for electronic alternatives.
Reports provide specific information on a particular topic on a formal, standardized way. Reports may include data summaries, findings, and actions to be taken.

The beating heart of our quality system brings us from functional to record to reports in a cycle of continuous improvement.

Functional documents are how we realize requirements, that is the needs and expectations of our organization. There are multiple ways to serve up the functional documents, the big three being paper, paper-on-glass, and some sort of execution system. That last, an execution system, united function with record, which is a big chunk of the promise of an execution system.

The maturation mind is to go from mostly paper execution, to paper-on-glass, to end-to-end integration and execution to drive up reliability and drive out error. But at the heart, we still have functional documents, records, and reports. Paper goes, but the document is there.

So how is this failing us?

Any process is a way to realize a set of requirements. Those requirements come from external (regulations, standards, etc) and internal (efficiency, business needs) sources. We then meet those requirements through People, Procedure, Principles, and Technology. They are interlinked and strive to deliver efficiency, effectiveness, and excellence.

So this failure to understand documents means we think we can solve this through a single technology application. an eQMS will solve problems in quality events, a LIMS for the lab, an MES for manufacturing. Each of these is a lever for change but alone cannot drive the results we want.

Because of the limitations of this thought process we get systems designed for yesterday’s problems, instead of thinking through towards tomorrow.

We get documentation systems that think of functional documents pretty much the same way we thought of them 30 years ago, as discrete things. These discrete things then interact through a gap with our electronic systems. There is little traceability, which complicates change control and makes it difficult to train experts. The funny thing, is we have the pieces, but because of the limitations of our technology we aren’t leveraging them.

The v-model approach should be leveraged in a risk-based manner to the design of our full system, and not just our technical aspects.

System feasibility matches policy and governance, user requirements allow us to trace to what elements are people, procedure, principles, and/or technology. Everything then stems from there.

Jargon and business terms

“Does your office have a jargon problem?“

The answer is inevitably yes.

In the quality profession we need to be careful to differentiate between jargon, slang, and technical terminology. Avoid the faddish and those terms that require socialization to learn and we’re usually doing okay.

The article from HBR above gives some good advice for striving to communicate as widely as possible. A good thing to think about as we get ready to start a new week.