Generative AI arrives in hospitals with a credibility problem. Clinicians have seen chat tools invent references and doses; finance teams have seen dashboards that disagree with the ledger. In that setting, the most valuable property of an AI assistant is not fluency. It is that the user can check it.
Design for verification, not persuasion
A grounded assistant answers only from the hospital's own data. When a manager asks which cardiology patients discharged last month still have unpaid bills, the answer should come with the query that produced it and the number of rows it returned, so the user can see exactly what was counted. In our Hospital 360 demo the assistant shows the SQL and row count behind each answer, and a verifier checks the numbers in the reply against the data1.
- Answer from data, or say no. If the database cannot answer, the assistant says so rather than filling the gap.
- Show the working. The query, the rows and the record behind every figure are one click away.
- Respect the role. Finance users see diagnosis fields masked, and diagnosis questions from finance roles are refused by policy1.
- Keep a record. Every question, AI draft and action is logged by user and role1.
Let the model interpret; let the server decide
The same principle applies when an assistant acts. An instruction such as ‘admit this patient’ or ‘start atorvastatin 40 mg once daily and repeat the INR’ can be interpreted by a language model, but the order itself should be rebuilt and re-validated by deterministic code: every drug checked against the formulary and stock, every test against the lab list, every action against the user's role and the record's state. Only then is a confirmation card shown, and nothing commits until the user clicks confirm1.
Where the language model sits, and where it does not
Division of labour in a grounded hospital assistant
| Task | Language model | Rules and server | Person |
|---|---|---|---|
| Answer a management question | Translates the question to a query | Runs the query; verifies numbers | Reads the answer and the SQL |
| Draft a medication order | Interprets the instruction | Re-validates drug, dose, stock, interactions | Doctor confirms or edits |
| Recommend investigations | Not used | Applies work-up rules; reconciles with results on file | Doctor orders |
| Score deterioration | Not used | NEWS2-style rule set on observations | Nurse and doctor respond |
| Reply to an insurer query | Drafts the letter from the encounter record | Restricts sources to that encounter | Finance reviews and sends |
Note: Based on the design of the Hospital 360 demo, which runs on synthetic data.
Source: DaasLabs, “Hospital 360 — SCIKIQ Healthcare-in-a-Box demo” (2026)
Not everything needs a language model
Some of the highest-value hospital tools should contain no generative AI at all. A diagnostic work-up assistant that lists the investigations recommended for a working diagnosis, and reconciles them against results already on file, is better built as a transparent rule library. Our demo's version uses 70 guideline-style rules across 30 conditions; because it is rule-based, nothing can be hallucinated1. Early-warning scoring is similar: a rule set over observations is explainable to every nurse on the ward.
A clinician will forgive an assistant that says ‘I can't answer that from the record’. They will not forgive one that sounds certain and is wrong. (DaasLabs view)