Every dashboard should name the decision it serves.
Caretech AI builds analytics for healthcare operations — utilization, facility performance, diagnostic throughput and population-level reporting — to a customer's own data model. Every Caretech analytics build starts the same way: a named role, on a named day, has a question they cannot currently answer.
Most dashboards answer nobody's question.
They are built from what the database happened to contain, not from what somebody needed to decide.
The tell is always the same: twenty tiles, no owner, opened enthusiastically for three weeks and then never again, while the decision it was supposed to support carries on being made from a spreadsheet somebody maintains by hand. Nobody is at fault. The analysis simply never had a decision attached to it.
So Caretech AI starts at the other end. Name the role. Name the moment in their week. Name what they will do differently depending on the answer. If those three cannot be stated, the chart is decoration, and a healthcare organization has enough of that already.
Seven steps, and the first one is not data.
The grammar is the same as everywhere else on this platform. Analysis produces an indicator; a qualified person decides; the decision is recorded. What differs here is that the chain begins with a question owned by a named role, and ends by being able to show that the question was answered.
From a question to a recorded decision
01 · A question
- Owned by a named role, at a named moment in their week.
02 · The record
- Which system actually holds the answer, and how complete it really is.
03 · A definition
- Every term in the question agreed and written down, because "utilization" means four things in one building.
04 · Measure
- Computed on that definition, and re-computable from it later.
05 · Indicator
- A number, a ranking, a shortlist. Never a conclusion.
06 · A person decides
- The named owner of the decision reads the indicator and acts.
07 · Recorded
- What was decided, by whom, and when — so the question can be shown to have been answered.
Six questions, each with an owner and a day.
These are the operational questions Caretech AI's analytics work is built around — each rendered here as the dashboard tile that answers it. They are written as questions on purpose: a metric with no question behind it is the thing Caretech is built to avoid.
"Is Thursday covered?"
Capacity against demand, far enough ahead that something can still be done about it — the only property that makes the answer worth computing.
"Where did the turnaround time go?"
Time broken down by step rather than reported as a single average, because an average says it is slow and nothing about where.
"Which site is drifting?"
Facility-level comparison on one shared definition, so a difference between locations is a real difference and not a difference in how they count.
"Who has not been contacted?"
14 awaiting first contact this morning
An administrative follow-up list built from what the record shows was and was not done. It ranks work; it does not assess anyone's health.
"What does this program look like overall?"
Population-level reporting on the organization's own cohort definitions, for planning and reporting obligations rather than for any individual's care.
"Which of our own numbers can we trust?"
Completeness, freshness and consistency of the underlying record, reported openly. The least requested analysis and usually the most valuable.
Operational analytics, and the line to clinical.
Analytics about a person's health is a different regulatory object from analytics about an operation, and the difference is not a matter of tone.
No clinical scoring
Caretech AI does not offer scoring of an individual's clinical risk, disease progression or condition as a capability. Where a build would require clinical scoring, the scope goes to regulatory counsel before it goes to engineering.
No prediction
Nothing here predicts a future clinical event. An indicator describes what the record already contains; a person decides what it implies.
No conclusions
Where an indicator touches care, it is presented to a qualified clinician with the data it came from, and their decision — not the indicator — is what is acted on and recorded.
That boundary is architectural. It is what makes an operational answer defensible, and the full scope position is published on the Trust Center.
Definitions first. Then data.
- A named person who owns each question, and can say what they would do differently depending on the answer.
- Access to the system that actually holds the record — and an honest account of where it is incomplete.
- Agreement on definitions, in writing, before anything is computed from them.
- A lawful basis for the data, and a decision about what is analyzed in identifiable form and what is not.
Each connection to an analytics, record or reporting system is scoped and built to your systems.
Tell us the question, not the dataset.
Who asks it, when they ask it, and what they would do differently if they had the answer. If we can write that sentence together, the rest is engineering.