VasanthandClaude Opus 5.5
1e44758398
- Wrong password: owl droops its head with a slow blink (replaces the head-shake) - Show password: the owl's eye rims and lenses glow amber - Tap the owl and it jumps - Title "G2Team Potential Updater" and "Sign in" centered inside the card; subtitle hides after sign-in - Password field autofocuses - DESIGN.md, design.json, PRODUCT.md and the design brief updated to match the page Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5.7 KiB
Product
Platform
web
Stack
delegated: a local page served by the bot itself with Python's standard-library http.server, bound to 127.0.0.1 and opened in the default browser on the ops user's Windows PC. It ships inside the existing PyInstaller exe (src/ChargeBilledAutomation.spec). Chosen because the ops team already runs that exe, starting a run needs a live process (a static HTML file cannot do that), it adds no new dependencies (Flask/Streamlit would), and claim data never leaves the PC. The bot itself stays Python (Selenium, pdfplumber, pandas, openpyxl).
Users
The client's operations team (process owner: Sulthan Shafiq N). Three FTEs do this work by hand today: open Waystar, go account by account, open each claim PDF and copy fields into the Excel report template. With the bot, they start the run themselves and watch it, without the RPA developer and without reading a console window.
Other people involved but not the primary users: the OTS RPA team (builds and maintains the bot), and managers (Vijayakumari G, Swaminathan) who follow report status.
Product Purpose
The Charge Billed bot, run from the G2Team Potential Updater screen, produces the Charge Billed Report: charges by procedure, pulled from Waystar CMS-1500 claim PDFs into Excel, one workbook per account. It exists because the client keeps asking for charge and payment reports by procedure, and capturing them by hand takes three people a long time.
Success means the ops team can start a run, see where it is, and know at the end which claims are saved, which need a person to check, and which failed, without asking the developer.
The UI to build first is run and watch the bot: start a run, see live progress per account and claim, and see which claims failed or need review and why.
Positioning
The bot reads the PDF's text layer directly (src/cms1500_text.py) instead of OCR or manual copying, and it does not guess. Any claim with a missing or inconsistent field gets a plain review note (for example "No Insured ID (box 1a)" or "Line charges 120.00 != box 28 total 140.00") so a person checks only those claims, not every claim.
Operating Context
- Runs on a Windows PC. The bot closes all Chrome windows, starts Chrome with a debug port (9222) and a dedicated profile, attaches Selenium, and logs in to Waystar (login.zirmed.com), including a security question.
- Settings come from
Input/input.xlsx(proxy, portal URL, Waystar login, security answers). The Waystar password rotates monthly. - Date range is fixed to the previous calendar month, so in practice it runs once a month. (Inferred from code; not confirmed as the schedule.)
- Steps today: close Chrome → read config → launch Chrome → attach → open Waystar → log in → process all accounts. Within an account it pages through the claims list, downloads each claim PDF, extracts it and saves rows in batches.
- Output per run date in
Output/<MM-DD-YYYY>/:PDF Folder/<Account (ID)>/<claim>.pdf,reports/<Account (ID)>.xlsx, and a per-account log (Claim ID, Status, Remarks, Timestamp). Error screenshots go inScreenshots/. - Runs resume: claims and accounts already in the log are skipped on the next run.
- Today all progress is console text tagged
[INFO],[WARN],[ERROR],[SUCCESS], with numbered[STEP n]lines. --selftest <pdfs>checks a build without Chrome or Waystar and prints counts only.
Capabilities and Constraints
- Confirmed report columns: Claim ID, Rendering Provider #, Signature of Physician, Date of Birth, Insurance Name, Insured ID Number, Date of Service, Diagnosis Codes, CPT, POS, Modifier, Units, Charges, Line Charges, Review Notes.
- Terms the ops team uses: account (a practice, shown as "Name (ID)"), claim, CMS-1500 box numbers, Charge Billed Report.
- PHI. Claim PDFs, reports, logs and screenshots hold patient data (names, DOB, insured IDs). The UI stays on localhost, never sends data to an outside service, and shows counts, claim IDs and review notes rather than patient details unless the task needs them.
- Credentials. Waystar login and security answers live in
Input/input.xlsx. The UI must never display them. - Undecided:
- Account scope: every Waystar account or only specific ones (asked 10 Mar 2026, no answer). The code currently processes every account in the dropdown.
- Payment Report and Charge Reconciliation Report: confirmed as future reports, not started. Optimantra access for them needs a token approved by Ankit Sanghi (pending).
- A screen for reviewing and fixing flagged fields: not chosen for now.
- Whether a run can be stopped or paused from the UI.
Brand Commitments
The UI is named G2Team Potential Updater (user's choice, 22 Oct 2026); the bot and its report keep the name Charge Billed. Mascot: the orange owl with glasses on a navy night sky.
Evidence on Hand
- Real run output from April 2026 in
Output/(several accounts). It is PHI: never copy it into designs, mockups, demos or screenshots. Use clearly fake sample data instead. - Project history:
../PROJECT_DETAILS.md,../Communication_Summary.md. - Not in the folder: the client's Charge and Payment Excel templates, the PDF field list, and any measure of time saved per report (only the 3-FTE figure is known). Do not invent time-saved numbers, accuracy rates or client quotes.
Product Principles
- The ops team runs it alone. Every state is readable without the developer or the console.
- Nothing fails silently. Every claim ends as saved, needs review, or failed, with its reason.
- Flag, don't guess. A claim the bot can't read cleanly goes to a person with a plain note.
- Patient data stays on this PC.
- Pick up where it stopped. A rerun continues; it doesn't start over.