• Policy: states the organization’s governing intent, responsibility, and boundaries.
• Procedure/SOP: controls who performs the work, prerequisites, sequence, decisions, exceptions, records, and authorization.
• Method summary or test-menu entry: gives role-appropriate facts; it does not replace the procedure.
• Job aid/checklist: supports a defined task and must remain linked to its controlling procedure and version.
• Manufacturer instructions: remain source material and system-specific direction; local controlled use must not obscure their current version.

For nonwaived testing, cover every applicable element of the path of workflow instead of relying on bench memory.

• Purpose, scope, definitions, authorized roles, responsibilities, and safety
• Request, patient/specimen identification, preparation, collection, handling, acceptability, and rejection
• Equipment, materials, reagents, calibrators, controls, storage, preparation, and readiness
• Stepwise performance, calculations, result interpretation, units, entry, review, and reporting
• Calibration, calibration verification, QC, maintenance, function checks, and acceptance criteria
• Reportable interval, reference information, critical/significant-risk communication, limitations, and interferences
• Corrective action, downtime, referral, amended reporting, retained records, and final reconciliation
• References, related documents/forms, approvals, effective date, review date, revision history, and archive status

A procedure is incomplete when it explains only the ideal run.

• unacceptable or ambiguous specimen; missing or conflicting order/identity
• QC, calibration, maintenance, temperature, reagent, or analyzer failure
• flags, delta checks, discordant evidence, unexpected interference, or result beyond the verified interval
• critical/significant-risk result, corrected report, unavailable recipient, or failed interface
• downtime, referral, supply shortage, service interruption, and recovery reconciliation

For each branch, define the hold point, owner, evidence, escalation, authorization, communication, and closure test.

1. Frame the controlled work. Name the process, intended users, setting, instruments or systems, start/end points, exclusions, and accountable owner.
2. Build the source register. Capture current regulation, accreditation criteria, manufacturer instructions, standards, risk evidence, and verified local specifications—with edition and access dates.
3. Map the real workflow. Observe normal work and handoffs; identify inputs, prerequisites, records, decision authority, and every material exception branch.
4. Draft for performance. Use ordered actions, explicit decision conditions, acceptance criteria, stop points, escalation, downtime, recovery, and records—not vague prose.
5. Challenge the draft. Have qualified reviewers test technical accuracy, safety, usability, interfaces, traceability, regulatory applicability, and alignment with actual validated practice.
6. Approve and control. Obtain required laboratory-director and designated approvals; assign identifier, version, owner, effective date, review cycle, and controlled distribution.
7. Implement as a system change. Complete validation/verification and build changes as applicable; update forms, LIS/middleware, labels, reference information, training, and competency before release.
8. Release, verify, and sustain. Remove superseded active copies, retain history, audit early use and exception handling, correct implementation gaps, then review, revise, retire, and archive through traceable change control.

Before an effective date, determine whether the change affects validation/verification, reference information, QC, calibration, reagents, safety, competencies, forms, test menu, LIS/middleware, interfaces, downtime materials, referral partners, or clinician communication.

Test the revised workflow—including exception paths—and retain objective implementation evidence. “Staff notified” does not prove the system changed safely.

This hub can teach structure, decision logic, and public requirements. It will not reproduce proprietary instructions, unpublished analyzer details, protected interfaces, or a laboratory’s confidential controlled procedures. Do not enter real patient, employee, or proprietary laboratory data in the teaching builder.

Open the Filled Example Cabinet for complete synthetic records—scenario, fields, decisions, evidence, approvals, implementation, and closure.

• Procedure revision & controlled implementation — source change through impact assessment, approval, training, effective release, removal of obsolete copies, and early-use verification.
• Method verification & release gate — planned claims, evidence set, exceptions, qualified authorization, and controlled go-live.
• New assay implementation & go-live — cross-system build, validation, risk controls, readiness evidence, launch, and post-release review.
• LIS, middleware & autoverification validation — rule logic, test cases, exception routes, traceable approval, controlled deployment, and monitoring.

Use safely: these are educational synthetic examples. Adapt them to the laboratory’s scope, instruments, manufacturer instructions, jurisdiction, accreditor, approved risk controls, and document system.

Roadmap—not autonomous document control. Future procedures could expose structured prerequisites, decision tables, required evidence, linked forms, version differences, and downstream change impact. The readable approved document, qualified review, controlled effective version, and validated local workflow remain authoritative.