HOSPITAL OPERATIONS · PRODUCTION PRODUCT
Patient Rounding
Nurse and leader rounding for Elevra, the hospital operations platform at Compass Healthcare Digital.
Opportunities had been designed as a separate module. In a working session we separated the two ways sites rounded, so I made an opportunity a state of the follow-up record sites already used, with assignment that branches by who does the rounding. Engineering scoped one system instead of two.
Two ways
sites rounded, nurse and leader.
One record
an opportunity became a state of it.
One system
engineering scoped, instead of two.
Production workflow recreated
The round stayed inside the platform nurses already used.
A recreation of Elevra's rounding surface.
- Patient
- Diane Foster · ICU 201-A
- Finding
- Missed drink in meal order
- Follow-up
- Open · Food & Nutrition
- Owner
- Unit leader
The round closes. The follow-up it raised does not.
Where it came from
These are real screens from the shipped product, reconstructed for this site. Every patient, site, and record shown is demo data.
The nav stack
Flat, then grouped by workflow, then focused to the module you're in.
The card wall
A repeated card, then a comparable row, then a record you can act on.
On the floor
The round happens at the bedside, on the same record.
Leaders carry a tablet on the unit. Each answer they tap is the row the desktop above shows.
Rounds
My rounds, Monday, March 9
Brian Coleman
54, MMed-Surg 305-BRND-1042, Nurse round
6 questions, Nurse leader script v3
Before you begin
Is the patient ready for rounding?
Environment of care
Is the room clean and well-maintained?
Is the bathroom being disinfected regularly?
Was the housekeeper courteous and respectful?
Food and nutrition
Is the patient satisfied with the menu options?
Was the diet order delivered correctly?
ELEVRA / PATIENT ROUNDING
The round ends.The follow-up continues.
RD-1184 / Leader round
Round completed
Diane Foster, ICU / 201-A
Follow-up
Finish the round. Keep the concern.
Keep unresolved concerns visible.
Service recovery
A concern becomes owned work
Was the room clean and well-maintained?
Make follow-up actionable.
Give follow-up an owner.
Follow-ups / FU-2481
One record throughout
Blanket warmer out of service
Record history
FU-2481
Keep one record, not two.
Preserve one record throughout.
Two names for one thing, at two different moments of its life.
Six months of screens never surfaced it, because a screen cannot show you where a record lives.
The object under discussion
Blanket warmer out of service
Blanket warmer out of service
The same lifecycle, built a second time.
One record, carrying its own history, wherever the finding is in its life.
Who rounds, by site
Each mark is a tenth of sites, by the team's working estimate. At seven, service line leaders did their own rounds. At three, a dedicated patient experience team did. Drawn as a separate module, every one of them would have kept a second record.
- Records per finding
- TwoOne
- Ownership
- Split across bothUnchanged
- Assignment
- Same everywhereBy operating model

The problem
Six months of screens, with no agreed model behind them.

Rounding is a scheduled walk of a hospital floor. Anything the rounder finds becomes a follow-up that someone has to close.
It is one module of a larger hospital operations platform.
In hand
Screens
Drawn over six months of informal conversation with stakeholders.
Not yet agreed
Or a release plan engineering could estimate.
Opportunities had been drawn as a module of their own, next to the follow-up system that already tracked each finding until it was closed.
Every prototype review reopened the same question: where does each thing live?
Rounding platforms treat a recorded concern as work with an owner: Qualtrics turns it into an assigned ticket, and CipherRounds alerts the team responsible for resolving it.
After the round
A finding becomes owned, timed work.
Rounding's weight sits in what happens after a “No”: the finding gets an owner and a clock, and the clock is why a finding has states at all.
What happens after a “No.”
Fig. 01Service-recovery loop
t = 0“Was the room clean and well-maintained?” answered No
Leaves the clock entirely and pages a supervisor at t = 0. An immediate escalation is not a shorter window, it is a different path.
The decisions
Three decisions changed the release.
A decision you can only see the outcome of is a claim. These carry what else was on the table and what each one cost, because that is the part a reader needs in order to disagree.
Stopped prototype iteration and mapped operating models instead.
Every review cycle re-opened the same questions about where things lived. In a working session we separated two operating models: at about a third of sites a dedicated patient experience team did the rounding, and at roughly 70% service line leaders did their own rounds, by the team's working estimate.
Rounding programs are staffed and scheduled very differently, from nurse managers rounding twice a day to food service teams hiring a dedicated rounding manager.
Nothing new to show in a review. A visible pause reads as a real cost in that kind of organization, and it was the right one to pay.
Made an opportunity a state a follow‑up can be in, rather than its own module.
The operating-model mapping showed an opportunity and a follow-up were the same object at different points in its life. A parallel module meant a second queue beside the follow-ups system sites already ran, with a finding raised in one place and closed in another.
Rounding tools route a finding to an owner: Qualtrics assigns a ticket, CipherRounds alerts the responsible team, and Aramark uses rounds for immediate service recovery.
Opportunities lost its own place in the navigation and the stakeholders who had been reviewing it as a distinct module lost the thing they could point at. It also meant reworking designs that had already been through review, which is the least popular kind of rework.
Phased the release around technical dependencies and pushed the patient module to last.
The patient module needed hospital census data from the admit, discharge and transfer feed, which came from a third-party record system on its own timeline. Patient lists and census-based dashboard metrics depended on it too.
Rounding platforms build their patient lists from hospital census feeds through ADT and EHR integrations.
The champion, who controlled pilot access, resisted the deferral. I reframed it as pilot risk: validate core rounds first rather than wait on a dependency nobody on the team controlled. The deferral was accepted once the dependency map was on the table.
Follow-ups
| Record | Finding | Location | Owner | State |
|---|---|---|---|---|
FU-2481 | Blanket warmer out of service | ICU / 201-A | EVS lead, night | Opportunity |
FU-2477 | Meal delivery missed | Med-Surg / 305-B | Nutrition lead | Scheduled |
FU-2469 | Room not turned over | ED / 102 | EVS lead, day | Resolved |
FU-2484 | Call light response time | ICU / 203-A | Charge nurse | Logged |
Fig. 02Release sequence
The round itself
History and question-level detail
The patient module
Nothing waits.
What shipped in each phase
Logging a round, raising a follow-up, closing it. The part every site does the same way, whichever operating model it runs.
The guardrails
Two guardrails the model still had to preserve.
Context is there before the round begins.
Before you walk in
ICU / 201-A
- Diet
- Regular, Low Sodium
- Language
- English
- Mobility
- Assisted, one person
Kudos on this patient's rounds
Explained the discharge plan to the son
Megan Alford, NursingAug 14
Waited so the family could finish saying goodbye
Dana Whitfield, TransportAug 13
Room turned over before the family arrived
Rosa Villanueva, EVSAug 12
The mandate
I defined the module’s product model.
AnupProduct definition
- Module architecture and release structure
- Operating models and site segmentation
ManagerPortfolio direction
- Roadmap above the module
- Final prioritization across the portfolio
- Handoff plan
EngineeringImplementation
- Admit, discharge and transfer integrations
- Estimation and production behavior of follow-ups
04 What changed
What came of it.
A clearer architecture, a production workflow, and a stop before duplication.
- The operating model gave the team something concrete to decide against.InheritedNo agreed architecture
- Rounding shipped inside the existing follow-ups workflow, not as a parallel product.ShippedExisting follow-ups workflow
- Engineering accepted the correction instead of building two competing systems.AcceptedOne path forward
- The instrument I would add: time from a negative finding to named ownership.Next measureTime to named ownership
- AI-assisted capture stayed in early testing. The patient module waited on an upstream feed.OpenAI capture, external module
05 Reflection
Next time the architecture is settled before any prototype exists.
The last two rows are the ones I keep returning to. Six months of screens had been standing in for an architecture.
The prototype did earn its place once. The sharpest objection to the design, that two rounders covering the same unit could log one finding twice, surfaced only because the prototype made the scenario visible.
Settle the architecture before prototyping. Use the prototype to expose failures you cannot see on paper.
More work








