Endotoxin Testing Systems: Qualification, Software, and Data Integrity

Endotoxin testing systems generate results used to evaluate pharmaceutical products, water, raw materials, process samples, and medical-device extracts against established bacterial endotoxin limits. For quantitative methods, the reported result may depend directly on incubation temperature, optical measurement, reaction timing, standard-curve processing, dilution factors, product-positive-control recovery, and software calculations.

Qualification must therefore address the complete analytical system rather than treating the reader as an isolated laboratory instrument. The system may include:

• Microplate or tube reader
• Integrated or separate incubation unit
• Optical detection components
• Plate transport or positioning mechanism
• Instrument controller
• Workstation and operating system
• BET application software
• Database or file-storage location
• Calculation and reporting functions
• User and security configuration
• Audit trails
• Electronic signatures, where used
• Network services and time synchronization
• Interfaces with LIMS or other systems
• Backup, restore, archival, and retrieval functions
• Supporting printers, barcode readers, or peripheral devices

The BET analytical method, endotoxin-limit calculation, maximum valid dilution, product interference, and method suitability are addressed in Bacterial Endotoxin Testing: Methods, Limits, and Suitability. This article addresses qualification and lifecycle control of the equipment and computerized functions used to execute those methods.

An endotoxin testing system remains suitable only when its physical performance, software and data controls, and lifecycle activities operate together. The following diagram summarizes how these three control areas support a reliable, traceable, and reconstructable BET result.

Qualification Objective

Qualification should establish documented evidence that the system:

• Is suitable for its defined BET applications
• Is installed and configured as approved
• Controls incubation within established limits
• Measures the required optical or other analytical response accurately
• Records reaction timing correctly
• Executes approved calculations consistently
• Enforces configured validity and acceptance rules
• Protects raw data, metadata, results, and audit trails
• Restricts functions to authorized users
• Transfers data accurately across interfaces
• Recovers records and configuration after failure
• Remains controlled through calibration, maintenance, change, and periodic review

A successful standard curve alone does not qualify the system. Routine controls may compensate for some analytical variability, but they do not replace verification of the instrument, software, configuration, security, and record-management functions on which the result depends.

System Boundary and Intended Use

The intended use defines what the system must do and establishes the basis for qualification. It should identify:

• Materials and products to be tested
• Gel-clot, turbidimetric, chromogenic, or recombinant methods supported
• Endpoint or kinetic measurement modes
• Required wavelengths or detection technologies
• Incubation temperature and duration
• Microplate, tube, or cartridge formats
• Required analytical range
• Standard-curve model
• Replicate strategy
• Product-positive-control calculations
• Sample dilution and preparation factors
• Result units
• Endotoxin-limit comparison
• Invalid-test rules
• Electronic-record and signature use
• Interfaces and external data destinations
• Record-retention requirements
• Number and type of users
• Laboratory operating environment

System boundaries should identify every component that can create, modify, calculate, transfer, store, display, report, or delete GMP-relevant data.

A workstation, network database, shared storage location, operating system, interface engine, or identity-management service may be outside the physical reader but still inside the validated system boundary. Conversely, pipettes, reference thermometers, and other supporting instruments may be separately qualified and calibrated even though their outputs affect system testing.

The system should be classified and assessed using the principles described in Computerized System Types and Classification.

Regulatory and Compendial Basis

Applicable requirements and guidance may include:

• 21 CFR 211.68—Automatic, Mechanical, and Electronic Equipment
• 21 CFR 211.160—General Requirements for Laboratory Controls
• 21 CFR 211.194—Laboratory Records
• 21 CFR Part 11—Electronic Records and Electronic Signatures
• USP <85> Bacterial Endotoxins Test
• USP <86> Bacterial Endotoxins Test Using Recombinant Reagents
• USP <1058> Analytical Instrument Qualification
• USP <1085> Guidelines on Tests for Endotoxins
• FDA Part 11: Scope and Application
• FDA Data Integrity and Compliance With Drug CGMP: Questions and Answers

A documented Part 11 assessment should determine which electronic records and signatures fall within scope. Part 11 should not be applied merely because an instrument contains software; applicability depends on whether electronic records or signatures are created, modified, maintained, archived, retrieved, or transmitted under applicable regulatory record requirements.

Predicate-rule requirements continue to apply whether the official record is electronic, paper-based, or a controlled combination of both.

System Architecture

A typical quantitative BET system contains four connected functional layers:

1. Measurement layer
   • Optical detector
   • Light source
   • Filters or wavelength-selection components
   • Plate or tube positioning
   • Incubation components
   • Temperature sensors
   • Timing functions
2. Control and acquisition layer
   • Instrument firmware
   • Reader controller
   • Signal acquisition
   • Well identification
   • Measurement sequence
   • Error and status detection
3. Application layer
   • Test setup
   • Standard concentrations
   • Sample dilutions
   • Standard-curve calculation
   • PPC recovery
   • Result calculation
   • Validity evaluation
   • Reporting
4. Data-management layer
   • User accounts
   • Audit trails
   • Electronic signatures
   • Database or file storage
   • Interfaces
   • Backup and restore
   • Archival and retrieval

Qualification must verify the individual layers and their integration. Accurate optical measurement is insufficient if well identities are mismatched, dilution factors are applied incorrectly, audit trails are incomplete, or records cannot be restored. A quantitative BET platform functions as an integrated signal-and-data pathway. The reader controls and measures the reaction, the software converts raw responses into calculated results, and the record-management functions preserve the result together with its supporting metadata and history.

User Requirements

The User Requirements Specification should define requirements that are clear, testable, risk-based, and traceable.

The URS may address:

Analytical requirements

• Supported BET methods
• Measurement range
• Required wavelengths
• Optical accuracy and precision
• Incubation range
• Temperature accuracy, uniformity, and stability
• Measurement interval and timing accuracy
• Plate, tube, or cartridge compatibility
• Standard-curve functionality
• Replicate handling
• Sample-dilution calculations
• PPC recovery
• Result units and rounding
• Limit comparison
• Invalid-run determination

Operational requirements

• Test creation and execution
• Sample identification
• Plate layout
• Method templates
• Instrument readiness checks
• Alarm and error handling
• Interrupted-run handling
• Review and approval workflow
• Report generation

Data-integrity requirements

• Unique user accounts
• Role-based access
• Administrator controls
• Audit trails
• Electronic signatures, where applicable
• Secure timestamps
• Raw-data retention
• Metadata preservation
• Record protection
• Accurate and complete copies
• Search and retrieval
• Backup and restore
• Archival and retention

Interface requirements

• LIMS communication
• Sample-list import
• Result export
• Barcode entry
• Network storage
• Printer or PDF output
• Time synchronization
• Error detection and reconciliation

Requirements should be linked to design, configuration, testing, deviations, and release through requirements traceability.

Risk Assessment and Validation Strategy

The risk assessment should identify functions whose failure could cause:

• An incorrect endotoxin result
• Failure to detect an invalid run
• Incorrect PPC recovery
• Use of an unauthorized or obsolete method
• Incorrect sample or standard identification
• Loss or alteration of raw data
• Misapplication of dilution factors
• Incorrect comparison with the endotoxin limit
• Undetected modification of results
• Inability to reconstruct test execution
• Incomplete transfer to LIMS
• Inability to recover required records

High-risk functions normally include:

• Optical response acquisition
• Incubation-temperature control
• Reaction timing
• Well or tube identification
• Standard-curve calculation
• Dilution correction
• PPC recovery
• Replicate processing
• Result rounding
• Validity rules
• Endotoxin-limit comparison
• Raw-data storage
• Audit-trail generation
• Access control
• Result approval
• Interfaces
• Backup and restore

The validation plan should define:

• System boundary
• Intended use
• Roles and responsibilities
• Supplier-documentation use
• Risk-assessment approach
• Required specifications
• IQ, OQ, and performance-verification activities
• Software and configuration testing
• Data-integrity testing
• Interface testing
• Traceability
• Deviation management
• Release requirements
• Lifecycle controls

Supplier and Documentation Assessment

Commercial BET systems commonly rely on proprietary hardware, firmware, and software. Supplier documentation may be leveraged after documented assessment. The assessment should consider:

• Supplier quality system
• Product-development controls
• Software-development practices
• Testing and release processes
• Defect and vulnerability management
• Version control
• Change-notification practices
• Technical support
• Calibration and maintenance capability
• Documentation availability
• Backup and recovery design
• Data-integrity functionality
• Product obsolescence strategy

Supplier testing does not eliminate user responsibility. Site qualification must confirm the installed configuration, intended use, critical calculations, security controls, interfaces, and laboratory workflows.

Design and Configuration Review

The design or configuration review should verify that the selected system can satisfy the approved requirements.

Review elements may include:

• Reader type and measurement technology
• Required wavelengths
• Incubation design
• Sensor arrangement
• Plate compatibility
• Workstation specifications
• Operating-system compatibility
• Software version
• Database architecture
• Network dependencies
• Storage capacity
• User-role model
• Audit-trail capabilities
• Electronic-signature functions
• Calculation configuration
• Report templates
• Interface design
• Backup method
• Cybersecurity and patching approach
• Vendor support and expected service life

Unresolved design limitations should be documented before qualification. Procedural controls should not be used casually to compensate for missing critical system controls.

Installation Qualification

IQ establishes the installed baseline. IQ should verify, as applicable:

• Manufacturer, model, serial number, and asset identification
• Reader, incubator, workstation, and peripheral components
• Instrument location
• Electrical and network connections
• Environmental requirements
• Required clearances and ventilation
• Installed optical components
• Plate carriers, adapters, and accessories
• Temperature sensors
• Firmware version
• Software version and build
• Operating-system version
• Database version and location
• Installed modules and licenses
• Configuration files
• Network name and address
• Time source
• Interface endpoints
• Data-storage paths
• Backup configuration
• Printer and report configuration
• Calibration status
• Manuals and certificates
• Approved antivirus or endpoint-security configuration
• Account and role configuration
• Audit-trail configuration
• Electronic-signature configuration, where used

The IQ record should establish a reproducible configuration baseline. Screenshots alone are insufficient when configuration files, system reports, database settings, or other more reliable evidence are available.

Operational Qualification

OQ should challenge critical functions throughout the approved operating range and include anticipated failure conditions.

Reader and Optical Performance

Testing should reflect the actual detection technology and intended method. Applicable tests may include:

• Wavelength accuracy
• Photometric accuracy
• Photometric linearity
• Optical repeatability
• Detector stability
• Well-to-well consistency
• Plate-position accuracy
• Read-position verification
• Stray-light evaluation
• Measurement range
• Response at relevant low and high levels
• Kinetic acquisition interval
• Timing accuracy
• Signal processing
• Error detection

Not every reader supports or requires the same optical tests. A fixed-filter reader, monochromator, fluorescence reader, and cartridge-based platform have different relevant characteristics. Qualification should verify the functions actually used rather than applying a generic spectrophotometer checklist.

Incubation Qualification

BET reaction kinetics are temperature-dependent. Integrated or separate incubation functions should be verified for:

• Setpoint accuracy
• Spatial uniformity
• Stability throughout the assay period
• Performance across the approved operating range
• Recovery after plate or tube insertion
• Overshoot and undershoot
• Loaded operating conditions
• Alarm or error response
• Independent reference-instrument traceability
• Temperature recording, where provided

Temperature mapping locations should represent corners, edges, center positions, and other locations justified by the incubator design. Acceptance criteria should distinguish:

• Setpoint accuracy
• Spatial uniformity
• Time-based stability
• Recovery time

A single temperature reading at the center of an empty platform does not demonstrate adequate incubation control across a loaded microplate. Incubation qualification should evaluate more than a single temperature reading. Distributed measurements across representative corner, edge, and center locations are used to assess setpoint accuracy, spatial uniformity, stability throughout the assay period, and recovery after plate insertion.

Mechanical and Operational Functions

Where applicable, OQ should verify:

• Plate insertion and ejection
• Tray or carrier positioning
• Shaking or mixing functions
• Lid or door detection
• Barcode reading
• Sample-position assignment
• Plate-orientation controls
• Start, pause, stop, and abort functions
• Power interruption
• Communication interruption
• Instrument restart
• Recovery after an incomplete run
• Error messages
• Prevention of use when required readiness checks fail

Interrupted runs should produce an unambiguous status. The system should not silently resume, overwrite the incomplete record, or permit an interrupted test to be reported as valid without controlled assessment.

Software Validation

Software validation should demonstrate that the configured application consistently performs its intended functions. Testing should address:

• Method creation
• Method approval and versioning
• Protection of approved methods
• Standard concentration entry
• Sample identification
• Plate-layout assignment
• Dilution entry
• Replicate configuration
• Test initiation
• Raw-response acquisition
• Threshold determination
• Standard-curve generation
• Result interpolation
• PPC recovery
• Sample-result calculation
• Dilution-factor correction
• Unit conversion
• Rounding
• Limit comparison
• Validity evaluation
• Result review
• Result approval
• Reporting
• Data export
• Record retrieval

Testing should include normal, boundary, invalid, and failure conditions. Examples include:

• Duplicate sample identifiers
• Missing standards
• Incorrect standard sequence
• Standard outside the configured range
• Failed negative control
• Failed PPC
• Result below the quantitation range
• Result above the calibration range
• Excessive replicate variation
• Dilution exceeding the MVD
• Attempted change to an approved method
• Attempted reporting of an invalid run
• Power or network interruption
• Incomplete interface transfer

Calculation Verification

All calculations affecting the reportable result should be independently verified. The verification should cover:

• Standard-curve regression
• Curve direction and mathematical model
• Correlation calculation
• Sample interpolation
• Dilution-factor application
• Sample-preparation factors
• Replicate averaging or other approved treatment
• PPC recovery
• Unit conversion
• Rounding rules
• Below-range and above-range handling
• Comparison with the endotoxin limit
• Pass, fail, invalid, and indeterminate classifications

Calculation testing should use known inputs with independently established expected results. Tests should include boundary values and values immediately above and below configured decision points.

Vendor statements that calculations were tested do not substitute for site verification of the actual configured method, units, dilution conventions, and reporting rules.

Manual calculations, spreadsheets, or transcribed values used outside the primary application should be included within the controlled process and assessed for validation and data-integrity risk.

Method Templates and Configuration Control

Approved BET methods are often implemented through configurable software templates. Controlled configuration may include:

• Method type
• Wavelength
• Incubation temperature
• Read interval
• Reaction threshold
• Standard concentrations
• Replicate requirements
• Curve model
• Correlation criterion
• PPC concentration
• PPC acceptance range
• Dilution factors
• Result units
• Rounding
• Endotoxin limit
• Control requirements
• Report layout

Method templates should have:

• Unique identification
• Version control
• Defined ownership
• Independent review
• Approval before use
• Protection from unauthorized modification
• Effective-date control
• Traceable change history
• Retirement of obsolete versions

The system should prevent analysts from using uncontrolled test settings or obsolete templates for GMP testing.

Electronic Records and Raw Data

The complete electronic record may include more than the final report. Relevant records can include:

• Original optical or fluorescence readings
• Time-stamped kinetic measurements
• Well or tube assignments
• Plate layout
• Standard concentrations
• Sample dilutions
• Method version
• Instrument configuration
• Calculated threshold times
• Standard-curve results
• PPC recovery
• Replicate results
• Instrument errors and flags
• User actions
• Audit trails
• Review and approval records
• Electronic signatures
• Export and interface status
• Reprocessing or recalculation history

A printed report or static PDF may not preserve all original data and metadata necessary to reconstruct the test. The official-record strategy must identify what constitutes raw data, where each record component is retained, and how the complete record can be retrieved throughout its retention period.

Electronic-record controls should follow the principles described in Electronic Records Lifecycle and Retention Control.

Audit Trails

Audit trails should be enabled for GMP-relevant functions where the system provides them and where they are necessary to reconstruct record history. Relevant events may include:

• Method creation and modification
• Method approval
• Changes to standards or concentrations
• Changes to sample identification
• Plate-layout changes
• Dilution-factor changes
• Test start, stop, or abort
• Result recalculation
• Manual result entry
• Result modification
• Result invalidation
• Reason-for-change entry
• Review and approval
• User-role changes
• Configuration changes
• Audit-trail setting changes
• Data export
• Record deletion attempts
• System-time changes

Audit-trail testing should verify:

• Automatic generation
• User identification
• Date and time
• Action performed
• Previous and new values, where applicable
• Reason for change, where required
• Linkage to the affected record
• Protection from modification or deletion
• Search, display, and export
• Retention with the associated record

Procedures should define which audit trails are reviewed, when they are reviewed, by whom, and how unusual activity is investigated. Detailed controls are addressed in Audit Trails and Data Change Control in Computerized Systems.

Access Control and Electronic Signatures

System access should be based on unique user identification and defined roles. Roles may include:

• Analyst
• Reviewer
• Laboratory supervisor
• Method administrator
• System administrator
• IT support
• Vendor service

Testing should verify:

• Unique accounts
• Authentication
• Password or equivalent controls
• Account lockout
• Session timeout
• Role-based permissions
• Least-privilege assignment
• Segregation between testing, review, and administration
• Account creation and deactivation
• Temporary or elevated access
• Prevention of unauthorized method changes
• Prevention of unauthorized result changes
• Administrator activity traceability

Shared analyst accounts compromise attribution and should not be used for GMP test execution.

Where electronic signatures are used, testing should confirm:

• Signer identity
• Date and time
• Meaning of the signature
• Required authentication
• Permanent linkage to the signed record
• Prevention of signature copying or transfer
• Traceability of changes made after signature

Access and signature controls are addressed further in Access Control and Electronic Signatures in Computerized Systems.

System Time

Timestamps may affect:

• Test initiation
• Kinetic measurements
• Audit trails
• Review and approval
• Sample hold-time assessment
• Sequence reconstruction
• Interface reconciliation

Controls should verify:

• Approved time source
• Time-zone configuration
• Synchronization with network time, where applicable
• Restrictions on time changes
• Audit-trail capture of authorized changes
• Behavior during daylight-saving changes
• Timestamp consistency among the reader, workstation, database, and LIMS

Uncontrolled clock differences can prevent reliable reconstruction of a test and its associated review.

Interfaces and Data Transfer

Interfaces may transfer:

• Sample identifiers
• Product or material codes
• Specifications
• Endotoxin limits
• Test assignments
• Dilution information
• Final results
• Units
• Status
• Review or approval information

Interface qualification should verify:

• Correct field mapping
• Complete data transfer
• Unit consistency
• Decimal precision
• Character limits
• Date and time formats
• Sample identity
• Method and specification version
• Rejection of invalid data
• Duplicate-transfer prevention
• Missing-record detection
• Communication-failure handling
• Retry behavior
• Reconciliation
• Auditability

Testing should include interrupted, delayed, duplicate, incomplete, and rejected transfers. A successful nominal transfer does not demonstrate adequate interface control.

Manual transcription used when an interface is unavailable should follow an approved contingency procedure with defined verification and reconciliation.

Backup, Restore, and Recovery

Backup protects against data loss but does not, by itself, demonstrate recoverability. The backup strategy should include:

• Raw data
• Metadata
• Audit trails
• Approved methods
• Configuration
• User and role information
• Electronic signatures
• Database records
• Reports
• Interface status
• Supporting system documentation

Controls should define:

• Backup frequency
• Backup type
• Storage location
• Encryption, where applicable
• Access restrictions
• Monitoring
• Failure notification
• Retention
• Restore responsibilities
• Recovery objectives

Restore testing should demonstrate that:

• Selected records can be recovered.
• Restored records remain complete and readable.
• Metadata and audit trails remain linked.
• Calculations and reports remain reproducible.
• Approved methods and configuration remain available.
• Access protections remain effective.
• The restored system can support its intended use.

Backup, archival, and disaster recovery are related but distinct controls. Their differences are addressed in Backup, Restore, and Disaster Recovery in Computerized Systems.

Performance Qualification and Intended-Use Verification

Performance qualification should demonstrate reliable operation under routine or representative laboratory conditions. PQ may include:

• Approved test methods
• Representative reagents
• Routine plate or tube formats
• Typical analysts
• Standard curves across the intended range
• Negative controls
• Positive controls
• Product-positive controls
• Representative sample dilutions
• Repeatability
• Run-to-run consistency
• Routine reports
• Review and approval workflow
• Record retrieval

System PQ should verify that the platform can execute the intended analytical workflow. It should not be confused with product-specific method suitability.

Method suitability establishes that a product matrix does not unacceptably inhibit or enhance the BET response. System qualification establishes that the equipment and software reliably execute, calculate, control, and document the approved test.

Vendor demonstrations or factory acceptance testing may support qualification but should not replace site testing under the installed configuration and intended operating conditions.

Deviations and Qualification Failures

Qualification discrepancies should be documented and assessed for:

• Root cause
• Affected requirements
• Data-integrity impact
• Product or laboratory impact
• Corrective action
• Retesting scope
• Residual risk
• Release impact

A passing repeat does not automatically invalidate the original failure. The cause of the failure and the justification for any retest must be documented.

Open deviations should be resolved before release unless a documented assessment demonstrates that the remaining issue does not compromise intended use, product quality, data integrity, or regulatory compliance.

Release for Routine Use

Release should confirm that:

• Requirements are approved.
• Risk assessments are complete.
• The installed baseline is documented.
• Required IQ, OQ, and PQ activities are complete.
• Critical calculations have been verified.
• Data-integrity controls are functioning.
• Interfaces have been qualified.
• Backup and restore have been demonstrated.
• Deviations are resolved or formally accepted.
• Traceability is complete.
• Procedures are approved.
• Users are trained.
• Calibration and maintenance programs are active.
• Method templates are approved.
• System ownership is assigned.
• The validation report is approved.

The release decision should identify the approved configuration, methods, operating conditions, interfaces, and any limitations.

Calibration and Routine Verification

Calibration and verification should be based on component function, manufacturer recommendations, intended use, performance history, and risk. Activities may include:

• Wavelength verification
• Photometric verification
• Temperature-sensor calibration
• Incubator temperature checks
• Timing verification
• Plate-position verification
• Preventive maintenance
• Diagnostic testing
• Reference-standard checks

Calibration records should identify:

• Instrument or component
• Standard used
• Traceability
• As-found result
• Adjustment or repair
• As-left result
• Acceptance criteria
• Due date
• Reviewer

An out-of-tolerance condition requires assessment of potentially affected BET results. The assessment should consider the magnitude and direction of the error, affected function, time since the last acceptable calibration, system-use history, method sensitivity, and product impact.

The broader control strategy is addressed in GMP Calibration Program and Metrology Control.

Maintenance

Preventive and corrective maintenance may include:

• Optical-system service
• Light-source replacement
• Filter or detector replacement
• Incubator repair
• Fan or heater replacement
• Tray or transport adjustment
• Workstation replacement
• Database maintenance
• Storage expansion
• Firmware servicing
• Cleaning
• Diagnostic testing

Post-maintenance assessment should determine whether the system requires:

• Inspection
• Calibration
• Functional verification
• Configuration verification
• Security verification
• Interface testing
• Targeted requalification
• Comprehensive requalification

The assessment should be based on the affected functions, not solely on whether the vendor labels the activity as routine service.

Change Control

Changes requiring documented assessment may include:

• Software upgrade
• Firmware update
• Operating-system change
• Database update
• Security patch
• Antivirus or endpoint-control change
• Workstation replacement
• Reader or incubator replacement
• Optical-component replacement
• Temperature-sensor replacement
• Network change
• Storage-location change
• Interface modification
• Method-template change
• Calculation or rounding change
• Report-template change
• Role or permission change
• Audit-trail configuration change
• Backup configuration change
• Instrument relocation
• Addition of a new BET method
• Transition to recombinant reagents
• Vendor support or licensing change

The assessment should identify:

• Affected requirements
• Affected risks
• Configuration changes
• Data migration
• Historical-record accessibility
• Testing required
• Procedure changes
• Training
• Regulatory or filing impact
• Requalification scope
• Release requirements

Emergency changes should be documented, authorized, retrospectively reviewed, and followed by appropriate verification.

Periodic Review

Periodic review should determine whether the system remains suitable, controlled, supported, and in its validated state. Review inputs may include:

• Current hardware and software inventory
• Approved configuration baseline
• Software and firmware versions
• Changes since the previous review
• Deviations and incidents
• Invalid or interrupted tests
• Calculation or reporting problems
• Audit-trail findings
• User-access review
• Administrator activity
• Security events
• Backup failures
• Restore-test results
• Interface errors
• Calibration history
• Maintenance history
• Performance trends
• Recurring standard-curve failures
• Temperature trends
• Vendor notices
• Known defects
• Patch status
• Training status
• Procedure status
• Open CAPA
• Data-storage capacity
• Record retrieval
• Vendor support
• Hardware and software obsolescence

Possible outcomes include:

• Continued use without additional action
• Procedural correction
• Training
• Configuration correction
• Increased monitoring
• Targeted verification
• Requalification
• Software or hardware upgrade
• Data migration
• System replacement
• Retirement planning

Periodic review should evaluate evidence accumulated during operation. It is not simply a confirmation that the original validation documents exist.

Requalification

Requalification may be triggered by:

• Significant repair
• Optical-component replacement
• Incubator repair
• Sensor replacement
• Software or firmware upgrade
• Workstation or server replacement
• Interface change
• Calculation change
• System relocation
• Repeated invalid runs
• Adverse performance trend
• Calibration failure
• Data-integrity event
• Backup or recovery failure
• Extended shutdown
• Periodic program requirements

The scope should be based on the affected functions and risks.

Examples:

• Incubator repair may require temperature accuracy, uniformity, stability, recovery, alarm testing, and representative assay verification.
• Optical-component replacement may require wavelength, photometric, repeatability, and analytical-response testing.
• A software upgrade may require regression testing of calculations, access, audit trails, reports, interfaces, record retrieval, and affected workflows.
• Workstation replacement may require installation verification, configuration comparison, security testing, interface testing, record access, and backup verification without repeating unaffected reader-performance tests.

System Retirement and Data Migration

Retirement planning should ensure that GMP records remain complete, readable, protected, and retrievable throughout their required retention periods.

Retirement activities may include:

• Inventory of records and metadata
• Identification of retention requirements
• Final backup
• Data migration or controlled archival
• Verification of record counts
• Verification of metadata and audit trails
• Comparison of source and migrated records
• Human-readable retrieval testing
• Deactivation of interfaces
• Removal of user access
• License and vendor-access termination
• Documentation of final configuration
• Controlled equipment disposition
• Approval of the retirement report

Data migration must preserve record meaning and relationships. Migrating only final PDF reports may be inadequate when raw readings, kinetic data, methods, audit trails, or metadata are required to reconstruct the original test.

Documentation Package

The lifecycle package should include:

• System description
• Intended-use statement
• System-boundary diagram
• Part 11 assessment
• System classification
• Supplier assessment
• User requirements
• Risk assessment
• Configuration specification
• Validation plan
• IQ, OQ, and PQ protocols
• Calculation-verification evidence
• Interface-testing evidence
• Data-integrity testing
• Backup and restore testing
• Requirements traceability
• Deviations and investigations
• Validation report
• Approved configuration baseline
• Method-template approvals
• Procedures
• Training records
• Calibration and maintenance plans
• Release approval
• Change records
• Periodic reviews
• Requalification records
• Retirement or migration records

Core Qualification Principle

A reliable BET result requires both:

• A suitable analytical method capable of detecting endotoxin in the specific product matrix
• A qualified analytical system capable of executing, calculating, recording, protecting, and reporting that method correctly

An acceptable product result is not reliable when incubation temperature was uncontrolled, optical response was inaccurate, calculations were incorrectly configured, controls were overridden, raw data were lost, or record changes cannot be reconstructed.