AI agents and LLM features
Applied to work people currently do by hand: reading documents, sorting queues, drafting replies. Built into the software you already run, with a person approving anything that matters.
Services
Healthcare product engineering.
The same engineering as anywhere else on this site, done by someone who already understands the domain. This page is about how the work is done. The domain itself is covered in depth on the healthcare page.
Where this usually starts
You are building or running healthcare software, and the risk is not in the code you can see. It is in the things that look like details until they are not — and in the fact that the vendor you are paying is learning them at your expense, on your timeline, with your money.
What this is
Most of the risk in healthcare software sits in details a general-purpose agency does not know exist. That a file which parses cleanly can still be wrong, and will be rejected days later by something that does not explain itself. That reconciliation has to balance, and "close enough" is not a state a ledger can be in. That an audit trail is not a feature request to be prioritised against others. That "we'll just store it" is a decision with legal weight, taken in an afternoon by somebody who did not know that is what they were deciding.
We start from that understanding. In practice this means the questions we ask in week one are different: what happens to a partially paid claim, who may write off a balance and where that is recorded, what the system does when the clearinghouse is unreachable for a day, and how you would demonstrate six months from now that a particular adjustment was made by a particular person for a stated reason. The answers shape the architecture, which is why they are asked before it is fixed.
How we approach it
What we think doing this well requires.
A file that parses is not a file that is correct
Structural validity is the easy half. We validate against what the content is supposed to mean, and we surface the difference rather than letting a well-formed but wrong file proceed quietly to a payer.
Reconciliation has to balance
If the deposit and the remittance disagree, that is not a rounding issue to be smoothed over. It becomes an exception with a value, an age and somebody responsible for it.
The audit trail is not a feature request
It is part of the data model from the first commit, because it cannot be added convincingly afterwards. A trail that starts the day somebody asked for one answers no useful question about the period before it.
Failure has to be loud
A batch that fails at three in the morning and tells nobody is worse than one that never ran. Every automated step reports success as well as failure, and somebody is told when the report does not arrive.
Synthetic data by default
Development and testing run on generated data with the shape of the real thing and none of the content. Production data does not go on developer machines — not for debugging, not for a quick check, not temporarily.
Written so your compliance people can read it
Data flows, retention, who can see what and which subprocessor touches which data, documented in a form you can hand to somebody whose job is to ask about it. That document is a deliverable.
What you get
Everything on this list is a deliverable, not an extra.
- Everything in the web application list — data model, designs, source, environments, migrations, runbook
- A written data-handling note covering flows, retention and access, for your compliance review
- Validation and error handling specified per interface, including what happens on a bad file
- Synthetic data generators, so your team can test without touching production data
- An audit model, documented, including what is recorded and for how long
- Documentation and handover to whoever maintains it next
Fit
Whether this is us.
Most unhappy projects were mis-scoped at the start rather than badly built. It costs nothing to be straight about this now, and it saves us both a call.
Best suited to
- You have a healthcare product and need engineers who do not have to be taught what an 835 is before they can be useful
- Your current vendor is learning the domain on your budget, and you can see it in the questions they ask
- A manual billing or operations process is being turned into something systematic
- You need somebody who will tell your board which parts are genuinely risky, in language the board can act on
Probably not us if
- You need your vendor to hold a HIPAA certification. There is no such thing, and a firm that offers you one is telling you something untrue on the first call
- You want clinical decision support, diagnosis, or anything that makes a care decision. We build administrative and operational software, and that line does not move
- The engagement requires production patient data on developer machines. We will not do that, and there is no version of the schedule that changes it
Related
Next to this.
Web applications and internal tools
The system your operation actually runs on, replacing the spreadsheet three people keep their own copy of. The process stops depending on who remembers the exceptions.
Healthcare software
Where this work goes deepest: claims and billing workflows, data exchange, reconciliation, audit trails and the formats healthcare actually runs on.
Tell us what you are trying to build.
Describe the problem in your own words. If we are not the right firm for it, we will say so.