- A mobile app that lets a claims clerk browse, filter, and capture medical billing claims by scanning paper documents.
- Optical character recognition and parsing happen entirely on the device — sensitive document images never get shipped off to a third party to be read.
- The backend is the system of record, deliberately separated from a read-only path used by an automation agent, so each door has exactly the access it should.
- The whole design is organized around one principle: sensitive data stays inside the boundary it belongs in.
Claims processing is a domain where the engineering and the data-handling are inseparable. The work is mundane on the surface — a clerk looks at claim documents, keys in the details, tracks status — but the data is exactly the kind you cannot afford to leak or mishandle. Claims Clerk is a project built to do that ordinary work well while treating the sensitivity of the data as a first-class design constraint, not an afterthought.
This is an architecture case study: what the system does, and the deliberate boundaries that shape it.
What it does
At the front is a mobile app for the clerk. It does the everyday things a claims tool needs: list and filter claims by status, payer, member, or free-text search, and open any claim for full detail. The more interesting capability is capture — instead of hand-keying a paper claim, the clerk points the phone at the document and the app turns it into a structured, reviewable record.
That capture flow is a small pipeline: scan the document, run optical character recognition, parse the recognized text into the claim's fields, let the clerk confirm and correct, then submit. The human stays in the loop as the final check — the app drafts the structured claim; the clerk approves it.
The defining decision: OCR happens on the device
The most important architectural choice is where the document gets read. It would be easy to send the scanned image to a cloud service to extract the text. Claims Clerk deliberately does not. The scanning, text recognition, and parsing all happen on the device itself — the image never leaves the phone to be read.
A scanned claim document is among the most sensitive artifacts in the system. Every place it travels is a place it could be exposed. Doing the recognition on-device means the raw image simply never enters that risk surface — the phone sends up the structured, confirmed fields, not the picture of someone's medical claim.
There's an honest tradeoff here worth naming. On-device deterministic parsing works cleanly when documents share a predictable layout. Genuinely messy, wildly varied documents are harder, and the right way to handle those is to process them inside a controlled environment you own — never by casually shipping images to an outside service. The principle holds either way: the sensitive artifact stays where you can account for it.
Two doors, not one
Behind the app sits the backend that owns the claims — the system of record. A clean piece of the design is that this is a separate door from the path an automation agent uses. The backend reads and writes claims data for the clerk. An agent that assists with the data reaches it through a different, read-only path, remotely.
Separating those access paths means each actor has exactly the capability it should and no more. The human clerk's app can create and update records. The automation can look but not touch, and reaches the data across a real network boundary rather than sitting on top of it. This is the opposite of the common shortcut where everything shares one over-privileged connection because it's easier.
Scanned images are served only through their own authenticated, human-facing path — they never travel across the agent's channel at all. The read path an agent uses can't even select the image data. Boundaries are enforced by the shape of the system, not by asking nicely.
The unglamorous parts, done properly
A production-grade app is mostly the parts nobody demos. Claims Clerk handles them deliberately: per-user authentication so every action is tied to a real clerk identity, a schema owned by proper database migrations rather than improvised on startup, and a shared authentication foundation reused across projects so this app didn't reinvent login from scratch. The mobile client and backend talk over a single clean contract, so the model or the internals can change without breaking the app.
None of that is flashy. All of it is what separates something you'd trust with real claims from a prototype.
The throughline
What ties Claims Clerk together is a single discipline applied everywhere: sensitive data stays inside the boundary it belongs in. Images are read on the device and never shipped out. The system of record and the automation path are separate doors with separate privileges. The agent crosses a real boundary to read, rather than being handed the keys. Each decision is the same idea in a different place.
That's the kind of system worth building carefully — where handling the data responsibly isn't a compliance checkbox bolted on at the end, but the thing the architecture is shaped around from the first decision.
Need a system where data handling is the hard part?
Boundary-aware architecture — keeping sensitive data where it belongs — is exactly the kind of work I take on.