Demo · synthetic data · no real patient information
BruxfordClaims Engine
العربية

From a doctor's note to a paid claim, inside the UAE

The engine reads the note, checks it against the payer's rules, drafts the prior-approval pack and hands it to a billing coordinator, who approves it before a bot submits it. Remittances come back and feed the dashboard.

Open the engineSee the dashboard
The engine on synthetic encounter ENC-1002: verdict, documentation gaps and the 60-minute clock.
The engine on synthetic encounter ENC-1002: verdict, documentation gaps and the 60-minute clock.
The dashboard: money flow from billed to recovered, the prior-approval clock and denials by payer.
The dashboard: money flow from billed to recovered, the prior-approval clock and denials by payer.

Screenshots of this demo, captured with Playwright. Synthetic data.

The flow, step by step

Select a step to see what it does, what data it touches and where it runs. The green boundary is the UAE: patient data never leaves it.

Doctor's note → Clinic EMR → Claims Engine → Payer rules → PA pack → Billing coordinator → eClaimLink / TPA portal → Remittance advice → DashboardInside the UAE:patient data allowedOutside the UAE:synthetic data onlydemo onlycode via CI/CDDoctor's noteFree text at the orderClinic EMROrder and codesClaims EngineReads the notePayer rulesWhat the payer needsPA packVerdict and justificationBilling coordinatorApproves every submissioneClaimLink / TPA portalSubmitted by the RPA botRemittance advicePaid or denied, and whyDashboardWhere the money goesGlobal model endpointDemo onlyRPA developersBuild on synthetic dataDoctor's note → Clinic EMR → Claims Engine → Payer rules → PA pack → Billing coordinator → eClaimLink / TPA portal → Remittance advice → DashboardInside the UAE:patient data allowedOutside the UAE:synthetic data onlyDoctor's noteFree text at the orderClinic EMROrder and codesClaims EngineReads the notePayer rulesWhat the payer needsPA packVerdict and justificationBilling coordinatorApproves every submissioneClaimLink / TPA portalSubmitted by the RPA botRemittance advicePaid or denied, and whyDashboardWhere the money goesGlobal model endpointDemo onlyRPA developersBuild on synthetic data
The steps as a list
  1. Doctor's note (Inside the UAE: patient data allowed): The doctor writes the encounter note and orders a service, such as an MRI or physiotherapy. 60 synthetic notes written by a model from a deterministic case mix.
  2. Clinic EMR (Inside the UAE: patient data allowed): Holds the encounter, the member's insurance and the order, and sends them to the engine. A JSON file of synthetic encounters stands in for the EMR.
  3. Claims Engine (Inside the UAE: patient data allowed): Reads the note with a language model: suggested ICD-10 and CPT codes, documentation gaps per payer element, a doctor query and a justification draft. Google Cloud me-central1 (Doha) and Gemini 4 Argon, which is possible only because the data is synthetic.
  4. Payer rules (Inside the UAE: patient data allowed): Decides whether prior approval is required, which elements the payer expects, session caps and code rules. Deterministic: the model never decides the verdict. Illustrative JSON rules for three fictional payers, not real payer policy.
  5. PA pack (Inside the UAE: patient data allowed): Puts together the pre-submission verdict, the codes to submit, the editable justification and the attachments list. Shown on the engine page under the verdict.
  6. Billing coordinator (Inside the UAE: patient data allowed): Reviews the pack, edits it if needed and approves. Nothing is submitted without a person approving it. You, pressing "Approve and submit". Worklists show what is due first.
  7. eClaimLink / TPA portal (Inside the UAE: patient data allowed): A bot logs in to the payer's portal, fills the prior-approval form, submits it and reads the status back. A deliberately clunky fictional TPA portal. Nothing reaches a real insurer or eClaimLink.
  8. Remittance advice (Inside the UAE: patient data allowed): The payer's remittance comes back with denial codes. The engine explains each one and drafts the corrected resubmission. 16 synthetic remittances with DoH/DHA-style denial codes.
  9. Dashboard (Inside the UAE: patient data allowed): Shows value at risk before submission, denials after it, and the prior-approval clock. Every number opens its definition and source. Computed from the synthetic set on every request.
  10. Global model endpoint (Outside the UAE: synthetic data only): Gemini 4 Argon reads synthetic notes for this demo. In production it sees public documents, code and synthetic data only. Used here because every note is synthetic.
  11. RPA developers (Outside the UAE: synthetic data only): Build and test the bots against synthetic data and mock portals, and ship code through CI/CD. The bot in this repository was built against the mock portal.

Bruxford Claims Engine demo. Fictional clinics, payers and patients. Payer rules are illustrative, not real payer policy.

Contact: hello@bruxford.comAPI docsVersion v2026.10.18.5
Claims copilot
I can see what is on this page. Ask about it, or ask me to draft, explain or submit.

Powered by CopilotKit