Medical portal development: appointments, patient account, MIS, telemedicine

Medical Portal Development: Where Appointment Booking and the Patient Account Break

Medical portal development does not start with the interface, but with the question of who owns the doctor's schedule.

If the portal keeps its own copy of the appointment grid while the clinic's records system runs separately, the discrepancy becomes visible within the first day: a slot was opened at the front desk, a patient booked it through online doctor booking—and by morning there are two people in the office for the same time.

The cause is usually the synchronization method. Doctor schedules are pulled in batches every few minutes, while bookings go directly to the portal database—the window between updates creates duplicate appointments.

During the morning peak, patient authorization is added to this: if login, schedule retrieval, and booking confirmation all hit the same node, the first surge takes down both login and booking at once.

Then the human loop kicks in. Patients call, the load on the front desk grows, operators reschedule bookings manually—and create new discrepancies that did not exist in the system.

A separate cause is divergent reference data: service, specialty, office, and appointment duration are described differently in two places, and the portal offers a slot that the clinic does not confirm.

That is why the order of work is the reverse of the usual: first a single source of truth for the schedule, then separation of reads and writes, and only then the patient account.

It is precisely at this junction that medical portal development most often breaks—not in the layout, but at the moment when the morning flow converges with the schedule.

What Changes After Launch: Booking Time, Load, Failure Rate

Before electronic booking was introduced, the patient's path to a doctor looked like this: a call to the front desk, a search for a slot in the schedule, a check against the log, clarifying questions, and a callback with confirmation—6–8 actions and two or three touchpoints.

After launch, the same path compresses to three steps: choosing a specialist, choosing an available slot, and confirming. The patient performs two of the three steps independently, so during peak hours, when the front desk physically cannot keep up, booking continues.

The load on the front desk decreases not "on the whole," but for a specific class of requests: the share of calls specifically about booking falls by about two-thirds.

Rescheduling, cancellations, and document-related questions remain—things that require a person, not an interface. The dispatcher stops being a bottleneck and switches to complex cases instead of mechanically searching for slots.

A telemedicine appointment is recorded in the same visit log as an offline consultation: slot, status, conclusion.

After the appointment, documents go into the medical system in a single stream—the exchange is built on FHIR, so the doctor does not fill out two systems in parallel, and the patient sees a single list of their encounters regardless of format.

In terms of booking service availability, an entire class of failures disappears—lost confirmation.

A slot is reserved atomically, resubmitting the form does not create a second appointment, and if the medical system is unavailable, the request is queued and completed when it recovers.

Previously, this was a reliable source of double bookings and "you are not in the schedule" responses—now such cases simply do not arise.

Implementation Options: From Scratch, on a Ready-Made Platform, with Ready-Made Modules

The choice of path is determined not by timelines themselves, but by how much freedom remains after launch. If appointment schedules, cancellation rules, and quota distribution fit standard logic, a ready-made medical platform solves the task faster.

If booking scenarios are non-standard, a custom core pays for itself with the very first modification.

The main bottleneck is the same for all three paths—integration with the MIS. The exchange of schedules, patient records, and appointment statuses is sensitive to format discrepancies, so we design the exchange scheme before the first line of code.

We analyze your booking scenarios, identify what is covered by standard functionality, and only then name the suitable option.

Implementation Stages: From Process Audit to Handover to Operation

Implementation begins not with mockups, but with an analysis of how booking works now: how many request intake channels there are, who has the right to reschedule and cancel a visit, how doctors of different specialties manage their schedules, and at what point data must enter the MIS.

An audit of booking processes reveals bottlenecks—double entry, lost requests, manual confirmation—and only after it does the technical specification appear, not the other way around.

Next, the work proceeds in stages, and each ends with an artifact that can be checked before rollout to all patients.

1. Discovery: employee roles, patient journeys, exchange points with the MIS and laboratory, requirements for storing medical data.
2. Patient data schema: a single profile, duplicate matching rules, access differentiation for sensitive fields, and an encounter log.
3. Booking design: appointment grid, cancellation rules, waiting list, and protection of a slot from double booking.
4. Assembly of the patient account and telemedicine: test results, prescriptions, payment, and video appointments with channel reservation.
5. Testing on real scenarios: schedule conflicts, connection loss during a video appointment, MIS unavailability—the portal behaves predictably.
6. Pilot operation on a limited group of patients and doctors: reconciliation of data with the MIS, measurement of response time under peak load.
7. Handover to support: update regulations, rollback procedure, integration scheme, and instructions for clinic administrators.

At each step, the client sees not a progress report, but a verifiable part of the system—before it affects all patients.

What the Client Retains: Diagrams, Regulations, Documentation

Portal documentation is maintained not "for release," but in parallel with development: each loop—appointment booking, the patient account, exchange with the MIS, telemedicine rooms—gets its own diagram and its own regulation.

At the output, the client is left with a package that a new contractor or in-house engineer can use to bring the system up without taking it apart piece by piece.

• Data flow diagram: the path of a request from the website form to a slot in the schedule, exchange points with the MIS, queue behavior when an external system is unavailable, and the retry procedure.
• Doctor access policies: roles and scope of visible records, the rule "own patient—someone else's record," logging of every opening of a medical record, and retention periods for these logs.
• Backup regulations: what goes into the backup (booking database, study attachments, service configuration), frequency, retention depth, responsible person, and a verified recovery scenario.
• Instructions for the front desk: double booking, rescheduling and cancellation of an appointment, shift closing, what to do if communication with the MIS is lost, and where to escalate.
• Instructions for doctors: working with the schedule, exporting reports, and offline appointment procedures in case the portal is unavailable.
• Environment configurations: service composition, exchange parameters, environment variables, secret storage locations, and their rotation procedure.
• Update and rollback regulations: rollout windows, criteria for returning to the previous build, and the role that makes this decision.

The package lives alongside the code: edits to the diagram and instructions are made in the same iterations as changes to the portal, so the document does not diverge from reality six months later.

We hand it over in a readable form—diagrams, text regulations, acceptance checklists—and conduct training on them.

Case Study: Booking Time Cut Threefold, Front Desk Load Dropped

A network of four branches came with a portal where booking went through a single form: the patient chose a specialty and left a phone number, and the front desk distributed requests manually.

Measurements before the work: 18% of patients booked independently, the rest went through a call; a registrar spent an average of 4 minutes per initial appointment, and during morning peak hours the portal's failure rate reached 11%—the form lost requests during traffic spikes.

What Was Changed

The schedule was moved into a separate service with its own storage and booking queue so that spikes would not block the form.

It was connected to the existing MIS Инфоклиника via two-way exchange: when a doctor closes an appointment window, it immediately disappears from the portal's output, and a booking from the patient account appears in the doctor's schedule without manual reconciliation.

Available windows began to be shown by branch and specific doctor, rather than by specialty as a whole, and rescheduling and cancellation without a call were added.

What Happened After

Booking time decreased from 4 minutes to 1 minute 20 seconds—threefold.

The share of independent bookings grew from 18% to 54%, the form's failure rate at peak dropped to 1.5%, and calls about standard questions ("is there a window," "reschedule my appointment") fell by about 40%.

The front desk switched to complex cases and repeat patients—the bottleneck shifted from request intake to working with bookings that require investigation.

Measurements were taken over comparable observation windows—two weeks before launch and two weeks after—so that seasonality in appointments would not blur the comparison.

Metrics are still being collected: time to window confirmation and the share of independent bookings are visible on a shared dashboard, so the next portal iteration is planned based on data, not feelings.

How Does a Portal Differ from a Clinic's Brochure Website and from an MIS?

A clinic's brochure website is a showcase: services, doctors, licenses, contacts. Booking here is usually reduced to a request form that goes to an administrator by email or into a spreadsheet—there is no schedule or patient data in such a system.

A portal is a service layer above the records system: it shows real appointment windows and provides a patient account with visit history, results, documents, and payment.

The key difference in functionality is where the source of truth lies. In an MIS (for example, 1С:Медицина), appointments, prescriptions, and signed documents are recorded: this is a records loop with legal significance and a narrow access circle.

The portal accesses this data but does not replace it—it gives the patient a copy, not the original.

That is why the website, booking, and patient account can comfortably live in one loop: a shared database, unified authorization, one domain. The portal and MIS are not combined in this way—the records loop is isolated, and communication goes through an integration layer.

Otherwise, external traffic and medical data end up in the same risk zone, and that already brings in the requirements of 152-FZ for the special category of personal data.

Common Technical Doubts: A Breakdown Before Start

The technical side of a clinic almost always comes with the same set of questions: how the portal will fit onto the existing records system, who will see what in the patient record, what will happen to the database during migration, and what will happen to booking if part of the infrastructure goes down. Below are the answers we give before start, so that this is not figured out at the launch stage.

These are not promises, but a description of how standard solutions are structured. If your configuration differs, we will analyze your case separately.

How is access rights differentiation handled?

Through roles with different data scope: a patient sees only their own documents, a doctor sees their own patients within the department, an administrator sees the schedule without clinical records. Every opening of a record goes into the audit log. The set of roles is changed by configuration, without code modifications.

How is patient data migrated?

We export records from the current system in a structured form, reconcile the number of records and key fields, and migrate in several passes. The previous system remains available for read access until reconciliation is complete—so rollback takes one step.

What happens to booking during a failure?

A slot is confirmed with a lock so that one cell does not go to two patients. If the primary segment is unavailable, booking moves to the backup, and an action that could not be performed immediately is queued. We verify the behavior with load tests, not just words.

How is patient data protected?

Encryption in transit and at rest, access via short-lived tokens, mandatory two-factor authentication for employees. Personal data does not go into analytics or external logs. Access differentiation and retention periods are fixed in policy.

Let's Discuss the Task: We'll Analyze Scenarios and Come Back with a Plan

We start the conversation with your scenarios, not with a template proposal: in a medical portal, almost everything is determined by how patient flows, doctor schedules, and rules for access to medical records are structured.

• Roles and scenarios: patient, doctor, front desk, clinic administrator—who performs which actions and what they see on the screen.
• Integrations: medical information system, laboratory, payment service, electronic document signature—what already works and in what mode exchange is available.
• Data and access: record composition, role rights, action log, retention periods, and requirements for personal data processing.
• Telemedicine: consultation schedule, cancellation and rescheduling window, appointment recording, behavior when the patient has a weak connection.
• Load: peak booking hours, seasonal spikes, number of simultaneous consultations, and headroom for growth.
• Constraints: what already exists on your side, who makes decisions, and which deadlines are critical for you.

In response, we send a staged work plan with acceptance points, a timeline estimate with buffer for integrations and approvals, team composition, and a list of risks that affect the schedule. Describe your task—we will come back with an estimate and a plan.