Practices and provider groups
Where the administrative load has grown past what the practice management system covers, and the gap is being filled by people and spreadsheets.
Healthcare
Healthcare software, built by people who know the workflow.
Claims and billing tooling, reconciliation, data exchange, dashboards and portals — the operational software a healthcare organisation actually runs on. This is the deepest area of our practice.
Why this work is different.
Healthcare software differs from ordinary business software in four ways, and none of them is technical difficulty. The workflows are regulated, so the system has to record not only what happened but that it was permitted to happen. The data is sensitive, so who can see what is a constraint on the design rather than a setting configured afterwards. The file formats are unforgiving, and a file that is very slightly wrong is rejected in a way that is easy to miss. And the cost of a quiet failure is somebody's money or somebody's care.
That last point is the one most often missed. A marketing site that breaks is embarrassing for an afternoon. A remittance file imported twice, or a batch that fails at three in the morning without telling anybody, is a fortnight of reconciliation and a genuine hole in a real ledger. Software for this work has to fail loudly, keep a record of what it did, and make the failure recoverable by somebody who was not there when it happened.
So the questions we ask early are not about screens. They are about what happens to a claim that is partially paid, who is allowed to write off a balance and whether that is recorded, what the system does when the clearinghouse is unreachable, and how you would prove six months from now that a particular adjustment was made by a particular person for a stated reason.
The claim lifecycle
What we build
What we build for healthcare organisations.
Described as capability areas rather than case studies. If you want to know whether we have solved a problem shaped like yours, ask and we will tell you plainly.
Revenue cycle and claims tooling
Claim submission, remittance processing, payment posting and denial tracking, and the reconciliation that ties the four together. Built as one connected process, because that is what it is, rather than four screens that each know a quarter of the story.
Financial reconciliation
Matching bank deposits to remittance files, surfacing the differences, and turning them into an exception queue somebody can work through. Variance reporting that says what is unmatched, by how much, and since when.
Interoperability and data exchange
Moving clinical and administrative data between systems in the formats those systems expect — message-based and API-based, inbound and outbound, with validation and error handling that does not swallow problems quietly.
Dashboards and operational reporting
Turning transactional data into something an operations lead can act on this morning: ageing, denial rates by reason, throughput, backlog. Every number traceable back to the rows it came from, because the first question anybody asks a dashboard is "where did that come from".
Patient- and staff-facing portals
Scheduling, intake, document exchange and communication. Designed for people who are stressed, in a hurry, on a phone, and not necessarily confident with software.
Integration work
Connecting practice management systems, clearinghouses and third-party services through their APIs — including the ones with incomplete documentation, undocumented rate limits and sandbox environments that behave differently from production.
AI applied to healthcare operations
Reading and structuring unstructured documents. Classifying and routing exceptions and denials by likely cause. Drafting correspondence and appeal letters for a person to review and send. Summarising long transaction histories into something an operations lead can act on. Each of these reduces manual review time, with a person approving the outcome. None of them decides anything on its own.
Formats and standards
What we work with, and what each one is.
The plain-English column is there on purpose. If you already know these, you know what we can do. If you do not, you should still be able to follow a conversation about your own systems.
- HL7 v2
- FHIR
- X12 837
- 835
- 270 / 271
- 276 / 277
- CMS-1500
- ICD-10
- CPT
- NPI
- HL7 v2
- The long-standing messaging standard hospitals, labs and practice systems use to tell each other that something happened — an admission, an order, a result. Pipe-delimited, venerable, and still everywhere.
- FHIR
- The modern standard for the same job, built as a web API. Resources over HTTP, usually JSON. Far easier to build against, and increasingly what newer systems expect.
- X12 837
- The claim itself. The electronic file a provider sends to a payer to ask to be paid, in professional, institutional and dental variants.
- 835
- The answer. Electronic remittance advice: what was paid, what was not, what was adjusted, and the reason codes explaining why. This is the file that has to reconcile against the money that actually arrived.
- 270 / 271
- Eligibility. A question to a payer about whether a patient is covered and for what, and the payer's reply. Asked before the visit if anybody is paying attention.
- 276 / 277
- Claim status. Asking a payer what has become of a claim already sent, and the reply. The difference between chasing by phone and knowing.
- CMS-1500
- The paper professional claim form. Still required in places, and still a layout that has to be produced exactly, down to the field positions.
- ICD-10
- Diagnosis codes. What the patient was treated for.
- CPT
- Procedure codes. What was actually done. Maintained by the American Medical Association and licensed accordingly.
- NPI
- The national provider identifier. The number that identifies a provider or organisation, and that a great deal of everything else is keyed to.
Automation
The document work that consumes a billing team's day.
A large part of healthcare back-office work is reading something, deciding where it goes, and typing it somewhere else. It is slow, it is repetitive, it scales only by hiring, and it is well suited to being done by software with a person checking the results.
We build agents for these tasks: ordinary programs with a language model inside them, given a narrow job, a fixed set of tools, and a complete log of everything they did. Work that occupies a person for hours frequently completes in minutes, and the team moves from working the whole pile to reviewing the exceptions.
Remittance and EOB reading
Explanations of benefit that arrive as PDFs and scans rather than as an 835, turned into structured lines your system can post.
Denial triage
Denials sorted by reason code, grouped by likely cause, and routed to the worklist and the person who can actually resolve them.
Appeal drafting
A first draft assembled from the denial reason, the claim and your own templates, for a biller to check, correct and send. The biller keeps the authority; the typing goes away.
Intake and referral documents
Faxes, scans and attachments read for the fields you need, with anything the agent is unsure about flagged for a person rather than guessed.
Pre-submission checks
Claims checked against payer-specific rules before they go out, so the rejection happens on your screen in a way you can fix rather than three weeks later in a file.
Answers from your own policy material
Staff questions answered from your payer policies, manuals and past cases, with a citation back to the source so the answer can be verified.
How we keep this safe
- A person reviews anything that moves money, changes a record of consequence, or goes out to a patient or a payer. The agent does the work; a person keeps the authority.
- No protected health information goes to a third-party model without the appropriate agreement in place. Where that is not available, the work runs on infrastructure you control, or it does not run.
- Accuracy is measured against a set of cases with known answers before anything is switched on, and again whenever a model or a prompt changes. You see the failures, not just the successes.
- Every run is logged in full — what came in, what the agent did, what it produced — so any individual item can be explained months later.
- Deterministic code does the parts that do not need judgement, because a rule is cheaper, faster and behaves identically every time.
- We build administrative and operational software. Clinical judgement — diagnosis, treatment, triage of a patient rather than a document — stays with clinicians.
Sensitive data
How we handle sensitive data.
These are engineering practices, described plainly. They are things we do, not badges we hold.
Least-privilege access
People and services get the narrowest access that lets them do their job. Enforced on the server, where the data is, not by hiding buttons.
Encryption in transit and at rest
TLS for everything on the wire. Encrypted storage and encrypted backups, with key management that does not depend on anybody remembering.
Audit logging
Access and changes recorded with who, what, when and the prior value. Written from the start of the build rather than added when somebody asks.
Environment separation
Development, staging and production genuinely separate — separate credentials, separate data, no shared accounts.
Synthetic data in development
Development and testing run on generated data that has the shape of the real thing and none of the content.
No production data on developer machines
Not for debugging, not for a quick check, not temporarily. If a problem can only be reproduced with real data, it is reproduced in a controlled environment with access recorded.
Built to support your BAA obligations
Designed so that you can meet the commitments you have made: restricted access, recorded activity, defined retention and disposal, and a clear account of which subprocessor touches what.
AI and sensitive data
Model providers are chosen on whether they will sign a BAA and on their data-retention terms, not on how they score on a benchmark. Data is de-identified or minimised before it reaches a model wherever the task allows it. No client data is used to train anybody's model. Every model call is logged for audit. And you decide what may leave your environment — that is not a vendor's decision to make on your behalf.
What we do not claim
There is no such thing as a HIPAA-certified vendor. Anybody who tells you otherwise is selling something. We do not hold SOC 2 or ISO 27001, we are not FDA cleared, and we will not imply any of it. What we offer is engineering practice designed for auditability, and enough candour that you can assess it yourself or have your compliance people assess it for you.
Who this is for
Who we work with.
Billing companies
Where margin is a function of how many claims one person can work in a day, and the tooling decides that number.
Healthcare technology teams
Where you have a product and need senior people who already understand the domain, rather than developers who need six months to learn what an 835 is.
Operations groups that have outgrown spreadsheets
Where a workbook that one person maintains has quietly become critical infrastructure, and everybody knows it.
If you can describe the problem, we can tell you whether we are the right firm.
A first conversation is usually twenty minutes and costs nothing. Bring the workflow that is causing trouble. Please do not send patient information.