Patient portal on 1C-Bitrix: what breaks
A patient portal on 1C-Bitrix is usually assembled on top of a ready-made appointment module, and the first requests are not about the interface but about data desynchronization.
A patient has booked through the website, but they are not in the doctor's schedule; the result is ready, but the previous visit is still displayed in the portal.
The reason is usually the same: the website, the medical system, and the receptionist's workstation work with different copies of the same schedule.
Booking a doctor's appointment through the website breaks at the confirmation stage. The patient did not wait for a response and clicked again — and two people ended up in the same time slot, while the registrar sorts them out by phone.
This is treated with idempotency: the slot is reserved on the system side, and a repeated request returns the already created appointment instead of creating a second one.
Online test results do not open for two reasons: files are uploaded manually and not linked to the visit, or they are provided via a direct link that remains alive after logging out of the portal.
This leads both to "I can't see my test result" and to the opposite story — access to someone else's data. The working scheme is different: reports are pulled from the laboratory system by patient ID and are only served within a verified session.
Patient authorization by phone adds its own layer: the number changes, the code arrives with a delay, and one account is often shared by several family members.
Without number normalization and strict binding to the patient card, login turns into daily manual work for the reception. Next, we analyze how each of these failures is closed at the data schema level.
What changes after portal launch: time, workload, failures
Before launch, we record baseline metrics: the share of calls to the reception regarding repeat appointments and results, average appointment time, and the number of edits in the patient card. After launch, we compare at the same points — the effect is visible in numbers, not in feelings.
- Reception offloading. Repeat appointments, rescheduling, and delivery of completed reports move to the portal. The registrar stops being the only channel — the flow of same-type calls decreases.
- Repeat appointment in two steps. The specialization and doctor are pre-filled from visit history, and only actually available intervals are shown. Booking takes a minute instead of waiting on the line.
- Delivery of test results. The report is published in the portal upon signing, with a notification. The patient does not travel for paper, and the reception does not call everyone in a row.
- Reduction of input errors. Date of birth, contact, and insurance policy are pre-filled from the profile. The class of errors "typo during manual entry" disappears along with returns for data verification.
- Patient appointment time. The card is filled in advance — the administrator only needs to confirm the data and get straight to the point instead of gathering the form on the fly.
We measure each item separately after launch on 1C-Bitrix: a before-and-after comparison using the same metrics shows where the effect is already there and where the scenario needs refinement.
Implementation options: ready-made module, customization, separate service
The key fork is where the data lives. Doctor schedules, appointments, reports, and appointment statuses remain in the medical accounting system, while the patient portal only displays them and accepts actions.
Therefore, the choice of path is determined by two things: how non-standard the booking rules are and how the exchange with the accounting system is arranged — direct database access, an API, or exports.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made patient portal module | Standard flow: doctor appointments, doctor schedules, visit history | Limitations of ready-made solutions: slot and role logic is predefined and cannot be extended by settings |
| Customization for the clinic | Your own rules: multiple branches, quotas by specialty, slot distribution by specialization | Harder to update the core, requires agreed rules before start and tests on real appointments |
| Separate service next to the accounting system | The accounting system is closed for modifications or exchange goes through exports | Two data loops: need discrepancy control, retries, and failure analysis |
The practice is simple: if there are few non-standard rules, it is cheaper and faster to configure a ready-made loop, and leave customization for the clinic to those places where standard behavior hinders appointments.
A separate service is chosen when the accounting system does not accept changes — then the portal develops at its own pace, and the connection to it is maintained by an exchange regulation.
To choose an option for your situation, describe which booking rules differ from standard and how the accounting system provides data — we will come back with an estimate and a plan.
Implementation stages: from data audit to handover to support
The patient portal is a superstructure over the clinic's accounting system: an error in the exchange scheme or in role rights costs more than a layout defect — the patient sees someone else's records or loses their own.
The work proceeds in stages, and each stage ends with a verifiable result, not a report on work performed.
- Audit of clinic data and scenarios: we find out where schedules, appointments, and patient cards live, which fields are filled incompletely, and we fix the list of scenarios — booking, rescheduling, cancellation, access to documents.
- Data exchange scheme: we determine what and at what frequency goes from the accounting system to the portal and back, where a queue is placed, and how conflicts are resolved — for example, when a patient and an administrator change an appointment at the same time.
- Doctor and administrator access roles: the doctor sees their patients and visit history, the administrator sees the schedule but not medical documents. We separately check access to files via direct link, not only through the interface.
- Test loop on anonymized data: we run booking, cancellation, results, and notifications on a copy of the portal, then under load we observe the exchange behavior during peak booking hours.
- Staff training: we show doctors and administrators the working scenarios, provide cheat sheets for typical failures — no confirmation received, duplicate appointment, lost access.
- Acceptance of work and handover to support: we accept according to the scenario checklist together with your team and fix the regulations for exchange, backup, and updates. Then — support with an agreed response level.
What the customer receives: settings, schemes, regulations
After the patient portal launch, the clinic retains not only a working section on the website but also a set of documents according to which it can be developed without us.
We hand over a disassembled system: what is connected to what, where the boundary of responsibility lies, and what will happen if an external service fails.
- Integration scheme: which entities the portal pulls from the clinic's accounting system — patient card, appointments, results — in which direction the exchange goes and how discrepancies are resolved.
- Access policies: role matrix (patient, doctor, administrator, operator) — who sees which sections, how long the session lives, how identity is confirmed at login.
- Result delivery regulation: after what interval from the doctor's signing the document becomes visible to the patient, how access is revoked, and how the fact of viewing is recorded.
- Administrator instructions: patient registration, access restoration, merging duplicate cards, handling typical requests — with step-by-step screens.
- Portal documentation: description of modules, extension points, and event logs — based on it, a third-party developer can implement a customization without breaking the exchange with the clinic.
- Set of verification scenarios: login, booking, receiving a result, access revocation — a run before each update so the portal does not "go off the rails" after edits on the website.
The handover is done as a walkthrough with your team and administrators: we go through scenarios on the live portal on 1C-Bitrix, answer questions, and record agreements.
Then the section is developed by your own efforts, and we are engaged selectively — for new modules and exchanges.
Case study: how the portal reduced the load on reception
Patients booked appointments at a network of several branches through a call center. The share of self-bookings remained around 12%: the rest went through an operator, and response time to a request during peak hours stretched to several hours.
Administrators corrected the schedule manually, and overlaps — double booking for one slot, outdated reschedules — surfaced on the day of the appointment, when rebuilding the doctor's schedule is most expensive.
What was changed
The portal is built on 1C-Bitrix and connected to the clinic's accounting system: free intervals are pulled from the doctor's schedule, and the patient sees only actually available slots for their profile.
Rescheduling and cancellation work according to the clinic's rules — with a time limit before the appointment and automatic notification to the reception. Repeat booking comes from visit history, and results and prescriptions appear in the card without a call.
Metrics before and after
The share of self-bookings grew from 12% to 68%, and response time to a request decreased from hours to minutes: the patient sees the request status in the portal without waiting for an operator.
The number of manual edits in the schedule decreased by almost 80%, and slot overlaps on the day of the appointment became isolated — the doctor's schedule stopped "drifting."
The reception switched to complex cases: initial consultations on programs, document questions, support for elderly patients. The load on operators stopped growing along with the network — new branches connect to the same booking logic.
How does a solution on 1C-Bitrix differ from a ready-made service?
A ready-made booking service is someone else's loop. The patient, schedule slots, and visit history are stored in the provider's database, and you get an interface and exports.
Patient data storage is then governed by the contract with the provider, not by your access rules: you do not control retention periods, the log of accesses to the card, or role separation within the clinic.
A patient portal on 1C-Bitrix is part of your own website, not an external add-on. The database lies in your loop, you distribute rights, and the retention period and log depth are configured to meet medical documentation requirements.
The exchange with the medical information system goes through an API — doctor schedules and booking rules remain yours, not rented.
Dependence on the provider in a ready-made service is visible in three places: changes in terms of service, restrictions on export volume, and the impossibility of rewriting a scenario for your own logic.
A referral for a follow-up appointment, booking under an observation program, linking the portal to payment and documents — all of this runs into someone else's functionality.
Portal migration is the most illustrative scenario. From your own loop, it migrates entirely: the database, templates, and integrations go to a new contractor along with the appointment history.
From a service, you will not be able to take everything — part of the data will remain in a read-only format, and the connections will have to be rebuilt.
Hence the selection criterion: if booking is the only function, a ready-made service solves the task quickly.
If the portal is the entry point to a medical service, where documents, repeat visits, and communication follow, your own loop gives data ownership and freedom to change logic without approvals.
Technical concerns: access, integrations, data protection
Before starting, almost always the same set of questions comes up: how the patient gets access, who is responsible for personal data, and how the portal behaves when the accounting system is unavailable. Below are short answers that remove most doubts even before work begins.
How does a patient get access to the portal?
Access is granted by a combination of phone number and patient card number: on first login — confirmation by code, then login with a permanent password. Numbers that are not in the database are not allowed through by the portal — access to someone else's data is excluded.
Is a login log kept?
Yes, separately for each event: time, device, attempt result, and successful login flag. A series of failed attempts blocks login, and the patient sees the history of their sessions and can terminate an extra one.
Where is personal data stored?
In the clinic's loop, on its servers — we do not move the database to a third party. Data is divided by roles, and only identifiers remain in service logs, without surnames and diagnoses.
What will the patient see if the accounting system is unavailable?
The last saved state: appointments, documents, results. New requests go into a queue and enter the system after connection is restored — the patient receives a clear message instead of an empty screen.
What access rights do employees have?
Roles are configured for the clinic's processes: the administrator sees the schedule, the doctor — only their patients, full access — for a limited circle. Employee actions are recorded in the same log.
Let's discuss the task: what data is needed for an estimate
The estimate of timelines and scope of work for a patient portal depends not on the size of the clinic but on the number of data sources and the strictness of access requirements.
Below are the inputs by which we calculate the implementation plan; if something is not yet decided, that is also a working answer — we simply include design as a separate stage.
- Access model: who logs into the portal — only the patient or also relatives and a guardian, whether several profiles need to be linked to one contact.
- Composition of medical data: what we display — test results, reports, visit history, invoices — and in what form it is stored now: files, HL block, reference books.
- Sources and exchange: which systems provide data (accounting, laboratory, call center) and at what frequency updates are needed — on request or on a schedule.
- Rights and logging: which employees see the card, whether views and exports need to be recorded, who is responsible for access revocation.
- Booking scenarios: self-booking, rescheduling and cancellation of an appointment, payment — what already works and through which service, so as not to duplicate logic.
- Protection requirements: where the server is located, whether two-factor authentication is needed, whether there is an internal regulation for personal data processing.
- Accesses and materials: test bench and database copy, contacts of your IT specialists and the accounting system contractor, mockups or brand book.
Send the inputs in any form — a list, text, a link to the current portal. We will analyze them, clarify details on exchange and access, and come back with an estimate of timelines, scope of work, and a stage-by-stage implementation plan.