Draft Annex 11 Section 6: System Requirements—When Regulatory Guidance Becomes Validation Foundation

The pharmaceutical industry has operated for over a decade under the comfortable assumption that GAMP 5’s risk-based guidance for system requirements represented industry best practice—helpful, comprehensive, but ultimately voluntary. Section 6 of the draft Annex 11 moves many things from recommended to mandated. What GAMP 5 suggested as scalable guidance, Annex 11 codifies as enforceable regulation. For computer system validation professionals, this isn’t just an update—it’s a fundamental shift from “how we should do it” to “how we must do it.”

This transformation carries profound implications that extend far beyond documentation requirements. Section 6 represents the regulatory codification of modern system engineering practices, forcing organizations to abandon the shortcuts, compromises, and “good enough” approaches that have persisted despite GAMP 5’s guidance. More significantly, it establishes system requirements as the immutable foundation of validation rather than merely an input to the process.

For CSV experts who have spent years evangelizing GAMP 5 principles within organizations that treated requirements as optional documentation, Section 6 provides regulatory teeth that will finally compel comprehensive implementation. However, it also raises the stakes dramatically—what was once best practice guidance subject to interpretation becomes regulatory obligation subject to inspection.

The Mandatory Transformation: From Guidance to Regulation

6.1: GMP Functionality—The End of Requirements Optionality

The opening requirement of Section 6 eliminates any ambiguity about system requirements documentation: “A regulated user should establish and approve a set of system requirements (e.g. a User Requirements Specification, URS), which accurately describe the functionality the regulated user has automated and is relying on when performing GMP activities.”

This language transforms what GAMP 5 positioned as risk-based guidance into regulatory mandate. The phrase “should establish and approve” in regulatory context carries the force of “must“—there is no longer discretion about whether to document system requirements. Every computerized system touching GMP activities requires formal requirements documentation, regardless of system complexity, development approach, or organizational preference.

The scope is deliberately comprehensive, explicitly covering “whether a system is developed in-house, is a commercial off-the-shelf product, or is provided as-a-service” and “independently on whether it is developed following a linear or iterative software development process.” This eliminates common industry escapes: cloud services can’t claim exemption because they’re external; agile development can’t avoid documentation because it’s iterative; COTS systems can’t rely solely on vendor documentation because they’re pre-built.

The requirement for accuracy in describing “functionality the regulated user has automated and is relying on” establishes a direct link between system capabilities and GMP dependencies. Organizations must explicitly identify and document what GMP activities depend on system functionality, creating traceability between business processes and technical capabilities that many current validation approaches lack.

Major Strike Against the Concept of “Indirect”

The new draft Annex 11 explicitly broadens the scope of requirements for user requirements specifications (URS) and validation to cover all computerized systems with GMP relevance—not just those with direct product or decision-making impact, but also indirect GMP systems. This means systems that play a supporting or enabling role in GMP activities (such as underlying IT infrastructure, databases, cloud services, SaaS platforms, integrated interfaces, and any outsourced or vendor-managed digital environments) are fully in scope.

Section 6 of the draft states that user requirements must “accurately describe the functionality the regulated user has automated and is relying on when performing GMP activities,” with no exemption or narrower definition for indirect systems. It emphasizes that this principle applies “regardless of whether a system is developed in-house, is a commercial off-the-shelf product, or is provided as-a-service, and independently of whether it is developed following a linear or iterative software development process.” The regulated user is responsible for approving, controlling, and maintaining these requirements over the system’s lifecycle—even if the system is managed by a third party or only indirectly involved in GMP data or decision workflows.

Importantly, the language and supporting commentaries make it clear that traceability of user requirements throughout the lifecycle is mandatory for all systems with GMP impact—direct or indirect. There is no explicit exemption in the draft for indirect GMP systems. Regulatory and industry analyses confirm that the burden of documented, risk-assessed, and lifecycle-maintained user requirements sits equally with indirect systems as with direct ones, as long as they play a role in assuring product quality, patient safety, or data integrity.

In practice, this means organizations must extend their URS, specification, and validation controls to any computerized system that through integration, support, or data processing could influence GMP compliance. The regulated company remains responsible for oversight, traceability, and quality management of those systems, whether or not they are operated by a vendor or IT provider. This is a significant expansion from previous regulatory expectations and must be factored into computerized system inventories, risk assessments, and validation strategies going forward.

9 Pillars of a User Requirements

Pillar	Description	Practical Examples
Operational	Requirements describing how users will operate the system for GMP tasks.	Workflow steps, user roles, batch record creation.
Functional	Features and functions the system must perform to support GMP processes.	Electronic signatures, calculation logic, alarm triggers.
Data Integrity	Controls to ensure data is complete, consistent, correct, and secure.	Audit trails, ALCOA+ requirements, data record locking.
Technical	Technical characteristics or constraints of the system.	Platform compatibility, failover/recovery, scalability.
Interface	How the system interacts with other systems, hardware, or users.	Equipment integration, API requirements, data lakes
Performance	Speed, capacity, or throughput relevant to GMP operations.	Batch processing times, max concurrent users, volume limits.
Availability	System uptime, backup, and disaster recovery necessary for GMP.	99.9% uptime, scheduled downtime windows, backup frequency.
Security	How access is controlled and how data is protected against threats.	Password policy, MFA, role-based access, encryption.
Regulatory	Explicit requirements imposed by GMP regulations and standards.	Part 11/Annex 11 compliance, data retention, auditability.

6.2: Extent and Detail—Risk-Based Rigor, Not Risk-Based Avoidance

Section 6.2 appears to maintain GAMP 5’s risk-based philosophy by requiring that “extent and detail of defined requirements should be commensurate with the risk, complexity and novelty of a system.” However, the subsequent specifications reveal a much more prescriptive approach than traditional risk-based frameworks.

The requirement that descriptions be “sufficient to support subsequent risk analysis, specification, design, purchase, configuration, qualification and validation” establishes requirements documentation as the foundation for the entire system lifecycle. This moves beyond GAMP 5’s emphasis on requirements as input to validation toward positioning requirements as the definitive specification against which all downstream activities are measured.

The explicit enumeration of requirement types—”operational, functional, data integrity, technical, interface, performance, availability, security, and regulatory requirements”—represents a significant departure from GAMP 5’s more flexible categorization. Where GAMP 5 allows organizations to define requirement categories based on system characteristics and business needs, Annex 11 mandates coverage of nine specific areas regardless of system type or risk level.

This prescriptive approach reflects regulatory recognition that organizations have historically used “risk-based” as justification for inadequate requirements documentation. By specifying minimum coverage areas, Section 6 establishes a floor below which requirements documentation cannot fall, regardless of risk assessment outcomes.

The inclusion of “process maps and data flow diagrams” as recommended content acknowledges the reality that modern pharmaceutical operations involve complex, interconnected systems where understanding data flows and process dependencies is essential for effective validation. This requirement will force organizations to develop system-level understanding rather than treating validation as isolated technical testing.

6.3: Ownership—User Accountability in the Cloud Era

Perhaps the most significant departure from traditional industry practice, Section 6.3 addresses the growing trend toward cloud services and vendor-supplied systems by establishing unambiguous user accountability for requirements documentation. The requirement that “the regulated user should take ownership of the document covering the implemented version of the system and formally approve and control it” eliminates common practices where organizations rely entirely on vendor-provided documentation.

This requirement acknowledges that vendor-supplied requirements specifications rarely align perfectly with specific organizational needs, GMP processes, or regulatory expectations. While vendors may provide generic requirements documentation suitable for broad market applications, pharmaceutical organizations must customize, supplement, and formally adopt these requirements to reflect their specific implementation and GMP dependencies.

The language “carefully review and approve the document and consider whether the system fulfils GMP requirements and company processes as is, or whether it should be configured or customised” requires active evaluation rather than passive acceptance. Organizations cannot simply accept vendor documentation as sufficient—they must demonstrate that they have evaluated system capabilities against their specific GMP needs and either confirmed alignment or documented necessary modifications.

This ownership requirement will prove challenging for organizations using large cloud platforms or SaaS solutions where vendors resist customization of standard documentation. However, the regulatory expectation is clear: pharmaceutical companies cannot outsource responsibility for demonstrating that system capabilities meet their specific GMP requirements.

A horizontal or looping chain that visually demonstrates the lifecycle of system requirements from initial definition to sustained validation:

User Requirements → Design Specifications → Configuration/Customization Records → Qualification/Validation Test Cases → Traceability Matrix → Ongoing Updates

6.4: Update—Living Documentation, Not Static Archives

Section 6.4 addresses one of the most persistent failures in current validation practice: requirements documentation that becomes obsolete immediately after initial validation. The requirement that “requirements should be updated and maintained throughout the lifecycle of a system” and that “updated requirements should form the very basis for qualification and validation” establishes requirements as living documentation rather than historical artifacts.

This approach reflects the reality that modern computerized systems undergo continuous change through software updates, configuration modifications, hardware refreshes, and process improvements. Traditional validation approaches that treat requirements as fixed specifications become increasingly disconnected from operational reality as systems evolve.

The phrase “form the very basis for qualification and validation” positions requirements documentation as the definitive specification against which system performance is measured throughout the lifecycle. This means that any system change must be evaluated against current requirements, and any requirements change must trigger appropriate validation activities.

This requirement will force organizations to establish requirements management processes that rival those used in traditional software development organizations. Requirements changes must be controlled, evaluated for impact, and reflected in validation documentation—capabilities that many pharmaceutical organizations currently lack.

6.5: Traceability—Engineering Discipline for Validation

The traceability requirement in Section 6.5 codifies what GAMP 5 has long recommended: “Documented traceability between individual requirements, underlaying design specifications and corresponding qualification and validation test cases should be established and maintained.” However, the regulatory context transforms this from validation best practice to compliance obligation.

The emphasis on “effective tools to capture and hold requirements and facilitate the traceability” acknowledges that manual traceability management becomes impractical for complex systems with hundreds or thousands of requirements. This requirement will drive adoption of requirements management tools and validation platforms that can maintain automated traceability throughout the system lifecycle.

Traceability serves multiple purposes in the validation context: ensuring comprehensive test coverage, supporting impact assessment for changes, and providing evidence of validation completeness. Section 6 positions traceability as fundamental validation infrastructure rather than optional documentation enhancement.

For organizations accustomed to simplified validation approaches where test cases are developed independently of detailed requirements, this traceability requirement represents a significant process change requiring tool investment and training.

6.6: Configuration—Separating Standard from Custom

The final subsection addresses configuration management by requiring clear documentation of “what functionality, if any, is modified or added by configuration of a system.” This requirement recognizes that most modern pharmaceutical systems involve significant configuration rather than custom development, and that configuration decisions have direct impact on validation scope and approaches.

The distinction between standard system functionality and configured functionality is crucial for validation planning. Standard functionality may be covered by vendor testing and certification, while configured functionality requires user validation. Section 6 requires this distinction to be explicit and documented.

The requirement for “controlled configuration specification” separate from requirements documentation reflects recognition that configuration details require different management approaches than functional requirements. Configuration specifications must reflect the actual system implementation rather than desired capabilities.

Comparison with GAMP 5: Evolution Becomes Revolution

Philosophical Alignment with Practical Divergence

Section 6 maintains GAMP 5’s fundamental philosophy—risk-based validation supported by comprehensive requirements documentation—while dramatically changing implementation expectations. Both frameworks emphasize user ownership of requirements, lifecycle management, and traceability as essential validation elements. However, the regulatory context of Annex 11 transforms voluntary guidance into enforceable obligation.

GAMP 5’s flexibility in requirements categorization and documentation approaches reflects its role as guidance suitable for diverse organizational contexts and system types. Section 6’s prescriptive approach reflects regulatory recognition that flexibility has often been interpreted as optionality, leading to inadequate requirements documentation that fails to support effective validation.

The risk-based approach remains central to both frameworks, but Section 6 establishes minimum standards that apply regardless of risk assessment outcomes. While GAMP 5 might suggest that low-risk systems require minimal requirements documentation, Section 6 mandates coverage of nine requirement areas for all GMP systems.

Documentation Structure and Content

GAMP 5’s traditional document hierarchy—URS, Functional Specification, Design Specification—becomes more fluid under Section 6, which focuses on ensuring comprehensive coverage rather than prescribing specific document structures. This reflects recognition that modern development approaches, including agile and DevOps practices, may not align with traditional waterfall documentation models.

However, Section 6’s explicit enumeration of requirement types provides more prescriptive guidance than GAMP 5’s flexible approach. Where GAMP 5 might allow organizations to define requirement categories based on system characteristics, Section 6 mandates coverage of operational, functional, data integrity, technical, interface, performance, availability, security, and regulatory requirements.

The emphasis on process maps, data flow diagrams, and use cases reflects modern system complexity where understanding interactions and dependencies is essential for effective validation. GAMP 5 recommends these approaches for complex systems; Section 6 suggests their use “where relevant” for all systems.

Vendor and Service Provider Management

Both frameworks emphasize user responsibility for requirements even when vendors provide initial documentation. However, Section 6 uses stronger language about user ownership and control, reflecting increased regulatory concern about organizations that delegate requirements definition to vendors without adequate oversight.

GAMP 5’s guidance on supplier assessment and leveraging vendor documentation remains relevant under Section 6, but the regulatory requirement for user ownership and approval creates higher barriers for simply accepting vendor-provided documentation as sufficient.

Implementation Challenges for CSV Professionals

Organizational Capability Development

Most pharmaceutical organizations will require significant capability development to meet Section 6 requirements effectively. Traditional validation teams focused on testing and documentation must develop requirements engineering capabilities comparable to those found in software development organizations.

This transformation requires investment in requirements management tools, training for validation professionals, and establishment of requirements governance processes. Organizations must develop capabilities for requirements elicitation, analysis, specification, validation, and change management throughout the system lifecycle.

The traceability requirement particularly challenges organizations accustomed to informal relationships between requirements and test cases. Automated traceability management requires tool investments and process changes that many validation teams are unprepared to implement.

Integration with Existing Validation Approaches

Section 6 requirements must be integrated with existing validation methodologies and documentation structures. Organizations following traditional IQ/OQ/PQ approaches must ensure that requirements documentation supports and guides qualification activities rather than existing as parallel documentation.

The requirement for requirements to “form the very basis for qualification and validation” means that test cases must be explicitly derived from and traceable to documented requirements. This may require significant changes to existing qualification protocols and test scripts.

Organizations using risk-based validation approaches aligned with GAMP 5 guidance will find philosophical alignment with Section 6 but must adapt to more prescriptive requirements for documentation content and structure.

Technology and Tool Requirements

Effective implementation of Section 6 requirements typically requires requirements management tools capable of supporting specification, traceability, change control, and lifecycle management. Many pharmaceutical validation teams currently lack access to such tools or experience in their use.

Tool selection must consider integration with existing validation platforms, support for regulated environments, and capabilities for automated traceability maintenance. Organizations may need to invest in new validation platforms or significantly upgrade existing capabilities.

The emphasis on maintaining requirements throughout the system lifecycle requires tools that support ongoing requirements management rather than just initial documentation. This may conflict with validation approaches that treat requirements as static inputs to qualification activities.

Strategic Implications for the Industry

Convergence of Software Engineering and Pharmaceutical Validation

Section 6 represents convergence between pharmaceutical validation practices and mainstream software engineering approaches. Requirements engineering, long established in software development, becomes mandatory for pharmaceutical computerized systems regardless of development approach or vendor involvement.

This convergence benefits the industry by leveraging proven practices from software engineering while maintaining the rigor and documentation requirements essential for regulated environments. However, it requires pharmaceutical organizations to develop capabilities traditionally associated with software development rather than manufacturing and quality assurance.

The result should be more robust validation practices better aligned with modern system development approaches and capable of supporting the complex, interconnected systems that characterize contemporary pharmaceutical operations.

Vendor Relationship Evolution

Section 6 requirements will reshape relationships between pharmaceutical companies and system vendors. The requirement for user ownership of requirements documentation means that vendors must support more sophisticated requirements management processes rather than simply providing generic specifications.

Vendors that can demonstrate alignment with Section 6 requirements through comprehensive documentation, traceability tools, and support for user customization will gain competitive advantages. Those that resist pharmaceutical-specific requirements management approaches may find their market opportunities limited.

The emphasis on configuration management will drive vendors to provide clearer distinctions between standard functionality and customer-specific configurations, supporting more effective validation planning and execution.

The Regulatory Codification of Modern Validation

Section 6 of the draft Annex 11 represents the regulatory codification of modern computerized system validation practices. What GAMP 5 recommended through guidance, Annex 11 mandates through regulation. What was optional becomes obligatory; what was flexible becomes prescriptive; what was best practice becomes compliance requirement.

For CSV professionals, Section 6 provides regulatory support for comprehensive validation approaches while raising the stakes for inadequate implementation. Organizations that have struggled to implement effective requirements management now face regulatory obligation rather than just professional guidance.

The transformation from guidance to regulation eliminates organizational discretion about requirements documentation quality and comprehensiveness. While risk-based approaches remain valid for scaling validation effort, minimum standards now apply regardless of risk assessment outcomes.

Success under Section 6 requires pharmaceutical organizations to embrace software engineering practices for requirements management while maintaining the documentation rigor and process control essential for regulated environments. This convergence benefits the industry by improving validation effectiveness while ensuring compliance with evolving regulatory expectations.

The industry faces a choice: proactively develop capabilities to meet Section 6 requirements or reactively respond to inspection findings and enforcement actions. For organizations serious about digital transformation and validation excellence, Section 6 provides a roadmap for regulatory-compliant modernization of validation practices.

Requirement Area	Draft Annex 11 Section 6	GAMP 5 Requirements	Key Implementation Considerations
System Requirements Documentation	Mandatory – Must establish and approve system requirements (URS)	Recommended – URS should be developed based on system category and complexity	Organizations must document requirements for ALL GMP systems, regardless of size or complexity
Risk-Based Approach	Extent and detail must be commensurate with risk, complexity, and novelty	Risk-based approach fundamental – validation effort scaled to risk	Risk assessment determines documentation detail but cannot eliminate requirement categories
Functional Requirements	Must include 9 specific requirement types: operational, functional, data integrity, technical, interface, performance, availability, security, regulatory	Functional requirements should be SMART (Specific, Measurable, Achievable, Realistic, Testable)	All 9 areas must be addressed; risk determines depth, not coverage
Traceability Requirements	Documented traceability between requirements, design specs, and test cases required	Traceability matrix recommended – requirements linked through design to testing	Requires investment in traceability tools and processes for complex systems
Requirement Ownership	Regulated user must take ownership even if vendor provides initial requirements	User ownership emphasized, even for purchased systems	Cannot simply accept vendor documentation; must customize and formally approve
Lifecycle Management	Requirements must be updated and maintained throughout system lifecycle	Requirements managed through change control throughout lifecycle	Requires ongoing requirements management process, not just initial documentation
Configuration Management	Configuration options must be described in requirements; chosen configuration documented in controlled spec	Configuration specifications separate from URS	Must clearly distinguish between standard functionality and configured features
Vendor-Supplied Requirements	Vendor requirements must be reviewed, approved, and owned by regulated user	Supplier assessment required – leverage supplier documentation where appropriate	Higher burden on users to customize vendor documentation for specific GMP needs
Validation Basis	Updated requirements must form basis for system qualification and validation	Requirements drive validation strategy and testing scope	Requirements become definitive specification against which system performance is measured

GMP Critical System

Defining a GMP critical system is an essential aspect of Good Manufacturing Practices (GMP) in the pharmaceutical and medical device industries. A critical system is one that has a direct impact on product quality, safety, and efficacy.

Key Characteristics of GMP Critical Systems

Direct Impact on Product Quality: A critical system is one that can directly affect the quality, safety, or efficacy of the final product.
Influence on Patient Safety: Systems that have a direct or indirect influence on patient safety are considered critical. This is where CPPs come in
Data Integrity: Systems that generate, store, or process data used to determine product SISPQ (e.g. batch quality or are included in batch processing records, stability, data used in a regulatory filing) are critical.
Decision-Making Role: Systems used in the decision process for product release or a regulatory filing are considered critical.
Contact with Products: Equipment or devices that may come into contact with products are often classified as critical.

Continuous Evaluation

It’s important to note that the criticality of systems should be periodically evaluated to ensure they remain in a valid state and compliant with GMP requirements. This includes reviewing the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security, and validation status reports.

Requirements on Privacy in Clinical Trials

Been thinking a lot recently of privacy in regard to clinical trials. As you do, I started with gathering some requirements together. Here is what I have:

Brief Standard Identifier	Description of Industry Standard	Regulation/Guidance/ Source
Subject Identification in Data Systems	The business has SOPs to ensure that data collection instruments and databases utilize an unambiguous subject identification code that allows identification and linkage of all the data reported for each subject. Data tools and systems do not contain personally identifiable information, except the unique subject identification code to link data across the study.	GCDMP – Data Privacy; ICH 5.5.5
Patient Diaries Review	The business has and utilizes SOPs to ensure that the Investigator site personnel review paper-based patient diaries prior to sending the diaries to Data Management to confirm that no personal identification information is present.	MHRA 8.2.7
Confidentiality of Subject Records	The business utilizes formal procedures and practices to ensure that the confidentiality of records that could identify subjects is protected in accordance with the applicable regulatory requirement(s).	ICH 2.11
Informed Consent Prior to Data Collection	The business has a process to establish expectations with the site and confirm that informed consent is obtained from every subject prior to clinical trial participation and prior to processing clinical data. The process should provide direction for withdrawal and revocation of consents.	ICH 2.9, 4.8.8, 6.5.3 21 CFR 50
Privacy and Personal Data Protection Policy	The business has a Privacy and Personal Data Protection Policy and a Chief Privacy Officer/ Data Protection Officer to ensure compliance with EU GDPR and other country, local, and Independent Ethics Committee-required privacy, and data protection practices.	US HIPAA EU 1995 Data Protection Directive 1995/45/EC EU GDPR 2016/679 Japan 2016 Act on the Protection of Personal Information- US Privacy Act
Privacy and Personal Data Protection Documented Practices	The business has documented procedures, standards, documentation requirements, and responsibilities for defining and ensuring confidentiality, protection, and security of personal data (including but not limited to employee, client, investigator, and patient data) and applying Privacy by Design requirements into procedures that include: definitions of personally-identifying information descriptions of personal information collected the purposes for which it is collected the lawful basis (in the EU) for its collection/use the types of persons to whom it will be released the countries to which it may be transferred privacy and security safeguards the rights of individuals with respect to their personal information compliance monitoring	US HIPAA EU Data Protection Directive 1995/45/EC EU GDPR 2016/679 Japan’s Law Concerning the Protection of Personal Information – 2005; Japan Act on the Protection of Personal Information- 2016
	The business has documented procedures, standards, documentation requirements, and responsibilities for conducting Privacy Impact Assessments, including when they are implemented, or documentation regarding why they are not applicable.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Personal Data Processing, De-identification and Pseudonymization	The business has documented procedures, standards, documentation requirements, and responsibilities for enhancing privacy and protecting personal data, both at the time of determining the means for processing data and at the time of actual processing, by adherence to the data minimization principle (i.e., ensuring that only data needed for a clinical trial are collected from clinical trial subjects’ records), encryption at rest and during transit, de-identification and pseudonymization. Where pseudonymization is deployed, the business has appropriate technical (e.g., encryption, hashing, or tokenization) and organizational (e.g., agreements, policies, privacy by design) measures in place to separate pseudonymous data from identification keys.	EU GDPR 2016/679
Personal Data Capture and Data Flow Procedures	The business has written procedures for documenting the data flow for the organization/for individual projects. The data flow comprises what personal data the organization holds, where it came from, and with whom they share it.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Individual Privacy Notice or Consent	Ensuring that individuals are informed of all required privacy provisions in Privacy Notice or Consent, including: their right to confirm if and how their data are processed, including the right to object to (or limit use of) processing and the right of erasure; plans for data retention; the right to receive a copy of their personal data and to have them transmitted to other organizations; and the complaint process.	US HIPAA EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Support for Personal Data Subject Requests	Receiving, processing, and responding to Personal Data Subject Requests submitted by Data Subjects per their rights under GDPR, and/or assisting the Client to fulfill Client’s obligation to do so: right of access right to rectification restriction of processing erasure (“right to be forgotten”)data portability objection to the processing, or the right not to be subject to automated individual decision making	EU GDPR 2016/679 Directive 1995/45/EC
Privacy and Personal Data Breach Procedures	Detecting, reporting, and investigating personal data breaches, and communicating confirmed data breaches to impacted parties within timelines dictated by applicable regulations (72 hours for regulatory authority reporting) and agreements. Sponsor will be notified of any data breach in association with sponsor projects, including breaches at subcontracted vendors, according to pre-defined timing.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679
Privacy and Personal Data Protection Training	The business trains all individuals who have access to personal data on the policy and practices that ensure confidentiality, protection, and security of personal data.	EU Data Protection Directive 1995/45/EC EU GDPR 2016/679

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.

Level of Effort for Planning

In the post “Design Lifecycle within PDCA – Planning” I laid out a design thinking approach to planning a change.

Like most activities, the level of effort is commensurate with the level of risk. Above I provide some different activities that can happen based on the risk inherent in the process and problem being evaluated.

This is a great reason why Living Risk Assessments are so critical to an organization.