A visit lasts fifteen minutes. For five of them, the doctor looks not at the patient but at the HIS screen: complaints, history, examination, diagnosis, prescriptions – all typed by hand. Whatever there is no time for gets written up after the shift, from memory. In case reviews at Kazakh clinics we consistently land on the same figure: 30–40% of a doctor's working time goes to documentation.
The other half of the problem surfaces later, once cases have already been submitted to the Social Health Insurance Fund. An expert finds a defect – no justification for hospitalization, a service code that diverges from the tariff schedule, a diagnosis that does not match the visit record – and the clinic is underpaid for work that was actually done. The two points are connected: charts are filled in a rush, defects pile up, the fund finds them. Let us look at how the AI platform breaks this chain.
Where a third of the visit goes
Documentation in a clinic is set up so that the same data is entered several times. An entry in the HIS. A paper form – form 025/u, consents, referrals. A discharge summary. If the patient brought results from an outside lab, someone transfers those into the system by hand too. Double entry surprises no one; people are used to it.
Then comes the arithmetic. Twenty visits a day, 8–12 minutes of documentation each, is three to four hours of typing every day. Examination templates help only in part: every case needs edits, and the boilerplate text itself turns into a defect when a fund expert sees identical examinations for different patients.
There is a third cost that is rarely counted: doctors finish charts in the evening, from memory. The quality of such records is lower, fatigue is higher, and it is precisely the evening charts that most often come back with remarks.
Why the fund does not pay for work that was actually done
A defect is almost never "treated poorly." It is "documented poorly." The typical set we see when going through the exports: a service was provided but not backed by a record; an ICD-10 code was entered out of habit and diverges from the text of the examination; in an inpatient case the justification for hospitalization is missing; a signature or date was lost when transferring from paper.
The main trouble is the moment of discovery. The quality of documentation becomes visible during the fund's review, weeks after the patient is discharged. It is too late to fix. The clinic loses payment for the case, defect statistics worsen its standing in monitoring, and instead of a "green zone" come the internal memos and explanatory notes.
A separate category of losses is resubmission. A case comes back, a statistician digs into it, the doctor recalls a visit from two weeks ago, the documents circle around for several days. All of this happens where a single check before sending could have been.
How a doctor fills in a chart by voice
A scenario from the prototype we set up for outpatient visits. The therapist conducts the visit as usual, only saying out loud what used to be typed: "cough for three days, temperature up to 38.2, throat hyperemic, harsh breathing, no wheezing." The platform sorts what was said into the structure of the chart: complaints separately, examination separately. From the text it proposes a diagnosis and an ICD-10 code – J20.9, acute bronchitis. Service codes are pulled in along with the diagnosis.
The doctor sees the finished record, edits one line, confirms – and the record goes to the HIS. The platform does not replace the medical system; it works on top of it: KMIS, Damumed, or another HIS stays in place. Where the system has an API, the integration is direct; where there is no API, the agent enters the data through the interface, using the same screens as a front-desk operator.
Speech is recognized in Kazakh and Russian at a native level, including the mixed speech that is normal during a visit. A paper form only needs to be photographed: a filled-in form 025/u is recognized and lands in the chart along with everything else. On the visit record this saves the doctor 50–70% of the time. Not "someday," but from the first day of the prototype.
How a case is checked before submission to the fund
Before sending, each case goes through a check against the fund's methodology. Not an abstract "quality assessment," but a concrete checklist: the diagnosis is stated and coded, services are justified by a record, signatures and dates are in place, and for inpatient cases the justification for hospitalization is filled in.
A mini-scenario from our demos. An inpatient case is being prepared for sending. The platform shows: 70% readiness, two remarks. The first – the justification for hospitalization is not filled in. The second – the service code does not match the tariff schedule and needs reconciling. Until the remarks are cleared, the case will not go out: sending opens after the corrections. The statistician sees exactly what to fix – instead of receiving, a month later, the wording "case rejected" with no details.
The check fires as an event: the case is closed, the process starts on its own. No one has to remember it or launch it with a button.
The checklist does not stand still, either: when the fund updates its methodology, the check rules are updated centrally on the platform – no notices on the staff-room wall, no retraining of personnel.
The quality traffic light: what the head doctor sees
Once a week the platform assembles a snapshot across the clinic: how many cases are correct, where the errors are, which department is in the green zone and which is at risk. Therapy – 98%. Surgery – 91%. Cardiology – 84% and fourteen remarks: worth a visit before the fund takes a look. No one prepares these figures by hand – the traffic light is built from the same checks every case passes through.
For the head doctor this is a change of optics: instead of dissecting rejections after the fact – a short list of the points where risk is accumulating right now. The conversation with the department head starts not with "why was our payment withdrawn" but with "we have a week to close fourteen remarks."
A telling detail from one of the reviews: the clinic was holding confidently in the green zone, but the admissions department was dragging it down – a couple dozen documentation errors a week. Everyone was watching the treatment departments, while the point of loss was at the entrance.
| Stage | The usual way | With the platform |
|---|---|---|
| Visit record | 8–12 minutes of typing into the HIS | 2–4 minutes: voice and confirmation |
| ICD-10 and service codes | selected by hand | proposed from the visit record |
| Paper forms | transferred into the system by hand | photo of form 025/u – recognized |
| Case check | during the fund's review, after the fact | before submission, with concrete remarks |
| Quality picture | assembled for the meeting | a traffic light by department once a week |
What this gives you in money
Effect per month = returned doctor-hours × cost per hour + cases paid by the fund without defects
Let us plug in cautious figures. A clinic with 30 doctors, each with about two hours of documentation a day, and the platform removes at least half – around 600 hours a month returned to visits. The second part is calculated from your own statistics: the share of defective cases and the average value of a case. If, out of a thousand cases a month, the fund used to withdraw payment on three percent, and now it is under one – the difference shows up in revenue within the first quarter.
In reviews the second part of the effect more often turns out to be larger than the first. Underpaid amounts are more noticeable than they seem before the count – they are simply spread across months and departments.
For an honest calculation, three figures from your own reporting are enough: cases per month, the share of defective ones, and the average tariff. We build this model together with the clinic's economist right there in the review.
What about the security of medical data
The first question at every demo – and rightly so. Medical data is processed inside the clinic's perimeter and does not leave it. Access is separated by roles: the front desk does not see what is available to the head doctor. Every action of the platform is written to a log – who did what and when with a record, and it can be pulled up in any audit. We covered the security model in detail in the article on data inside the perimeter.
Where a clinic should start
We start not with a contract but with a prototype. You provide de-identified examples – a few visit records, a couple of case exports – and in about a week we tune the platform to your HIS and your forms. Doctors try voice recording on real visits, the statistician looks at the case check. This is free and commits you to nothing.
If the economics add up, a production rollout takes from eight weeks: integration, permissions, staff training. After that – a subscription, with no capital development. The details of the solution are gathered on the AI for medicine page, and you can arrange a demo through contacts.
Frequently asked questions
Will the platform replace our HIS?
No. The platform is an add-on: it prepares charts, codes, and checks, but the record still lives in your HIS. The connection is via API, and for systems without an API – through the interface, the way an employee would work.
The doctors will not want to dictate – what then?
That is exactly what the prototype before rollout is for: the doctor tries it on their own visits and compares for themselves. The argument is usually a single one – minus 50–70% of the time on the record. The platform does not add steps for the doctor, it removes them.
How long does the launch take?
The prototype – about a week, free. A production rollout – from eight weeks depending on the HIS and the set of scenarios. The payment model is a subscription; we work out the configuration after reviewing the clinic's processes.