Director says ICA RTT is fine. StoreFront returned 200. The VDA is green. The nurse is still waiting for the chart. That is the Epic response-time problem in one sentence: remoting health is not the wait the clinician feels.
Direct answer: Measure Epic — Hyperspace or Hyperdrive — response time from what the clinician sees on the screen — on the glass — not only from Citrix HDX/ICA counters, RDP latency, StoreFront or Workspace HTTP, or host CPU. Time the interval from a click or key until the expected Epic screen state is visible. That interval is click-to-ready. It is the number a CAB, a help desk, and clinical informatics can share.
Epic is the EHR and application layer. Citrix, Microsoft RDS, AVD, and other VDI stacks deliver the pixels. Product context: Epic / EHR on the glass. Sister posts on the same glass clock: Citrix, RDS, and cloud VDI response time. Load-test method: How to load test Citrix and How to load test Citrix Virtual Apps and Desktops. This article is narrower: how to time Epic itself.
Why a green Director tile is not “the chart appeared”
HDX, ICA, RDP, and cloud remoting protocols move pixels out and keyboard and mouse in. Director, Monitor, broker health, and host CPU are good at telling you the session is up and the channel is healthy. They are not a stopwatch for “Hyperspace painted” or “the chart is ready.”
A session can stream a logon animation, a spinning cursor, or a half-drawn Epic window and still look connected. Profile attach, GPO, FSLogix (or equivalent), and the EHR client itself sit after remoting is already up. StoreFront and Workspace are websites. Hammering them with an HTTP generator times the store, not the chart.
A green Director tile is useful. It is not the same as “the chart appeared.”
Host CPU can sit at 40 percent while login-to-shell stretches and Hyperdrive paints late. Protocol RTT can look fine while open-chart stalls. Green remoting tiles do not close an “Epic is slow” ticket.
Left column is what broker, protocol, and host timers see. Right column is what the clinician waits on. Only the right column is Epic response time as a person experiences it.
Which Epic steps to time
Write the steps before you pick a tool. Three intervals cover most Epic UX arguments on published apps and remoted desktops:
- Logon-to-shell — from credentials submitted (or the Workspace / StoreFront / Gateway / portal launch) until a usable desktop or published-app window is ready: shell, icons, no logon animation. Not “the broker returned a session.”
- Epic / published-app launch — from the icon or Start-menu click until first usable paint of Hyperspace or Hyperdrive. Not “the process started on the VDA or Session Host.”
- In-session transactions — from the click or key that starts the work until the ready state: open chart, search, save, switch activity. This is the wait that generates “Epic is slow” tickets after everyone is already in session.
Pin the image, VDA or Session Host SKU, Workspace or Remote Desktop client, StoreFront / Gateway / portal build, and the published Epic resource. A timer on a moving image is a story, not a measurement.
For capacity work, run a logon storm separately from density. Storm stresses login-to-shell. Density stresses in-session chart and search work on hosts that already have clinicians. Blending them hides which interval broke.
Time it like a script, not a feeling
On remoted Epic there is no DOM event that means “done.” The practical signal is the bitmap. The measurement pattern is the same one CitraTest has used for years on published EHR GUIs:
- StartTimer when the user action happens — submit, Workspace launch, click, or key.
- WaitForImage until a baseline of the ready state is visible: the shell, the Hyperspace or Hyperdrive window, the chart.
- StopTimer when that image matches.
The recorded interval is click-to-ready for that step. Image recognition — and OCR when the ready state is text — is how you know the glass painted. You do not install an agent on the VDA to learn that. That is the core of on-the-glass APM.
That pipeline is the same for login, Epic launch, and in-session chart work. Change the start action and the ready image. Keep the timer.
Stopwatch versus synthetic
A person with a stopwatch can time one Epic logon on a quiet morning. That is a demo, not a measurement program.
A one-off cannot give you a tail, run at shift change every weekday, hold concurrent published-app sessions while timing open-chart, or attach a screenshot of the failed state. Means hide the damage until the service desk is already taking “Epic is slow” calls.
A synthetic does the same StartTimer → WaitForImage → StopTimer path as a real Workspace or Remote Desktop client, on a schedule or under load, with the same Hyperspace, Hyperdrive, and chart-ready baselines. That is on-the-glass monitoring when it runs continuously, and an Epic-on-Citrix (or RDS / AVD) load test when it ramps concurrent users.
If you only have a stopwatch, use it to write the acceptance line — then automate the line. Example language teams already put on capacity plans (schematic only, not a customer dataset): logon-to-shell 45 seconds at p95 and 60 seconds at p99; Epic published-app open 8 seconds at p95; open-chart inside the written budget at p95; fewer than 1 percent of runs fail, disconnect, or hang.
Continuous watch versus load test
On-the-glass is an idea, not a product SKU. Two jobs share the path for Epic:
- CitraTest VU load-tests capacity. Freeze the image, walk the real StoreFront / Workspace / Gateway path into published Epic, run storm and sustain as separate shapes, stop at the written budget. That is the concurrent-clinician number a CAB can defend. See CitraTest VU load testing.
- CitraTest APM watches production. The same login → Epic → open-chart steps, every N minutes, with alerts and screenshots when glass time slips. That is the morning watch after go-live or an image change. See CitraTest APM.
The lab answers “how many good Epic sessions fit on this SKU.” The watch answers “is today’s logon-to-shell and open-chart still inside the SLA.” Do not use a load-test generator as your only production monitor, and do not treat a single synthetic as a density number.
No agents on the VDAs, Session Hosts, or brokers are required for that path. Each virtual user or monitor is another Workspace or Remote Desktop session launching Epic like a clinician. If the generator desktop is pegged, you are measuring the lab, not the farm.
What this is not
- It is not a replacement for Director, Monitor, HDX Insights, RD Connection Broker health, or AVD host metrics. Keep those for the remoting path.
- It is not an HTTP soak of StoreFront, Workspace, or Gateway. Keep that for the front door.
- It is not “we have full-stack APM, so Epic is covered.” Published Hyperspace and Hyperdrive GUIs are pixels, not traces.
- It is not a claim about Epic’s internal tooling or proprietary metrics — only the delivered session UX on Citrix, RDS, AVD, and peers, on the glass.
- It is not a promise that last quarter’s number survives a new VDA image, FSLogix policy, Hyperdrive build, or a move to DaaS / AVD. Re-time the glass when the image changes.
Take the interval clinicians already wait
Epic response time, as a clinician experiences it, is click-to-ready on the glass — Hyperspace or Hyperdrive chart ready, not a green protocol tile. Time logon-to-shell, Epic published-app launch, and the in-session steps that generate tickets. Separate logon storm from density. Use a stopwatch only to write the line. Use a synthetic to keep the line: CitraTest VU under load, CitraTest APM every shift.
When you need that path without agents on the farm — real Workspace or Remote Desktop client, image and OCR, StartTimer to StopTimer for Epic — schedule a demo. Product pages: Epic / EHR on the glass, CitraTest VU, and CitraTest APM.