Integration of Laboratory Information Systems with 1C-Bitrix

LIS integration with the website breaks at the order exchange stage

LIS integration with the website most often breaks not at the level of reference data, but at the exchange of orders — where two different data models meet.

The website operates with a cart and an order, while the laboratory information system operates with a referral, a specimen, and a set of tests.

As long as the mapping of these entities is not fixed, every new service or test profile produces a discrepancy: the order goes out with an incomplete set of fields, the LIS rejects it, and on the website it remains in the "accepted" status.

Then manual upload kicks in — an upload performed by an operator once a day or upon a call from the laboratory.

It masks the problem but does not cure it: orders are duplicated on resubmission, lost when a failure occurs mid-upload, and the readiness status is not returned to the website, so the patient sees "in progress" even after the result has been issued.

The more intake points there are, the higher the share of lost orders and the more expensive it becomes to sort out discrepancies manually.

A separate point of failure is the reverse flow. Results and statuses from the LIS must return to the website and to the personal account, but without idempotent exchange, resubmission creates duplicates, and a partially applied batch leaves the order in an intermediate state.

Let's break down how this is closed at the LIS integration level: a fixed exchange contract, a queue with retries, and a log that shows the fate of each order.

What a connected system delivers: turnaround times, duplicates, manual operations

Before integration, the LIS and the website each live their own life: a form submission lands in email or a spreadsheet, an operator manually transfers it into the laboratory system, and the client learns the order status by phone.

At scale, this creates a delay between submitting a request and putting it into work, duplicates when the form is resubmitted, and manual entry where fields get lost and items get mixed up.

The more requests per day, the more noticeable the drop-off — and the higher the cost of an operator error.

A connected system removes these gaps at the level of data exchange, not policy.

A website request is created directly in the LIS, linked to the patient and the set of tests, so the speed of processing requests no longer depends on whether the operator has managed to work through the queue.

Duplicate requests are filtered out at the input: a resubmitted form is recognized by the combination of contact and order composition, and instead of a second card, the existing one is updated. Manual entry is reduced to exceptions — the cases where the data genuinely requires a human.

The reverse flow closes the main source of phone calls. Order status is pulled from the LIS to the website and the customer portal: the client sees what stage the test is at, whether the result is ready, and whether it can be collected.

This changes the class of failures — instead of "lost the request" and "couldn't get through," what remains are isolated exchange failures that are visible in the log and can be replayed by resubmission rather than manual recovery.

Staff workload is also reduced separately: operators stop being the channel for transferring data between systems and focus on samples rather than reconciling cards. Below, we break down how this is structured and what exactly is covered at each stage.

Ways to connect a website and a laboratory system

The exchange method determines what happens when the laboratory system is unavailable or responds slowly.

A direct connection to the LIS database from the website side provides minimal latency when reading reference data and statuses, but tightly couples the two systems: a change in the data schema or an LIS update breaks the pages, and every request from the front end becomes a potential point of failure.

An intermediate layer — a service that maintains a contract with the website and communicates with the LIS itself — decouples releases and allows reference data to be cached, but adds a component that also needs to be maintained.

A message queue removes the main pain point — the unavailability of one of the parties.

A request from the website goes into the queue, a worker picks it up, passes it to the LIS, and returns the result; in the event of a failure, the message is not lost but retried according to a defined policy.

The price for this is the delay between sending and the result appearing, so for scenarios where "the patient is waiting for a response on the screen" it is combined with a synchronous channel for fast operations.

In practice, a hybrid is more often assembled: a queue for requests and results, an intermediate layer for reference data, and a direct channel — only for service exports within a secured environment.

The choice is fixed at the design stage, because changing the method after launch means rewriting scenarios and re-acceptance.

How implementation works: from audit to handover to support

Implementation of the integration between the laboratory information system and 1C-Bitrix begins with an audit: we look at what data already lives in the accounting system, what requests and results come from the laboratory, where manual transfer currently happens, and at which stages time is lost. The output is a data flow map and a list of scenarios that the integration must cover.

Next, we design the exchange scheme: we determine what is transferred and in which direction, how the service and patient reference lists are matched, and how discrepancies and duplicate records are handled.

The scheme is agreed upon before setup begins — this way, changes do not turn into reworking an already finished contour.

1. Integration audit — we survey the accounting system, the laboratory contour, and current manual operations, and record the loss points and exchange requirements.
2. Exchange scheme design — we describe the data composition, reference list matching rules, and handling of errors and duplicate records.
3. Exchange setup — we implement the transfer of requests, statuses, and results between the systems, and configure logging for every step.
4. Scenario verification — we run real cases: a new request, a status change, a completed result, cancellation, and re-export.
5. Exception handling — we check behavior when one of the systems is unavailable, with duplicates, and with incorrect data.
6. Handover to support — we prepare documentation on the exchange scheme, the procedure for actions during failures, and access for maintenance.

Verification is performed on real scenarios, not on test stubs: it is important to see how the system behaves when reference lists diverge, the connection drops, and data is retransmitted. Each scenario is recorded with the expected result — this is the basis for acceptance.

Handover to support includes a procedure: who does what during an exchange failure, how to roll back an incorrect export, and where to view the operations log. After that, maintenance is carried out according to a documented scheme, without dependence on a specific engineer.

What remains in hand: schemas, access rules, regulations

Implementation ends not with the launch of the exchange, but with the handover of a package that allows the system to be operated without us. Below is what exactly remains with the customer after the delivery of the integration of the laboratory information system with Bitrix.

• Data flow schema — where the request comes from, where the sample is created, how the result is returned to the patient card, which fields are mapped where. The schema reflects real routes, including cancellation and re-collection branches.
• Integration configurations — working exchange profiles on both sides, the list of reference books and mapping rules, queue and retry settings. Everything is moved into files and versioned, rather than living in someone's head.
• Access rules — roles for operators, laboratory technicians, and administrators, the permission matrix for reading and writing for each data type, the procedure for issuing and revoking accounts.
• Operator manual — step-by-step scenarios in the language of the shift: how to accept a request, what to do in case of a discrepancy, how to record a cancellation, where to look when an error occurs.
• Exchange regulations — synchronization frequency, maintenance windows, behavior when one of the systems is unavailable, the procedure for manual reconciliation, and escalation rules.
• Support documentation — description of integration points, logs and metrics, typical failures with causes and actions, the update procedure when reference books change.
• Acceptance protocol — a list of tested scenarios with results, including rollback and recovery after a failure.

The package is designed so that a new administrator or contractor can figure it out without verbal explanations. Describe the task — we will come back with an estimate and a plan.

Case study: how double entry of lab requests was eliminated

The laboratory received test requests via a form on the website, and then manual transfer began: an operator opened the email, copied the patient and tube data into the laboratory system interface, and cross-checked against a paper log.

One request took 12-15 minutes, during peak hours the queue grew, and by evening some requests were pushed to the morning.

Duplicates arose where a client submitted the form again without waiting for a response: the operator did not see that the request was already in progress and created a second card.

1C-Bitrix on the website side and the laboratory system on the production side lived in different environments — hence the double entry.

We connected them via an exchange: the form on the website creates a request, its data goes to the laboratory system, and the status returns back to the website and to the client's personal account.

The matching key was the request number and the patient identifier, so a repeated form submission is recognized as the same request rather than a new one.

What changed in numbers

We also separately closed the reference data desynchronization: the list of tests and sample acceptance rules are now maintained in one place and pulled into the website, so the client physically cannot select a combination that the laboratory will not accept. Errors at the submission stage, which previously surfaced only in the lab, dropped to almost zero.

Two months after launch, operators stopped keeping the paper log as the primary source — it remained only for cross-checking. The freed-up time went to processing samples rather than transferring data.

If your requests are still traveling manually between the website and the laboratory system — describe the task, and we will come back with an estimate and a plan for the integration.

How is integration through an intermediary layer different from a direct connection?

A direct connection is when the integration module on the website side accesses the laboratory system's database directly: with the same request, the same account as the internal LIS components.

It works fast and at the start seems like a simple solution, but the website and the laboratory end up tightly coupled: a change in the data schema, an LIS version update, or scheduled maintenance on either side immediately breaks the integration.

Debugging such a failure is difficult — the error comes from someone else's system, and the point of failure is shared by both.

An intermediary layer breaks this coupling. A buffer appears between the website and the LIS — a message queue and a broker service that accepts requests from the website, queues them, and passes them to the laboratory system in a format convenient for it.

If the LIS is unavailable, the request is not lost but waits in the queue and is sent again; if formats diverge, only the conversion at the layer is fixed, without interfering with either system.

The difference shows up in two things — fault tolerance and the cost of modifications. A direct scheme gives minimal latency, but any LIS unavailability turns into lost requests and manual triage.

The layer adds a small delay for queuing, but survives a restart, a connection drop, and an update of either side: accumulated messages are delivered after recovery.

Maintenance is also structured differently. With a direct connection, every modification means coordinating with the LIS vendor, getting access to its database, and risking the production data.

With the layer, modifications are localized: a new scenario is a routing rule and a transformation at the broker, while credentials to the laboratory database remain only with it.

The choice depends on the load and latency requirements: for a stream of requests with high data-integrity requirements, the layer pays off; for rare reference queries, a direct connection is enough.

Common technical questions about integrating a website with a laboratory system

The questions below are the ones that most often come up during the evaluation stage: they concern not functionality but operations. We address them before the start, because the answers change the exchange architecture, not just the code.

How is data integrity verified when transmitting requests and results?

Each record receives an identifier on the source side and an acknowledgment of receipt on the receiving side. Reconciliation is done by checksums and the number of items: any discrepancy is recorded immediately rather than surfacing a week later in reports.

Statuses are reconciled separately — a request cannot "hang" between stages, and any mismatch goes into the review queue.

What happens during a failure: the connection drops, the system is unavailable?

The exchange goes through a queue with retries: undelivered packets are not lost but returned to processing on a set schedule with an increasing interval.

The exchange log stores the request body, the response, the time, and the result code — any operation can be reconstructed from it. Failure handling does not require manual intervention in standard cases: the operator only gets involved with data conflicts.

Who is responsible for failures after launch — us or you?

We fix the division of responsibilities in the regulations: our side is the exchange layer, the queue, the log, and catalog matching; yours is the availability of the laboratory system and the correctness of the data in it.

The log shows which side the error occurred on, so the "everything works on our end" argument does not arise. For the launch period we assign a responsible engineer, and after that — support at an agreed response level.

Describe your integration — we will get back to you with an estimate and a work plan.

Let's discuss your task and come back with a plan

To come back with an estimate and a work plan rather than generalities, we need to understand your current setup.

Describe how the exchange between the laboratory system and the website is currently structured: what data is transmitted (orders, statuses, results), in which direction, at what frequency, and what happens in case of a failure.

Separately — the pain points: where orders get lost, what has to be entered manually, which reports are compiled by hand.

That is enough for us to come back with a work plan: stages, the scope of the integration, what we do on the LIS side, what on the 1C-Bitrix side, how we verify the correctness of the exchange, and how we roll back in case of a failure.

We provide the estimate based on scope, not "by eye" — by the number of entities, exchange directions, and error-handling scenarios.

• Analysis of the current setup — what already works, what is duplicated, where the bottleneck is.
• Stage-by-stage work plan — from exchange prototype to production launch.
• Estimate of timelines and team composition — without "from and to" ranges, based on the specific scope.
• Exchange scheme — what data, in what format, at what frequency.
• Failure scenarios — what happens when the LIS or the website is unavailable, how we catch up on what was missed.
• Verification procedure — how we make sure results arrive without distortion.
• What we need from your side — access credentials, a test environment, a contact person for the LIS.

The next step is a short, to-the-point conversation: you describe the task and the current setup, we ask clarifying questions and come back with an estimate and a work plan. There are no obligations at this stage — you receive a document you can use to make a decision.