Put a hospital floor plan on the wall. Mark one department, one shift, and one piece of work. That is the first implementation cell. Everything outside the line stays unchanged until the cell produces evidence.
Hospital copilot implementation fails on vague scope long before it fails on model choice. “Launch the platform” gives nobody a safe unit to test. A department rollout gives the hospital a clinical owner, source system, reviewer, fallback, and decision date for each cell.
Key takeaways
- Roll out one department-workflow cell at a time.
- Give each cell a clinical owner, operations owner, system owner, and pause authority.
- Simulate identity, routing, correction, outage, and rollback before live use.
- Expand on measured evidence, not the size of the vendor’s module catalog.
Build the rollout board
The rows are departments. The columns are workflows. A cell might be “hospitalist discharge-summary draft” or “cardiology clinic visit-note draft.” It is not “hospital AI.”
| Department | First workflow | Source | Human review | Final system | Fallback |
|---|---|---|---|---|---|
| Ambulatory clinic | Visit-note draft | Encounter and approved chart context | Treating clinician | Designated EHR | Established documentation route |
| Hospital medicine | Discharge-summary draft | Approved inpatient record | Responsible clinician | Designated EHR | Existing discharge process |
| Access center | Scheduling task | Approved schedules and booking rules | Authorized staff or configured rule | Scheduling system | Staff booking queue |
| Revenue cycle | Reviewable claims work item, if in scope | Signed record and approved billing inputs | Coding or billing staff | Claims system | Existing work queue |
The last column determines whether the cell can be piloted. If staff cannot explain the fallback, the rollout is not ready.
Patient Square’s Hospital Copilot page lists documentation and operational modules and describes both a complete Patient Square HIS/EHR path and an incumbent-system path (Hospital Copilot). Those choices change the board. A bundled record system adds migration and cutover. An incumbent path adds interface and reconciliation work. Neither route should be inferred from the product name.
Give six people explicit authority
The executive sponsor funds the change and resolves priorities. The clinical owner defines acceptable use and can stop a clinical workflow. The operations owner manages staffing, training, and exceptions. The privacy and security owner reviews data handling and incidents. The record-system owner controls configuration, interfaces, and downtime. The vendor counterpart owns product escalation.
One person can hold more than one role in a smaller hospital. No role can be blank.
NIST’s AI Risk Management Framework uses Govern, Map, Measure, and Manage as its core functions (NIST AI RMF). The AI RMF Playbook supplies optional actions. A rollout board turns those ideas into operating assignments: governance names authority, mapping defines the cell, measurement sets pass conditions, and management decides what happens next.
Phase 0: contract and architecture
Complete this before patient data enters the pilot.
Document the data used by each cell, the vendor’s role, retention, permitted uses, access, incident route, return or deletion, subcontractors, and service dependencies. HHS says a covered entity using a cloud service to maintain electronic protected health information needs an applicable business associate agreement and must perform its own risk analysis (HHS cloud guidance).
Name the authoritative system for every output. If an AI prepares a note, label it as a draft and identify the authentication event. CMS’s July 2025 guidance says the treating physician or non-physician practitioner must sign entries made by a scribe, including AI technology, to authenticate the documentation and care (CMS signature guidance).
Draw dependencies. Identity, patient matching, schedules, clinical context, results, messaging, billing, and the record system each need an owner. A line on the diagram is also a possible failure route.
Phase 1: simulation room
Use fictional patients and approved test accounts. Run the cell through ordinary work, then make it uncomfortable.
Create two similar patient names. Remove a source field. Send a correction after the draft appears. Deny one user access. Break the destination. Delay a dependency. Restore service and watch what duplicates. Ask a staff member who missed training to take over.
The ASTP/ONC SAFER Guides cover patient identification, organizational responsibilities, system configuration, test-result follow-up, clinician communication, and contingency planning among their EHR safety areas (SAFER Guides). Select the guides that touch the cell and turn their recommended practices into simulation cases.
Record findings in four columns: trigger, observed behavior, risk, owner. Fix the workflow and rerun the same case. A new slide deck is not a retest.
Phase 2: one shift, shadow mode
Choose willing users and representative work. Keep the established process authoritative while the team compares the copilot output. Do not select only the cleanest cases.
For documentation, measure missing content, misplaced content, corrections, completion time, and the point of sign-off. For operations, measure wrong queues, staff takeover, unresolved exceptions, and final completion in the authoritative system. Track counts and examples. A single average can hide a rare event the clinical owner would never accept.
Hold a ten-minute review at shift end. The owner categorizes failures while the context is fresh. Product bugs, configuration errors, workflow gaps, source-data problems, and training misses need different responses.
Phase 3: limited live pilot
Move the cell into normal work only after simulation and shadow-mode pass conditions are met. Keep the user set and case scope bounded. Publish the fallback at the workstation, not in a project folder nobody opens during an outage.
The person with pause authority should be reachable during every pilot shift. Staff need a plain instruction: stop the cell, use the fallback, preserve the evidence, and route the incident. They should not debug a clinical workflow while a queue grows.
Review performance daily at first. Weekly review is enough only after exception patterns stabilize and owners are closing them within the agreed time.
Phase 4: expand across one axis
Expand to more users in the same department or the same workflow in another department. Do not widen both at once. One-axis expansion keeps the comparison legible.
Before expansion, require:
- pass conditions met for the agreed review period;
- no unresolved stop-rule event;
- exception volume within staffed capacity;
- downtime and rollback rehearsed;
- contracts and interfaces valid for the wider scope;
- the receiving department’s clinical and operational owners named.
If the next department changes the clinical vocabulary, source systems, staffing, or record path, treat it as a new cell. Success in dermatology does not validate a surgery workflow. Success in an ambulatory note does not validate claims routing.
The stop card
Print one card for each cell. It should name conditions that pause work immediately, conditions that trigger same-day review, and conditions that can wait for the weekly meeting.
Wrong-patient content, an unclear final status, an unauthorized disclosure, loss of the approved fallback, or an output sent beyond its review boundary belong in the first category. Repeated template mismatch may belong in the second. Cosmetic preferences can wait.
The clinical owner sets those categories. The vendor can help investigate; it does not decide the hospital’s tolerance.
The board after go-live
Keep the rollout board. It becomes the operating inventory: departments, workflows, data sources, reviewers, final systems, fallbacks, measures, and owners. Review it when a module changes, an interface moves, a vendor updates terms, or a department changes its process.
The floor plan should fill slowly.