EasyVOB AI Verification Portal: automating the front of the VOB
An internal prototype that reads raw eligibility notes and returns structured benefits, a match score, and level-of-care eligibility. Built on synthetic data as a step toward automating EasyVOB's verification work.
Shared from the team. This build is the work of one of our devs, who has been automating and improving EasyVOB's verification step. Much of it was hand-coded and refined with Codex and Claude Code. Written up in the third person with their permission.
## the problem
A VOB starts as a wall of unstructured eligibility text: deductibles, out-of-pocket maximums, in-network and out-of-network amounts, plan status. Someone has to read it and turn it into an admit decision. On the live EasyVOB service that step is done by hand, by a HIPAA-trained team.
One of our devs wanted to find out how much of the reading and structuring a model could handle before a human signs off. So they built a prototype that runs on synthetic patient notes, not real PHI — enough to test the idea without putting patient data through a workflow that isn't cleared to hold it.
This is a share of that process, not a finished product: an attempt to automate and improve the front of the verification step while keeping the human sign-off the live service depends on.
## what I built
They built an internal 'AI Insurance Verification' portal with Admissions and Agent views, marked Internal Tool. A user pastes raw eligibility notes plus a payer/plan, hits Run AI Verification, and gets a Verification Summary: extracted in-network and out-of-network deductibles and out-of-pocket maximums.
It includes a Level of Care eligibility table covering Detox, Residential, PHP, IOP, and OP, plus a developer JSON view exposing a comparison engine — planFound, per-field match flags, matchScore, and overallMatch — so every extracted value can be audited against what was expected rather than taken on faith.
Under the hood: a Spring Boot backend (VerificationController to VerificationService to a typed VerificationResponse) behind a plain HTML, CSS, and JavaScript frontend, with note sanitization before anything is displayed. The AI extraction layer is OpenAI, not Claude. Much of the code was written by hand; end to end, the flow works today on test notes.
## how Claude was actually used
- 01
Hand-coded first, AI-assisted second
Most of the portal was written by hand. The dev used Codex and Claude Code as coding assistants to speed up and improve parts of it, not to generate the whole thing. The AI tools sped up the work; they didn't replace it.
- 02
Frontend and API wiring
AI assistance went mainly into the portal UI — the eligibility-notes input and payer/plan field, the empty state, the live Verification Summary panel, the Level of Care table, and the developer JSON view — and into verification.js, the layer that posts notes to the backend endpoint and renders the structured results live.
- 03
Honest credit
The OpenAI extraction layer and the Spring Boot backend are the dev's own work. The AI coding tools (Codex and Claude Code) assisted with the frontend; that's the extent of what they get credit for. On a build that points at healthcare data, an accurate credit line matters more than a bigger one.
## stack
## results (the verifiable kind)
- ✓End-to-end flow works on synthetic data: pasted eligibility notes produce a structured Verification Summary (in-network and out-of-network deductibles and out-of-pocket maximums) and a developer JSON payload.
- ✓On the demo note, the comparison engine returns planFound, overallMatch, a matchScore, and per-field match flags such as innDeductibleMatch and oonOopMaxMatch — a comparison result, not an accuracy claim.
- ✓A Level of Care eligibility table renders for Detox, Residential, PHP, IOP, and OP.
- ✓The backend exists as a Spring Boot REST endpoint (VerificationController), a service layer (VerificationService), and a typed response (VerificationResponse), in a private Git repository with commit history.
- ✓The AI-assisted portion is the portal UI and the verification.js frontend-to-API wiring, shown in the empty and live-verification screenshots; the rest was hand-coded.
## what I learned
- →Code-first means receipts. This prototype lives in a private Git repository with commit history, so the process is traceable instead of lost.
- →Credit only what is checkable. The AI tools assisted with the UI and the wiring; the AI extraction engine is OpenAI and much of the code was hand-written. Keeping that line precise is the difference between a receipt and marketing.
- →Putting AI in the VOB loop is a compliance decision before it is a feature. This runs on synthetic data on purpose. The distance to production is a BAA-covered model, minimum-necessary inputs, audit logging, and a human signing off on any reimbursement figure before anyone relies on it.
- →This automates the front of the step, not the decision. The goal is to speed up reading and structuring the notes, while the final verification stays human — the same standard the live service is built on.
$ follow --the-build
Watch it happen, don't take my word for it
Every build on this site gets documented as it happens — the prompts, the dead ends, the results. No course at the end of this funnel. There is no funnel.
follow on x →