BillingHub — a billing platform that collects its own claims
A client-management platform plus a claims-collection automation for a US medical-billing company serving Hospice and Home Health providers — it gathers the claims itself, flags the broken ones on arrival, and keeps every byte on HIPAA-compliant cloud.
Client
US medical billing · Hospice & Home Health
Role
Full-stack developer — built it from scratch
Engagement
Delivered under NDA
The problem
A US company does medical billing for Hospice and Home Health providers. It needed one internal platform to run the whole operation — a single place for its client organizations, their patients and physicians, the claims and the errors, all of it validated and re-checked, on reliable HIPAA-compliant infrastructure.
One of the heaviest daily jobs was getting claim statuses. Operators worked by hand through a terminal session: for each client they connected, entered a login and password, switched between screens and pulled the data out manually. The terminal is slow — extracting data for a single client took several minutes, and a full pass across all clients stretched to tens of minutes (around 35 and more). Every single time.
What I built
BillingHub — one internal platform, built from scratch, end to end. A single system that holds the client organizations (Hospice / Home Health), their patients and physicians, the claims and the errors — and validates everything several times over. The claims-collection automation is one standout part of a much larger whole.
Core
Client management
A single registry of client organizations (Hospice / Home Health) with business-specific custom fields, service statuses (active / suspended / terminated) and a full change history per client — who changed what and when, down to the individual field. Bulk import of clients is supported.
Access
Roles & access control
A flexible role model: for each role you configure exactly which fields an employee can view and which they can edit, and which slice of clients they reach. Access to sections — the claims catalog, client management, record deletion — is just as granular, so each person gets exactly what their work needs and nothing more.
Validation
Patient & physician validation
The system checks entered data automatically. ICD-10 codes are verified against icd10data — a code must match the diagnosis and the patient’s gender and must not be on an internal blocklist. Treating physicians are checked against CMS (data.cms.gov) for the required authorizations, catching errors in codes and patient data early.
Security
HIPAA-grade security
Deployed on HIPAA-compliant Google Cloud (covered by a BAA) with managed Cloud SQL, Secret Manager and encryption. Access runs on signed, short-lived tokens with one active session per user; sign-in adds TOTP two-factor. Every mutating action is recorded in an audit log, passwords are stored only as hashes, and the automation talks to the platform over a protected channel.
The claims engine
Pulling claim statuses was the worst of the daily grind — so it became the platform’s most powerful part. The old way: an operator opened a legacy terminal, signed in client by client, paged through screens and copied records out by hand. Minutes per client, around 35 and more for a full pass — every single time.
Now a scheduled automation does it end to end: it connects to the external claim-status system, walks every active client and loads thousands of claims in a single pass — managing which clients to collect, watching credential validity and logging every session. Classification runs alongside, so problem claims are flagged on arrival and operators open a ready-made list instead of re-reading everything.
See it below. By default a cursor works the terminal the slow, manual way — one patient at a time. Hit “Run automation” and the same work runs hands-off: pages flip and records stream into the store.
CLAIM STATUS INQUIRYTip: turn on automation to feel the speed →
RX-NODE 04417 REGIONAL CLAIMS GATEWAY SVC 06014
OP ZX5193 CLAIM STATUS INQUIRY SES 7F2D
SELMID PROV S TOB CLS FRM DT THRU DTREC DT
LAST NAME IN TOT CHG REIMB
K7X2P9Q4A1 404118 S B9099 329 010626 030626 040226 HARLOW T 420.00 1610.20
M3D8R1V7C2 404118 S B9099 329 012426 032426 040226 NAKAMORI S 500.01 1464.59
P9F4L0X2B6 404118 S B9099 32A 040826 040826 040926 ABLESON R
T2W6H8Y3N5 404118 S MOPPS 329 030326 040126 040226 VOSKERIN M 860.01
B5C1Q7Z9D8 404118 S MOPPS 329 030426 040226 040926 MARCHETTI G 860.01
R8K3J2V6T0 404118 S B9701 329 021126 031026 040126 OKONKWO P 500.01 1925.10
PROCESS COMPLETED --- PLEASE CONTINUE
PF3 EXIT PF6 SCROLL FWD
Claims store
0records
0warnings
0errors
Reconstruction for this case study — all data is fictional; the real system is under NDA.
What made it hard
Sensitive medical data throughout — data isolation, careful logging, field- and section-level access roles, and a HIPAA-compliant environment under a BAA.
Correctness of the entered data really matters — so validation is multi-layered: ICD-10 against the diagnosis and the patient’s gender, an internal blocklist, and physician authorizations checked against CMS.
A slow legacy terminal was the only way to get claim statuses — the automation had to drive it reliably and idempotently, turning tens of minutes of manual work into an instant pass.
The collection stays strictly within the standard software and interfaces the authorized agency provides — no hacking, bypasses or reverse engineering, and nothing that could disrupt government systems.
The result
One internal platform now runs the whole operation — clients, patients, physicians, claims and validation in a single system.
Claim collection that used to cost hours of manual terminal work (≈35+ minutes per pass) now runs automatically on a schedule — thousands of claims per pass.
Problem claims are flagged on arrival: operators open the platform and immediately see a ready-made list of exactly what needs attention.
Everything runs on reliable HIPAA-compliant cloud with two-factor authentication.
Confidentiality & legitimacy
This project was delivered under an NDA, so what you see here is intentionally incomplete — the interface is reworked for this write-up (not a real screenshot), some functionality is omitted, and certain automation details are withheld at the client’s request. None of it bends the rules.
Non-disclosure
The work was done under a signed NDA and an established data-handling protocol. Internal details, client names and anything that could identify a patient are deliberately left out of this case.
Data protection
No real sensitive or personal medical data was ever disclosed or used outside the protected environment — everything is stored and transmitted encrypted. All data shown in the demo is entirely fictional.
Legitimate automation
The claims-collection automation runs strictly within the standard software and interfaces the authorized agency itself provides — no hacking, security bypasses, reverse engineering or unauthorized access, and nothing that could disrupt or block government systems.