The analysis is written
Every section of the panel has text: what the Squad looked at, what it found and what it suggests looking at first. That is where its reasoning adds value — and it is the only part it drafts.
Hospitals · Dashboards and indicators
Hospital dashboards and indicators
The panel is not a screen somebody has to remember to open. It is a written document that arrives finished at the start of the morning, with the arithmetic in the open behind every number — and with whatever changed since yesterday already named.
It is written by a Squad — the platform's orchestrating agent. It wakes up on schedule, reads the hospital systems through their APIs and publishes in PDF and HTML.
The deliverable
A document that arrives, not a screen that waits
Every hospital already has dashboards. The problem is rarely a missing screen: it is that the screen only exists when somebody opens it, picks the right period and knows what to look for. At seven in the morning, with the waiting room filling up, nobody opens it.
A dashboard waiting to be opened
- Only informs the person who already knew which filter to apply and which tab to look at
- Shows the total, never the parts: when it does not add up, nobody finds out where
- Comparing with last week means exporting twice and matching the columns by hand
- It does not say what changed — it says what exists, and the reader has to spot the difference
- If a system was down overnight, the chart looks the same, only lower
A document written by the Squad
- Arrives by email at six in the morning, in PDF and HTML, with nobody asking
- Every aggregate comes with its parts printed next to the total
- The comparison is already made, against the historical window the query itself returned
- The analysis is written: what went up, what went down and what needs a human decision
- A source that did not answer becomes a named line in the document, not a silent gap in the chart
The difference is not a prettier chart. It is that the document was written by someone who read the data.
The table is not typed
Tables and charts are declared by reference: the Squad says which API call the data comes from and how to group it. The server reads the response, does the arithmetic and draws. The numbers never pass through the model.
It comes out whole or not at all
An empty document is refused before publishing, and a block whose math could not be done does not become a handsome axis with nothing inside. No ellipses, no "remaining items omitted".
Who writes it
How a Squad assembles the daily panel
The Squad is the platform's orchestrating agent: it has no channel of its own and never talks to a patient. It wakes up on schedule, queries the hospital's APIs, decides what is worth reporting, writes the document, publishes it in PDF and HTML and sends it to the recipient list. Every day, with nobody asking.
Wakes up on schedule
The schedule is set by the manager — Monday to Friday at 5:40 AM, say, before the front desk opens. Waking up is not an order to act: the Squad reads its own context and decides whether that run calls for a document at all.
Queries the systems
It calls the tools it was given — api_get_schedule_capacity, api_get_appointments, api_get_payer_remittance — and asks, in the same call, for the historical window that will serve as the comparison.
Decides what is worth reporting
Not everything that moved deserves a paragraph. It separates normal variation from what fell outside the window's pattern and writes about the second — naming the specialty, the shift or the payer where it happened.
Publishes and delivers
The server assembles the document with the house stylesheet, generates the PDF, keeps the HTML and sends the email to the registered addresses. The run is logged with what was queried, what was decided and what was sent.
From the inside, the run has a log. That is how the manager traces where each block of the document in their inbox came from.
Daily Panel · scheduled routine
Monday to Friday, 5:40 AM · scope: previous day, full outpatient schedule
Running Daily Panel · via schedule Step 7 of 9
05:40:02Woke up on schedule — scope: previous day, full outpatient schedule
05:40:05api_get_schedule_capacity(day="previous", history_window_days=30)
05:40:111st attempt timed out on the HIS — retried and answered in 6 s
05:40:19498 slots for the day and 30 days of history came back in the same response
05:40:22api_get_appointments(day="previous") — 428 records read
05:41:03No-shows classified by booking lead time — 4 bands
05:41:48Blocks declared: 1 chart, 1 table, 1 meter — all pointing at calls made this run
05:42:06publish_document(format=["html","pdf"])
05:42:09Sending to the registered recipients
498 slots read · 428 appointments · 103 no-shows classified Published in PDF and HTML
Nobody asked for this panel
when there is nothing worth reporting, the run records that and publishes nothing — and still counts as successful
What you are looking at
The header declares the routine and the scope. In the log, each mono line is a real tool call; the reasoning lines say what the Squad concluded from that response. The attempt that timed out on the HIS — the hospital information system — was not hidden: it became a yellow line with the timing of the second call.
The footer closes with the parts of the run: how many slots were read, how many appointments, and how many no-shows went into the classification.
Only on Hal-AI
A scheduled automation fires because the clock struck and delivers what the flow anticipated. Here the orchestrator decides what that run calls for — including concluding that there is nothing new and publishing nothing at all.
- Simulation mode to rehearse the routine without sending email
- A stop button that interrupts the run mid-flight
- An auditable history of every round, with what was queried and what was sent
Arithmetic in the open
Every total arrives with its parts beside it
It is a house rule, and it holds for every document the platform publishes: no aggregate ever appears on its own. If the number does not add up, the reader sees exactly where it stopped adding up — without opening the system, without asking anyone to run the query again.
A small example, repeated on every page
One specialty offered 159 slots in the week. The panel never writes only that. It writes 159 = 118 booked + 41 open, and when the reader scrolls down to the table they find the 118 broken out by shift and the 41 broken out by day.
It looks like typographic fussiness. It is not: it is what lets you check the document in ten seconds instead of half an hour. If the parts do not add up to the total, the error has an address — one part too many, one too few, or two different time windows in the same table. Without the parts, a wrong number looks exactly like a right one.
- Total with its parts: 498 slots offered appear as 214 in the morning + 186 in the afternoon + 98 in the evening.
- Percentage with its base: 86% occupancy never goes out alone — it goes out as 428 booked out of 498 offered.
- Chart with its sum: the figure caption states that the bars add up to the total quoted in the text, and shows the parts.
- Named exclusions: a record left out of a grouping is counted and explained, never dropped in silence.
It compares with yesterday without remembering yesterday
This is a technical detail of the platform worth understanding, because it changes what you can ask a Squad for. It keeps no files between runs and has no memory of the previous round. There is no folder where yesterday's panel sits waiting for today's.
The historical comparison comes from the query itself: when the Squad calls the schedule API, it asks for the last thirty days in the same call. The baseline arrives in the same response as the day's data, and that is what the reading is made against.
If the window does not come back in the response, there is no comparison in that document — and the document says so, instead of inventing a reference.
On the console side, all of this is the configuration of one routine — and the comparison window is a parameter of the query itself, not a file kept somewhere.
Frequency
Daily — Monday to Friday, at 5:40 AM
Before the front desk opens. When it wakes up, the Squad reads its own context and may conclude there is nothing new to report that day.
Comparison window
30 days asked for in the same call
The history arrives in the api_get_schedule_capacity response, alongside the day's data. There is no baseline stored between one run and the next.
Output format
HTML for reading on screen and a PDF attached to the email
The stylesheet belongs to the server: the agent writes content, never appearance.
Mode
Live delivery Simulation available
No disk, no files, no memory of yesterday
everything it compares came back in this round's response — and the document states which window that was
159
slots in one specialty's week — printed in the panel as 118 booked + 41 open
100%
of runs with an audit trail: what was queried, what was decided, what was recorded
0
numbers in the panel typed by a language model — tables and charts read the API response
The routine
The panels a hospital operation asks for every day
Each one is a routine of its own, with its own schedule, its own source and its own recipient list. They cover the same subjects as the other pages in this section — here they show up from the side of the person reading the result.
Daily Funnel
What the schedule offered, what was booked, what became a completed visit and where the slot was lost — by shift and by specialty. It is the panel that opens the morning for scheduling coordination.
source: api_get_schedule_capacity
Denials by root cause
How much was denied in the period — the glosa, the line a payer refuses to pay — grouped by the cause behind it rather than by the code the payer sent back. It carries each case's appeal deadline and what expires first.
source: api_get_payer_remittance
Transmission status
Batches sent, batches accepted, protocols imported and what got stuck in the technical validation of TISS, the claims exchange standard Brazilian payers are required to use — every contracted payer in one panel, with no portal hopping.
source: api_get_tiss_batch
Compliance and contract
It audits the account against the medical record before the batch goes out: an item billed with no record to sustain it, a note that does not cover the procedure charged, an item charged below contract. Every finding comes out with the reference that produced it and with the evidence that is missing.
source: api_get_patient_account
Channel service
Volume on the official number, the share resolved without anyone from the team stepping in, time to first reply and how much arrived outside front-desk hours.
source: api_get_channel_conversations
Schedule operations
Bookings, reschedules and cancellations made by the agent in the official schedule, with the share completed on the first attempt and what needed a handoff to the front desk.
source: api_post_appointment
One routine per subject, not one giant panel
Putting it all in a single document would be simpler. It would also be useless: billing does not read the scheduling funnel, and scheduling coordination does not open denials by root cause. Each routine has its own time, its own source and its own recipient list — and can be switched on alone, without waiting for the others.
That is also what makes it possible to start small. A hospital usually switches on the Daily Funnel first, because the source already exists and the result shows up in the first week, and only later adds the revenue-cycle routines.
The panel is the reading, not the action
When the reading calls for a conversation with a patient — pulling the waiting list for a slot that went unused, say — the one who speaks is the channel agent, on the hospital's official number. The Squad talks to it in plain language and gets an answer back, including when the answer is this person was already contacted yesterday, I did not repeat it.
Six different documents, written by the same kind of agent, reading the systems the hospital already has.
The deliverable
The daily panel, as it arrives
Below is a representation of the Daily Funnel for the example hospital — a mid-to-large network, 28 outpatient specialties, around 2,500 consultation slots offered per week. The page is light and serifed on purpose: the deliverable does not look like the console, it looks like a report.
Daily Funnel · run #312
What the schedule offered on Wednesday, what became care and where the slot was lost
Document published by the Squad at the end of the 5:40 AM run, covering the previous day's outpatient schedule, compared against the thirty-day window that came back in the same query.
01The day at a glance
The schedule offered 498 slots on Wednesday — 214 in the morning, 186 in the afternoon and 98 in the evening. 428 were booked, which is 86% occupancy, and 304 became completed visits: 61% conversion from offered slot to care delivered. Of the 428 booked, 103 people did not show up and 21 canceled the same day; another 70 slots were never booked at all.
Slots offered
498
214 morning + 186 afternoon + 98 evening
Did not become care
194
70 open + 103 no-shows + 21 canceled on the day
Schedule occupancy
86%
428 booked out of 498 offered
02Open slots by business day in the window
Across the five business days in the window, 346 slots went unbooked, an average of 69 a day. Wednesday came in at 70, within expectation. The outlier is the Friday before, at 82 — and Friday is the day the waiting list for the highest-demand specialties grows the most.
Slots that went unbooked, by business day
source: api_get_schedule_capacity · scale and drawing by the server
Figure 1 — 74 + 82 + 62 + 58 + 70 add up to the 346 open slots across the five business days; the average of 69 is 346 ÷ 5.
03The funnel by shift
Evening is the shift with the lowest occupancy and the highest share of no-shows over booked slots. Morning carries the schedule: 190 of the day's 428 appointments sit there.
| Shift | Offered | Booked | Completed | No-shows | State |
|---|---|---|---|---|---|
| Morning | 214 | 190 | 138 | 44 | 89% occupancy |
| Afternoon | 186 | 158 | 112 | 38 | 85% occupancy |
| Evening | 98 | 80 | 54 | 21 | 82% occupancy |
| Total for the day | 498 | 428 | 304 | 103 |
Table 1 — the same api_get_schedule_capacity call as Figure 1, grouped by shift. The 21 same-day cancellations (8 + 8 + 5) have no column of their own: on every row, booked = completed + no-shows + cancellations.
04No-shows by booking lead time
The 103 no-shows are not spread evenly across waiting time. More than half — 52 of 103 — come from slots booked more than thirty days ahead. In proportion to the volume in each band, someone who booked more than thirty days out misses the appointment about twice as often as someone who booked for the same day. Lead time is the cheapest predictor this schedule has.
More than 30 days52
8 to 30 days33
Up to 7 days14
Same day4
Figure 2 — 52 + 33 + 14 + 4 add up to Wednesday's 103 no-shows, split by how far ahead the slot was booked.
05Comparison inside the window
This reading is compared against the previous thirty days because the window came back in the same api_get_schedule_capacity response. Against it, Wednesday closes above average on occupancy and on conversion, and the distribution of no-shows by lead time repeats the month's pattern. Had the query not returned the history, there would be no comparison in this document — the routine keeps no files between runs and has no way to recover yesterday's panel.
What the board has to decide70 slots went unused on Wednesday and 82 on the Friday before, while the waiting list for the highest-demand specialties is still open. Calling that list in for those slots is a human decision: the Squad reports the unused capacity, but it does not rearrange the schedule or book a patient on its own.
What you are looking at
A header with the period, the API call that fed the piece and the run number. Five numbered sections, each with the text the Squad wrote before the data block. Figure 1 and Table 1 read the same response — one grouped by day, the other by shift.
The block that closes the document is the only one that does not report: it separates what the routine already handled from what needs a person to decide.
No number stands alone
498 appears as 214 + 186 + 98. 194 appears as 70 + 103 + 21. 86% appears as 428 out of 498. The five bars in Figure 1 add up to the window's 346 open slots, and the four meters in Figure 2 add up to exactly the 103 no-shows in the table.
Checking the piece means looking at two parts on the screen — not running the query again in the system.
The advantage
Scheduling coordination opens the inbox at seven and already knows where to look: the unused capacity is named by shift, the no-shows are explained by lead time, and the pending decision is separated from the rest.
Because the structure is the same every morning, today's document can be compared with yesterday's without anyone redoing the math to line the two readings up.
Delivery
The email that carries the document
The document is the deliverable; the email is only its front door. So the body of the message is short and follows one hard rule: no number appears in the email unless it is in the attached document. Whoever reads on the phone on the way to the hospital gets the essentials; whoever needs the detail opens the PDF.
Sent by the Squad · today 5:42 AM
Daily Funnel — Wednesday, Sep 16
Good morning. The schedule offered 498 slots yesterday; 428 were booked and 304 became visits. 70 slots went unused and 103 people did not show up — more than half of them had booked more than thirty days ahead.
There is one open decision in the document: the 70 unused slots on Wednesday and the 82 from the Friday before, with the waiting list still open.
Daily Panel · run #312 Delivered
The attachment also comes back into the run's chat as a clickable file — that is how the manager opens the piece without leaving the conversation with the orchestrator.
Daily Funnel — Sep 16
Open document
The published document bubble, as it appears in the Squad's run chat.
Who receives it is a record, not an instruction in text
The recipient list belongs to the hospital and lives in the console. During the run the Squad picks from inside it — it does not type a new address, does not edit the list and does not improvise a forward. Every address is checked before the send.
board@hospital.example outpatient.scheduling@hospital.example billing@hospital.example audit@hospital.example · pausedTaking someone off the list is a change to a record, not a rewrite of the agent's prompt — and an address outside the list is blocked before the send.
Different panel, different recipient. There is no point sending denials to scheduling coordination or the daily funnel to billing: each routine has its own list.
| Who receives it | Panel | Why that document |
|---|---|---|
| The board | Daily Funnel and the weekly roll-up | Needs the short reading of what changed, with the pending decision already separated from the report. |
| Scheduling coordination | Daily Funnel, broken out by specialty | Acts the same day: calls the waiting list for the slot that went unused and redistributes next week's capacity. |
| Billing | Denials by root cause and Transmission status | Works against contractual deadlines: needs to know what expires first and which batch got stuck in validation. |
| Commercial and relations | Channel service | Tracks volume on the official number, response time and the complaint that turned into a handoff. |
| Internal audit | The run trail, without the document | Does not need the indicator: needs to know what was queried, what was decided and what was sent. |
HAL Copilot
When the manager would rather ask than read
The panel answers the question that repeats every day. For the question that just came up — why did occupancy drop on Wednesday? — the path is different: the HAL Copilot, the internal assistant for whoever runs the place.
It queries the hospital's own data in read-only mode and answers with text, a table and a chart on screen. The manager can export to PDF, ask for a recurring check, or simply close the page: the mission keeps running on the server and the result arrives by notification.
- Ask in plain language, with no filter, no tab and no need to know the field name in the system.
- The same arithmetic in the open: the answer carries its parts, the way the document would.
- Read-only — the Copilot does not book appointments, does not send batches and does not change records.
- Deep analysis reads case by case when the question calls for it, instead of handing back only the aggregate.
HAL Copilot
online
Why did occupancy drop on Wednesday?7:18 AM
It did not drop against the window: Wednesday closed at 86%, above the average of the last thirty days. What changed is where the capacity went unused — 70 open slots, concentrated in the evening shift.7:18 AM
Where exactly?7:19 AM
The evening offered 98 slots and booked 80, 82% occupancy — the lowest of the three shifts. Morning came in at 89% and afternoon at 85%.7:19 AM
Chart that by day and send it to me as a PDF7:20 AM
Done. You can close the page: I will let you know when the file is ready.7:20 AM
Same memory, same read-only tools. What changes is who pulls the trigger: here, the manager; in the panel, the Squad's schedule.
Two ways to ask for the same number
- Now, in the conversation: the Copilot answers the manager with the table on screen and the PDF ready to forward.
- On its own, on schedule: the Squad publishes the full document and delivers it to the registered list, with nobody asking.
Today's question becomes tomorrow's routine: when the same query repeats every week, it stops being a question and becomes a scheduled panel.
Limits
What the panel is not
A daily panel that promises to be everything ends up being used for nothing. It is worth spelling out what this piece does not replace — and what the platform refuses to do.
It does not replace the hospital's BI
BI is where you look at the long series, cross one dimension with another and investigate the hypothesis nobody has formulated yet. The daily panel is something else: it is the reading of what changed since yesterday, written to be read in three minutes before the operation opens.
The two live together. When the question the panel raises needs the whole series, it goes to BI — or to the Copilot, which reads it in plain language.
It reads the record to check the account, not to weigh in on the case
No aggregate panel carries a name, a document number, a phone number or any other patient identifier. The Squad reads schedules, accounts and payer remittances; in the compliance routine it also reads the medical record — to check whether the documentation sustains what was billed and to point out, item by item, where it does not. That is as far as the clinical reading goes: it does not write a line about diagnosis, treatment or medical advice.
It hands over the finding; executing is the hospital's
The panel hands over the finding already backed up: the unused slot, the denial that expires first, the batch that got stuck and the item the documentation does not sustain — each with its likely cause and its deadline. What it does not do is execute: it does not rearrange capacity, does not cancel a batch, does not open a contractual exception and does not call a patient on its own. The hospital signs off on the correction, in a separate block at the end of the document; the work of finding it is already done.
- It invents no reference: with no historical window in the response, there is no comparison in the document
- It truncates no list: the document comes out whole, with no ellipses and no "remaining items omitted"
- It publishes no empty piece: a block with no data is refused before the document goes out
- It picks no recipients: whoever is not on the registered list does not receive it
Failing to deliver is bad. Delivering a handsome axis with nothing inside is worse, because it goes unnoticed.
A panel exists so that someone can decide. Deciding on an approximate number is worse than having no panel at all.
Questions
Frequently asked questions
Does this mean one more system to open every day?
No. The panel arrives as a document: a PDF attached to the email and an HTML version at the link, for whoever prefers to read on screen. There is no new login for the board or for scheduling coordination — anyone who wants to browse the console has access, but nobody needs it to receive the morning reading.
Do the numbers in the table pass through the AI model?
No. Tables and charts are declared by reference: the Squad says which API call the data comes from, which list to use and how to group it. The server reads the response, computes the sums, percentages and scale, and draws the block. The model writes the analysis and chooses the angle — the arithmetic is not its job.
That is why every aggregate comes out with its parts beside it: they come from the same response as the total, and disagreeing with each other would mean the data changed at the source.
If it keeps nothing between runs, how does it compare with yesterday?
The comparison comes from the query itself. When the Squad calls the schedule API, it asks for the historical window in the same call — the last thirty days, for instance — and the baseline arrives in the same response as the day's data. It has no disk, keeps no file from one run to the next and does not remember the previous round.
The practical consequence is worth knowing when you design the routine: if the API returns no history, that day's document comes out without a comparison, and says so. Nothing is reconstructed from memory.
Who defines the recipient list and who can change it?
The hospital does. The list is a record in the console, maintained by whoever the hospital authorizes, and each routine has its own. The agent picks from inside the list during the run; it does not create an address, does not edit the list and does not forward the document outside it. An address outside the list is blocked before the send, and the delivery is logged with how many recipients were reached.
What happens if a system is down when the run starts?
The failed attempt becomes a line in the log, with the time and the result of the retry. If the source stays unavailable, the block that depended on it is not filled with an estimate: it comes out named as not measured, and the document explains which reading was missing that day.
A run that concludes there is nothing worth reporting is also a declared outcome, not a failure for a supervisor to investigate — it records the check and publishes no document.
Bring us the report your team assembles by hand every morning
We will show you how the Squad reads the hospital systems, writes the document with the arithmetic in the open and delivers it on schedule — to the recipient list the hospital defines.