Electronic medical records and digital health operations for Nigerian practices.
Keeping the paper system going during an EMR rollout is sensible insurance for a few weeks and a slow failure after that. The difficulty is that nobody wants to be the person who removes the book.
Demonstrations show a system at its best. The questions that determine whether you will still be happy in three years are mostly about what happens after the sale, and they are rarely volunteered.
Rejected claims are rarely rejected for clinical reasons. They are rejected for missing authorisation, wrong enrolment details, late submission and incomplete documentation, all of which are process problems.
Inventory modules fail for a predictable reason: they require perfect data entry to give useful output, and busy staff cannot sustain perfection. The systems that survive are the ones designed around that.
Most practices have a backup. Far fewer have ever restored one. The gap between those two states is where clinics discover that their backup has been silently failing for months.
In a clinic where everyone knows everyone, shared logins feel practical. They also make it impossible to know who read a record, which is the one question that matters when something goes wrong.
Cloud systems are sold on being available anywhere. The question that matters in a Nigerian clinic is what happens during the hours when the power is out, the network is down, or both.
Most EMR projects that fail do not fail technically. They fail at the front desk, where staff quietly keep a parallel paper system because the training assumed a clinic that could pause.
The instinct when moving to an EMR is to bring everything across. That decision alone can double the cost and delay the launch by months, usually to digitise records nobody will open again.
The most useful hour in an EMR project happens before any vendor is contacted. Writing down what actually happens now, in order, exposes the problems that software will either solve or entrench.