Thirty fields, one insurer portal, zero API

Salam Health is a hospital information system for dialysis — nurses, treatment forms, inventory, accounting, fifteen centers across the province. Most of that we built properly: APIs, PostgreSQL, offline sync where connectivity was bad.

Insurance claims were the weekly morale hit. The clinical record was accurate. The national insurer's web portal wanted the same information again — thirty-plus fields per claim — entered by hand. One claim could eat most of a day. Multiply that across centers and you are paying nurses to be data entry clerks.

The insurer had a portal, not an API

We asked about integration. Proper EDI or a stable API would have taken quarters we did not have, if it happened at all. The portal worked. Humans could submit claims through it. It was just slow, repetitive, and exactly the kind of task that rots when smart people have to do it under deadline pressure.

So we used Puppeteer. Not because it is elegant. Because our backend already had the claim payload and the portal was the only door.

What we built

We mapped HIS entities to form fields once, with validation before anything hit the queue. Headless sessions filled and submitted claims in batch. Every run logged success or failure per claim so staff could pick up exceptions manually instead of guessing what the bot did overnight.

We did not pretend the portal was deterministic. Edge cases went to humans on purpose. The goal was to remove the ninety percent that was pure repetition.

Standard-path processing dropped from about a week to about a day. That is the number people remember. The operational change was simpler: nurses went back to patient work.

Living with Puppeteer in production

Portals change. Selectors break. We treated the scripts like production code — versioned, monitored, owned by engineering, not a one-off on someone's laptop. It is technical debt you choose consciously when the alternative is manual labor at fifteen sites.

I would still make the same call given the same constraints. Clean internal data and a hostile external UI is a bad place to add headcount.