A clickable web prototype for primary care clinics participating in Medicare's APCM program. Checks the three monthly billing requirements for every patient, assigns the right reimbursement code (G0556 / G0557 / G0558), and exports CMS-ready documentation — built to pitch a real client before committing to the full backend build.
Primary care clinics already do the work Medicare's APCM program pays for — checking in on patients with chronic conditions, keeping care plans current, coordinating follow-ups. But getting reimbursed means proving, every single month, that three boxes were checked for each patient: consent on file, an active care plan, and at least one documented contact. Most clinics track this in spreadsheets, miss contacts, and leave real revenue on the table. I set out to turn care they're already providing into billable, documented work — without adding staff.
I built it as a clickable prototype first: plain HTML, Tailwind for styling, and vanilla JavaScript, with the browser's local storage standing in for a real database so every action you take persists through the whole demo. That let me show a clinic admin, a provider, and a super-admin all using the same connected system — eight working screens — without spending weeks on a backend that might get redesigned after the first client conversation. I deliberately cut real accounts, servers, and data storage, and kept the parts a buyer actually judges: the billing checklist, the patient registry, and a one-click CMS-ready export. The lesson for your first app: build the version that proves the idea to a customer before you build the version that scales to a thousand.
The hard part wasn't code — it was translating a dense government billing rulebook into logic the software could enforce. APCM reimbursement hinges on exact conditions: three monthly criteria per patient, plus a billing code that changes with how many chronic conditions someone has (G0556 at $15, G0557 at $50, G0558 at $110 a month). Getting that wrong in a real clinic means denied claims or a failed audit, so the registry had to flag precisely what's missing for each patient and assign the right code automatically. Encoding rules written for auditors, not engineers, took more care than any screen in the app.
What's live today is a fully interactive prototype — eight connected screens covering the public site, clinic onboarding, a provider dashboard, a patient portal, and a platform-wide admin panel, all demo-ready in a browser with no install. I built it to pitch a specific client, paired with a presentation deck and a phased plan to rebuild it on React and Supabase once the concept is approved; roughly six weeks from spec to demo, though without commit history that's an estimate. There's no App Store launch or live user count yet — this is the proof, not the product. The takeaway: a prototype real people can click through will win you a 'yes' faster than a finished app nobody asked for.