Core laboratory
- Chemistry analyzers
- Immunoassay analyzers
- Hematology analyzers
- Coagulation analyzers
Laboratory instrument integration
Medical Laboratory Instrument Integration
When analyzers do not talk to the LIS, technologists retype results, QC sits in a separate log and every new instrument is a risky project. Agnotic Technologies builds the instrument interfaces and middleware rules that move orders, results and QC data between your analyzers and your laboratory information system.
ASTM and CLSI LIS2-A2HL7 v2Autoverification rulesHIPAA-ready
Trusted by global innovators
What is medical laboratory instrument integration?
Medical laboratory instrument integration connects analyzers to the laboratory information system, so work orders reach each instrument and results, flags and QC data return without retyping. Agnotic Technologies builds it for you: ASTM and HL7 v2 interfaces, middleware rules for autoverification and a validated onboarding process for every new analyzer.
This page is about the instrument side of the lab. Orders and results between your EHR and reference labs such as Quest and LabCorp are covered on our lab integration services page.
The LIS itself, with accessioning, reporting and billing, is covered on our laboratory information system development page. Here we connect the analyzers and middleware to whichever LIS you run.
Data path
How does a result travel from the analyzer to the LIS?
Six handoffs, each one a place where a result can stall or change. We design and test every one.
Order becomes a work order
The LIS holds the tests for each accession. The interface either sends them to the analyzer in advance or answers the analyzer's query when the tube arrives.
Specimen identified
The analyzer reads the tube barcode and asks the host which tests to run. Unknown or duplicate barcodes go to a review queue, never to a guess.
Run and raw result
The analyzer returns the result with units, flags and the instrument identity, plus reagent lot and run details where the instrument sends them.
Middleware rules
Rules check QC status, instrument flags, limits and deltas. A result that passes moves on; one that fails is held for a technologist, a rerun or a dilution.
Filed in the LIS
The verified result files against its accession with the rule outcome and analyzer recorded, ready for the LIS to report to the EHR.
Acknowledged and logged
Every message is acknowledged. A failed message is queued for replay and alerted on, so no result is dropped without someone knowing.
Instrument protocols
Which interfaces connect analyzers to the LIS?
Most labs run a mix. Older analyzers speak ASTM over serial lines; newer ones and most middleware speak HL7 v2 over TCP.
| Code | Name | Typical use |
|---|---|---|
| ASTM E1381 / CLSI LIS1-A | Low-level transfer | Framing, checksums and acknowledgement between an analyzer and the host, over serial or TCP. |
| ASTM E1394 / CLSI LIS2-A2 | Record format | Header, patient, order, result and terminator records that carry work orders down and results up. |
| HL7 v2 (IHE LAW profile) | Analyzer messaging over HL7 v2.5.1 | Work orders, host queries and results with acknowledgements, used by newer analyzers and middleware. |
| CLSI POCT1-A | Point-of-care connectivity | Messaging between point-of-care devices and their data manager before results reach the LIS. |
| File export | CSV or XML results file | Instruments that write results to a folder. A watched-folder listener reads, validates and archives each file. |
| Vendor interface | Published by the instrument maker | Where the vendor documents its own interface, we build to that document and its version. |
Decision table
Where should each rule live: analyzer, middleware or LIS?
Putting the same rule in two places is the most common cause of results that behave differently by instrument. We give each rule one home.
| Rule or function | Analyzer | Middleware | LIS | Our usual choice |
|---|---|---|---|---|
| Flags and error codes | Generates them | Maps each code to an action | Stores the flag with the result | Map once in middleware and keep the raw flag |
| QC evaluation | Runs the controls | Applies the lab's QC rules and holds results on failure | Records QC status | Middleware, so a failed run stops results before they file |
| Autoverification | Rarely | Rules by test, range, flag and delta | Some LIS products support it | One home only, where the lab already validates its rules |
| Delta checks | No patient history | Possible with a history feed | Has the full patient history | LIS, or middleware with a history feed |
| Reruns and dilutions | Performs them | Triggers them from rules | Records the final result | Middleware |
| Reflex tests that bill | Runs them once ordered | Can suggest them | Orders and charges them | LIS, so billing and orders stay in step |
What we build for laboratory instrument integration
Each piece is scoped on its own, so a first release can be one analyzer and one rule set.
Instrument drivers
ASTM and HL7 v2 drivers over serial, TCP or file, one per analyzer model, behind a single internal result model.
Host query and worklist service
Answers analyzer queries by barcode and sends work orders in advance where the analyzer expects them.
Middleware rules engine
Autoverification, rerun and hold rules written with your lab, versioned, tested against sample results and logged when they change.
QC data capture
Control results stored by lot and level, kept apart from patient results, with data ready for QC charts and review.
Test code mapping
Each instrument test code mapped to an LIS test and LOINC code, with units and decimal places checked.
Interface monitoring and replay
Connection status, message queues and alerts for each analyzer, with replay for any message that failed.
Instrument families
Which lab instruments do we connect?
We work from the instrument maker's interface specification, so any analyzer with a documented interface is in scope.
Specialty sections
- Urinalysis
- Blood gas
- Molecular and PCR
- Microbiology identification
Automation
- Track systems
- Pre-analytical sorters
- Sample storage
Point of care
- Glucose meters
- Point-of-care data managers
- Handheld analyzers
Original checklist
What do we test before a new analyzer goes live?
Our onboarding checklist for each instrument. It produces interface evidence the lab can file with its own verification records.
- Interface specification from the instrument maker, with the exact protocol version
- Every instrument test code mapped to an LIS test and a LOINC code
- Units, decimal places and reportable range checked against the LIS test build
- Each flag and error code mapped to an action, with none left unhandled
- Host query and download modes tested, including unknown and duplicate barcodes
- QC results captured by control lot and level, never filed as patient results
- Autoverification rules reviewed and approved by the laboratory before go-live
- Parallel run against the current interface or manual entry, with every difference logged
- Connection loss, resend and duplicate result handling tested on the bench
- Interface test evidence handed over before the first patient result is reported
Quality rules
How do CLIA quality rules shape the integration?
The lab owns its CLIA compliance. We build the interface so the evidence and controls it needs are already in place.
Verification before patient results
A new test system is verified before it reports. Our interface tests and parallel runs feed that work, and nothing reports until the lab signs off.
QC that holds results
Controls are stored by lot and level. A failed run holds patient results on that analyzer, and controls run again after reagent changes or maintenance.
Comparison across analyzers
Where one test runs on two instruments, paired results export for the lab's twice-yearly comparison.
Audit and access
Rule changes, releases and manual edits are logged with user and time. Agnotic signs a BAA before any PHI is shared, as part of HIPAA-ready engineering.
How we work
How do we bring a new analyzer online?
Four steps per instrument, with a fixed first release agreed before build starts.
1.
Scoping call
We list your analyzers, their protocols, any middleware already in place, your LIS and the rules you want automated.
Scope first
2.
Specification and test map
We read the instrument maker's interface document and build the test code, flag and unit maps with your lab team.
Maps first
3.
Bench build with simulated messages
The driver and rules are built and tested against recorded and simulated messages, with synthetic patients only.
No PHI in test
4.
Parallel run and go-live
The interface runs alongside the current process until differences are resolved and the lab approves it for patient reporting.
Lab sign-off
Scope drivers
What drives the cost of an instrument integration?
We do not quote a price before scoping. These factors move the effort most.
Number and age of analyzers
Each model needs its own driver. Older serial analyzers may also need a serial to network bridge.
Quality of the interface specification
A complete vendor document keeps mapping short. A thin one means more time capturing and reading real messages.
Middleware in place or new
Connecting to existing middleware is mostly mapping. Building the rules layer itself is a larger piece of work.
Autoverification scope
A few high-volume tests is a contained rule set. Rules across every section need more testing and lab review.
LIS interface change process
Some LIS vendors make interface changes themselves on their own schedule, which shapes the plan.
Validation effort
Parallel run length and the evidence your lab needs for its records add effort on both sides.
Who needs it
Who needs laboratory instrument integration?
Labs and lab technology teams where results must move from instrument to record without retyping.
Hospital core labs
Many analyzers across sections, feeding one LIS through middleware.
Reference labs
New analyzers added often, each needing a fast, repeatable onboarding.
Physician office and urgent care labs
A few analyzers connected straight to a small LIS.
Lab middleware startups
Products that sit between analyzers and the LIS and need tested drivers.
Diagnostic instrument makers
Teams that need LIS connectivity built and documented for their analyzer.
Point-of-care programs
Device results gathered by a data manager and sent on to the LIS.
Standards in scope
Standards used in laboratory instrument integration
ASTM E1381ASTM E1394HL7 v2POCT1-ALOINCCLIA
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Facts and sources
Which rules shape laboratory instrument integration?
Short facts we design around, each linked to its primary source.
Under CLIA, a laboratory that introduces an unmodified, FDA-cleared or approved test system must, before reporting patient results, show it can match the manufacturer's accuracy, precision and reportable range, verify the reference intervals for its patients, and document this work.
Source: 42 CFR 493.1253 (eCFR)Unless a specialty rule or an approved equivalent procedure says otherwise, CLIA requires at least two control materials of different concentrations for each quantitative procedure, at least once each day patient specimens are tested.
Source: 42 CFR 493.1256(d)(3) (eCFR)CLIA requires control testing before patient testing resumes after a complete change of reagents, major preventive maintenance, or replacement of any critical part that may affect test performance.
Source: 42 CFR 493.1256(d)(6) (eCFR)A laboratory that runs the same test on different instruments, methods or sites must evaluate and define the relationship between those results twice a year, and document the comparison.
Source: 42 CFR 493.1281 (eCFR)FDA classifies a calculator or data processing module for clinical use, an electronic device intended to process laboratory data, as Class I (general controls), exempt from premarket notification subject to the limits in 21 CFR 862.9.
Source: 21 CFR 862.2100 (eCFR)
Frequently Asked Questions
Lab integration moves orders and results between your EHR or platform and outside reference labs. Instrument integration happens inside the lab: it connects analyzers and middleware to the LIS. Many labs need both, and we scope them separately.
A lab with a few analyzers and simple rules can connect them directly to the LIS. Middleware earns its place when you want autoverification, QC holds or reruns across many instruments. We recommend one after seeing your analyzers and rules.
Yes. We build the ASTM driver for the serial line and, where needed, add a serial to network bridge so the analyzer can reach the host. We test the line settings and checksums on the bench first.
It can be. FDA classifies a calculator or data processing module for clinical use as a Class I device under 21 CFR 862.2100. Whether a given build falls under that or another classification is a regulatory question we raise with your regulatory lead at scoping.
Your laboratory decides the rules and approves them. We turn them into versioned rule sets, test them against sample results, and log every change so the lab can show what ran and when.
It depends on scope; we agree a fixed first release on the scoping call. One analyzer with a complete interface specification is a smaller release than several analyzers with a new rules layer.
Yes. Agnotic signs a business associate agreement before any PHI is shared. Bench testing uses recorded or simulated messages with synthetic patients only.