The rail
Two worlds.
One line.
Your patients carry public cover, private cover, sometimes both. One connection gives you access to both the private and public sector worlds. Eligibility, consent, benefit coordination and the whole revenue cycle ride the same rail — and stop being yours to hold.
- 00AuthenticateGet your system onto the rail
access token - 01IdentifyResolve who is at the desk, with consent
unique_patient_id - 02Verify coverFind what they are covered for, here, today
selection_ref - 03ConsentProve they were present and willing
authorization_ref - 04VisitOpen the encounter against the chosen cover
visit_id - 05TreatRecord what was found and what was done
diagnosis_id - 06PreauthorizeGet approval before the thing is done
approved amounts - 07BillAdd what was actually done, priced live
line refs - 08SubmitPass every gate, then close the claim
claim_id - 09ReconcileMatch the money to the invoice
remittance - ↳InvoiceSend the tax invoice to KRA (eTIMS)
invoice number - ↳CollectTake the patient's share (Slade Advantage)
payment ref
Why it exists
Connecting to one payer is a project. Connecting to every payer your patients actually carry is a permanent department.
Without the rail
- Two identity vocabularies, two benefit shapes, two claim lifecycles
- Consent factor rules re-implemented per payer, per member, per facility
- Failures that surface days later, wearing a costume
- Other organisations' release schedules inside your roadmap
- A standing team to track payer changes and sit in payer meetings — headcount that could have been building your product
- And the thing all of it ends in: preauths and claims declined for rules you were never told changed
On the rail
- One
unique_patient_idthreading every stop, whoever pays - One consent flow that resolves the legal factors for you
- One error shape, every reason returned at once
- Every response carries
next_action— you read the next move rather than working it out - Payer changes absorbed by the rail, not by your release notes — no tracking team, no payer meetings, no engineers held back for it
- And the thing all of it ends in: preauth and claim approval rates that rise because the rules were current when you asked
Two ways in
UnderstandWhat the rail is forThe problem it removes, how benefit coordination works, and what the revenue cycle looks like end to end. Prose, diagrams, no credentials needed.Read the argument →BuildRide the railEight stops, in order. Each one: why it exists, the call, runnable curl, what you keep, and what breaks here. Start at Identify and follow
next_action.Start at Identify →The eTIMS branch
A claim is not the only thing that leaves a visit.
Billing produces obligations the payer never sees. Those leave the rail after Bill and run on their own branch — same journey, different destination.
Building with an agent
Every page here is readable by machines, too.
Each page has a plain markdown twin at .md, and the whole corpus is indexed in llms.txt. Every stop on the golden path ships a prompt block you can hand straight to your coding agent.