EKLIS is a cloud-hosted laboratory information system (LIS) for US clinical laboratories: a LOINC-coded test compendium, barcode ordering and scanner-first accessioning, specimen and result tracking that will not allow an out-of-order step, 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 separate data store 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 enforced by the system rather than a status field someone types over, and every access to patient data writes a permanent record naming the user who made it.
Two tracked sequences carry the patient-safety weight. A specimen moves from ordered to collected to accessioned to complete, with rejected as a dead end of its own, and an out-of-order move is refused outright. A result moves from preliminary to final, and a final result can never be changed: a correction creates a new version linked to the one it replaces, 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 independently of the rest of the application, so analyzer and HL7 traffic keeps flowing during system updates; it logs every incoming message before acting on it, checks that each ASTM message arrived intact, and only ever files a result into that laboratory'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 exact to the cent — export, denial, payment posting and denial analytics all work from the same records, 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 final outcome.
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 list of analyzer connections with per-connection 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 a permanent record of 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 the same way the laboratory's own staff place orders, a portal scoped to their own orders, report PDFs for those orders, and anything that is not theirs treated as if it doesn't exist.
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 exact to the cent, medical-necessity rules that flag an ABN at order time, charges and a draft claim on order completion, export ready to send through the clearinghouse connection, 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 data store, 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 analyzer and HL7 connections are part of the system: automatic connections to each instrument, a per-connection code map, and a message log the laboratory can read when an instrument goes quiet. |
| System updates | Instrument traffic is refused while the system restarts, and someone reruns the batch afterwards. | Analyzer connections run independently of the rest of the system, with a permanent message log in front of every incoming message, so nothing is lost while the system updates. |
| 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 version it replaced 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 exact to the cent, and a dashboard of status, denial reasons, clean-claim rate and balance from the same records. |
12 modules, each describing what is built today.
Every laboratory gets its own separate data store, its own staff, and a permanent 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 system.
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 automatically, never entered by hand.
Result entry with automatic flagging, a verification step that releases to the report, and corrections that add a version instead of overwriting one.
Runs independently of the rest of the system, so instrument traffic keeps arriving during updates, with every incoming message saved before it is read.
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, exact to the cent, 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 registry of laboratories.
Most shared software separates customers with a filter buried in application logic, which means a single mistake in that filter is a data breach. EKLIS separates laboratories with a data store. Each laboratory is registered in a small central directory and has a data store entirely of its own; the only way to reach it is to ask that directory for the laboratory by its own identifier, and the directory answers only for a laboratory that is registered and active. An identifier that doesn't match the expected pattern is refused before it ever reaches the data itself.
The system's own permissions are limited to that central directory and each laboratory's own data store, so the separation survives a software bug rather than depending on there never being one. Which laboratory a request belongs to comes from the verified, signed-in session and nowhere else — never something the browser or an outside caller could simply claim — and a sign-in for a laboratory that isn't in the directory is refused before anything is read.
The failure mode is deliberately quiet. An attempt to read across laboratories is treated as if the data doesn't exist at all, rather than confirming that it exists but is off-limits. Structural updates are applied automatically, in order, the first time a laboratory's data store is opened, so a brand-new laboratory and a long-running one always end up on the same layout without anyone doing it by hand.
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 its record in the system 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 system requires an explicit identity confirmation 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 real, final outcome, not a note in a comment field.
Auto-verification is where a laboratory information system either earns its keep or quietly hurts someone, so the checks are explicit, ordered, and editable rather than buried in hidden per-test settings. 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, 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 check 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 check that is easiest to fake and hardest to fix afterwards, so it is evaluated by the system itself on every run, not left to memory. A control lot carries a mean, a standard deviation and a level; each run's result 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 that closes auto-verification 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 part of the system that cannot afford to be tied to the rest of the application is the connection to the analyzers. An analyzer doesn't know that a system update is in progress; it simply connects and sends. So that connection work runs independently, reads the laboratory's list of configured equipment, and keeps one active connection per enabled analyzer or HL7 feed — starting and stopping as that list changes, rather than needing a restart to pick up a new instrument.
Saving comes before reading. When a message arrives, the raw text is written to that laboratory's message log as received, and only then is it read and acted on. Whatever happens next — filed, empty, ignored, error — is written back onto that same stored message. Processing errors are caught and recorded rather than allowed to crash anything, so a malformed message from one instrument cannot interrupt the connections other instruments are using. Connections that go quiet for too long are automatically closed rather than left hanging.
Both connection types are treated as unverified input, because that is what they are. Every ASTM message is checked to confirm it arrived intact, and a damaged message is rejected outright, so nothing is filed from a message that didn't survive the trip. Every HL7 message gets a clear response — an acceptance for a result message that was processed, an error for one that failed, a rejection for a type the system does not handle — rather than silence. And when a result does file, it can only land on a specimen that belongs to that same laboratory, has actually been accessioned, and has that test still open on its order; a code the connection's map does not recognize, 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 — exactly once, and only when a payer is attached — its charges and a draft claim are generated from the fee schedule, exact to the cent. Export assembles the clean claim from the same records: 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 record 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; it cannot be edited after release, and 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; it cannot be edited after release, and 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, 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, denying access by default, from who is actually signed in.
| Object | States | What is refused |
|---|---|---|
| Specimen | ordered → collected → accessioned → complete, with rejected as a final outcome | Any out-of-order step, 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, a permanent record | Picking up a specimen that was never collected, and applying the same field action twice — repeating it returns the original outcome |
Both are enforced by the system itself, so a stale screen cannot talk it 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 | Results connected directly from bench analyzers | Confirms each valid message; rejects one that didn't arrive intact, with nothing filed |
| HL7 result messages | Specimen identifier, code and value read directly from the message | A confirmation when filed, a clear error when processing fails |
| Any other HL7 message type | Logged and recorded as ignored | A clear rejection naming it unsupported |
Every inbound message is logged before it is read, and the outcome is written back onto the stored message.
Every promise on this page maps to something the software actually enforces.
Completely. Each laboratory gets its own separate data store, and the system will only connect to a data store for a laboratory that is registered and currently active — its own permissions are limited to that laboratory's data, so there is no way for a request to reach across. A request for another laboratory's data is treated as if it doesn't exist rather than simply refused, and a sign-in for a laboratory that is not registered is rejected before anything is read.
No. A final result cannot be edited. A correction creates a new version carrying its reason, links back to the one it replaces, 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 incoming message is saved to the laboratory's message log before anything is processed, so a failure is recorded on the stored message rather than losing it, and the connection stays up. A damaged ASTM message is rejected outright and nothing is filed from it; an HL7 message that cannot be processed is answered with a clear error.
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 analyzer and HL7 connections are part of the system, but they run independently of the rest of the application, precisely so instrument and result traffic keeps being accepted during system updates. Each connection starts and stops as the laboratory's equipment list changes, and belongs to the laboratory that set it up.
Only their own orders. The order, its results and its report PDF are all treated as if they don't exist for a provider who did not place it, and the bench screens — worklists, quality control, critical values — are refused for the provider role entirely.
The laboratory issues a one-time access code, stored encrypted and shown once, which it can reset. The patient signs in with the laboratory identifier, record number, date of birth and that code, and receives a short-lived sign-in that only works on the patient's own read-only screens. They see current final results and the latest report — never preliminary or held ones — and sign-in failures all look the same and are protected against repeated attempts, so a record number cannot be guessed by trial and error.
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, exact to the cent; export refuses to build a claim when a required ABN is unsigned.
The connection point is ready, the live connection is not. Eligibility checking is ready to connect to a payer's system, and without configured payer credentials it answers with an explicit, clearly labeled placeholder for demonstration and testing — it is never dressed up as a real payer response. The same is true of claim submission: export builds and stores the completed clean claim, ready to send through the clearinghouse connection.
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.
