The operator console for Northlake Health's Denials Investigator (dev, org 900000109 / app 900000102). A revenue-cycle manager asks why claim denials rose; Ava — an AI employee — investigates the hospital's Databricks lakehouse and comes back with a cause, a dollar figure and a recommendation. He approves, and she re-checks on her own two minutes later. THE POINT OF THE SCREEN is that her work is checkable. Anyone can be told an agent analysed their denials; AvaLive shows the actual SQL she sent to Databricks, in order, with what came back and how long each query took — and it does NOT hide a query she got wrong and corrected, because that is the most convincing thing on the page. Two decisions worth knowing about: * Her trace does not come from the AI-employee monitor API. That endpoint needs an org-scoped studio token and answers "no organization scope on this account" for every user of this console. It comes instead from two views (northlake_app.ava_trace / ava_decisions) exposed as ordinary rdbms record views, behind a login role that cannot read the aiemployee schema at all. Seeded by sm2/custom-apps/denials-investigator/07_console_views.sql. * Ava's own activities — Record Findings, Confirm Recovery, Flag Still Elevated, Escalate — are deliberately absent from STAGE_ACTIONS. Putting them on screen would only let a person sign in as the agent and press its button, which is a person impersonating an agent rather than an agent working. Violet is the AI and nothing else is violet; amber is the one queue a human owns. No API URL is compiled in — config.js carries it at placement time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
42 lines
2.0 KiB
Markdown
42 lines
2.0 KiB
Markdown
# Northlake Health — Denials Desk
|
|
|
|
The operator console for the **Denials Investigator** app (dev, org `900000109`
|
|
/ app `900000102`). A revenue-cycle manager asks why claim denials rose; an AI
|
|
employee — **Ava** — investigates the hospital's Databricks lakehouse and comes
|
|
back with a cause, a dollar figure and a recommendation. The manager approves.
|
|
|
|
This repo is **outside sm2** on purpose: it is a frontgen artifact. A push to
|
|
`main` triggers a build, and the artifact is placed at
|
|
`https://preview-dev.getzino.in/northlake-health/`.
|
|
|
|
## What is where
|
|
|
|
| Path | What it is |
|
|
|---|---|
|
|
| `src/api/config.ts` | Every id: app, workflow, activities, record views, stages, per-stage actions |
|
|
| `src/api/client.ts` | The gateway client. App-scoped routes plus the two rdbms views that carry Ava's trace |
|
|
| `src/screens/QueueScreen.tsx` | A queue — the record view filtered on `current_state_name` |
|
|
| `src/screens/CaseScreen.tsx` | One investigation: findings, recommendations, Ava's live work, the actions |
|
|
| `src/screens/NewInvestigationScreen.tsx` | Ask a question — the INIT activity's form, read live from view-service |
|
|
| `src/components/AvaLive.tsx` | **The demo.** Every query Ava runs, as she runs it |
|
|
|
|
## Running locally
|
|
|
|
```bash
|
|
npm install
|
|
npm run dev # http://localhost:5174 — talks to dev.getzino.in via .env
|
|
```
|
|
|
|
Sign in as `dan.reyes@northlake.example`. The org is fixed in `config.ts`.
|
|
|
|
## Two things that will bite
|
|
|
|
1. **No API URL is compiled in.** `config.js`, written by the server when it
|
|
places the build, carries `VITE_ZINO_API_URL`. A production build with no
|
|
`config.js` fails loudly rather than calling whichever backend built it.
|
|
2. **Ava's trace does not come from the monitor API.** That endpoint needs an
|
|
org-scoped studio token; an app sign-in gets "no organization scope on this
|
|
account". It comes from two views (`northlake_app.ava_trace`,
|
|
`ava_decisions`) exposed as ordinary rdbms record views. Seeded by
|
|
`sm2/custom-apps/denials-investigator/07_console_views.sql`.
|