Why US Clinical Labs Are Modernizing Now
Lab results inform more than 70% of all clinical decisions [1]. The LIS governs specimen accessioning, instrument interfacing, result reporting, and the audit trail that regulators inspect. When it fails, the diagnostic workflow of the health system fails with it.
Four concurrent pressures are forcing US labs to move now.
- Regulatory. The 2025 CLIA updates represent the first major overhaul in decades [2]. Tighter proficiency testing criteria, new analyte requirements, and stricter personnel qualification rules create compliance gaps that maintenance alone cannot close.
- Vendor consolidation. CoPath is effectively end-of-life following Oracle’s $28 billion Cerner acquisition. The Clinisys consolidation of Sunquest and Orchard has added further platform uncertainty across US hospital labs. Labs that delayed are now deciding under deadline.
- Cybersecurity. Legacy LIS platforms are a named ransomware attack surface. In confirmed 2025 incidents, legacy systems were explicitly identified as the primary point of entry. Average healthcare ransom payments reached $2.3 million in 2025, with recovery costs running three to five times that figure.
- Staffing. The lab technologist workforce faces a structural shortage exceeding 24,000 vacancies annually over the next decade. That gap is accelerating demand for autoverification, reflex triggering, and rules-based routing that aging platforms cannot reliably support.
The constraint that makes all of this harder: a lab running 5,000-plus tests per day does not stop. Every modernization decision is made against a system that must remain operational throughout.
LIS vs. LIMS: Understanding the Difference
A Laboratory Information System (LIS) and a Laboratory Information Management System (LIMS) are frequently conflated, but they serve different environments under different regulatory obligations.
| LIS | LIMS | |
| Environment | Clinical diagnostic labs: hospitals, reference labs, pathology departments | Research, environmental, pharmaceutical, and manufacturing labs |
| Regulatory framework | CLIA, CAP, HIPAA, state licensure | ISO 17025, GxP, research-specific standards |
| Core function | Patient specimen processing, result reporting, critical value alerting | Sample management and analytical data tracking |
| Typical users | Hospital core labs, reference labs, anatomic pathology | Pharma R&D, contract research organizations, environmental testing |
| Key integrations | EHR, analyzers, billing systems, PACS | Instruments, bioinformatics pipelines, research databases |
| Billing / RCM | Yes — CPT code mapping, payer logic, charge capture | No patient billing obligation |
The workflows, compliance obligations, failure modes, and vendor landscapes are distinct. This article addresses clinical LIS modernization in US hospital core labs, reference labs, and multi-site health systems specifically.
Why Clinical LIS Modernization Is Different
A clinical LIS is not a standard enterprise application. It is simultaneously connected to the EHR, pharmacy platform, billing system, PACS, reference lab partners, and 50 to 200 or more instrument analyzers running different communication protocols. Rebuilding that connectivity during a migration is where most programs fail.
The functional scope migration must preserve spans eight domains:
- Test ordering and specimen accessioning: Receives orders from the EHR, assigns accession numbers, and tracks chain of custody from receipt through result
- Instrument interfacing: Bi-directional communication with every analyzer on the fleet, each with its own protocol, field mapping, and transformation logic
- Rules engine: Auto-verification parameters, delta check thresholds, reflex testing algorithms, critical value thresholds, and result calculation formulas, encoded as system configuration
- Quality control: Westgard rule monitoring, QC lot management, and Levey-Jennings tracking across assays
- Result reporting: Structured delivery to the EHR, patient portal, ordering physician, and reference lab partners
- Billing and RCM: CPT code mapping, payer-specific logic, and charge capture tied to test completion
- Compliance and audit trail: The unbroken chain-of-custody record CLIA inspectors review; every specimen event, result modification, and result release logged
- Reference lab management: Send-out ordering, external result receipt, and result routing back into the patient record
No subset of these can be deferred. Migration must achieve functional equivalence across all eight before cutover.
CLIA and CAP set the governance floor. Any new or modified analytical method must be validated before go-live. This is a regulatory requirement, not a best practice. The audit chain cannot break during a transition window.
The CoPath replacement scenario is the sharpest current urgency signal for US pathology labs. A peer-reviewed migration study at a three-site health system documented what compliance-grade migration requires in practice: full SOP overhaul across all lab departments, 45 consecutive-case validation, and greater than 99% workflow reproduction confirmed before go-live [2].
Post-go-live, deficiencies were still found upstream of the LIS, in pre-analytic workflows the pre-migration assessment had not covered. Validation scope must extend beyond the LIS boundary. Limiting it to what sits inside the system is a scoping error that produces post-go-live findings.
Cerner CoPath End of Life: What US Pathology Labs Need to Do Now
CoPath Plus has been the dominant LIS for US anatomic pathology, surgical pathology, cytology, and molecular genetic pathology for decades. That era is ending.
Oracle’s $28 billion acquisition of Cerner in 2022 set the trajectory. Oracle has not made CoPath a strategic product. Active development has effectively ceased. Hundreds of US pathology labs are running a platform with no credible roadmap, no active security patching pipeline, and a vendor that has signaled consolidation rather than investment.
For labs still on CoPath, the question is no longer whether to migrate. It is how to do it without losing 20 years of accumulated AP configuration.
Why CoPath Migration Is Harder Than a Standard LIS Replacement
A clinical chemistry LIS migration is complex. A CoPath migration is a different category of problem.
The configuration that accumulates inside CoPath over 20 years is unlike anything in a core lab LIS. It includes:
- Gross description templates: Organ- and specimen-specific language frameworks built by pathologists over years, each tied to specimen type, procedure code, and site
- Microscopic interpretation workflows: Structured diagnosis entry logic, synoptic reporting templates, and cancer staging integrations customized to the department’s practice patterns
- Custom stain and special study protocols: IHC panel logic, special stain ordering rules, and result interpretation guidance encoded as system configuration
- Addendum and amendment workflows: Department-specific processes for result correction, attestation, and amended report routing
- CPT and billing logic: AP-specific code mapping tied to specimen type, procedure, and diagnosis combinations that differ substantially from clinical chemistry billing
None of this is documented. It exists in CoPath configuration, built incrementally by pathologists, AP informatics specialists, and LIS administrators who may no longer be at the institution.
The Timeline Pressure
Labs that are still evaluating options face a compressing window. Epic Beaker AP, Sunquest AP, and Ligolab are the primary replacement targets in the US market, and each requires a significant implementation and validation period.
A CoPath migration at a multi-site academic medical center realistically requires 18 to 24 months from project kick-off to full decommission.
Labs that have not begun the comprehension phase (extracting what CoPath actually contains before any platform selection) are already behind a responsible timeline.
The Comprehension Requirement
A CoPath migration cannot be safely planned without first producing a complete inventory of what the legacy system contains. Every gross template, every microscopic workflow, every billing rule, every stain protocol must be extracted, documented, and used as the configuration specification for the target system.
This is not a task the new platform vendor performs. They configure their own system. The comprehension work, mapping what CoPath contains before migration begins, is the prerequisite that determines whether the migration succeeds or reconstructs from memory.
The Two Problems That Break LIS Migrations
Every LIS migration eventually hits two structural problems. Both are knowable in advance. Both are consistently underestimated. The new platform vendor can solve neither, because both live in the legacy system.
The Instrument Interface Problem
A mid-to-large US hospital core lab connects 50 to 200 or more analyzers to the LIS. Each communicates via its own protocol: HL7 v2, ASTM LIS2-A, RS-232 serial, or fully proprietary interfaces across chemistry, hematology, coagulation, urinalysis, blood gas, microbiology, molecular, and POC devices.
These interfaces were not built at once. They accumulated over 15 years, often by IT staff who have since left. The full interface topology (field mappings, transformation rules, result routing logic, alert thresholds) exists only inside the running LIS. There is no external document that accurately reflects what the system is doing.
Rebuilding 150-plus custom connections is not a migration task. It is a parallel re-engineering project that must be completed, tested, and validated before the legacy system can be decommissioned.
A single missed field mapping in a coagulation interface can produce incorrect result flagging. A broken HL7 segment in a hematology interface can silence a critical value alert. The required discipline: map every interface configuration before any vendor conversation begins. Migrate in instrument-group waves, not a single cutover.
The Clinical Intelligence Problem
The LIS rules engine contains 15 or more years of encoded clinical decision logic. A peer-reviewed autoverification study validated 833 individual rules across 30 assays at one lab; 93.87% passed in the initial phase [3].
None of this logic is in a document. MLO Online notes that most labs lack the source of truth documentation that annual rule audit standards require [4]. The rules exist in LIS configuration only.
Six categories of logic accumulate to that scale. Each carries distinct failure modes when misconfigured during migration.
Auto-Verification Parameters
Auto-verification parameters are the conditional rules that determine whether a result can be automatically released to the ordering physician without technologist review. They encode instrument-specific flag logic, reference range checks, delta comparisons, and result-state conditions that must all evaluate to “pass” before auto-release is triggered.
When these parameters are missing or misconfigured in the target system, the failure mode is not an error message. The lab’s auto-verification rate drops without a clear signal as to why. Technologist review queues fill unexpectedly. What was releasing automatically now requires manual review on every result: an invisible degradation in throughput that surfaces only after go-live.
Delta Check Thresholds
Delta checks compare a patient’s current result against their most recent prior result for the same analyte, within a defined time window. Each analyte has its own delta threshold, its own time window, and its own action rule: hold for review, flag for supervisor, auto-release despite the delta, or reflex to a confirmatory test.
A delta check misconfigured with the wrong threshold allows results to auto-release that should be flagged. One set at too tight a value floods the review queue with false positives. Both degrade the lab’s clinical reliability without triggering an obvious system error.
The misconfiguration is invisible until a clinical team notices that results are behaving differently from the legacy system.
Reflex Testing Algorithms
Reflex testing algorithms define the conditional logic that automatically orders a follow-up test when an initial result meets a trigger condition. A CBC with abnormal white cell flags triggers a peripheral blood smear order. A positive RPR triggers a TPPA confirmation. A hemoglobin value below a defined threshold triggers hemoglobin electrophoresis.
These algorithms are department-specific, built over years, and often extended informally when clinical practice changes.
A missed reflex algorithm in the modernized system means a follow-up test that does not fire. For a patient whose diagnosis depends on that confirmatory result, the missed trigger is a clinical failure that produces no error log, because the system does not know a reflex was supposed to occur.
Critical Value Thresholds and Alert Routing
Critical value thresholds define the analyte ranges that require immediate clinician notification: potassium below 2.5 or above 6.5, glucose below 40, and hemoglobin below 6.0. CLIA mandates that labs establish, maintain, and document critical value policies, and that results meeting those thresholds are communicated to the responsible clinician within a defined timeframe.
A missed or misconfigured critical value threshold in the modernized system is simultaneously a patient safety event and a CLIA regulatory finding. It is the highest-stakes failure mode in LIS migration. Unlike auto-verification degradation, which affects throughput, a missed critical value alert can affect patient outcomes directly.
Result Calculation Formulas
Many reported results are not raw instrument outputs. They are calculated values derived from multiple measured inputs. Anion gap is calculated from sodium, chloride, and bicarbonate. Corrected calcium adjusts for albumin concentration. eGFR is derived from creatinine, age, sex, and race using a standardized equation. Calculated LDL applies the Friedewald formula to cholesterol, HDL, and triglyceride values.
These formulas must be re-implemented in the target system with identical precision. A formula that uses a different equation version, a different rounding method, or a different albumin correction factor will produce results that differ systematically from the legacy system.
These discrepancies are difficult to detect during validation unless the testing set explicitly covers the edge cases where the formulas diverge.
Interpretive Comment Libraries
Interpretive comment libraries are collections of structured text linked to specific result ranges, analyte flags, and clinical contexts. They are built over years by lab directors and medical directors, and they represent the lab’s accumulated interpretive guidance: the annotation that appears on a result report to help the ordering physician understand an unusual finding.
These libraries are among the most underestimated components of an LIS migration. They are not clinical rules in the automated sense. They do not trigger actions. But they are part of the result output that clinicians rely on. A migrated system that loses its interpretive comment library produces result reports that are technically accurate but stripped of the contextual guidance the lab has developed over its operational lifetime.
Most US labs cannot produce a complete autoverification rule catalog from existing records. A $0 Modernization Assessment extracts it directly from the codebase, every parameter, every threshold, every reflex algorithm. Request yours here.
Three Paths for Clinical LIS Modernization
US hospital labs and health systems evaluating LIS modernization are effectively choosing between three paths. The right path depends on the state of the legacy system, the lab’s timeline pressure, and how much of the existing configuration is understood before the program begins.
| Path | Best For | Typical Timeline | Primary Risk | When to Choose It |
| Commercial platform replacement (LigoLab, Orchard, SCC, Sunquest) | Labs with well-documented configurations and manageable interface counts | 12 to 18 months | Undiscovered configuration gaps surface post-go-live | Legacy system is well-understood; documentation exists and is current |
| Integration-layer modernization (middleware / API layer preserving legacy core) | Labs needing EHR connectivity improvements without full replacement | 6 to 12 months | Legacy core debt remains; compliance gaps not addressed | Short-term connectivity problem; full replacement deferred intentionally |
| Comprehend-and-modernize (extract legacy logic before committing to a platform) | Labs with large interface counts, undocumented rules engines, or CoPath EOL pressure | 18 to 24 months | Timeline extends if comprehension phase is underestimated | Configuration is not well-understood; documentation gaps are known or suspected |
Path three is not simply a methodology preference. It is the prerequisite for paths one and two.
A commercial platform replacement executed against an incomplete picture of the legacy system’s interface topology and rules engine is path one in name only. It is path three with the comprehension phase skipped, which means undiscovered gaps surface after go-live rather than before. Integration-layer modernization that preserves a legacy core without understanding what that core contains leaves the highest-risk configuration intact.
For most US labs evaluating CoPath replacement, or for any lab with more than 50 instrument interfaces and no current interface documentation, path three is not a conservative choice. It is the only choice that produces a known-complete migration.
LIS Migration Execution: Parallel Running, CLIA Compliance, and Timeline Planning
Given the constraints above, LIS migration execution is governed by requirements defined by CLIA, CAP, and the realities of 24/7 US clinical operations.
Parallel Running Is Not Optional
Both the legacy and target LIS must operate simultaneously through the transition. Results must be reconcilable. Specimen IDs must be continuous or dual-mapped so any specimen accessioned during the window is traceable in both systems.
This is the operational safety net that prevents specimen loss. It is also the mechanism for verifying equivalence in a production environment before the legacy system is decommissioned.
Standard timelines by scope:
| Migration Scope | Typical Timeline | Parallel Running Period |
| Single community hospital lab | 6 to 12 months | 2 to 4 weeks minimum for core lab |
| Multi-site US health system | 12 to 24 months | Per-site, staggered; longer for microbiology and molecular |
| Reference lab with high send-out volume | 12 to 18 months | Extended for reference lab partner interface validation |
These timelines assume pre-migration comprehension work is complete before implementation begins. Labs that start vendor selection before mapping their interface topology and rules engine are building a schedule on incomplete information.
CLIA Chain-of-Custody Continuity
CLIA requires an unbroken audit trail for specimen receipt, processing, and result reporting [5]. A gap in that trail is a CLIA finding, regardless of whether the specimen was processed correctly. Migration windows do not create a regulatory exception.
Designing for CLIA continuity during parallel running requires three specific structural decisions before go-live:
- Accession number continuity: The legacy and target systems must either share a continuous accession number sequence or maintain a dual-mapping table so any accession number from the transition window resolves in both systems. A specimen accessioned in the legacy system during the parallel period must be traceable in the target system’s audit trail.
- Result record synchronization: Results generated in the legacy system during parallel running must be queryable in the target system post-cutover. This requires either data migration of in-flight results or a defined retention policy for the legacy system during the post-cutover warranty period.
- Audit log integrity: Both systems must produce complete, timestamped event logs for every specimen action during the parallel window. Gaps in either log constitute a CLIA finding independent of the accuracy of the results themselves.
These decisions must be designed, built, and tested before going live. Resolving them during parallel running under live lab conditions is the error mode that produces regulatory findings.
The Cost of Getting This Wrong
A lab that migrates with unresolved critical value configurations carries a patient safety liability from day one. A lab mid-transition on a legacy platform with known cybersecurity exposure faces ransomware recovery costs that dwarf any timeline savings.
The investment in mapping every interface and extracting every rule before migration begins is small against the cost of discovering what was missed after cutover.
How Legacyleap Approaches LIS Modernization
Pre-migration comprehension and post-migration parity validation are where conventional tooling provides the least support. A platform vendor configures their own system. They cannot extract what lives in your legacy LIS before the process begins. That gap is where migrations are lost.
Legacyleap is a US-focused legacy modernization company that closes that gap through a multi-agent platform operating at the system level, not the file or prompt level. For US hospital core labs, reference labs, and health systems evaluating LIS replacement, the relevant capabilities are the Assessment Agent, the Documentation Agent, and the QA Agent.
Assessment Agent: Extracting What the Legacy System Contains
The Assessment Agent maps the legacy LIS codebase directly, from the system itself, not from documentation or institutional memory.
For a clinical LIS, that means a complete inventory of every instrument interface: protocol, field mappings between instrument output and LIS fields, transformation logic applied to raw instrument data, and alert conditions tied to result patterns.
It also means extracting the full rules engine: auto-verification parameters, delta check thresholds, reflex logic, critical value configurations, and calculation formulas.
The output is a structured catalog the lab can review, validate, and use as the configuration specification for the target system. Most US labs cannot produce this catalog from existing records. Without it, migration planning is built on memory.
Documentation Agent: The Asset CAP Validation Requires
The Documentation Agent produces the test rule catalog and interface specification library as structured, reviewable outputs. These are the documented baseline, method by method and rule by rule, that CAP requires before any new or modified analytical method can go live.
A static document that accurately reflects an aging LIS configuration usually does not exist. The Documentation Agent derives the specification directly from the codebase, then makes it available for lab director review and sign-off before migration planning proceeds.
QA Agent: Clinical Parity Enforcement
Parity validation in a clinical LIS context is not a code compilation check. The QA Agent validates that the modernized system produces identical auto-verification decisions for equivalent inputs. A result that triggered a technologist review flag in the legacy system must trigger the same flag in the new system. A result that auto-released must auto-release under the same conditions.
This applies directly to critical value alerts. A missed threshold in a US clinical lab is simultaneously a patient safety event and a CLIA finding. The QA Agent runs as a pre-cutover gate, not a post-deployment audit.
Governance and Deployment
Every transformation Legacyleap produces is diff-based and requires human review before acceptance. AI cannot merge, deploy, or execute code paths. This is an architectural constraint, not a policy.
For CLIA-regulated environments, that distinction matters. Every change to a system governing clinical decisions must be reviewable, attributable, and logged. Legacyleap’s diff-based review model and audit logs are aligned to that requirement by design.
As a modernization services partner for regulated US health systems and reference labs, Legacyleap deploys on-prem or within the client’s VPC. Source code never leaves the client’s infrastructure. PII filters are applied before inference. Access policies are configurable to HIPAA requirements.
The platform’s incremental approach maps directly to the parallel running requirement LIS migration demands. The lab continues on the legacy system while the modernized system is built against the extracted rule and interface catalogs, validated for parity, and transitioned one instrument group or functional domain at a time.
| Legacyleap Capability | LIS Modernization Application |
| Assessment Agent — full codebase mapping | Complete instrument interface topology and rules engine catalog |
| Documentation Agent — structured output generation | CAP-required documentation baseline for method validation |
| QA Agent — parity validation | Auto-verification decisions and critical value alerts enforced pre-cutover |
| Diff-based human review, no AI write access | Audit trail aligned to CLIA and HIPAA |
| On-prem / VPC deployment | Data residency and PHI handling met by design |
| Incremental, phased transformation | Parallel running constraint accommodated for 24/7 operations |
Where to Start Based on Your Situation
The right first step depends on where your lab sits in the decision process.
- If you are on CoPath with an Oracle deadline bearing down: The comprehension phase is already overdue. The first step is a complete extraction of your CoPath configuration (gross templates, microscopic workflows, billing logic, stain protocols) before any platform selection conversation begins. Selecting Epic Beaker, Sunquest AP, or any other replacement target without that inventory means configuring the new system against assumptions.
- If you have 150-plus instrument interfaces and no complete interface documentation: Map the interface topology before the migration timeline is set. Every interface that is not documented before migration planning begins is a risk item that will either compress the timeline or surface post-go-live. The interface extraction is the deliverable that makes the migration plan credible.
- If you are pre-vendor-selection and have not mapped your rules engine: Do not begin vendor evaluation without first understanding the scale and complexity of what you need to configure in the target system. A vendor demo cannot tell you how many autoverification parameters, delta check thresholds, or reflex algorithms your legacy system contains. Only the codebase can.
With a 2025 CLIA regulatory update in effect and CoPath replacement pressure active across US pathology departments, the labs that move through the comprehension phase now are the ones that avoid discovering their gaps under the deadline.
A $0 Modernization Assessment produces the interface topology, rules engine inventory, and modernization blueprint needed before any migration conversation begins.
Our Technical Demo shows Legacyleap’s LIS-specific comprehension and documentation capabilities in action, including how the Assessment Agent maps a legacy interface topology and how the Documentation Agent produces a test rule catalog that meets CAP validation requirements.
FAQs
Replatforming preserves the existing application logic while migrating it to a modern infrastructure or runtime: a new database engine, a containerized deployment, or a cloud-hosted environment. Replacement retires the legacy system entirely and reconfigures its functionality in a new platform. For most US hospital labs, replatforming a clinical LIS is not a realistic option because the underlying logic is vendor-proprietary and cannot be extracted and redeployed. Replacement is the operative path. The correct approach for a mid-size lab is comprehend first: extract the full interface topology and rules engine from the legacy system, then select the replacement platform, then configure against the extracted specification.
CLIA requires an unbroken chain-of-custody audit trail for every specimen from receipt through result release. During a migration window, every specimen event (accessioning, processing, result entry, result modification, result release) must be logged in a system of record at all times. A finding occurs when any gap exists in that trail, regardless of whether the underlying result was accurate. Common migration-related findings include: accession numbers that cannot be resolved in either system during the parallel window, result records present in the legacy system but not migrated to the target, and audit log timestamps that do not account for the full parallel running period.
The primary replacement targets in the US market are Epic Beaker AP, Sunquest AP (Clinisys), and LigoLab. Epic Beaker is the most common destination for health systems already on Epic EMR, given the integration advantage. Sunquest AP is the natural path for labs already in the Clinisys ecosystem. LigoLab is gaining share as an independent replacement, particularly for reference labs and labs seeking a standalone AP platform. The selection decision depends heavily on EMR alignment, existing Clinisys relationships, and the volume and complexity of the legacy CoPath configuration that must be reproduced.
The four most consistent failure causes are undocumented instrument interfaces discovered mid-migration rather than before planning begins; incomplete rules engine extraction that produces post-go-live auto-verification failures and missed critical value alerts; validation scope limited to the LIS boundary that misses pre-analytic workflow deficiencies; and parallel running periods too short to verify equivalence across the full test menu before legacy decommission. All four are plannable and preventable. They are not execution failures. They are pre-planning failures.
Costs vary substantially by scope, interface count, rules engine complexity, and whether the lab is replacing a clinical chemistry LIS, an AP system, or both. A single community hospital core lab replacement typically ranges from $500,000 to $1.5 million in total program cost, including software licensing, implementation services, validation, and internal resource time. A multi-site health system replacing both clinical and AP systems across three or more sites can reach $5 to $15 million or more. These figures are directional; actual costs depend on interface count, rules complexity, and the comprehension work required before configuration begins. Labs that skip pre-migration comprehension typically incur significantly higher post-go-live remediation costs.
Most legacy LIS platforms communicate with the EHR via HL7 v2, a message-based standard that has been in clinical use since the 1980s. Modern EHR platforms increasingly expect HL7 FHIR, a REST-based API standard. The translation between these two protocols is handled either by an interface engine (Mirth Connect, Rhapsody, Iguana) or by the LIS vendor’s own integration layer. During LIS migration, the interface engine configuration (message mappings, transformation rules, acknowledgment handling, error routing) must be reproduced for every order and result message type. Breaks in this layer produce silent failures: orders that do not reach the LIS, results that do not reach the EHR, and acknowledgment gaps that are not detected until a clinician notices a missing result. The interface mapping documentation produced during the comprehension phase is the specification this rebuild requires.
References
[1] CDC Division of Laboratory Systems. 70% of medical decisions depend on laboratory test results. CDC Foundation. https://www.cdcfoundation.org/programs/global-health-security-laboratory
[2] Treskin E, et al. Data migration, validation and implementation of a new laboratory information system in an academic pathology department. PMC, June 2025. https://pmc.ncbi.nlm.nih.gov/articles/PMC12332207/
[3] Xiao Y, et al. Development and implementation of an LIS-based validation system for autoverification. PMC, 2021. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8170738/
[4] MLO Online. Auto-verification rules — now what? https://www.mlo-online.com/information-technology/lis/article/13017229/auto-verification-rulesnow-what
[5] CMS. Clinical Laboratory Improvement Amendments (CLIA). https://www.cms.gov/regulations-and-guidance/legislation/clia
