Why telemedicine breaks at the junction with MIS and laboratories
A telemedicine platform rests not on a doctor's video consultation, but on data exchange with external systems. Integration with MIS and exchange with the laboratory are the busiest area: here third-party formats, local directories, and different notions of who a patient is meet. We analyze typical points of failure.
The first gap is the schedule. Slots in the MIS and in the online appointment booking module live in different data stores and are reconciled on a timer: while the next reconciliation is running, one slot manages to be booked twice.
The patient comes online at the appointed time, the doctor sees an empty window, support manually resolves the conflict and reschedules the appointment. With a flow of bookings, this turns into a constant source of errors and calls to the clinic.
The second junction is exchange with the laboratory. When a result arrives by email or file, an operator manually transfers the values into the chart: units of measurement get mixed up, lines are lost, data is hours late.
The third is identification: registering for a doctor's video consultation with a different phone number or email creates a second chart, the patient's history diverges, and prescriptions remain in one of them.
Then the domino effect kicks in: the doctor makes a decision based on incomplete data, the patient cannot find prescriptions, administrators duplicate the same work. Below we analyze how this is closed — from a unified patient registry to an exchange queue with laboratories.
What integration of telemedicine with MIS and laboratory systems provides
The linkage of telemedicine with MIS and laboratory systems removes manual work.
The doctor and patient work in a single patient chart: prescriptions, conclusions, test results, and appointment history are pulled by identifier rather than by the combination "last name and date of birth." Duplicate charts stop appearing, and the history is assembled with one query instead of a call to the registration desk.
Loading of test results comes as a stream from the laboratory: the response arrives structured, is matched to the test code, and is placed into the chart with a "new" mark.
The doctor does not need to retype values from a file or wait for an email — next to the current values, they see the dynamics from previous tests.
Loading doctors' schedules closes the second source of manual operations. The appointment grid is synchronized with the MIS in both directions: a slot booked in the telemedicine office is immediately closed in the clinic's schedule. Double bookings and "two patients at the same time" go away as a class of failures.
The share of manual operations is calculated directly — how many staff actions are required per appointment.
Usually it is transferring data between systems, reconciling records, and resolving discrepancies; after integration, only exception control remains, which the system flags itself.
Time to result drops from hours to minutes: the laboratory response appears with the doctor almost immediately, and the appointment is not postponed to the next day.
Failures noticeable to the patient also go away separately: the result is in the wrong chart, the test is lost, there is no conclusion by the appointment. Result delivery is built with retries and a log — a channel failure results in a delayed record, not data loss.
Telemedicine operating formats: comparison of four schemes
Connecting to MIS and laboratories is not a single interface but a choice of scheme: from point-to-point exchange to standardized profiles. The scheme determines how much work it costs to add a new partner and what happens when they update their system on their side.
| Scheme | When appropriate | What limits it |
|---|---|---|
| Direct integration | one or two partners, stable system versions, small order flow | each new MIS or laboratory is separate development; a third-party update breaks the exchange |
| Intermediate layer | several partners, different formats, exchange log and send retries needed | the layer needs to be designed, monitored, and maintained together with third-party systems |
| Exchange via industry standard (HL7 FHIR profiles) | partners support the standard, horizon is years, data composition is broad | standard support is incomplete: laboratories expose some fields outside the profiles |
| Manual upload | rare tests, no access to a software interface, quick start needed | input errors, delayed result, no tracing or repeated delivery |
| Hybrid scheme | streaming referrals online, individual partners manually | a unified storage and consolidation rules are needed, otherwise data diverges |
How we choose a scheme
We calculate ahead by the number of partners and frequency of their turnover. If there are two or three laboratories with ready interfaces ahead, direct integration gets into operation faster, but each subsequent one adds a separate code branch and a point of failure.
When there are more than ten partners or the composition changes every quarter, the intermediate layer and standard-based exchange enable connecting a new participant without changes to the core — the work is reduced severalfold.
The hybrid scheme here is not a compromise but a normal end state of a mature platform: a rare partner sends conclusions as a file, a streaming referral goes through the standard, and the doctor sees both in one patient card.
Implementation stages: from integration audit to handover to support
Implementation of a telemedicine platform almost never starts with code: first you need to understand what you will be interfacing with.
MIS, laboratory system, doctor's schedule, and document storage are different at each clinic, and exchanges between them are the most expensive part of the project. Therefore, we proceed sequentially: each stage removes a risk that is cheaper to close before development.
- System audit. We inventory sources: doctor and service directories, patient storage, access provisioning procedure, availability of a test environment. The output is a prioritized list of integrations with a list of limitations.
- Integration scheme. We fix the flow map: who initiates the exchange, by which identifier the patient and test are matched, what happens when one of the parties is unavailable. We agree on the scheme before the first line of code.
- Exchange setup. We implement according to the scheme: queues, retries, operation log. We separately handle appointment cancellation, rescheduling, and re-issuance of a result — otherwise duplicates create extra appointments for the doctor.
- Acceptance checks. We run end-to-end scenarios on real data: booking, confirmation, appointment, result, rejection. Plus behavior during a connection loss and at the morning load peak.
- Pilot operation. A limited group of doctors works in parallel with the usual process — this reveals discrepancies that do not occur on test data.
- Handover to support. We hand over documentation, regulations, and monitoring: an alert for exchange failure, delivery retry, incident investigation procedure. The clinic's team receives instructions for each type of failure.
Integration schemes, regulations, and access policies on output
A platform that cannot be handed over to its own team is a rental, not development.
Therefore, along with a working product, we prepare a package of artifacts that the customer's engineer and support service use to run the system without us: from data flow diagrams to actions in emergency situations.
- Integration schemes — an exchange map between the portal, clinic MIS, and laboratory systems: who initiates the request, which identifiers link the patient across different environments, where the primary consultation record is stored, and how discrepancies in service directories are handled.
- Access matrix — a table of roles (doctor, patient, clinic administrator, laboratory employee, integration service account) with an exact list of fields and operations: who sees the full text of the conclusion, who sees only the test result, who can export the appointment history.
- Exchange regulation — operating procedure when an external system is unavailable: repeated message delivery, scheduled retries, a daily discrepancy reconciliation window, where errors are written, and who receives the notification.
- Instructions for doctors — analysis of typical appointment and connection loss scenarios: how to continue the consultation if the channel is lost, where to save the draft conclusion, and at what address to report the incident.
- Recovery plan — target service restoration times and acceptable data loss volume, procedure for switching to a backup environment, responsible persons for each action, and the criterion by which normal mode is declared.
- Medical data handling policy — retention periods for records and logs, who opened the patient chart and when, and how export is arranged at the patient's own request.
- External systems registry — a list of connected laboratories and clinics with versions of their interfaces and contacts of responsible persons: it is clear whom to go to when the format changes on their side.
We write documents in the language of processes, not only software interface descriptions: the on-duty engineer finds an answer in minutes, and a new developer joins the project without secondhand explanations.
Case study: telemedicine and MIS — metrics before and after
The clinic conducted appointments in MIS, and the laboratory delivered results by emails and spreadsheets: they reached the patient chart only after manual transfer by an administrator.
For a hundred appointments, there were about forty calls to the registration desk asking "where is my result," and transfers produced 5–6% discrepancies — typos in dates, lost items, duplicated charts.
Metrics before and after
| Metric | Before linkage | After |
|---|---|---|
| Result release time | up to 26 hours, manually | 3–4 hours, automatically |
| Share of manual transfer errors | 5–6% of records | less than 0.5% |
| Calls to the registration desk per 100 appointments | ~40 | ~9 |
| Duplicate patient charts | constant, manual resolution | isolated, filtered at entry |
What was changed in the integration
Orders and results went through a queue with delivery confirmation: each message is tagged with an order identifier, so resending does not create a second record, and laboratory unavailability does not lead to losses — messages arrive after it is restored.
The patient is matched by a master index (policy number and date of birth), a new profile for the same person is no longer created, and the doctor does not need to manually verify attachments.
The exchange goes through the industry standard for structured medical data, so parsing free text from emails has been removed entirely.
The registration desk stopped being a bottleneck: freed-up hours went to booking and supporting appointments, not to reconciling results.
Discrepancies are now visible in the event log before they reach the chart — disputed cases are resolved point by point, not by a continuous review of uploads per shift.
How does standard-based exchange differ from direct upload from MIS?
The difference shows in two places: how much it costs to connect a new counterparty and what happens when they update their system.
Direct upload reads the internal entities of the MIS, while the exchange standard describes the same data in a common model — hence both timelines and maintenance costs diverge.
Direct upload is a query to specific entities of an already deployed MIS: schedule, patient card, test results. It works quickly and predictably while there is a single environment and the vendor does not change the schema.
As soon as the laboratory updates a module, some fields are renamed or change type — the integration silently returns empty values, and the incident surfaces with the doctor during an appointment.
The exchange standard (for example, FHIR) places an intermediate layer between systems: the source brings data to a common model, and the application reads only that.
Connecting a second laboratory or a second MIS is a new adapter, not rewriting the logic of appointments, results, and notifications.
Many vendors support such exchange, and then an already deployed MIS provides data itself, while the adapter comes down to configuration and field mapping verification.
What costs more is not maintenance but the absence of the layer. In a direct scheme, every counterparty update means edits in several places in the code; in the standard one, it is one mapping, and the rest is untouched.
We usually do a hybrid: we leave direct upload for single stable sources, and route the core — schedule, records, results — through the intermediate layer and cover it with checks for incomplete responses.
Technical concerns: logging, access, fault tolerance
Access logging is built on the principle of "every action is a record": doctor login, opening the patient chart, exporting documents, editing the conclusion.
The log is stored separately from the working database, is read-only, and is not deleted together with the data — during investigation, the entire chain is visible. This is a requirement of 152-FZ, and in telemedicine it is checked more strictly than in most industries.
Four concerns that are most often raised before project start, and how they are addressed engineering-wise.
How is patients' personal data protected?
Flows are separated: patient data lives in a protected environment, anonymized statistics separately. Rights are configured down to the field level: a doctor sees only their own patients and the sections of the chart they need. Demonstration stands run on synthetic data; there are no copies of real charts there.
What happens if the connection drops during an appointment?
The consultation does not break off: the video stream switches to audio, the draft conclusion and appointment state are saved locally. When the connection returns, the doctor continues from the same point rather than starting over.
If the interruption drags on, the patient joins a queue for a repeat call — the history is preserved.
Can the upload format to the laboratory be changed?
Exchange with MIS and laboratories is separated into a dedicated layer: changing the format or connecting a new laboratory does not affect the logic of the doctor's office.
A new format is added as a separate module, old ones continue to work, and already transmitted results are not rebuilt.
How long does doctor training take?
We show the doctor's working day using their own scenarios: appointment, prescription, conclusion export — usually one or two meetings. After that, short instructions and review of disputed cases remain. The acceptance metric is the share of appointments conducted without support requests.
Let's discuss the task: what is needed to evaluate your platform
To come back with a timeline estimate and work plan rather than general wording, we need a minimum of inputs about your platform.
Below is what most often determines the effort: exchange environments with external systems, role composition, and requirements for storing medical data.
If some points are not yet defined, this does not block the conversation — we will record assumptions and verify them during the pilot stage.
- Appointment scenarios: video consultations, asynchronous questions to the doctor, issuance of conclusions and prescriptions — what already works and what is yet to be done.
- Integrations: with which MIS, laboratories, and pharmacy services exchange is needed, in which direction data flows (appointments, results, prescriptions), and how patients and doctors are matched between systems.
- Data handling: requirements for storage and anonymization of health information, access logging, processing consents, and export on request.
- Roles and access: patient, doctor, coordinator, clinic administrator — who sees what, which actions they confirm, and how rights are separated between clinics.
- Load and fault tolerance: how many consultations must be supported simultaneously, how the system behaves during peak hours, and what happens when an external laboratory is unavailable.
- Current state: whether there is a prototype, code, design, process description; what we reuse and what we rewrite.
- Project constraints: launch timelines, team composition on your side, who makes decisions on clinical and legal matters.
After that, we break the work into stages, name the team composition for each area, and propose a pilot stage on one scenario — with acceptance criteria and extension points. Describe the task in free form: we will come back with a timeline estimate and work plan.
