Despite auto-scan, ≈70% of supplementary insurers were still entered by hand
1 · First ship: scanning instead of typing
I created and owned the design epic, along with the epic for the supplementary-insurer directory that serves as its data foundation.
Practitioners typed their patients' supplementary-insurance details by hand: insurer identifier, agreement type, a secondary reimbursement criterion. One wrong field was enough to get an invoice rejected several days later. Two documented factors made it worse. Additions and changes run ≈1.6× higher in the first quarter than the rest of the year, because contracts renew annually. And the number of supplementary insurers has been divided by more than 3 in about fifteen years through mergers, so patients' cards change often, without the practitioner being told.
The challenge
How do you remove manual entry of complex administrative data, without asking practitioners to understand the technical mechanics underneath?
We read the two-dimensional barcode printed on third-party payment cards and pre-filled the administrative fields, from two entry points: the phone camera, scanning the physical card, and a document already in the patient record, where the code is detected without re-importing anything. The practitioner keeps a single check: the coverage period, the one piece of data the barcode doesn't guarantee.
The second entry point looked secondary during research. It turned out to be frequent in use: the “lazy” paths, the ones that save the user an extra action, are often the ones that get adopted.
2 · The measure that changed the brief
After the scan shipped, ≈70% of supplementary insurers were still entered manually. Manual entry was declining, but slowly: ≈8 points in 15 months. Behaviour was changing over years, not quarters. At the same time, documents shared by patients had grown by an order of magnitude in ≈2.5 years, yet only ≈2% were used to create a supplementary-insurer record.
The feature worked. The problem had moved: it was no longer about entry, it was about discoverability and habit.
3 · Second ship: fixing it from the invoice
I owned the design ticket tied to the product epic, and widened its scope from “add a supplementary insurer from the invoice” to unifying supplementary-insurer editing across the whole product, plus groundwork on managing coverage during billing.
A practitioner facing expired coverage had to leave the invoice mid-flow, open an administrative tab, add the card, then come back. Practitioner interviews pointed the same way: one described losing time because adding an insurer opened an administrative screen outside the billing flow; another wanted to reuse the last document the patient had shared when booking. The project was timed to ship before the year-end period, when coverage changes en masse.
The challenge
How do you let a practitioner add or update a supplementary insurer without leaving their invoice, while addressing a broader discoverability and habit problem?
Kept, after RICE scoring
An “Add supplementary insurer” action inside the billing modal, selecting another insurer for a prior period, a selector on the administrative screen, grouping add actions in one place, and a banner pointing to the auto-scan feature.
Dropped
Forcing a supplementary insurer onto a past invoice, and in-flow scanning from a phone.
4 · Outcome
Observed: the auto-scan shipped, and its adoption stayed slow — ≈70% manual entry after launch, down ≈8 points in 15 months.
The add-from-invoice feature shipped; its post-launch results aren't documented in this portfolio. Targets: more insurers added from the billing flow, less manual entry, and higher satisfaction among practitioners who use supplementary third-party payment.
5 · Learnings
Practitioners don't want to understand the reading technology; they want it to work. So the scan's failure message deserves as much care as its success screen: it decides whether the user tries again or goes back to typing.
Adoption of a good feature follows a slower rhythm than its shipping. Watching ≈70% manual entry persist despite a faster alternative forced a rethink: it stopped being a feature problem and became a discoverability and habit problem.