Clinical lab validation console · Portfolio project

Prove each result before it leaves the lab.

The screen where a medical biologist validates results before they reach the doctor: tubes checked against the order, Westgard QC that holds what it cannot vouch for, delta and consistency checks from a versioned rules engine, a critical-value call that cannot be skipped, and releases nobody can rewrite.

Open the console See the design system

Demo — not a medical device — synthetic data only.

Biological validation of MOREAU, Lucie: potassium 6.8 mmol/L flagged HH critical with a +2.1 delta against her file of 50 hours earlier, every result with its unit, reference interval, range bar, previous value and analyzer; on the right the release prerequisites, the rule trace of the potassium (AV-K v3.2 refused, CV-K v1.3 critical, DC-K v2.0 delta) and Sign & release blocked until the critical call is documented

01 · The need

Three thousand tubes a day, one signature each.

A biologist signs off results all day, most of them routine, a few of them urgent. Whether what they sign is right comes down to three things: the patient, the analyzer, the value.

The right patient

A tube's label checked against its order at reception, the identity re-checked before signing, and every action naming the patient it is about — so one file is never validated as another.

An analyzer that can be trusted

Internal QC on every analyzer and analyte, judged by the Westgard rules, and the results of a failed run held until the analyzer is fixed and re-checked.

A value that makes sense

Each result against its reference, the patient's previous result and the related analytes; the routine proposed for auto-validation, the unusual brought forward, the critical called in.

02 · The rules

What the console holds to.

A few rules every screen keeps, enforced by the server and the database, not only shown — because a result released by mistake cannot be called back.

A number never travels alone

Unit, reference interval, analyzer and QC status on every result, and a text flag beside every colour. A result missing one of them is not displayed.

Blocked until it is safe

A critical value cannot be released before the call is documented with read-back; a result held by QC cannot be validated; the server refuses what the screen greys out.

Released means released

A released report is immutable in the database itself. A correction is a signed amendment with its reason, and the original stays visible beside it.

A demo, and it says so

Not a medical device, no compliance claimed, synthetic data only: generated patients and tubes, rule limits labelled as not clinically validated, zero external calls, and a banner on every screen.

03 · The console

Built and running.

Stills of the live console on its synthetic lab day: the validation screen, the critical-value call, Westgard QC with a hold, reception, the tracking of every tube, the audit trail.

The critical-value call dialog for potassium 6.8 mmol/L, which cannot be dismissed: the patient's identity, the critical limits, the person reached, role, service, extension and call time, read-back with the value as repeated, the attempts log, and three actions: record the call, log a failed attempt, escalate to on-call — The critical-value call, documented with read-back

Internal QC of potassium on CHEM-01: Levey-Jennings charts for both control levels with ±1, 2 and 3 SD lines, the last runs as red squares beyond 2 SD; the Westgard panel under rule set QC-WG v4.1, the corrective-action form, and the violet hold banner under the shell — Westgard QC: a 2-2s rejection holds the results it covers

Reception: a tube scanned into the 52 px field, the order and the tube label compared side by side and matched, the order's tubes, the simulated bench seeing hemolysis, and the non-conformity checklist with its action — Reception: label against order, non-conformities and their action

Tracking: every tube of the day with its seven-step lifecycle from received to released, the current step and since when, turnaround against the target, STAT tubes and QC holds flagged — Every tube's lifecycle and turnaround, a day at a time

The audit trail: each action with its time to the second, its actor — a person, an analyzer, the middleware or a synthetic colleague — the file and tube, the reason, and details such as rule versions and report hashes — The audit trail: who, what, when and why

The regulatory and quality awareness page: ISO 15189 and COFRAC, the French biologie médicale framework, IVDR, HPRIM, HL7 v2, LOINC and ASTM, HDS hosting — each with what Probatio shows and what it does not claim — then the live catalogue of published rules and rule sets — Regulatory awareness, and the rule catalogue it runs

04 · Choices

Weighed, chosen, and why.

Each key decision, with the alternatives, the choice and its reason. Each one is written down as a decision record in the repository.

Writing the rules

Weighed: Rules in code · a general rule language · typed rules over a closed set of evaluators
Chosen: Rules as data — id, version, kind, parameters — over six evaluator kinds: Westgard, delta, consistency, interference, critical, auto-validation; a published rule set pins one version of each.
Because: Every evaluation is stored with the version and the rule set that produced it, so a decision from last month replays exactly; a published rule changed without a new version fails a hash test and a database trigger.

What a failed QC run holds

Weighed: Flag the run only · hold since the run · hold since the last accepted run
Chosen: Every unreleased result of that analyzer and analyte since the last accepted run is held, until a corrective action is recorded and a rerun is accepted; then the tubes are measured again.
Because: A run that only warned may be the first half of a 2-2s. The database test that proved the hold caught exactly that case.

Talking to analyzers and the hospital

Weighed: In-process fakes · HTTP and JSON · the real wire formats, simplified
Chosen: ASTM E1381/E1394 over TCP with frames, checksums, ACK/NAK and retransmission, and HL7 v2 ORM, ORU and ACK over MLLP — codecs written in-house, simulators as separate NestJS services.
Because: The simulators reach the lab system only through the wire a real instrument would use; replacing one with a real analyzer changes a mapping, not the workflow.

Keeping a released report released

Weighed: Checks in the API · constraints in the database
Chosen: PostgreSQL triggers refuse any change to a released result or report version, and to the audit trail; an amendment is a new version with its reason and the hash of its content.
Because: The rule holds whatever code reaches the table, not only the code that remembers it.

Where the lab day comes from

Weighed: Synthea · a fake-data library · an own seeded generator
Chosen: A deterministic generator of about 3,000 tubes a day — physiological profiles, patients with history, hemolysis, QC drift, analyzer silences, critical values — replayed up to now through the real workflow.
Because: The cases the workflow needs exist on demand, the same seed gives the same day byte for byte, and synthetic colleagues keep the queues alive at any hour.

05 · How it's built

From the analyzer's frame to the signed report.

Simulated instruments and a simulated hospital system speaking the real wire formats, a lab information system with its rules engine, and a console that only shows what the engine decided.

Simulators

Two NestJS services: four analyzers that take work lists and answer results and QC over ASTM, and a hospital system that sends HL7 orders and receives the released reports over MLLP.

Rules engine

Plain TypeScript shared by every part: the analyte catalog, Westgard multirules, delta and consistency checks, auto-validation, the protocol codecs — 139 tests, the boundary of every rule among them.

Lab system

NestJS 12 on PostgreSQL: orders, tubes, results, QC holds, critical calls, signed releases and amendments, an append-only audit, a projection that keeps the queue one indexed read.

Console and server

Next 16 and React 19 on its own design system, live by server-sent events; PM2 and nginx on my own server, a nightly reset, deploys registered in Zeus and watched by Iknos.

06 · Status

What is built, and what is next.

Live as a demo, built ticket by ticket, each decision written down as it is taken.

Built · analytical

Reception and trackingBarcode scan, identity against the order, non-conformities with their action, the seven-step lifecycle and turnaround for every tube.
Quality controlLevey-Jennings charts, the six Westgard rules, holds, corrective actions and reruns.
Instruments and feedsASTM analyzers and the HL7 hospital system, simulated as separate services on the real wire formats.

Built · validation

ValidationTechnical and biological validation, the queue ranked by risk, delta and consistency checks, the trace of every rule applied.
Critical values and releaseThe call protocol with read-back, release signed by the biologist, batch signing of auto-validated files, amendments.
Audit and regulatoryThe append-only trail, and a page on ISO 15189, COFRAC, biologie médicale, IVDR, HL7 and HDS.

HPRIMThe French lab format as a second codec behind the same order and result feeds.
MicrobiologyCultures and susceptibility, a workflow with its own steps and rules.
Rule authoringA biologist-facing screen to draft a new rule version and publish it as a new rule set.

Validate a file,
on a live synthetic lab day.

Open the critical potassium and try to sign it: the release stays blocked until the ward is called and the value read back. Then record a corrective action on the held QC run, and amend a released result to see the original stay.

Open the console All the apps