01
How the ninety days run
Five phases, each with an exit condition. A phase does not start because the calendar says so; it starts because the previous one finished.
Prepare
Environments, feeds identified, people named, the governance group formed and meeting once before anything is installed.
Exit: sponsor, wards and data feeds confirmed in writing.
Baseline
Measure today's performance with the platform switched off. This is the phase hospitals want to skip and the one that makes the result defensible.
Exit: four baseline numbers agreed and signed.
Connect and configure
Lab and ADT feeds, your formulary and protocols, roles mapped to real staff, beds and wards loaded, consent notice approved.
Exit: safety suite passes on this deployment.
Live on two wards
Scribe and ward board with clinicians who volunteered. Weekly review where what the system got wrong is the agenda.
Exit: four consecutive weeks of use with no unresolved safety issue.
Measure and decide
Same measures, same method as the baseline. Compliance pack printed from real use. Go or no-go with numbers on the table.
Exit: a decision, either way, recorded.
Scope does not grow during the ninety days. A third ward, a new integration or an extra module is written down as "after the decision" — a pilot that expands mid-flight cannot be compared to its own baseline.
02
Who does what
| Activity | Hospital | HealthTeky | Decides |
|---|---|---|---|
| Clinical scope and wards | Clinical sponsor | Advises | Clinical sponsor |
| Infrastructure and access | Platform owner (IT) | Provides the build and runbook | CIO |
| Formulary and protocols | Pharmacy and clinical leads | Loads and validates | Governance group |
| Model approval before go-live | Governance group | Supplies validation evidence | Chair of governance |
| Consent notice and patient rights | Data protection officer | Supplies the template | DPO |
| Training delivery | Ward leads release staff | Trains by role | Clinical sponsor |
| Baseline measurement | Quality team | Defines the method, does not touch the data | Quality lead |
| Incidents during the pilot | Existing incident process | Investigates the platform's part | Medical director |
| Go or no-go | Sponsor and governance group | Presents evidence | Hospital |
The baseline is measured by the hospital's own quality team, not by us. A vendor measuring its own before-and-after is the fastest way to make a real improvement unbelievable.
03
Before day one
A consultant or medical director who will chair the weekly review and defend the pilot when it is inconvenient.
Volunteered, not assigned. A ward told to pilot software will prove nothing except that it was told.
Who owns access, integrations and the environment, and can act inside a day.
Chair, clinical owners, DPO and platform owner. First meeting held before installation.
Staging with de-identified data, and production. See the architecture document's readiness checklist.
Which analyser or HIS sends what, over which protocol, from which address.
Which model provider, if any, may see patient text — recorded with a name and a date.
The manual fallback per module, agreed with the ward leads.
04
Taking the baseline
Four numbers, measured the same way before and after. Write the method down in week one and do not change it in week twelve.
| Measure | Method | Sample | Baseline |
|---|---|---|---|
| Documentation minutes per consultation | Observed and timed, not self-reported | [30 consultations per ward] | [__ min] |
| Denial and short-payment rate | Denials ÷ claims submitted, by payer, with reason codes | [3 months of claims] | [__%] |
| Length of stay, case-mix adjusted | Adjusted; unadjusted numbers move for reasons unrelated to software | [Same two wards, 3 months] | [__ days] |
| Time to communicate a critical result | Minutes from the finding to a named clinician acknowledging it | [All critical results in the period] | [__ min / not measured today] |
Most hospitals find they cannot state the fourth number at all. That is itself a finding worth taking to the quality committee, and it is the measure most likely to improve visibly within the ninety days.
05
Configuration
Roughly two weeks of work, most of it the hospital's own content rather than software settings.
- Wards and beds loaded to match the physical layout, including bays and isolation rooms.
- Roles mapped to real staff, including who may approve prescriptions, sign notes, and read the audit trail. Start tighter than feels comfortable; widening is easy.
- Your formulary replaces the seed list. Until it does, an unknown drug is flagged rather than cleared — safe, but noisy.
- Approved protocols loaded into the Clinical Brain with owner, version and approval date. Documents are screened for injected text before indexing.
- Consent notice approved by the DPO, in the languages your patients speak, and in use at registration.
- Escalation contacts for critical results, by ward and by shift, including out of hours.
- Feeds connected in staging first, with a week of shadow running before production.
Point the lab feed at staging for a week and compare what arrives against the analyser's own report. Mapping errors surface here, cheaply, instead of on a ward round.
06
Training
Short, role-specific and hands-on. Nobody learns clinical software from a slide deck.
| Role | Length | Covers |
|---|---|---|
| Doctors | [45 min] | Patient 360, dictating a consultation, reviewing and signing a draft, what an override means and when to write a reason |
| Nurses | [45 min] | Ward board, recording vitals, sepsis bundle timers, handover, escalating an alert |
| Pharmacists | [30 min] | Dispense checks, batches and expiry, controlled-drug entries, stewardship flags |
| Radiologists | [30 min] | Dictation to structured report, signing, recording critical-result communication |
| Reception and records | [30 min] | Registration, consent capture, patient links, rights requests |
| Governance group | [60 min] | Guardian console, model registry, audit verification, the monthly agenda |
Every session shows a case where the system was wrong or incomplete, and what the clinician did about it. Training that only shows success produces staff who trust the screen more than their own judgement — the exact failure mode the platform is designed to avoid.
07
Go-live runbook
Day −1
- Safety suite run on production configuration; results filed with the governance group.
- Backups verified and a restore tested in the last month.
- Ward leads confirm staffing for the first two days, with a super-user on each shift.
- Downtime procedure printed and physically on the ward.
Day 0
- Enable the modules in the agreed order: Record first, then scribe, then ward board. Not all at once.
- Floor-walking support on both wards for the whole shift, by someone who can change configuration the same hour.
- Issue log open from the first minute; every issue gets an owner and a time.
- End-of-day huddle on each ward: what worked, what annoyed, what to change tonight.
Day 1 onward
- Daily stand-up for the first week, then weekly.
- Configuration changes batched into one evening release rather than made live during a shift.
- First audit-chain verification and compliance pack printed at the end of week one, to prove it works before anyone needs it.
Any module can be switched off from the Guardian console without touching the rest. If a ward asks for it to stop, it stops that shift — then we find out why. A pilot that cannot be halted is not a pilot.
08
The first four weeks live
The weekly review is the engine of the pilot. Forty-five minutes, same agenda, chaired by the clinical sponsor.
- What the system got wrong. Overrides and rejected drafts, read out, with the clinician present where possible.
- Alerts per shift by category. Anything dismissed almost every time is changed or switched off — the alert is at fault, not the staff.
- Critical results: every one, and how long it took to reach a named person.
- Issue log: what is open, what is fixed, what is waiting on the hospital.
- One thing to change this week. Only one, so it can actually be assessed.
An override rate of zero is a warning sign, not a success. It usually means staff are signing without reading. If it appears, say so out loud in the review and check a sample of signed drafts against their source.
09
Support and escalation
| Severity | Example | Response | Route |
|---|---|---|---|
| 1 · Patient safety | Missed escalation, unsafe draft signed, critical result not delivered | [Immediate] | Clinical sponsor and medical director, model suspended if implicated |
| 2 · Clinical workflow blocked | Ward board down, cannot sign notes | [Within 1 hour] | Platform owner and named engineer |
| 3 · Degraded | Drafting falling back to templates, a feed rejecting messages | [Same working day] | Platform owner |
| 4 · Request | Configuration change, new user, report | [Next release] | Issue log |
Severity 1 follows the hospital's existing incident process first. The platform's part is investigated alongside it, never instead of it, and the audit entry id is recorded on the incident so the two records can be read together.
10
Risks, and what we do about them
| Risk | Sign it is happening | What we do |
|---|---|---|
| Clinicians do not adopt it | Dictation unused after week two | Sit with them for a shift. If the workflow is wrong, change it or stop the module — do not train harder. |
| Alert fatigue | A category dismissed almost every time | Change the threshold or switch it off; record the decision in the governance minutes. |
| Baseline never taken | Week three arrives with no numbers | Pause go-live. The pilot cannot produce evidence without it. |
| Feed mapping errors | Unmapped results in the interop log | Shadow run catches most; the rest surface as text rather than as a wrong value. |
| Scope creep | A third ward asks to join in week six | Write it down as "after the decision" and thank them — it is a good sign. |
| Key staff leave mid-pilot | Sponsor or platform owner changes | Named deputies from week zero; the pilot pauses rather than drifts. |
11
The decision
At week twelve the hospital decides. These are the inputs, and they are agreed at week zero so nobody moves the goalposts afterwards.
- The four measures, before and after, measured the same way by the same team.
- The clinicians' verdict, collected directly — would they keep it, and what would they change?
- The safety record: incidents, overrides, alerts dismissed, critical results communicated in time.
- The compliance pack, printed from real use, with the audit chain verified.
- The cost, against the value model's assumptions — replaced now with what actually happened.
If the numbers do not move and the clinicians would not keep it, the honest conclusion is to stop. We would rather a hospital said no at week twelve than renewed for a year out of politeness — and we would rather know what did not work.
12
Scaling beyond the pilot
- Ward by ward, not all at once. Each new ward gets the same training and a super-user, and the first week is supported.
- Modules in the order that earned trust in the pilot, usually Record and scribe first, then ward and ICU, then pharmacy and radiology.
- Governance keeps meeting monthly with the same agenda. Scale multiplies exposure; the review is what keeps pace with it.
- Re-baseline each new area before it goes live. A hospital-wide number hides the ward that got worse.
- Infrastructure review at the top of the sizing table: a background queue and separated interoperability endpoints, as the architecture document sets out.
13
Templates
Week ___ Date ________ Chair ______________ Present ______________ 1. What the system got wrong this week Overrides: ____ Rejected drafts: ____ Examples discussed: ________ 2. Alerts per shift, by category Dismissed almost always? ________ 3. Critical results: count ____ Longest time to acknowledge ____ min 4. Issue log: open ____ fixed ____ waiting on hospital ____ 5. The one change for next week: _________________________________ Owner: ____________ Review on: ____________
[ ] Safety suite passed on production config Signed: ________ [ ] Backup verified, restore tested within 30 days Date: ________ [ ] Super-user on each shift, both wards Names: ________ [ ] Downtime procedure printed and on the ward [ ] Modules enabled in order: Record __ Scribe __ Ward board __ [ ] Issue log open, owner named [ ] End-of-day huddle held on each ward Notes: ________
Id ____ Raised ________ By ______________ Ward ____________ Severity: [ ] 1 safety [ ] 2 blocked [ ] 3 degraded [ ] 4 request What happened: ___________________________________________________ Audit entry id (if any): __________ Patient affected: [ ] no [ ] yes Owner: ____________ Target: ________ Closed: ________ Resolution / change made: ________________________________________