Yashas
1c1c120202
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>
50 lines
2.2 KiB
HTML
50 lines
2.2 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
<!--BASE_HREF-->
|
|
<title>Northlake Health | Denials Desk</title>
|
|
<!-- Inline SVG data-URI favicon: no asset to resolve, which matters because
|
|
this build is promoted between environments unchanged and a
|
|
/favicon.ico would resolve against whatever mount path the server
|
|
chose. The mark is the one in src/components/NorthlakeLogo.tsx — a
|
|
teal chevron over a pulse line. Change one, change the other. -->
|
|
<link
|
|
rel="icon"
|
|
href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 40 40'%3E%3Crect width='40' height='40' rx='9' fill='%230E7C86'/%3E%3Cpath d='M8 25h6l3-7 4 12 3-8h8' fill='none' stroke='%23fff' stroke-width='2.6' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E"
|
|
/>
|
|
<meta name="theme-color" content="#ffffff" />
|
|
<!-- Theme, resolved BEFORE first paint. This duplicates a few lines of
|
|
src/theme.ts on purpose: the bundle is a module and therefore deferred,
|
|
so resolving the theme in React means the browser paints light first
|
|
and a dark-mode user gets a white flash on every navigation. Blocking
|
|
and inline is the only place this can run early enough. Keep the
|
|
localStorage key in step with THEME_KEY. -->
|
|
<script>
|
|
(function () {
|
|
try {
|
|
var t = localStorage.getItem('northlake-denials-theme');
|
|
if (t !== 'light' && t !== 'dark') {
|
|
t = window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches
|
|
? 'dark'
|
|
: 'light';
|
|
}
|
|
document.documentElement.setAttribute('data-theme', t);
|
|
if (t === 'dark') {
|
|
var m = document.querySelector('meta[name="theme-color"]');
|
|
if (m) m.setAttribute('content', '#10233a');
|
|
}
|
|
} catch (e) {
|
|
document.documentElement.setAttribute('data-theme', 'light');
|
|
}
|
|
})();
|
|
</script>
|
|
<script src="./config.js"></script>
|
|
</head>
|
|
<body>
|
|
<div id="root"></div>
|
|
<script type="module" src="/src/main.tsx"></script>
|
|
</body>
|
|
</html>
|