1. Define intended use and the record boundary
State what the configured system will calculate, decide, review, approve, retain, and exchange. Identify the assays, reportable results, users, sites, environments, source files, methods, calculations, review steps, reports, retention needs, and downstream systems in scope.
Trace one analysis from the plate-reader source through import, mapping, concentration derivation, model fitting, suitability, exclusions, review, any signature, report, and downstream filing. Name the system and process owner responsible for each record and transfer.
2. Write requirements and rank the risks
Turn intended use into testable user and compliance requirements. For each requirement, identify failure modes and their potential effect on result accuracy, product or patient risk, record integrity, availability, and regulatory obligations.
Assign technical, procedural, or combined controls and the evidence needed to verify them. Risk determines depth and priority; it does not excuse an applicable requirement or replace an explicit acceptance criterion.
| Requirement area | Example configured-workflow question |
|---|---|
| Identity and authority | Can only the assigned role approve a method or review a result? |
| Scientific calculation | Does the approved data set return the expected result with the approved settings and units? |
| Record integrity | Do source identity, configuration, results, exclusions, decisions, and report remain linked and protected? |
| Retrieval and continuity | Can authorized users retrieve the complete record and recover service after a tested failure? |
| Interface | Are sent, received, rejected, retried, duplicate, and corrected records reconciled? |
3. Approve the exact configuration and operating controls
Record the product release, environment, authentication, organization roles, approved method versions, reader profiles, report settings, connected systems, retention arrangements, procedures, and training that define the implementation. Verify that application-enforced controls are actually configured as approved.
Establish configuration ownership and change control before testing. A protocol result cannot remain interpretable if settings can change without identity, assessment, and approval.
4. Assemble supplier and customer evidence by requirement
Assess the supplier and the evidence actually available for the exact release. Product requirements, architecture and data flow, security information, requirements-to-test traceability, verification results, known issues, release notes, operating guides, and verified examples can support requirements they directly address.
Build one traceability matrix from each customer requirement to the risk, configured control, accepted supplier evidence, planned customer test, procedure, and final result. Reliance on supplier testing should be explicit; customer testing should concentrate on the approved configuration, use-specific risks, procedures, and interfaces.
| Example requirement | Supplier evidence | Customer evidence |
|---|---|---|
| Only an approved method can produce a routine result. | Product rule and verification for method lifecycle and locked execution. | Configured role and method test using the customer approval procedure. |
| A known data set returns the approved relative-potency result. | Calculation requirements, automated verification, and expected-result fixture. | Expected-result test using the approved method, settings, units, and report. |
| The retained report identifies the exact source and configuration. | Report requirement, generation tests, and released report example. | Retrieval and review test in the approved filing procedure. |
5. Approve and execute the customer protocol
Approve the scope, responsibilities, environment, prerequisites, test data, steps, expected results, objective evidence, acceptance criteria, deviation process, and final-release rule before execution. Define protocol labels such as IQ, OQ, and PQ by purpose rather than assuming the labels prescribe universal tests.
Execute with qualified users in the relevant environment. Cover representative intended-use paths and risk-based failures: role boundaries, approved calculations and reports, invalid inputs, record retrieval, interfaces, interruptions, recovery, and procedural handoffs as applicable.
6. Resolve deviations and authorize—or reject—use
For every unexpected result or protocol departure, record the affected requirement, observed evidence, investigation, correction, retest authorization, impact, and disposition. Update traceability with the executed result; do not replace the failed observation with an unexplained passing rerun.
The final report identifies the implemented version and configuration, summarizes requirements and risks, supplier reliance, executed tests, deviations, residual gaps, procedures and training, and the approved decision. State whether the workflow is authorized for the intended use, authorized with named restrictions, or not accepted.
7. Maintain the validated state through change
Assess product releases, configuration and method changes, interfaces, procedures, incidents, and infrastructure changes against affected requirements, risks, and prior evidence. Select and approve proportionate regression testing or requalification before the changed workflow enters regulated use.
Retain access reviews, incident and recovery records, backup and restore evidence, interface monitoring, periodic reviews, training changes, and archive or retirement decisions. A validated state is maintained by controlled evidence, not by repeating the original label indefinitely.
Limits and where a controlled workflow helps
A purpose-built workflow can reduce the number of separately controlled records. Provenarium provides versioned methods, locked routine execution, authenticated review history, immutable reports, bounded comparison and trending, and exact-record method-approval signatures.
Those controls can support a customer assessment but do not replace it. Authorized Team users can describe intended use and operating context, inspect release-linked readiness, and generate an editable customer assurance package from the exact saved profile. The customer remains responsible for configured-workflow validation and the decision to authorize use.
Frequently asked questions
If the vendor has tested the software, is our deployment already validated?
No. Vendor requirements, verification, and release records can support the assessment, but the regulated organization still evaluates and approves the configured system for its intended use, environment, users, procedures, and interfaces.
Can a supplier evidence package replace customer testing?
It can support requirements the customer assesses and accepts, reducing unnecessary duplication. Customer evidence still addresses the approved configuration, procedures, users, interfaces, and use-specific risks.
Is Part 11 compliance the same as computerized-system validation?
No. They overlap but answer different questions. Computerized-system validation establishes fitness for intended use; a Part 11 assessment determines whether applicable electronic records and signatures have the required technical and procedural controls.
Does every update require full requalification?
Not automatically. Assess the release and configuration change against affected requirements, risks, records, interfaces, and prior evidence, then document the proportionate testing and approval needed before use.
Are IQ, OQ, and PQ documents always required?
Terminology and document structure vary. Define the required purpose, evidence, environment, responsibilities, and acceptance in the plan, then use protocol names that fit the organization’s quality system.
Primary references
- 21 CFR Part 11 — Electronic Records; Electronic SignaturesElectronic Code of Federal Regulations
- Part 11, Electronic Records; Electronic Signatures — Scope and ApplicationU.S. Food and Drug Administration
- Data Integrity and Compliance With Drug CGMPU.S. Food and Drug Administration
- Computerized Systems in Drug EstablishmentsU.S. Food and Drug Administration