Ten years building healthcare software in the Philippines, and the lesson that stuck this year had nothing to do with code.
A clinic we work with downloaded a batch of files our software had already generated and sent to the government. Then they tried to upload those same files back into our software.
Over and over.
They were sure it would flip a status in our own software and shake loose a payment they were owed. (For the record, that confusing status is ours to fix, not anyone else’s. We’ll do a better job with our messaging to make that clear.)
It does nothing. It is not a step in any process. They did it anyway, because no one would tell them why they had not been paid, and pressing a button felt better than sitting still.
I have thought about that clinic more than any bug we shipped this year. It is what building on top of a government system, in the middle of a national reform, looks like from the ground.
Here is the setup. The Philippines is rolling out one of the biggest healthcare reforms in a generation, a new primary care benefit that gives ordinary Filipinos free consults, medicines, and lab tests, and pays clinics for each patient they enroll. We are one of the certified vendors wiring clinics into it. The mission is good. The day to day is something else.
You learn the rules by breaking them
Picture a form whose instructions are inconsistent, outdated, or missing entirely. What you can find does not tell you a field’s limit, which ones are required, or what date format it wants. You submit, the server rejects it, and that rejection is the most useful documentation you get. You change one thing, submit again, and reverse-engineer your own rulebook on top of the one you were given.
Migrations are worse. Move a clinic off the old government software and its export comes out in a shape the new system will not take. An afternoon of work becomes a week. I have written before about what it takes to build integrations, and this is that problem with a deadline and someone’s payroll attached.
No two offices answer the same way
The part that broke me a little: the rules are not applied the same way twice. One clinic keeps doing something the old way and gets paid. Another does the exact same thing, in a different region, and gets nothing, with no note explaining the gap. Same action, two outcomes, decided by whichever office happened to process it.
When that is the terrain, there is no rule you can hand anyone. There is only “it depends,” and you learn which one you got after the money either lands or does not.
Our hands are tied
My team spends real hours on this. They fix what they can reach and stay on the line with clinics through the mess. But most of what breaks lives behind a wall we do not have keys to. And when a payment is short, the frustration lands on whoever the clinic can reach, which is usually us.
I assumed that as a certified vendor we would have a priority line, somewhere to get a straight answer when a clinic’s numbers do not add up. There is not really one that works like that, and I do not think it is for lack of people. I just do not know why. I would change my mind the day someone shows me the door I have been missing.
The part that feels unfair
When a clinic is not paid for some patients, they are usually not told why. Just a smaller number than they expected. No reason, no line item. And when they ask, the answer is some version of “ask your vendor.”
That is why the clinic re-uploading its own files makes a sad kind of sense. Some of these places run on that money. A few have taken out loans against payments they were promised and have not received. When the only official answer is silence, you start pressing every button in reach.
And yet, I get it
I could stay angry about this. I mostly do not, for two reasons it took me a while to reach.
The scale is enormous. One program across 17 regions and hundreds of local offices, each with its own people and its own read of the rules. Someone from a regional office walks into a clinic and says something with total confidence that the head office never actually said, because the message never reached them whole. That is not malice. It is what a huge institution moving fast looks like from the floor.
And some of the vagueness might be deliberate. The system tightened after people gamed it, ghost patients, rosters padded with names that never walked in. I cannot prove the opacity is on purpose. But the logic holds. Publish the exact rules, and the people gaming them optimize against those rules too. The honest clinics pay for the dishonest ones, in confusion and delay.
So we document
We write down what the rejections teach us. We adapt. We build buffers so the clinic feels as little of this as possible, and we absorb blame we did not earn.
This is the least glamorous version of a thing I have argued for years, that the internal systems you invest in quietly end up being the product.
If you want to see the thing we built for it, it is our SeriousMD YAKAP module. And if you run a clinic that is living this rather than building it, I wrote the practical version there too, on why a SAP 1 comes up short and what to check first.
What I keep wishing for is small and boring. Rules that are actually written down. A reason attached to every rejection. A real vendor support line where we can get useful replies. Not to embarrass anyone. Because when this works, a Filipino who could not afford care gets it, and a clinic gets paid for showing up.
I am still working out how you settle into a system that is being written while you build on it. If you work on one too, I would like to hear how you handle it.
