A microphone on a rounding cart does not tell you what the hospital bought. It could feed a standalone AI scribe that drafts one note. It could sit inside a wider hospital product with discharge, claims, bed, scheduling, and record-system scope. The hardware looks identical. The operating boundary does not.
That boundary is the buying decision.
Takeaways:
- Buy the scribe when the bounded problem is note drafting and the surrounding systems already work.
- Evaluate a hospital copilot by named workflows, owners, review points, final systems, and fallbacks.
- Decide whether the incumbent HIS/EHR stays authoritative before comparing features.
- A demo passes only when the team can recover from a failure, not when one clean note appears.
Two products can share the same first screen
A standalone scribe listens during an encounter and prepares a note draft. The clinician checks the history, examination, assessment, and plan, corrects the text, and authenticates the record. CMS says medical records should be complete, legible, and recorded during or soon after the encounter. Its signature guidance also addresses authentication of entries made by scribes, including AI technology (CMS E/M guide, CMS signature guidance).
A hospital copilot may include that same drafting job, then place it beside other named hospital workflows. Patient Square lists Claims Management, AI Discharge Summary, Bed/IPD Management, and an AI Copilot EHR within Hospital Copilot. Those names define categories to investigate. They do not prove automatic filing, adjudication, diagnosis, coding, or an interface to an incumbent system.
The practical comparison starts one level below the product label.
| Buying question | Standalone AI scribe | Hospital copilot |
|---|---|---|
| Primary scope | Encounter documentation | Documentation plus named hospital workflows |
| Final decision | Clinician reviews and signs | Authorized owner still reviews each bounded output |
| Record-system choice | Usually keep the incumbent record system | Keep the incumbent or select a complete HIS/EHR path |
| Rollout unit | Clinician, specialty, or documentation team | Department plus workflow plus system boundary |
| Main failure mode | Bad or incomplete draft | Bad draft, broken handoff, wrong queue, or unclear system ownership |
| Evidence to request | Note quality, edit burden, consent, data handling | The same evidence plus interfaces, exceptions, reconciliation, downtime, and cutover |
Start with the work, not the bundle
Write one sentence for every workflow under consideration. Keep the verb and the final owner visible.
“The hospitalist reviews and signs a discharge-summary draft in the designated record” is testable. “AI automates discharge” is not. The first sentence names the person, artifact, review, and destination. The second hides all four.
Use a boundary sheet like this during procurement:
| Workflow | Source | Draft or task | Reviewer | Final system | Failure route |
|---|---|---|---|---|---|
| Ambulatory visit | Encounter plus approved context | Note draft | Treating clinician | Designated EHR | Existing documentation process |
| Inpatient discharge | Approved inpatient record | Summary draft | Responsible clinician | Designated EHR | Existing discharge process |
| Claims work | Signed record plus approved billing input | Reviewable work item, if contracted | Coding or billing staff | Claims system | Existing work queue |
| Bed workflow | Authorized census and operational input | Bed/IPD task, if contracted | Bed or operations staff | Named operational system | Manual bed board or current queue |
If a vendor cannot fill a cell without vague nouns, the scope is not ready for a contract. If the hospital cannot name the fallback, the scope is not ready for a live pilot.
The standalone scribe is often the right answer
A hospital does not need a platform project to fix every documentation problem. A standalone scribe can be the cleaner choice when five conditions hold:
- the hospital wants note drafting, not a record-system change;
- the current scheduling, discharge, claims, and bed workflows are staying in place;
- clinicians can review drafts inside a defined operating process;
- export and filing responsibilities are understood; and
- privacy, retention, access, and incident terms are acceptable.
That is a narrow purchase. Narrow is useful. It shortens the pilot, reduces dependencies, and lets the clinical owner measure edit burden without pretending the rest of the hospital changed.
The limit should remain visible. A draft does not select a diagnosis, choose an ICD-10 code for billing, send a prescription, or complete a claim. Patient Square describes ICD-10 output as suggestions and prescription content as a draft. Authorized people decide what becomes part of care and the legal record.
The copilot case begins at the handoff
A broader product earns its place when the hospital is buying several connected workflows or a new record-system path. Even then, connection is a hypothesis until the team sees evidence.
Follow one item across the floor. A discharge note begins with approved inpatient context. A clinician reviews it. The signed record may later support coding, billing, patient communication, and follow-up. Every handoff needs a source, an owner, a state, and a recovery rule. A bundle can reduce vendor boundaries, but it does not erase departmental boundaries.
NIST’s AI Risk Management Framework organizes work around Govern, Map, Measure, and Manage (NIST AI RMF). The labels fit a hospital evaluation well:
- Govern: name the clinical, operational, privacy, security, and technical owners.
- Map: document the workflow, affected people, data, dependencies, and failure consequences.
- Measure: define what the pilot will count and inspect.
- Manage: set stop rules, incident routes, change control, and expansion criteria.
This is not paperwork for its own sake. It keeps a polished demo from becoming an unnamed production dependency.
Settle the record-system path early
Patient Square describes two Hospital Copilot deployments. A hospital may keep its incumbent HIS/EHR and use selected Patient Square workflows alongside it, or choose the complete Patient Square HIS/EHR as the system of record. The first path needs explicit handoffs and reconciliation. The second adds migration, cutover, downtime, archival, and staff-transition work.
Neither path is automatically smaller. An incumbent path can accumulate interface and duplicate-entry work. A replacement path can turn one product decision into a hospital-wide data and operations program.
Ask for a one-page answer to these questions before pricing the rollout:
- Which system is authoritative before, during, and after the pilot?
- Which data must move, and which historical data stays where it is?
- Is the proposed movement an export, a live interface, or manual entry?
- Who reconciles a partial failure or duplicate?
- How does the hospital return to the established process?
- What evidence proves that an output reached the intended record?
Patient Square states “EHR-ready export (PDF · HL7 · FHIR).” That is an export-format statement. It is not proof of a live endpoint, named EHR connection, automatic write-back, or conformance certification. Treat every live exchange as separate discovery until the parties document and test it.
Put privacy terms beside the workflow
HHS says a cloud service provider that creates, receives, maintains, or transmits ePHI for a covered entity or business associate is generally a business associate, even when the information is encrypted and the provider lacks the key. The regulated organization needs an applicable business associate agreement and its own risk analysis (HHS cloud guidance).
Do not review that obligation in a separate track from the workflow. For each cell, record what data enters, where it goes, whether audio is retained, which derived artifacts persist, who can access them, how access is logged, what subcontractors touch them, and how return or deletion works.
A short-lived pilot still handles real information if real patients are involved. Run the first failure tests with synthetic patients and approved test accounts.
The demo should break on purpose
One accurate draft proves very little. Use a synthetic case and force the process through conditions the sales path would rather skip:
- two similar patient identities;
- a missing source field;
- a correction after the first draft;
- an unauthorized user;
- an unavailable destination;
- a network interruption;
- a staff handoff; and
- service restoration after queued work exists.
Observe the product and the people. Does the draft remain visibly unreviewed? Can staff tell which system is authoritative? Does a retry create a duplicate? Can the authorized user correct the record without hiding the earlier state? Does the fallback work while the queue grows?
The purchase is ready for a pilot when the hospital can answer those questions in writing. It is ready to expand only after the same workflow passes its stop rules across representative shifts.
Patient Square’s stated boundary
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus a bundled AI EHR, scheduling, and messaging as you move up the plan. Hospitals get Hospital Copilot.
Hospital Copilot is demo-priced. It lists ten modules and supports either a complete Patient Square HIS/EHR or an incumbent-system path. Module names are the start of discovery, not permission to infer unlisted behavior. The Hospital Copilot page carries the current scope.
Bring the boundary sheet to the call.