Start by separating four different questions

Assay validation, computerized-system validation, Part 11 assessment, and data-integrity review overlap, but each answers a different question and requires different evidence.

Verifying relative-potency calculations does not assess user access, and testing electronic signatures does not establish assay accuracy. A qualification protocol becomes evidence only after the responsible organization executes, reviews, and approves it.

QuestionWhat the evidence should establish
Analytical procedure validationThe assay can produce a result fit for its stated scientific purpose.
Computerized-system validationThe configured system performs its intended functions consistently and preserves the required records.
Part 11 assessmentApplicable electronic records and signatures have the necessary technical and procedural controls.
Data-integrity reviewData remain attributable, legible, contemporaneous, original or a verified true copy, accurate, complete, consistent, enduring, and available.

Define intended use and draw the system boundary

Write a concrete intended-use statement before choosing documents or tests. Identify the assays, reportable results, users, sites, environments, source files, approved methods, calculations, review steps, reports, retention needs, and downstream systems in scope.

Follow one analysis from the plate-reader export through import, plate mapping, concentration calculations, model fitting, suitability evaluation, exclusions, review, any required approval or signature, reporting, and transfer to a LIMS or ELN. Include every person, procedure, software component, infrastructure service, and interface that can affect the record.

  1. State what the system is used to calculate, decide, review, and retain.
  2. Name the regulated records and the system that controls each one.
  3. Identify configurations and interfaces that can change the result or its meaning.
  4. Identify which controls Provenarium provides and assign the remaining responsibilities to your organization or another service provider.

Evaluate the controls implemented in the application

Documentation cannot substitute for controls the application must enforce. Review how the configured system enforces user access, approved method use, record protection, change history, review and signatures, data retrieval, and interface behavior.

The exact requirements depend on intended use and applicable regulations. The examples below are control areas to assess, not a universal checklist or a claim that every use requires every feature.

Control areaBehavior to evaluate
Users and permissionsUnique identities, defined roles, appropriate permissions, and controlled access changes.
Methods and configurationControlled settings; draft, approved, superseded, or retired versions; and an identifiable method used for each run.
Run recordsSource data, mappings, settings, results, exclusions, suitability outcomes, reviews, and reports remain connected and protected.
Recorded change historyRelevant original and changed values, actor, time, reason, and relationship to the affected record are retained.
Review and signaturesReviewer identity, decision, meaning, intent, time, and record linkage are preserved where approvals or signatures are used.
Retrieval and exportComplete human-readable and electronic copies can be produced without losing context or meaning.
InterfacesTransfers expose status and errors and address duplicates, retries, reconciliation, corrections, and versioned data formats.

The Team plan includes product evidence and qualification templates

The Team plan provides evidence for the standard released product. Each document identifies the applicable product version, scope, status, owner, and approval so your organization can determine whether it applies to its configuration. For each release, Provenarium updates the affected documents or records why an update is not needed.

A useful package lets a customer understand what was built, which requirements were verified, what changed in a release, and which protocol steps still need to be performed in the customer environment.

Standard deliverableWhat it should explain
Product and system descriptionSupported use, components, deployment model, system boundary, and supported configurations.
Product requirementsThe functions and controls the standard product is designed to provide.
Architecture, data flow, and security descriptionWhere data enter, move, persist, leave, and which services protect them.
Requirements-to-test traceabilityLinks each product requirement to its verification record and identifies gaps or items that do not apply.
Verification resultsTest scope, environment, outcome, deviations, and approval for the released version.
Release notes and change assessmentWhat changed, affected requirements and risks, known issues, and areas customers should reassess.
Administration and operating guidesConfiguration, access, backup, retrieval, export, and routine use of supported functions.
Qualification protocol templatesSuggested installation, configuration, functional, and intended-use checks for customer execution.
Verified example data setsKnown inputs and expected outputs for confirming calculations and report behavior.

Your organization validates its configured workflow

The regulated organization owns the conclusion that the implemented system is suitable for its intended use. Provenarium product documents and test records can reduce duplicate effort, but they do not define the customer’s records, procedures, users, configurations, interfaces, risks, or acceptance decision.

The resulting records commonly include the items below, adjusted for the organization’s quality system, risk, and applicable requirements.

Customer recordCustomer-specific content
Applicability and scope assessmentApplicable records, regulations, sites, processes, systems, interfaces, and exclusions from scope.
Intended use and user requirementsWhat users must accomplish and what the configured workflow must control.
Risk and supplier assessmentFailure modes, patient/product/data impact, supplier reliance, and planned controls.
Approved configuration recordMethods, reports, roles, permissions, retention, integrations, and environment settings.
Validation or qualification planResponsibilities, deliverables, environments, testing, deviations, acceptance, and release approach.
Executed testsRepresentative intended-use cases, permissions, calculations, reports, interfaces, failures, retrieval, and recovery as applicable.
Deviations and final reportObserved issues, resolutions, residual risk, evidence summary, approval, and authorization for use.
Procedures and training recordsAdministration, use, review, signatures, change control, incidents, backup, retention, periodic review, and retirement.

Connect each requirement to product and customer evidence

Traceability becomes useful when a reviewer can move from an exact requirement to the application behavior, vendor verification, and customer test that support it. Broad statements such as “the system is validated” hide those connections.

If your organization has assessed and accepted Provenarium product evidence, customer tests need not repeat every product test. They should focus on the approved configuration, operating procedures, interfaces, and use-specific risks.

Example requirementVendor evidenceCustomer evidence
Only an approved method version may be used for a routine run.Product requirement, rules controlling method status and permissions, and verification results.Configured role and method test using the customer approval procedure.
A known relative-potency data set must return its approved expected result.Calculation requirements, automated verification, and verified example data.Expected-result test using the approved model, settings, units, and report template.
A LIMS transfer must preserve run ID, result, unit, method version, and status.Versioned interface specification and standard transfer/failure tests.End-to-end tests covering field mapping, retries, duplicates, errors, and checks that sent and received records match.

What the Team plan includes—and what requires custom work

The Team plan covers controls, documentation, and product evidence for standard Provenarium configurations. Custom work begins when a project adds assay-specific calculations, connects customer systems, migrates records, or requires customer-specific testing and documentation.

This boundary keeps the regulated workflow practical: customers do not need a custom software project to receive the standard controls and qualification materials, while assay-specific engineering and implementation work are scoped explicitly.

Customers may perform implementation and qualification with their own qualified personnel. Optional consulting is available when they want Provenarium to assist with customer-specific execution or documentation.

Included with TeamOptional consulting and custom development
Method versioning, report review, electronic signatures tied to a specific report version, access, record protection, and retrieval controls.New calculations, scientific models, or assay-specific workflow behavior.
Product requirements, traceability, verification records, release notes, and known issues.Custom importers, reports, exports, data formats, or user experiences.
Qualification protocol templates and verified example data sets.LIMS, ELN, plate-reader, identity, or other customer-specific integrations.
Standard administration, configuration, and operating guides.Migration, implementation planning, tests for the customer’s configured system, and customer-specific documentation support.

Maintain the validated state after release for regulated use

Qualification is not the end of the lifecycle. For each product release, Provenarium describes the changes and affected requirements or risks. For each release or customer configuration change, the customer assesses impact, selects proportionate regression testing or requalification, updates procedures or training, and approves the change before regulated use.

Incident records, access reviews, backup and restore evidence, interface monitoring, periodic review, and an archive or retirement plan help show that the configured system remains controlled. Testing and documentation should match the affected requirements and risk; repeating every original test is not automatically necessary.

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 vendor qualification package replace customer testing?

It can reduce unnecessary duplication when supplier evidence is assessed and relied on appropriately. Customer evidence still needs to address the approved configuration, intended use, organization-specific risks, procedures, and interfaces.

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 by organization and context. Define the required evidence and responsibilities in the validation or qualification plan, then use protocol names that fit the organization’s quality system.

Primary references