# A Level 4 Hospital Moving Off Paper Records

> A 60-bed county facility running paper registers and one much-loved Excel workbook. What the sequencing looked like, and the week that went badly.

Source: https://www.afyaconnect.africa/case-studies/level-4-hospital-paper-to-hms
Publisher: AfyaConnect HMS (Neurobyte Technologies), Nairobi, Kenya

---

*Level 4 hospital, ~60 beds · Central Kenya*

> **Disclosure:** This is an anonymised, composite account drawn from deployments of this type. The facility is not named because we do not have permission to name it, and no performance percentages are quoted because we have not measured them. What is described here is the change in how the work is done, which is the part we can stand behind.

## Where they started

Outpatient registration in a hardback register. Inpatient notes in paper files retrieved from a records room by a clerk who knew the shelving system by memory and was, correctly, treated as indispensable. Billing in an Excel workbook maintained by one person in the finance office. The pharmacy had its own till and its own book. Claims were assembled at month-end by a clerk working from the paper files.

Nothing about this was unusual and none of it was anybody's fault. It is what a facility of this size builds when it grows faster than its systems.

The problems were the predictable ones. Files went missing — not often, but often enough that a clinic occasionally ran without notes. Claims were assembled weeks after the encounter by someone who had not been there, which is the single largest driver of rejections. And nobody could answer a question like "how many admissions last quarter" without a person spending a day counting.

## What we did first

Not the clinical record. Registration and billing.

This is counter-intuitive and it is the right order. Going live on clinical notes first means asking clinicians to change how they work before the system has done anything for them, and you lose the room. Registration and billing produce a visible benefit in week one — the queue moves, the bill is right — and buy the goodwill you will need later.

**Weeks 1–2.** Registration, outpatient queue, billing with M-Pesa. Demographics for active patients imported from the register. Duplicate detection flagged around a hundred probable duplicates for a human to review rather than auto-merging them, which is the only safe way to do it.

**Weeks 3–4.** Pharmacy. Stock take on a Sunday, opening balances entered, barcode POS live on Monday.

**Weeks 5–7.** Clinical records for outpatient, then admissions and wards. By this point staff had been using the system daily for a month and it was no longer strange.

**Week 8.** Claims from the clinical record rather than from the paper file.

## The week that went badly

Week 3. The pharmacy stock take was done from the existing stock book rather than by counting, because counting is tedious and the book was believed to be accurate. It was not. Within four days the system's stock figures disagreed with the shelves, staff concluded the system was wrong, and confidence took a fortnight to recover.

The lesson is dull and worth repeating: **take opening balances by counting, not from the book you are replacing.** If the book were accurate you would not be replacing it.

## What changed structurally

- The claim is built from the encounter, by the system, with the diagnosis the clinician actually recorded. It is no longer assembled at month-end by someone reading a file.
- Eligibility is verified at the desk, before the service, rather than discovered at rejection.
- The records clerk's knowledge is no longer a single point of failure.
- "How many admissions last quarter" is a screen, not a project.
- The Excel workbook still exists. Finance keeps it for one report we have not replaced yet, and we would rather say that than pretend otherwise.

## What we would do differently

Migrate less history. We brought across more historical outpatient data than anyone subsequently used, which cost a week of clerical time and returned nothing. Demographics and active problems are almost always enough; the paper archive can stay an archive.

## Questions this raises

### How long does it take to move a level 4 hospital off paper?

Eight weeks is a realistic figure for a facility of this size with pharmacy, wards and claims, going live module by module rather than all at once. Compressing it below about four weeks tends to fail — not because the software takes that long to configure, but because staff cannot absorb that much change at once and revert to paper under pressure.

### Should we go live on everything at once or module by module?

Module by module, and start with registration and billing rather than clinical notes. A phased go-live gives staff a visible win before you ask them to change how they document care, and it means a problem in one module does not stop the whole facility. Big-bang go-lives are how facilities end up running paper and software in parallel for six months.

### What happens to our paper records?

In most deployments they stay as an archive. Demographics and active problems for current patients are entered; historical notes are retained on paper and consulted when needed. Retyping years of historical notes costs far more clerical time than it returns, and we would talk you out of it.

---

**Author:** The AfyaConnect Clinical & Product Team — Health systems and product engineering, Neurobyte Technologies

The team that builds and supports AfyaConnect writes these guides. Everything here is written against software we actually ship and support in live Kenyan facilities — the SHA claims flow, the PPB controlled substances register and the eTIMS invoicing described in these guides are modules we maintain, not features we read about. Where regulation is still moving, we say so rather than guessing.

- Supports 40+ healthcare facilities across Kenya and East Africa
- Builds and maintains the SHA/NHIF claims, PPB register and KRA eTIMS modules described in these guides
- Works to the Kenya Data Protection Act 2019 and Digital Health Act 2023 requirements for patient data
