Customer Portal Help Desk: 1-800-834-8618
LIMS IQ Validation & compliance DOC LIS-VALIDATION
REV 2026-08

LIS Validation — IQ, OQ, PQ, and What Inspectors Expect

What LIS validation covers, how IQ/OQ/PQ qualification stages work, and how a cloud LIS validation package supports CLIA, CAP, and 21 CFR Part 11 inspections.

Request a demo Read the guide

Quick answer: LIS validation is the documented confirmation that a laboratory information system installs, operates, and performs as intended before clinical results depend on it. The standard structure is three qualification stages — Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) — each with protocols, test scripts, recorded outcomes, and signed-off reports that satisfy CAP, CLIA, and 21 CFR Part 11 expectations.

CAP customizes its inspection checklist to the laboratory’s testing menu, while CMS surveyors use the CLIA survey procedures and interpretive guidance for the requirements that apply. When LIS validation evidence is in scope, organizing signed IQ/OQ/PQ records by phase and responsibility makes each requirement, test, outcome, and approval easier to trace than a scattered set of spreadsheets and emails. This guide explains what validation is, how the qualification stages break down, who owns which evidence, and how a cloud LIS validation package differs from a legacy on-prem one.

Why validation matters

Validation is not paperwork for its own sake. It exists to answer two questions the lab director, the lab IT lead, and an inspection team may need the evidence to address:

  1. Does the LIS do what it is supposed to do — for this lab’s tests, instruments, interfaces, autoverification rules, and report templates?
  2. Is there documented evidence that proves it — protocols, test scripts, signed-off outcomes, and version-controlled records that a CAP or CLIA inspector can follow?

When a result lands in a patient chart, the chain of trust ends at the validation package. If the rule that released the result has not been validated, the result has not been validated. That is the regulatory premise behind CAP’s all common checklist, CLIA’s quality system requirements under 42 CFR Part 493, and 21 CFR Part 11 for FDA-regulated work.

The three qualification stages

Validation is broken into three stages by industry convention. Each has its own protocol, test scripts, expected results, evidence record, and signature.

Installation Qualification (IQ)

IQ confirms the system is installed correctly and ready for configuration.

Typical IQ evidence:

  • Software version and build deployed.
  • Infrastructure platform — cloud region, datacenter, network topology, redundancy.
  • User provisioning, authentication, and role assignments.
  • Time synchronization and audit-trail timestamp source.
  • Backup, retention, and disaster-recovery configuration.
  • Initial security baseline — TLS, access lists, session policy.

For a cloud LIS, IQ shifts. The lab does not own the servers, so vendor-issued attestations replace lab-executed install scripts. The cloud-IQ evidence is signed by the vendor and accepted by the lab.

Operational Qualification (OQ)

OQ confirms each function works as specified across the supported envelope.

Typical OQ scope:

  • Order entry — manual, HL7 ORM, requisition import.
  • Accessioning — barcoded specimens, batch accessioning, container labeling.
  • Result entry — instrument interface, manual entry, ASTM/HL7 inbound.
  • Autoverification rules — configured rules executed against representative data; override behavior captured.
  • QC — control entry, Levey-Jennings rendering, Westgard rule evaluation, corrective action workflow.
  • Reflex rules — trigger logic, downstream test ordering, audit chain.
  • Report templates — PDF and HL7 ORU rendering with patient and result placeholders.
  • Interfaces — bidirectional HL7 v2.x with EMR, instrument interfaces, reference-lab routing, billing handoff.
  • Role-based access — each role exercised against permitted and prohibited actions.
  • Audit trail — change capture, event types, timestamp, user attribution, immutability.

Each function has a written test script, an expected result, and a recorded actual result. OQ runs in parallel with configuration so each module is validated as it is configured rather than bundled at the end.

Performance Qualification (PQ)

PQ confirms the configured system performs end-to-end with representative data.

Typical PQ scope:

  • Parallel run with the production environment using live or near-live volumes.
  • Each lab specialty workflow exercised against the lab’s actual test catalog.
  • Reflex chains followed through to final result release.
  • QC failure handling validated end-to-end.
  • Critical-result delivery measured against turnaround targets.
  • Cross-system reconciliation — results from LIS match what the EMR receives, what billing sees, and what reaches the patient or client portal.

PQ duration should be set by coverage and acceptance criteria, not a default number of weeks. The lab needs enough representative cases and operating cycles to exercise its configured specialties, interfaces, exception paths, and release controls. PQ closes only after the required evidence is complete, observed mismatches are resolved or formally dispositioned, and the designated lab owners approve the configured workflow for go-live.

Vendor responsibility vs lab responsibility

The cleanest validation packages have a clear split.

Vendor responsibility — product validation:

  • The software meets stated functional specifications.
  • New releases are regression-tested against a baseline test suite.
  • The cloud platform meets stated availability, security, and audit-trail specifications.
  • A change-control process governs releases and is auditable.

Lab responsibility — site validation:

  • The configuration is correct for this lab’s workflows.
  • The test catalog, reference ranges, autoverification rules, reflex rules, and report templates reflect the lab’s SOPs.
  • Interfaces map to the EMR’s compendium, the instrument’s actual message envelope, and the billing system’s expected fields.
  • End-to-end workflows produce the right outcome on representative data.

When the split is unclear, validation gaps appear: the vendor assumes the lab will test something; the lab assumes the vendor already did. Inspections find those gaps. A good vendor validation package names the split explicitly and gives the lab protocols and test scripts to execute the site-side work.

Cloud LIS validation — what changes

Cloud LIS validation differs from on-premise in three places.

  1. IQ becomes attestation-driven. Vendor-issued evidence replaces lab-executed install scripts because the lab does not own the infrastructure.
  2. Release validation becomes recurring. On-prem labs control when upgrades happen; cloud labs follow the vendor’s release cadence. A documented release-validation procedure replaces the one-time-per-upgrade pattern: the vendor publishes release notes and a regression-test summary; the lab validates the impacted configured areas only, not the entire system.
  3. Disaster-recovery and continuity evidence comes from the vendor. The lab’s BC/DR plan references vendor attestations for RTO, RPO, replication, and failover testing rather than running its own server-side DR drills.

Everything else — OQ and PQ — is the lab’s responsibility regardless of deployment model. Configured workflows must be validated against the lab’s actual data, every time, in either model.

How to organize inspection evidence

The exact inspection questions depend on the laboratory’s testing menu, applicable requirements, and configured workflows. Organize the validation package so staff can demonstrate the system’s intended behavior and the evidence behind released results.

The evidence should let staff answer questions such as:

  • Show me the OQ for autoverification on this analyte.
  • Show me the most recent release-validation summary for the last vendor update.
  • Show me an audit-trail entry for a corrected result and walk me through what happened.
  • Show me the test script for a critical-result notification and the recorded execution.
  • Who signed off on the current reference ranges for pediatric chemistry, and what evidence supports them?

A validation package that maps each question to a clearly signed artifact is easier to trace against the applicable requirement. A package spread across unrelated files forces staff to assemble that evidence during the inspection.

What to expect from a vendor validation package

When you evaluate a cloud LIS, the validation package is one of the deliverables to scope explicitly in the RFP. The strongest packages include:

  • Vendor IQ attestation — version, environment, and cloud-platform evidence the vendor signs and the lab accepts.
  • OQ protocols and test scripts — written for each module, scoped to the lab’s enabled functionality, and updated when the platform changes.
  • PQ guidance — parallel-run methodology, representative data approach, and acceptance criteria the lab uses on its own workflows.
  • Release validation — release notes, regression-test summaries, and impacted-area mapping so the lab validates only what changed between platform versions, not the whole system.
  • Audit-trail evidence — built-in event history that is queryable and exportable for inspection requests, traceable to CLIA, CAP, and 21 CFR Part 11 expectations.
  • Electronic signature support — for orders, results, QC, corrective actions, and configuration changes where the regulatory frame requires it.

A vendor that cannot show these artifacts during a demo is a vendor that will hand the lab an unfinished validation package. Ask to see real samples — redacted is fine — before signing.

How LIMS IQ supports site validation

LIMS IQ provides platform controls and onboarding services that a laboratory can exercise and document during its own validation:

  • Cloud-native platform — the laboratory does not maintain on-premise servers, while its configured workflows and interfaces still need site testing.
  • Tamper-evident audit trail — all record edits, result changes, approvals, and configuration changes captured with immutable event history (see Chain of Custody & Audit Trail).
  • Role-based access — every action attributed to a named user, with permissions scoped to lab role (see Security & Compliance).
  • HIPAA-aligned controls — encryption at rest and in transit, audit logs, and access controls structured to support the security side of CLIA, CAP, and HIPAA evidence.
  • White-glove onboarding — the LIMS IQ team supports data migration, instrument connectivity, custom report configuration, and staff training, giving the lab configured workflows to test before go-live.
  • Configurable workflows — autoverification, reflex rules, reference ranges, and report templates are configured per lab rather than hard-coded, so site validation focuses on the lab’s actual rules instead of platform defaults.

Validation responsibilities and deliverables vary by laboratory, edition, and project scope. Confirm required IQ/OQ/PQ protocols, test scripts, approval records, and release documentation in the statement of work. The LIS Implementation Timeline explains where configuration, interface testing, validation, and go-live fit in the broader project.

Request a demo to review the documented LIMS IQ workflows your lab would validate, or contact the team to clarify validation responsibilities and deliverables for your RFP.

Frequently asked

What is LIS validation?
LIS validation is the documented process of confirming that a laboratory information system installs, operates, and performs as intended in your specific environment before clinical results depend on it. The standard structure is three qualification stages — Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) — each with written protocols, test scripts, expected results, recorded outcomes, and a signed-off summary report. Validation supports CAP, CLIA, ISO 15189, and 21 CFR Part 11 expectations by giving the laboratory traceable evidence for its configured system.
Who is responsible for LIS validation — the vendor or the lab?
Both, with a clear split. The vendor documents how the software is tested and what implementation artifacts are available. The lab remains responsible for validating its configured workflows, test catalog, instruments, interfaces, reference ranges, autoverification rules, and report templates against its own data and procedures. LIMS IQ provides onboarding for data migration, instrument connectivity, report configuration, and staff training; labs should confirm any IQ/OQ/PQ protocols, test scripts, and sign-off support during project scoping.
What is the difference between IQ, OQ, and PQ?
Installation Qualification (IQ) confirms the system is installed correctly — versions, infrastructure, network access, user provisioning, configuration baseline. Operational Qualification (OQ) confirms each function works as specified across the supported test envelope — order entry, accessioning, result entry, QC, autoverification, reporting, interfaces, role-based access. Performance Qualification (PQ) confirms the configured system performs end-to-end against the lab’s actual workflows with representative data — typically run in a parallel period before go-live. Each stage has its own protocol, scripts, and approval signature.
How does cloud LIS validation differ from on-premise validation?
The vendor-side IQ is simpler for cloud — the lab does not own the servers, OS, or upgrade path, so installation evidence is replaced by vendor-issued attestations that the production environment matches the validated platform. Site-side OQ and PQ are equivalent: the lab still validates its own configuration, interfaces, reference ranges, autoverification rules, and report templates. Cloud also adds release-validation responsibility — when the vendor pushes a new release, both vendor and lab follow a documented re-validation procedure for impacted areas rather than retesting the entire system.
How does LIS validation align with CAP, CLIA, and 21 CFR Part 11?
CAP and CLIA expect documented evidence that systems used for patient testing perform as intended, with controls around access, change management, audit trail, QC, and result release. A signed validation package — IQ, OQ, PQ protocols and reports — provides the documented evidence. 21 CFR Part 11 (which applies to FDA-regulated lab work and clinical trials) adds electronic signature, audit-trail integrity, and computer-system validation rigor. ISO 15189 expects equivalent control. A cloud LIS validation package is structured so the same artifacts support all four frameworks rather than running parallel validations.
How long does LIS validation take?
There is no responsible universal week range for LIS validation. Plan it as readiness gates within implementation: IQ closes when the environment and configuration baseline are documented, OQ progresses as configured modules and interfaces become testable, and PQ begins when end-to-end workflows can run with representative data. The schedule depends on test-catalog complexity, instrument and HL7 interface count, migration scope, sites and specialties, validation depth, and partner test-environment readiness. The project plan should define entry criteria, required evidence, issue-resolution rules, owners, and approval signatures for each gate.