HOSPITAL OPERATIONS · PRODUCTION PRODUCT
Patient Rounding
Nurse and leader rounding for Elevra, the hospital operations platform at Compass Healthcare Digital.
Correcting a module architecture under a deadline, then phasing the release around the one dependency the team did not own.
The real surface
The round stayed inside the platform nurses already used.
A recreation of Elevra's rounding surface.
Nurse's View
Elevra
Sacred Heart Medical
Completed rounds
50%
Below Target (90%)
Patients w/o rounds
2
Needs Attention
Rounds w/ opportunity
25%
In Range (15-25%)
Rounds
4 rounds on this roster1 with an open opportunity
Diane Foster
67y · ICU / 201-A
Missed drink in meal order
Last updated
Today, 9:41 AM
by System
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 navigation items in one left rail, no grouping between them.
The card wall
Round cards repeat the same anatomy, whether the round is new or already complete.
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.
Sites already running follow-up
Each mark is a tenth of the estate. Seven of them already ran follow-up in production, so a second module would have duplicated the record at every one of those seven.
- Records per finding
- TwoOne
- Ownership
- Split across bothUnchanged
- Sites needing a second workflow
- Seven in tenNone
The problem
Six months of conversation, no structure.
Rounding is a hospital operations routine: a floor gets walked on a schedule, and what's found becomes a follow-up somebody has to close.
One module in a wider hospital operations platform, not a standalone build.
Six months of informal conversation. Screens existed. No agreed architecture, no release structure.
Opportunities drawn as their own module, beside a follow-ups system most sites were already running.
The prototype was doing work that requirements conversations should have been doing.
What the screens missed
The parts that never made it to a screenshot.
Every screen above is real, but partial. Rounding's actual weight sits in what happens after a “No”: the finding becomes a timed piece of work somebody owns, and the clock on it is the reason a finding has states at all.
What happens after a “No.”
Fig. 01Service-recovery loop
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. The mapping that replaced it turned up the thing that reordered the release: sites did not round one way.
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 the two were the same object at different points in its life. A parallel module would have duplicated a follow-ups workflow already running at roughly 70% of sites, with people trained on it and data in it.
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.
It depended on the hospital admit, discharge and transfer feed, an integration owned outside the team. Everything else in the rounding suite could be built without it.
The most compelling part of the story moved out of the first release. It was read as scope reduction until it was reframed as pilot risk, and reframing it took a conversation rather than a slide.
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.
The guardrails
Two guardrails the model still had to preserve.
Consent comes before capability.
AI interaction layer · early testing
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
Design defined the product model. Engineering owned implementation.
Anup
Product definition and design
- Module architecture and release structure
- Operating models and site segmentation
Manager
Portfolio roadmap and prioritization
- Roadmap above the module
- Final prioritization across the portfolio
- Handoff plan
Engineering
Implementation from this point forward
- Admit, discharge and transfer integrations
- Estimation and production behavior of follow-ups
Design established what the system needed to be. Engineering owned how it became production software.
04 What changed
What came of it.
A clearer architecture, a production workflow, and a stop before duplication.
- Six months of screens had not resolved the architecture. The operating model gave the team something concrete to decide against.InheritedNo agreed architecture
- Rounding stayed inside the follow-ups workflow already running at roughly 70% of sites, and shipped there rather than as a parallel product.ShippedExisting follow-ups workflow
- Engineering accepted the architecture correction and scoped one path forward instead of two competing systems.AcceptedOne path forward
- Adoption and time saved were never measured. The instrument I would add: time from a negative finding to named ownership.Not measuredAdoption, time saved
- AI-assisted capture remained in early testing. The external patient module stayed dependent on an upstream feed outside this release.OpenAI capture, external module
05 Reflection
The stop should have come sooner.
The last two rows are the ones I keep returning to. Six months of screens had been standing in for an architecture, and I built on them for longer than I should have. Next time the information architecture gets settled in one structured session before any prototype exists.
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.
The judgment I keep is which questions deserve a prototype, and which ones get one so they can be avoided.
More work