EKLIS is a multi-tenant cloud LIS for US clinical laboratories: a LOINC-coded test compendium, barcode ordering and scanner-first accessioning, a server-enforced specimen and result state machine, an interface engine that speaks ASTM and HL7 to the analyzers, auto-verification gated on quality control, a documented critical-value loop, versioned report PDFs, provider and patient portals, and charges and claims generated the moment an order completes.
EKLIS is a laboratory information system built for the bench rather than adapted from a clinic chart. A laboratory signs up, gets its own MySQL database and a LOINC-coded starter compendium, and can run a real day's work without waiting on an implementation project: register a patient, build an order from the compendium, print barcode labels, collect, accession by scanner, enter or receive results, verify them, and hand back a report PDF. Every one of those steps is a server-enforced transition rather than a status field someone types over, and every access to patient data writes an append-only audit row attributed to the user who made it.
Two state machines carry the patient-safety weight. A specimen moves ordered → collected → accessioned → complete, with rejected as a terminal branch, and an out-of-order move is refused outright. A result moves preliminary → final, and a final result is never mutated: a correction inserts a new version linked to the one it supersedes, carrying the reason, and both stay visible — the report PDF prints a CORRECTED banner and names the version. Accessioning refuses to assign a number without an explicit confirmation that the operator matched two patient identifiers against the label, and critical values open a notification that closes only when someone records who was told and confirms the read-back.
The connectivity and money layers are the two places a lab-first system has to be different from a clinical one. The interface engine runs as its own process, so analyzer and HL7 traffic keeps flowing while the application deploys; it writes every inbound message to a durable per-tenant log before it processes anything, validates ASTM frame checksums, and treats all interface traffic as untrusted input that can only file into that tenant's own accessioned specimens and open order tests. On the other side, medical-necessity rules and the ABN prompt run at order time, and completing an order generates its charges and a draft claim in integer cents — export, denial, payment posting and denial analytics all sit on the same data model, so the laboratory never re-keys into a billing system what it already knows.
Needs · To get a tray of tubes onto the bench quickly without ever putting a number on the wrong patient's specimen.
Gets · A single focused barcode field that keeps the cursor, a confirm step that requires the two-identifier match before any number is assigned, sequential accession numbering with the receiving user recorded, and rejection with a reason as a proper terminal state.
Needs · To see what is waiting, enter or review results, know why the system held something, and be able to correct a released result without erasing what was reported.
Gets · Split worklists for what needs entering and what needs verifying, automatic high/low/critical flagging against sex-specific intervals, the hold reason on every held result, and corrections that create a linked new version with its reason.
Needs · To bring a new analyzer online, tune what may release itself, keep quality control honest, and answer an inspector about who did what.
Gets · The interface registry with per-interface code maps and a readable message log, the auto-verification rule editor with a rule-set version badge, control lots with Westgard evaluation and Levey-Jennings charts, staff and role management, and an append-only audit row on every patient-data access.
Needs · To place an order, attach the diagnoses, and get the report back — without seeing anyone else's patients or being handed the bench.
Gets · Order entry through the same validated endpoint the laboratory uses, a portal scoped to their own orders, report PDFs for those orders, and a flat 404 on anything that is not theirs.
Needs · To read their own finished results without a phone call, and to be sure nobody else can read them by guessing a record number.
Gets · Sign-in with the laboratory identifier, record number, date of birth and a one-time code issued by the laboratory; a short-lived, patient-only session; current final results with flags and reference intervals; and the latest report PDF.
Needs · To bill from what the laboratory actually did, to know why claims are being denied, and to stop preventable denials before the specimen is drawn.
Gets · Payers and a fee schedule in integer cents, medical-necessity rules that flag an ABN at order time, charges and a draft claim on order completion, export through the clearinghouse seam, a denial workflow with reasons, payment posting against the balance, and a dashboard of status, denial reasons, clean-claim rate and outstanding balance.
| Area | Today | With Laboratory Solutions |
|---|---|---|
| Getting started | A server in the closet, a vendor install, and a compendium built from scratch before the first order. | Self-serve provisioning creates the laboratory, its own database, its schema and a LOINC-coded starter compendium — reviewed and adopted by the lab before go-live. |
| Analyzer connectivity | A separate middleware box between the instruments and the LIS, with its own license, its own failure modes and its own vendor. | The interface engine is part of the system: ASTM and HL7 listeners, a per-interface code map, and a message log the laboratory can read when an instrument goes quiet. |
| Deploying the software | Instrument traffic is refused while the system restarts, and someone reruns the batch afterwards. | The interface engine is its own process with a durable message log in front of every parser, so inbound messages are stored before they are parsed. |
| Releasing results | Autoverification is a setting nobody can explain, or everything is released by hand. | Five named gates in a fixed order, rules stored as data, a rule-set version stamped on every auto-released result, and a written hold reason on everything that did not pass. |
| Correcting a result | Someone edits the value and the old number is gone. | The correction is a new linked version with its reason; the report prints CORRECTED and names the version, and the superseded row stays on the record. |
| Critical values | A phone call and a note in a logbook, if anyone remembers to write it. | A notification that will not close without the name of the person notified and an explicit read-back confirmation, attributed and audited. |
| Getting paid | Results are exported to a billing service that re-keys them, and denials arrive weeks later with no pattern anyone can see. | Necessity checked at order time, charges and a draft claim generated on completion in integer cents, and a dashboard of status, denial reasons, clean-claim rate and balance from the same rows. |
12 modules, each describing what is built today.
Every laboratory gets its own database, its own staff, and an append-only record of who touched what — the base that everything else is built on.
The catalog the whole system reads from: LOINC-coded tests with specimen, container, units, sex-specific reference intervals and critical limits.
The scanner-first path from a printed label to an accession number, with the two-identifier check enforced by the server.
The draw list a phlebotomist works from, and a custody trail that survives a phone with no signal.
The lab's primary surface: how much work is waiting, where it is stuck, and what is urgent — computed, never typed.
Result entry with automatic flagging, a verification step that releases to the report, and corrections that add a version instead of overwriting one.
Its own process, so instrument traffic keeps arriving while the application deploys, with a durable message log in front of every parser.
Instrument results release themselves only when every gate passes, and quality control is the first gate — not a report someone files afterwards.
The two paths a result takes when it cannot simply be printed: an urgent phone call that has to be documented, and a specimen that has to leave the building.
Three ways a finished result leaves the laboratory, each seeing exactly what it is allowed to see.
Charges and claims produced from the order the laboratory already ran, in integer cents, with the payer decisions made before the draw rather than after the denial.
Two surfaces outside the laboratory's own staff: a patient ordering for themselves, and the platform owner minding the tenant registry.
Most multi-tenant software separates customers with a column and a `WHERE` clause, which means a single forgotten filter is a data breach. EKLIS separates laboratories with a database. Each tenant is a registered row in a small core database and a MySQL database of its own; the only way to get a connection is to ask the registry for one by slug, and the registry answers only for a laboratory that is registered and active. A slug that fails a strict pattern never reaches SQL at all.
The application's own database credentials are granted just the core database and the tenant-database prefix, so the isolation survives an application bug rather than depending on the absence of one. Tenant identity comes from the validated session token and nowhere else — not a header, not a body field, not a client-held value — and a token minted for a laboratory that is not in the registry is refused before anything is read.
The failure mode is deliberately quiet. An attempt to read across laboratories answers 404, not 403, because 403 confirms that the thing exists. Schema changes are applied by an ordered, idempotent migration runner when a tenant's engine is first opened, so a new laboratory and an old one converge on the same schema without a manual step in between.
An order is not a form the laboratory retypes into tubes. Choosing tests produces the specimens: the system groups the ordered tests by specimen type and container and creates one specimen per distinct pair, each with its own sequential identifier. That identifier is what gets printed, scanned and tracked, so the physical tube and the database row are the same object from the first moment.
Labels print as ZPL — the language Zebra printers actually speak — with a PDF fallback for a laboratory that has not got one yet. Each label carries the patient's name, date of birth and record number, the specimen type and container, a STAT marker when the order is urgent, and the specimen identifier as a scannable barcode. Those are the two identifiers a technologist is required to match, printed where the match is made.
The accession screen is one focused field. Scan, and the matching collected specimen is shown; confirm, and the next sequential accession number is assigned with the receiving user and the time. The confirmation is not decoration: the endpoint takes an explicit identity-confirmation flag and refuses the request without it, and it refuses a specimen that was never marked collected. A tube that is unusable is rejected with a reason instead — hemolyzed, quantity not sufficient, mislabeled — which is a terminal state, not a note in a comment field.
Auto-verification is where a LIS either earns its keep or quietly hurts someone, so the gates are explicit, ordered, and stored as data rather than buried in per-test code. A result filed by an analyzer is considered for release only if auto-verification is enabled for that test; then only if it is not critically flagged; then only if quality control for that test was in control within the last day; then only if the value sits inside the configured auto-verify range; and finally only if the delta against the patient's own prior final result is within the configured absolute and percentage limits.
Everything about those rules is editable and versioned. The auto-verify range and the delta limits live in a per-test rule row, and any change bumps the laboratory's rule-set version. Every auto-released result stores the version that released it, so 'which rules were in force when this went out' is a stored fact rather than an archaeological question. A result that fails a gate is held as preliminary with the reason written on it — critical, QC not in control, above or below range, delta — and appears on the human verify worklist with that reason attached.
Quality control is the gate that is easiest to fake and hardest to fix afterwards, so it is evaluated server-side on every run. A control lot carries a mean, a standard deviation and a level; each run's z-score is checked against the Westgard multirules — 1-3s, 2-2s, R-4s, 4-1s and 10x — against the recent run history. A violated run is out of control, and out of control closes the auto-verification gate for that test until control is regained. The Levey-Jennings chart sits directly above the entry field, so the drift that fired the rule is visible where the decision is made.
The one component that is not allowed to be part of the application is the interface engine. An analyzer does not know that a deploy is in progress; it opens a socket and sends. So the engine runs as its own process, reads the interface registry from the core database, and runs one TCP listener per enabled interface, starting and stopping listeners as the registry changes rather than requiring a restart to pick up a new instrument.
Durability comes before parsing. When a message arrives, the raw text is written to that laboratory's message log with a received status, and only then is it parsed. Whatever happens next — filed, empty, ignored, error — is written back onto that stored row. Processing exceptions are caught and recorded rather than propagated, so a malformed message from one instrument cannot take down the listener that other instruments are using. Session timeouts bound how long any one connection can hold a thread.
Both protocols are handled as untrusted input, because that is what they are. ASTM frames are checksum-validated and a corrupt frame is answered with a NAK, so nothing is filed from a frame that did not survive the wire. HL7 messages are unwrapped from their MLLP envelope and answered with an ACK — an accept for a result message that was processed, an error for one that failed, a rejection for a type the engine does not handle, rather than silence. And when a result does file, it can only land on a specimen that belongs to that tenant, is in the accessioned state, and has that test still open on its order; a code the interface's map does not know, or a specimen that does not exist, is rejected with the reason written to the log.
The reason laboratory billing goes wrong is usually that it starts too late. By the time a claim is built in a separate system, the decisions that would have made it clean — was the patient covered, does the diagnosis support the test, did anyone get an ABN signed — are weeks in the past. EKLIS moves them to the order. Medical-necessity rules are ICD-10 prefixes attached to a test; when an order's diagnoses match no rule for a test that has them, the order is marked as requiring an ABN at the moment it is created, before anyone draws anything.
Completing the order does the rest. When the last outstanding test goes final, the order closes and — once, idempotently, and only when a payer is attached — its charges and a draft claim are generated from the fee schedule, in integer cents. Export assembles the clean-claim payload from the same rows: payer, subscriber, the order's diagnoses and the coded service lines. It refuses to export a claim whose order requires an ABN that has not been signed, which is the difference between a denial you handle later and one you never receive.
After that it is a worklist rather than a mystery. A denial carries its reason and the claim can be corrected and re-exported; payments post against the balance until it reaches zero and the claim reads paid; and the dashboard reports claims by status, the top denial reasons, the clean-claim rate and the outstanding balance — computed from the claims themselves rather than from a parallel ledger that has to be reconciled.
Each test's ICD-10 prefix rules are checked against the order's diagnoses; a test with rules and no match flags the order as needing an ABN.
ZPL or PDF labels carry name, date of birth, record number, container and the specimen barcode; collection stamps the time.
The scan finds the specimen; what happens next depends on what the bench confirms.
An analyzer files through the interface engine, or a technologist enters by hand; either way the value is flagged against the sex-specific interval and the critical limits.
Rule enabled, not critical, QC in control within the day, inside the auto-verify range, delta check against the patient's own prior result.
Verification makes the result final and immutable; corrections add a linked version with a reason. The report PDF is generated, versioned and archived.
When the last test is final the order and its specimens close, and charges plus a draft claim are generated once from the fee schedule.
A provider or the front desk builds the order from the compendium; the system derives one specimen per specimen type and container, validates the diagnoses, and flags the order for an ABN when a test fails its medical-necessity rule.
Labels print as ZPL or PDF with the patient's name, date of birth, record number and a scannable specimen barcode; collection moves the specimen out of the ordered state and stamps the time.
The bench scans the barcode into a single focused field and confirms two patient identifiers against the label; only then is the next sequential accession number assigned, with the receiving user recorded. An unsuitable specimen is rejected with a reason instead.
The analyzer files the result through the interface engine, or a technologist enters it by hand. Either way the value is flagged against the patient's sex-specific reference interval and the test's critical limits.
Instrument results pass the auto-verification gates — rule enabled, not critical, QC in control, within range, delta check — and record the rule-set version that released them; anything held lands on the human verify worklist.
Verification makes the result final and immutable; a correction adds a linked version rather than overwriting. The report PDF is generated and archived, and the provider portal and patient portal serve the current version.
Completing the last test closes the order and generates its charges and a draft claim; export produces the clean-claim payload, denials carry a reason for re-work, and payments post against the balance.
Vocabularies, tiers and matrices drawn from the product documentation — the same terms the software uses.
| Role | What it unlocks |
|---|---|
| Admin | Everything, plus staff and role management, the interface registry and code maps, reference-lab setup and send-out flags |
| Technologist | Result entry, verification and corrections, quality control and auto-verification rules, critical-value acknowledgement, send-outs |
| Accessioner | Patient registration, order entry, collection and accessioning, rejection, send-outs, patient portal access codes |
| Phlebotomist | Collection and the bench worklists — never result entry or verification |
| Provider | Order entry and a portal of their own orders, results and report PDFs; the bench surfaces are refused |
| Billing | Payers, fee schedule, necessity rules, claims, export, denials, payments and billing analytics |
Roles are checked deny-by-default on every endpoint, from the session token's claims.
| Object | States | What is refused |
|---|---|---|
| Specimen | ordered → collected → accessioned → complete, with rejected terminal | Any out-of-order transition, and accessioning without the two-identifier confirmation |
| Result | preliminary → final, corrections add a linked version | Verifying a result that is already final, a second entry against the same order test, and entry against a specimen that is not accessioned |
| Critical notification | open → acknowledged | Acknowledgement without a read-back confirmation, and acknowledging a loop that is already closed |
| Claim | draft → exported → denied or paid | Exporting anything but a draft or denied claim, exporting with a required ABN unsigned, charges with no CPT code, and a payment larger than the balance |
| Custody event | collected → picked up → received, append-only | Picking up a specimen that was never collected, and applying the same field action twice — a replayed action returns the original outcome |
Both are enforced server-side under a row lock, so a stale screen cannot talk the system into an illegal move.
| Gate | What it checks | Hold reason recorded |
|---|---|---|
| Rule enabled | Auto-verification is switched on for this test | Auto-verification disabled |
| Not critical | The value is not flagged critically high or low | Critical |
| QC in control | The most recent control run for the test within the last day was in control | Quality control not in control |
| Auto-verify range | The value sits inside the configured range for the test | Above or below the auto-verify range |
| Delta check | The change from the patient's own prior final result is within the absolute and percentage limits | Delta exceeded |
The first gate that fails writes its reason onto the result and sends it to a person.
| Protocol | What is accepted | What is answered |
|---|---|---|
| ASTM E1381 / E1394 | Framed records over TCP with the ENQ/ACK/EOT session handshake; results read from the order and result records | ACK per valid frame; NAK on a checksum failure, with nothing filed |
| HL7 v2.5.1 result messages | MLLP-wrapped messages; specimen identifier from the order segment, code and value from the observation segments | An accept acknowledgement when filed, an error acknowledgement when processing fails |
| Any other HL7 message type | Logged and recorded as ignored | A rejection acknowledgement naming it unsupported |
Every inbound message is logged before it is parsed, and the outcome is written back onto the stored message.
Every promise on this page maps to something the software actually enforces.
At the data layer. Each laboratory gets its own MySQL database, and a database engine is only ever resolved through the registry of registered, active tenants — the application's own database grant is scoped to the tenant prefix, so there is no query that could reach across. A cross-tenant read answers 404 rather than 403, and a token minted for a laboratory that is not registered is rejected before anything is read.
No. A final result is immutable. A correction inserts a new version carrying its reason, links the superseded row to it, and leaves both visible in the order's history. The report PDF prints a CORRECTED banner and names the version next to the test, and the footer states that prior versions are retained by the laboratory.
Five things, in order: auto-verification is enabled for that test, the result is not critically flagged, quality control for that test is in control within the last day, the value sits inside the configured auto-verify range, and the delta check against the patient's own prior final result passes. Any gate that fails holds the result as preliminary with the reason recorded, and it goes to a person.
It is already saved. Every inbound message is written to the laboratory's durable message log before anything is processed, so a parse or processing failure is recorded on the stored message rather than losing it, and the listener stays up. A corrupt ASTM frame is answered with a NAK and nothing is filed; an HL7 message that cannot be processed is answered with an error acknowledgement.
The label carries the name, date of birth and record number alongside the specimen barcode, and accessioning will not assign a number unless the operator explicitly confirms the two-identifier match — the request is refused without it. A specimen that was never marked collected cannot be accessioned at all, and the receiving user and time are stored on the specimen.
No — the interface engine is part of the system, but it runs as its own process rather than inside the application, precisely so analyzer and result traffic keeps being accepted while the application is being deployed. Listeners start and stop as the interface registry changes, and each interface belongs to the laboratory that created it.
Only their own orders. The order, its results and its report PDF all answer 404 for a provider who did not place it, and the bench surfaces — worklists, quality control, critical values — are refused for the provider role entirely.
The laboratory issues a one-time access code, stored hashed and shown once, which it can rotate. The patient signs in with the laboratory identifier, record number, date of birth and that code, and receives a short-lived token of a distinct kind that only works on the read-only patient endpoints. They see current final results and the latest report — never preliminary or held ones — and sign-in failures are uniform and rate-limited so a record number cannot be probed.
At the order, not the invoice. Medical necessity is checked against per-test diagnosis rules while the order is being placed, and a failing order is flagged as needing an ABN there and then. Completing the order generates its charges and a draft claim once, in integer cents; export refuses to build a claim when a required ABN is unsigned.
The seam is, the connection is not. Eligibility sits behind an adapter, and without configured payer credentials it answers with an explicit, deterministic stub for demonstration and testing — it is never dressed up as a real payer response. The same is true of claim submission: the export builds and stores the structured clean-claim payload through the clearinghouse seam.
We walk through it with your data and your team — not a canned demo.
Program and billing eligibility are determined by each practice and its payers. Results and alerts do not constitute a medical diagnosis. Third-party names are trademarks of their respective owners and do not imply endorsement.
