A clinic without a single paper chart: digitising Zamanmed in Aravan

What it looked like day to day

• Appointments went into a notebook. The administrator wrote patients in by hand. Working out whether a doctor had a free slot meant leafing through pages.
• Patient charts lived in paper folders. Finding one meant physically finding it on a shelf. A lost folder meant a lost history.
• Case history came from what the patient said. On a repeat visit the doctor relied on the person's account and on old prescriptions they had brought along — if they had brought them.
• Doctor output and revenue were counted from ledgers and tickets. Somebody totalled up visits and services by hand to produce figures for a period.
• A patient who did not show up simply vanished. No record of the no-show was left, and there was nobody and nothing to bring them back with.
• Reports were assembled by hand in spreadsheets. From scratch each time, for whatever management had asked.

Note the important part: the problem was not that the clinic worked badly. Doctors saw patients, patients got treated, the clinic earned. The problem was that every piece of information existed in exactly one copy and in an awkward form. A paper chart is only ever in one place. A notebook is visible only to whoever is standing next to it. A report exists only while somebody is sitting there assembling it.

What triggered the change

The stated reason was reporting: pulling data together by hand ate time and still left management without a current picture.

But the real reason was different — a deliberate decision by the owner to move onto digital records. Nobody forced the clinic. There was no inspection, no incident, no dispute with a patient. The owner simply decided that a medical practice in the 2020s should run in a system rather than in a notebook, and got in touch with us.

That is a rare and, frankly, the best kind of client: when the decision comes from inside rather than being imposed from outside, an implementation goes completely differently — management does not quietly resist the change, it helps push it through.

Booking and scheduling

A schedule in the system replaced the notebook. The administrator sees which doctors and rooms are busy, books a patient into a free slot and cannot accidentally put two people in the same one. Booking information is available to every member of staff at once, not only to whoever is holding the notebook.

A patient who does not turn up no longer disappears without trace: the visit stays in the system with its own status, and there is something to work with afterwards.

Electronic medical records

The core of the project. Every patient got an electronic record holding their visit history, prescriptions and consultation outcomes.

The change sounds simple and it alters the doctor's work entirely: on a repeat visit the history opens on screen instead of being reconstructed from the patient's account and creased paperwork out of their bag. The doctor can see what was prescribed before, how the patient responded to treatment and what happened at previous consultations.

Consultation templates

The most labour-intensive part of the implementation. A consultation template is the structure a doctor uses to record the examination, the diagnosis and the prescriptions. Universal templates do not exist: every speciality has its own logic and every doctor their own habits of phrasing.

We went through with each doctor how they genuinely describe a consultation, and turned that into templates that fill in quickly rather than taking longer than writing by hand. That stage, together with the training, took the bulk of the two-month timeline.

The dental module

For the dental surgery we configured a dedicated module built around an odontogram — an interactive tooth chart on which the condition, completed treatment and planned treatment are marked for each tooth.

This is where a purpose-built medical system shows its advantage: a general-purpose CRM cannot cover this task at all, and without it a dentist ends up drawing the chart by hand in a paper record.

Inpatient care

The clinic runs a full inpatient ward, and that moved into the system too. The module holds the list of admitted patients, admission durations, the ward and room assignment, the attending doctor, prescriptions and case comments, the case history and the visit history. A separate report covers inpatient activity over a period.

Before the implementation this information lived on paper and in people's heads. Now the current state of the ward — who is admitted, in which room, who is managing the case and what has been prescribed — is visible in the system at any moment, without walking into the department and without cross-checking paper ledgers.

Finance, payroll and consolidated reporting

We configured doctor payroll based on services actually delivered, plus consolidated clinic reporting. Management gets the picture on revenue, consultations and utilisation without merging ledgers and tickets by hand.

Reporting that used to be assembled manually for every request is now produced from data the system accumulates in the course of ordinary work.

Referral tracking

A significant share of patients at clinics in Kyrgyzstan arrive on a partner's recommendation, and that channel is usually tracked by hand or not tracked at all.

iWeb configured the referral module: the system records who sent the patient, accumulates statistics for each partner and produces a summary for settlements. This data used to be gathered from ledgers and the administrators' memory — now the report comes out of the system. The setup follows the clinic's own requirements and internal rules.

The practical value for management is simple: it becomes visible which acquisition channel actually works and which one exists only in conversation.

The loyalty programme

We set up a patient loyalty programme — a retention tool that, in a small clinic, works better than chasing new arrivals. A regular patient comes back on their own if there is a clear reason to.

Messaging with patients

We connected the WhatsApp integration: administrators message patients from inside the system rather than from a personal phone. That solves two problems at once — work conversations stop leaking into private accounts, and the history of communication with a patient stays with the clinic when an administrator leaves.

The patient app and the website

Patients got access to the app included with the platform: booking, visit history and prescriptions are available from a phone.

Separately, iWeb built the clinic website with online booking. A patient books from the site and the request lands in the shared schedule — with no phone call and no administrator involved at the first step.

First reason: this is patient personal data

A clinic's database is not an online store's customer list. It holds information about people who sought medical care. The very fact that someone attended a clinic belongs to what a person entrusts to that institution, not to what they hand over for marketing use.

A patient who came in for a consultation never consented to receiving promotional messages. Using the database for a campaign means using data for a purpose other than the one the person supplied it for.

Second reason: the industry has already learned this the hard way

This is not a theoretical argument. In the practice of implementations like this there was a period when access to the database made such campaigns technically possible. The outcome was predictable: patients who did not want those messages started complaining. The complaints led to investigations and to clinics risking having their accounts blocked.

So even on purely pragmatic grounds — leaving ethics aside entirely — messaging a medical database creates more problems for a clinic than it brings patients. Platform policy does not support these scenarios, and that is a correct restriction rather than a shortcoming.

Doctors used to a word processor

The hardest part of the project. For years the doctors had written notes in an ordinary word processor: a blank page, complete freedom of phrasing, their own familiar templates in their own files.

A medical system is built differently. It is structured: a consultation record has fields, a diagnosis has a classifier, a prescription has its own place. For the system that structure is a necessity — only structured data can later be found, counted and put into a report. For a doctor it initially looks like a loss of freedom.

There turned out to be only one workable answer: one-to-one training with every doctor. Not a general lecture, but working through each person's speciality, their phrasing and their typical consultation, then tuning templates so that filling one in takes less time than the old routine in a word processor. Until a doctor sees that the new way is faster, they will keep drifting back to the old one.

Consultation templates took longer than we expected

A related task. A template cannot be taken off the shelf — it has to reflect how a specific doctor describes a consultation. Otherwise the doctor fights the form instead of working in it.

We budgeted less time for this than it actually took. We now plan the template and training stage separately and warn clients in advance: this is not technical configuration, it is joint work with the doctors, and it does not go faster by the contractor adding more people.

Two months, and our first project of this kind

Plainly: this was our first clinic information system implementation, and the project took about two months. Part of that time went on getting to grips with the logic of medical record-keeping ourselves — it is built differently from record-keeping in retail or hospitality.

The experience was worth it. We walked the path from paper folders to a working system alongside the clinic, and we now know where the real difficulty in such a project sits: not in installing the platform, but in the templates and in the people.