TL;DR​

The pragmatic 2026 stance: support both in the LIMS, prefer v2 when the partner offers both, plan a multi-year migration to FHIR for new integrations. This post explains why.

:::note LabFlow has no integration module today This is a domain primer, not a product page. LabFlow implements neither HL7 v2 nor FHIR. Interoperability is planned work — see the roadmap. :::

What HL7 v2 looks like on the wire​

An ORM^O01 order message:

MSH|^~\&|EMR_SYS|MERCY_HOSPITAL|LAB_SYS|MERCY_LAB|20260511093045||ORM^O01|MSG00123|P|2.5.1
PID|1||MRN12345^^^MERCY^MR||GARCIA^MARIA^^^||19850712|F|||123 MAIN ST^^BOSTON^MA^02101||(617)555-1234
PV1|1|O|ER^01^A|||||||||||||||V00078
ORC|NW|ORD789012||GRP456||||||||||DOE^JOHN^^^MD
OBR|1|ORD789012|||GLUCOSE^GLUCOSE TOLERANCE^L|||20260511090000|||||||||DOE^JOHN^^^MD
NTE|1||Patient fasted for 12h.

The structure is segment-line / field-pipe / component-caret / subcomponent-ampersand. The MSH (Message Header) declares the message type (ORM^O01), version (2.5.1), and routing. PID carries patient identification. PV1 carries the patient visit (encounter). ORC is the common order. OBR is the test request. NTE is a note.

The same message in FHIR R4 (as a ServiceRequest bundle):

{
  "resourceType": "Bundle",
  "type": "message",
  "entry": [
    {
      "resource": {
        "resourceType": "ServiceRequest",
        "status": "active",
        "intent": "order",
        "code": {
          "coding": [{"system": "http://loinc.org", "code": "2345-7", "display": "Glucose [Mass/volume] in Serum or Plasma"}]
        },
        "subject": {"reference": "Patient/pat_001"},
        "requester": {"reference": "Practitioner/prov_123"},
        "encounter": {"reference": "Encounter/enc_456"},
        "note": [{"text": "Patient fasted for 12h."}]
      }
    },
    {
      "resource": {
        "resourceType": "Patient",
        "id": "pat_001",
        "identifier": [{"system": "urn:mercy:mrn", "value": "MRN12345"}],
        "name": [{"family": "Garcia", "given": ["Maria"]}],
        "birthDate": "1985-07-12",
        "gender": "female"
      }
    }
  ]
}

The same information, twice the verbosity. FHIR's resource-and-bundle model is self-documenting (every field has a published StructureDefinition) at the cost of a bigger wire footprint. The trade-off is intentional — FHIR was designed to be human-readable and to be parsed by generic JSON tooling without needing the HL7 spec on screen.

Why HL7 v2 still dominates clinical traffic​

Three reasons, in order of impact.

The first is inertia. Every clinical EMR has an HL7 v2 integration team that's been running for 20+ years. The order-to-result loop with the local lab is wired through v2; switching to FHIR means re-engineering an integration that already works. The cost is high; the immediate benefit is unclear.

The second is completeness. The HL7 v2 spec covers every clinical-message scenario through 30+ years of accumulated revisions — patient registration (ADT), orders (ORM), results (ORU), scheduling (SIU), pharmacy (RDS), billing (DFT). FHIR R4 covers the equivalent but the equivalents are newer; some edge cases (specific instrument-result patterns, specific reimbursement workflows) still have richer v2 coverage than FHIR coverage.

The third is fall-back tooling. The ecosystem of HL7 v2 integration engines (Mirth Connect, Rhapsody, Iguana, Cloverleaf, NextGen Connect) is mature, well-staffed, and operationally stable. A lab that runs into a v2 integration issue at 2am has documented paths to fix it. The FHIR equivalent (HAPI FHIR Server, Aidbox, Medplum, Microsoft FHIR Server) is competitive on technical merits but the operational depth — the runbook for 2am — is shallower.

The net is that clinical-lab integrations in 2026 are predominantly v2 in production, with FHIR endpoints sitting alongside as a secondary surface. The roadmap is FHIR-everywhere; the production reality is v2-with-FHIR-alongside.

Where FHIR R4 has won​

The FHIR R4 wins are concentrated in three areas.

Patient-facing apps and APIs. The 21st Century Cures Act in the United States (2020) mandated that EMRs expose FHIR-based patient APIs. Every certified EMR now does. Patient-facing apps (the patient portal, third-party health apps) connect via FHIR, not v2. A LIMS that wants to be readable by a patient app via the EMR's FHIR endpoint must speak FHIR.

Value-based-care reporting. CMS quality-measure submissions and HL7's eCQI reporting use FHIR. A laboratory whose data feeds value-based-care metrics must export FHIR-shaped data.

New integrations. A greenfield integration in 2026 — a new lab onboarding to a new EMR, a research collaboration, a public-health surveillance feed — is usually written in FHIR rather than v2. The new code defaults to FHIR; the old code stays on v2.

This is why a modern LIMS supports both surfaces — production traffic on v2, patient-app and reporting traffic on FHIR. Neither protocol is going away; the boundary between them is workflow-dependent.

Message-type mapping​

The canonical mapping between v2 messages and FHIR resources for laboratory workflows:

The mapping isn't always one-to-one. An ORU^R01 with multiple OBX segments (one per analyte) maps to one DiagnosticReport with many Observation resources. An OBR carries a test panel; the FHIR equivalent is the ServiceRequest.code with a panel LOINC and the constituent ServiceRequest.replaces references.

A lab that supports both protocols typically maintains a per-connection mapping table that translates partner test codes to LOINC and vice-versa.

Transport differences​

HL7 v2 typically transports over MLLP (Minimal Lower Layer Protocol) — a raw TCP connection with start-of-block and end-of-block markers around each message. Sometimes v2 is also delivered via SFTP file drops, or via HTTPS as a webhook payload. The transport is a separate decision from the message format.

FHIR R4 is almost always REST over HTTPS — POST /ServiceRequest to create an order, GET /Observation?subject=Patient/123 to query results. Authentication is OAuth 2.0 (typically with SMART on FHIR profile) or mTLS. The transport is part of the spec.

The transport difference matters operationally. MLLP needs network-level access (often a VPN or a dedicated leased line); it doesn't traverse corporate proxies cleanly; it requires firewall rules per partner. FHIR's HTTPS transport rides existing internet infrastructure — much simpler to set up, easier to monitor, more amenable to mutual TLS or OAuth.

Tooling comparison​

The tooling gap explains a real part of why labs prefer to do new work in FHIR — the tools are nicer to use, the validator is published by the standards body itself, and the data shape is documented inline rather than requiring a separate reference.

Migration strategy — the canonical pattern​

A lab that wants to migrate from v2-dominant to FHIR-dominant typically goes through five phases over 2-5 years.

Phase 1 — accept FHIR inbound. Start by accepting FHIR ServiceRequest for new orders alongside v2 ORM^O01. Both produce the same canonical order in the LIMS. The EMR partners that already speak FHIR can switch; the v2-only partners are unaffected.

Phase 2 — emit FHIR outbound for new partners. Any partner onboarded after a certain date defaults to FHIR Observation + DiagnosticReport outbound. Existing partners continue receiving v2 ORU^R01.

Phase 3 — dual-emit for transitional partners. Existing v2 partners get FHIR emission added in parallel; both wires carry the same data. The partner's clinical team validates the FHIR side against the v2 side over several months. Once validated, the v2 side is retired for that partner.

Phase 4 — patient-facing FHIR. The patient portal (and any third-party patient apps) connect via FHIR. By this phase, FHIR coverage is broad enough that the patient app is the primary use case for FHIR-emit on the lab side.

Phase 5 — v2 maintenance mode. v2 is still supported for the long-tail partners that haven't migrated, but new development stops on v2. The integration engine continues to run; engineering attention shifts to FHIR.

Most large labs in 2026 are between Phase 2 and Phase 4. Phase 5 is rare; even labs that consider themselves "FHIR-first" still emit v2 for legacy partners.

The honest framing — neither is going away​

A common mistake when reading about HL7 v2 and FHIR R4 is to assume one will replace the other. The realistic 2026 view:

• HL7 v2 is not going away soon. The installed base is too large; the migration cost per partner is too high; the immediate benefit per partner is too small. v2 will continue to carry the majority of clinical-lab production traffic through 2030 at least.
• FHIR R4 is not optional. Every modern EMR exposes FHIR; every patient-facing app connects via FHIR; every value-based-care reporting flow uses FHIR. A LIMS without FHIR support is unbookable for new integrations and unable to serve patient apps.
• The two coexist. A modern LIMS speaks both, maps between them at the canonical-data-model layer, and routes inbound and outbound traffic per-partner. The boundary is workflow-dependent, not technology-dependent.

A system that takes this stance explicitly treats both protocols as first-class: a per-connection field-mapping dictionary handles the translation, and one canonical order produces v2 or FHIR output according to the partner's connection record.

Frequently asked questions​

Is HL7 v2 deprecated by the HL7 standards body?​

No. HL7 v2 is still actively maintained by HL7 International. The current version is v2.9 (released 2019); v2.10 is in development. The standards body recognises that v2 is in production everywhere and continues to evolve it alongside FHIR.

Can I run an EMR integration over FHIR alone, with no HL7 v2 at all?​

For greenfield deployments with a new EMR partner that supports FHIR-write fully, yes. For most production scenarios — where the partner's clinical workflow already runs on v2 — practical answer is no, you'll still need v2 for the existing path. The pragmatic stance is "FHIR-where-possible, v2-where-required".

What about HL7 v3 and CDA documents?​

HL7 v3 (the predecessor to FHIR) is rarely seen in lab integrations today; it was complex enough that most vendors skipped it and went straight to v2-or-FHIR. CDA (Clinical Document Architecture) is a separate concern — it's used for clinical document exchange (discharge summaries, care plans) rather than for the order-result lab loop. A lab integration almost never touches v3 or CDA directly; if a partner only speaks them, a transformation layer (Mirth Connect with a custom transformer) typically sits between.

Does FHIR R4 cover every clinical use case v2 covers?​

For the lab-EMR loop, yes — orders, results, patient updates, scheduling, billing all have FHIR resources. For some specific edge cases (instrument-specific result formats, certain pharmacy workflows), v2 still has richer real-world coverage because the v2 specs accumulated 30+ years of vendor extensions. For new integrations, FHIR is sufficient; for migrating an existing integration with vendor extensions, the gap analysis is per-partner.

How does SMART on FHIR fit in?​

SMART on FHIR is a security profile for FHIR — it specifies how an OAuth 2.0 flow works between an EMR (acting as authorization server) and a third-party app (the FHIR client). The 21st Century Cures Act in the US mandates SMART on FHIR for patient-facing apps. From the LIMS perspective, SMART on FHIR governs how patient-facing surfaces (the patient portal, mobile apps) authenticate to the EMR's FHIR endpoint; the LIMS-to-EMR backend integration usually uses a separate machine-to-machine auth (typically OAuth client credentials or mTLS).

What about cost — is FHIR cheaper to integrate than v2?​

The unit economics tilt toward FHIR for greenfield: less specialist talent needed, no MLLP infrastructure, simpler validation. For migrating an existing v2 integration, FHIR is more expensive in the short term (re-engineering cost) and cheaper in the long term (lower ongoing maintenance). The break-even is usually 12-24 months, but varies wildly by integration complexity.

Should I learn HL7 v2 if I'm starting in lab informatics in 2026?​

Yes, despite the steep learning curve. v2 is what's running in production today; if your work touches lab integrations at all, you'll see v2. Learning FHIR first is easier (it's self-documenting); learning v2 second extends the skill set. The combination is durable — both protocols will be relevant through the 2020s and beyond.

Does LabFlow support either?​

No — neither, today. LabFlow implements no HL7 v2 messaging and no FHIR resources, and it exposes no public API of any kind. Interoperability is planned and unbuilt; the sequence is on the roadmap. What LabFlow does have today is the coded catalogue any future mapping would need — see the test catalogue.

Where to read more​

• What LabFlow has not built — including interoperability.
• HL7 v2 official site — the standards-body reference.
• HL7 FHIR R4 specification — the canonical FHIR reference.
• Inferno test suite — the official FHIR conformance test suite, useful for validating a FHIR endpoint.
• Mirth Connect (NextGen Connect) — the canonical open-source v2 integration engine.

About the author: Ahsan Mahmood is the engineer behind LabFlow. Contact at aoneahsan@gmail.com or via aoneahsan.com.

:::note LabFlow does not implement quality control today Quality control is planned and unbuilt — see the roadmap. Nothing below describes a LabFlow feature. :::

The vocabulary first​

A QC measurement is a single reading of a control material — a manufactured substance whose target concentration is known. The lab runs the control through its analyser the same way it runs a patient sample, plots the measured value on a Levey-Jennings chart, and checks the rules. The vocabulary:

The mean and SD come from one of two sources. The manufacturer ships an assayed value with each lot (the population mean across many labs); the lab also computes an in-house mean / SD after 20 in-house measurements. The in-house values are typically tighter than the manufacturer's broader-population assay; the lab uses the in-house values once available.

The six base rules​

Each rule's name encodes its trigger: "how many consecutive measurements, how many SDs from the mean, on which side".

1-2s — the warning, not the rejection​

Trigger: 1 measurement is more than 2 SD from the mean (either side).

Verdict: Warning. Not a rejection rule on its own.

Why a warning: About 5% of in-control measurements naturally land outside ±2 SD by chance (the area under a normal distribution beyond ±2 SD is approximately 4.55%). Treating every 1-2s as a rejection produces a 5% false-rejection rate — far too high for a routine workflow. Westgard's original 1981 paper specifically warned against using 1-2s standalone.

How to use it: Use 1-2s as the trigger that escalates evaluation of the stricter rules. If 1-2s trips on a measurement, the system evaluates 1-3s, 2-2s, R-4s, 4-1s, 10-x in sequence. If none of those trip, the run is in-control with a 1-2s warning logged. If any of those trip, the run is out-of-control.

1-3s — the random-error catcher​

Trigger: 1 measurement is more than 3 SD from the mean (either side).

Verdict: Reject.

Clinical interpretation: A measurement at >3 SD has a natural-occurrence probability of about 0.27% (twice the area beyond ±3 SD on a normal distribution). A 1-3s trip on a true in-control run is rare; it usually signals a single random error — a sample mishandling, a pipetting mistake, a one-off analyser glitch. Look at the most recent maintenance or operator change; re-run the QC.

2-2s — the systematic-shift catcher​

Trigger: 2 consecutive measurements (on the same level or across the lab's run grid, see below) are more than 2 SD from the mean on the same side.

Verdict: Reject.

Clinical interpretation: Two consecutive measurements both >2 SD on the same side rarely happens by chance (probability about 0.05%). It usually signals a systematic shift — a new reagent lot needs recalibration, the analyser's calibration has drifted, an instrument temperature is off. The fix is a recalibration or reagent-lot change followed by re-QC.

The "same side" condition is key. Two measurements at +2.1 SD and -2.1 SD do not trip 2-2s; those would trip R-4s instead (random-error increased imprecision). The directional consistency is what makes 2-2s a systematic signal.

R-4s — the random-imprecision catcher​

Trigger: Within the same QC run (or across consecutive runs on the same analyser + analyte), 2 measurements differ by more than 4 SD — one above +2 SD and one below −2 SD.

Verdict: Reject.

Clinical interpretation: Increased random error — the analyser is now imprecise. Common causes: a pipette is jamming, a reagent is partially expired, the analyser's sampling probe is contaminated. The fix is a hardware-side intervention (clean / replace / recalibrate) followed by re-QC.

4-1s — the smaller-systematic-shift catcher​

Trigger: 4 consecutive measurements are more than 1 SD from the mean on the same side.

Verdict: Reject.

Clinical interpretation: Like 2-2s but with smaller individual deviations and a longer pattern. Systematic shift that's persistent but mild — often a recalibration or a reagent-lot change picked up before it grows into a 2-2s. Same fix as 2-2s.

10-x — the long-drift catcher​

Trigger: 10 consecutive measurements are on the same side of the mean (regardless of how close to the mean they are).

Verdict: Reject.

Clinical interpretation: Long-running systematic drift — the analyser has slowly moved off-target. Common cause: a slow degradation in reagent (an opened vial sitting too long), a calibration that's slowly drifting, a temperature trending. The fix is a fresh calibration followed by re-QC. 10-x is sensitive to mild drifts that the other rules miss.

Some labs use 8-x or 12-x instead of 10-x; the exact number is a configurable parameter in most LIMS. The principle is the same.

The canonical multi-rule set​

Westgard's canonical recommendation, still the most-used in 2026:

1-2s as warning → if trip, evaluate 1-3s / 2-2s / R-4s / 4-1s / 10-x in sequence. Reject on the first hit. If none, in-control with a 1-2s warning logged.

The evaluation order matters. The strictest rules (1-3s) run first; the weakest catchers (10-x) run last. A 1-3s trip on the current measurement is a rejection regardless of whether 4-1s would also trip — the system stops at the first rule that fires.

In a flow chart:

new measurement
  ↓
| is 1-2s tripped? |
  ↓ no             ↓ yes
 in-control       check 1-3s
                  ↓ no
                  check 2-2s
                  ↓ no
                  check R-4s
                  ↓ no
                  check 4-1s
                  ↓ no
                  check 10-x
                  ↓ no
                  in-control with 1-2s warning logged

Rules that need >1 measurement (2-2s, R-4s, 4-1s, 10-x) consider the current run plus the most-recent N−1 in-control runs on the same analyte + same analyzer + same level. The "same analyzer" qualification matters in a multi-instrument lab — a 10-x trend on Cobas-A should not lock reporting on Cobas-B, because the instruments are independent.

How to read a Levey-Jennings chart​

A Levey-Jennings (LJ) chart plots QC measurements on a single analyte × level over time. The X-axis is the run number or timestamp; the Y-axis is the measured value. Three horizontal bands mark the SD lines:

       value
         |
  +3 SD ─┼───────────────────────  reject band (1-3s)
         |
  +2 SD ─┼───────────────────────  warning band (1-2s)
         |
  +1 SD ─┼───────────────────────
         |
   mean  ┼━━━━━━━━━━━━━━━━━━━━━━━  target
         |
  -1 SD ─┼───────────────────────
         |
  -2 SD ─┼───────────────────────  warning band (1-2s)
         |
  -3 SD ─┼───────────────────────  reject band (1-3s)
         |
         └───────────────────────────────────── time / run

Each QC measurement is a dot on the chart. Visual patterns to spot:

• Single outlier above +3 SD or below -3 SD — 1-3s rejection.
• Two consecutive dots both above +2 SD (or both below -2 SD) — 2-2s rejection.
• One dot above +2 SD and the next below -2 SD — R-4s rejection.
• Four consecutive dots above +1 SD (or below) — 4-1s rejection.
• Ten consecutive dots all above the mean (or all below) — 10-x rejection.
• A consistent slow climb or descent — drift; 10-x will catch it eventually but a human eye spots it sooner.

A good LJ chart also marks lot transitions (vertical dashed lines) because each new lot resets the in-house mean / SD computation, and it surfaces the violated rule code per point rather than only colouring the point.

What happens when a rule trips​

When a rule rejects, the QC run is marked out-of-control and the system locks patient-result reporting for the (analyte + analyzer) pair until the lab acknowledges and acts. The action options:

Patient reporting unlocks automatically when the next QC pass is in-control. The override path requires a Lab Manager with the explicit qc.override permission, and the audit row carries the manager's name and the reason.

Beyond the six base rules​

The six base rules are the canonical set. Extensions exist for specific scenarios:

Most modern LIMS expose these as configurable rule combinations on a per-analyte basis. The default ship is usually the canonical Westgard multi-rule; the custom rules are opt-in.

Sigma metrics — the modern complement​

Sigma metrics quantify a method's analytical performance as a "sigma value" — roughly, how many SDs of tolerance fit between the method's bias and its allowable error. The formula:

sigma = (TEa - |bias|) / CV

Where TEa is the total allowable error (often from CLIA limits), |bias| is the absolute systematic bias the method shows vs. a reference, and CV is the coefficient of variation (SD / mean × 100).

A method at sigma ≥ 6 is "world-class" — almost any QC rule set will catch errors before they reach patients. A method at sigma ≤ 3 is shaky and needs the strictest possible multi-rule set just to stay safe. The Westgard team published charts ("Westgard Sigma Rules") that prescribe which rule combination to use based on the method's sigma value:

Sigma metrics aren't enforced in rule evaluation; they're an evidence artefact for performance reviews and an input to choosing the multi-rule set. A lab tracks its sigma metrics per analyte and reviews them quarterly.

Frequently asked questions​

Why isn't 1-2s a rejection rule?​

Because about 5% of in-control runs naturally trip 1-2s by chance (the area beyond ±2 SD on a normal distribution). Treating every 1-2s as a rejection produces a 5% false-rejection rate — far too high to run a routine clinical workflow. Westgard's 1981 paper specifically warned against this; CLSI EP18 and EP23 echo the warning. Use 1-2s as the trigger that escalates evaluation of the stricter rules.

How many in-house measurements do I need before I can switch from manufacturer's mean / SD to in-house?​

Twenty is the canonical answer — twenty in-house measurements on the same (level + lot + analyzer) lets the in-house mean and SD stabilise enough to use. Some labs use 25-30 for highly-variable analytes; tightening the threshold to 15 is sometimes done but produces noisier in-house statistics. Most modern LIMS default to 20 and let the lab override per analyte.

How does this work in a multi-instrument lab?​

QC is tracked per (analyte + analyzer + level + lot). A lab with two Cobas analysers running the same test runs QC independently on each; the rule evaluation respects the instrument boundary so a 10-x trend on Cobas-A does not lock reporting on Cobas-B. This is the canonical pattern; any LIMS that mixes QC across instruments has a defect.

What's the difference between Westgard and CLSI rules?​

CLSI EP23 and EP18 are the formal standards-body documents that codify and extend Westgard's work for the clinical laboratory. The CLSI documents are normative for accreditation purposes (CAP, CLIA, ISO 15189) and add the procedural overlay — how to run QC, how often, how to document overrides. The Westgard rules themselves remain unchanged; the CLSI documents are the canonical place to find them quoted in a regulator-accepted form.

Can I run Westgard rules on qualitative tests (positive / negative results)?​

Not directly — Westgard rules are designed for quantitative measurements that follow a roughly normal distribution. Qualitative tests use a different QC scheme: typically, a positive control and a negative control are run with each batch, and the QC pass/fail is binary (did the positive control read positive and the negative control read negative?). The CLSI EP12 standard covers qualitative QC.

What's the false-rejection rate of the canonical multi-rule set?​

About 0.03 to 0.05 percent per run — i.e. one false rejection in every 2000-3000 in-control runs. This is well below the 1% threshold most labs target. The false-rejection rate of a poorly-chosen rule set can climb much higher; the canonical multi-rule was specifically designed to keep this low while maintaining good error detection.

Do I need to learn the rules myself, or does the LIMS handle them?​

A LIMS that implements QC handles the rule evaluation and surfaces the violated-rule code on the run; the lab manager needs to understand what each rejection means in order to choose the right corrective action. The clinical knowledge of "1-3s usually means random error → look at the operator or the most recent maintenance" is what the lab manager brings. (LabFlow does not evaluate QC rules today — see the roadmap.)

Are Westgard rules used outside clinical chemistry?​

Yes — the same rules apply to any quantitative QC, including haematology, immunoassay, molecular diagnostics, environmental testing, and food safety. The "in-control / out-of-control" decision is method-agnostic; the rules are method-agnostic. The reference values (mean, SD) are method-specific; the rule logic is universal.

Where to read more​

• What LabFlow has not built — including quality control.
• The original Westgard paper: J.O. Westgard, P.L. Barry, M.R. Hunt, T. Groth, "A Multi-Rule Shewhart Chart for Quality Control in Clinical Chemistry", Clinical Chemistry 1981.
• CLSI EP23 (statistical quality control for quantitative measurement procedures) and CLSI EP18 (laboratory quality control) — the accreditation-relevant documents.
• WestgardQC.com — the family's reference site, which has detailed worked examples and additional rule combinations.

About the author: Ahsan Mahmood is the engineer behind LabFlow. Contact at aoneahsan@gmail.com or via aoneahsan.com.

What a LIMS does (and doesn't)​

A LIMS owns the operational backbone of a laboratory. Specifically:

The split is sharp on purpose. A LIMS is optimised for the laboratory's idiosyncratic workflows — instrument barcodes, reference ranges, QC statistical methods, stability budgets, accreditation evidence packs — and inherits less generic-business functionality than an ERP would carry.

LIMS vs LIS — the term-of-art confusion​

The two terms are used interchangeably in casual conversation, but historically they meant slightly different things:

As of 2026 the distinction has faded. Cloud-era systems serve both clinical and industrial use cases, and most vendors use "LIMS" as the umbrella term. This post uses LIMS throughout; if you read "LIS" in a clinical-laboratory context, treat it as a synonym.

LIMS vs EMR — the most common confusion​

The EMR (Electronic Medical Record) is the system a clinician uses; the LIMS is the system a laboratory uses. The two systems integrate but do not overlap.

A typical flow:

1. A clinician orders a test in the EMR (Epic / Cerner / Meditech / Allscripts / athenahealth / eClinicalWorks).
2. The EMR transmits the order to the LIMS via HL7 v2 (ORM^O01 message) or FHIR R4 (ServiceRequest resource).
3. The lab collects the sample, runs the test, validates the result, and releases the report.
4. The LIMS transmits the result back to the EMR via HL7 v2 (ORU^R01) or FHIR R4 (Observation + DiagnosticReport).
5. The clinician reads the result in the EMR; the patient's chart now carries it.

The two systems are joined at the hip but maintained separately. A clinician never logs into the LIMS; a lab technologist never logs into the EMR. Each system owns its own audit log, its own user list, and its own data model. The integration is a structured message-passing relationship, not a shared database.

A LIMS that bundles a patient portal (so patients can see their own results without going through the EMR) is a common modern feature. The portal is a LIMS-side surface, not an EMR-side feature. (LabFlow does not have one today — it is planned and unbuilt.)

The modern cloud-multi-tenant pattern​

The 1990s and 2000s LIMS pattern was a self-hosted, single-tenant Windows application sold per-seat with annual maintenance fees. The 2020s pattern is cloud-hosted, multi-tenant SaaS billed per-tenant or per-test, with these characteristics:

The trade-offs are real. A multi-tenant LIMS shares infrastructure across customers, which means the security model has to enforce tenant isolation at every read and write — a single bug can leak patient data across customers. The mature multi-tenant systems run their tenancy enforcement at the database layer — Postgres row-level security, or an equivalent — rather than only in application code, so even a bug in the application cannot leak data across customers.

LabFlow is a multi-tenant cloud LIMS on hosted Postgres, with the tenant boundary enforced by deny-by-default row-level security on every table. See tenancy and row-level security.

What to look for in a LIMS (the buyer's checklist)​

The list a hospital procurement team should check, in roughly the order of how easily the answer can be verified:

1. Multi-tenant security model — does the vendor have published documentation of the tenant-isolation guarantee, and is it enforced at the database layer?
2. HL7 v2 + FHIR R4 support — both, not just FHIR, because most EMRs still rely on v2 for production traffic.
3. Accreditation-ready audit log — every change writes to an immutable log; the audit log can be exported as an accreditation evidence pack.
4. Quality Control with Westgard rules — Levey-Jennings charts, multi-rule sets (1-3s / 2-2s / R-4s / 4-1s / 10-x), reporting locks on out-of-control runs.
5. Critical-result acknowledgement workflow — released critical-flagged results require a named clinician's acknowledgement before the loop closes (CAP and CLIA both expect this).
6. Reagent lot traceability — every patient result traces back to the exact reagent lot used to generate it.
7. Offline-first mobile surface — phlebotomists doing home collection need to work through dead zones; the LIMS must reconcile on reconnect without producing duplicate or missing chain-of-custody events.
8. No vendor lock-in on data egress — the lab owns its data; the vendor provides a documented export path (CSV, FHIR Bundle, BigQuery sync).
9. Per-tenant configuration depth — branding, report templates, label templates, working hours, integrations, all configurable without vendor engagement.
10. Honest pricing transparency — published per-tenant or per-test pricing, with no "request a demo" gating on the core price tier.

A LIMS that scores well on these ten is in the top quartile of the modern market.

Frequently asked questions​

Is a LIMS the same as a Laboratory Information System (LIS)?​

For practical purposes in 2026, yes. The terms have converged; "LIMS" is now the umbrella term used by most vendors for both clinical and industrial laboratory software. A casual mention of "LIS" in a clinical-laboratory context can be read as a synonym.

Can a small lab (5 staff, no IT team) run a modern LIMS?​

Yes — cloud-multi-tenant LIMS are explicitly designed for the small-lab case. The lab signs up, configures the tenant settings (branding, working hours, integrations) through a UI, and the system is operational within days. No IT team required for the LIMS itself; the lab's clinic-level IT team handles the network and the integrations with the EMR.

What does a LIMS typically cost?​

The market range in 2026 is wide. Single-tenant on-premise LIMS from incumbents cost six to seven figures upfront plus maintenance. Cloud-multi-tenant LIMS price per-tenant per-month or per-test. The honest answer is "ask the vendor for a published per-test or per-tenant rate" — vendors who refuse to publish are often the ones with the widest variance.

Are open-source LIMS viable?​

OpenELIS, SENAITE, and a few others exist and are used in specific deployments (typically resource-constrained or public-health labs). The trade-off is operational cost: an open-source LIMS shifts the cost from license fees to hosting, maintenance, and customisation. For a small lab without an IT team, a SaaS LIMS is usually cheaper end-to-end. For a large public-health network with engineering staff, open-source is viable.

How long does a LIMS implementation take?​

A simple deployment of a cloud-multi-tenant LIMS for a single-site clinical lab can complete in 4-8 weeks (configuration + EMR integration + staff training + parallel-run). A multi-site, multi-EMR deployment can take 6-12 months. The classic on-premise LIMS implementations historically took 18-24 months; cloud has compressed this dramatically.

Does a LIMS replace the lab's instruments?​

No. Instruments are the analytical hardware (chemistry analysers, haematology counters, microbiology readers). A LIMS reads results from those instruments — typically via HL7 v2 ORU^R01 messages or instrument-specific file formats — and provides the operational layer around them. The instrument vendors and the LIMS vendor are usually different companies; the integration is documented per instrument.

What's the biggest mistake a lab makes when choosing a LIMS?​

Buying for today rather than for the lab's growth trajectory. A LIMS that's perfect for 200 samples/day at a single site becomes a bottleneck at 2000/day across three sites. The reverse mistake — over-provisioning for hypothetical scale — also happens but is less common. The pragmatic move is to assume 5x growth over five years and verify the LIMS handles that without architectural changes.

Where to read more​

• LabFlow's user guide — every screen the product actually ships, area by area.
• Result review and release — the release gate, critical-value escalation, and why an amendment is a new version rather than an edit.
• Tenancy and row-level security — how two laboratories share one database.
• What LabFlow has not built — including quality control, billing and interoperability.

LabFlow is one example of a multi-tenant cloud LIMS, and it is partly built: its documentation states which areas exist and which do not. Other vendors will document their offerings differently; the buyer's checklist above is vendor-neutral.

About the author: Ahsan Mahmood is the engineer behind LabFlow. Contact at aoneahsan@gmail.com or via aoneahsan.com.