EHR Performance Optimization

What is EHR performance optimization?

EHR performance optimization is the technical work of making an electronic health record respond quickly and predictably: measuring response times for real clinical tasks, finding the layer that causes delay, and fixing it in the database, application, network, APIs or interfaces. It differs from workflow optimization, which changes what users do rather than how fast the system answers.

The goal is predictability as much as speed. A chart that opens in two seconds every time feels faster than one that usually opens in one second and sometimes takes fifteen, and the slow tail is where most of the clinical frustration and risk sits.

How should you measure EHR performance?

Measure EHR performance by timing the clinical tasks users perform, at percentiles, by site and time of day. Server CPU graphs explain a slowdown; they do not tell you whether clinicians are waiting.

• Task timings: Chart open, patient search, order entry, note sign, results review and medication administration, timed from click to usable screen.
• Percentiles: Track the median and the 95th percentile. Averages hide the slow tail that users remember.
• Segments: Split by site, department, device type and hour, because a slowdown at one clinic over a slow link looks like noise in the overall average.
• Synthetic checks: A scripted test patient opened every few minutes from each major site gives a steady baseline that does not depend on user volume.
• Interface lag: Time from an event in the source system, such as a result being finalized, to its appearance in the chart.
• Batch windows: Start and end times of nightly jobs, extracts and backups, and whether they still finish before the morning clinics start.

Agree on targets with clinical leaders before tuning starts, written per task and per percentile. Without targets, every fix is a success and nobody knows when to stop.

Where does EHR latency come from?

EHR latency comes from one of six layers, and the fix depends on finding the right one. Trace a slow task end to end before changing anything, because tuning the wrong layer wastes weeks.

• Client: Heavy screens, large scripts, many widgets loading at once, or an old workstation. Common after a template adds sections nobody uses.
• Network and virtual desktop: Latency to a remote data center, or an overloaded virtual desktop host, often isolated to particular sites.
• Application server: Thread pools or memory exhausted under peak load, or a screen that makes dozens of sequential calls instead of a few.
• Database: Missing indexes, stale statistics, lock contention, or reporting queries competing with clinical transactions.
• External calls: Drug interaction checks, decision support services, eligibility lookups or third-party apps that respond slowly inside the user's click.
• Interfaces: Queues that delay results, orders and admissions, so the data the user needs is not there yet.

Distributed tracing, where each request carries an identifier through every service it touches, is the fastest way to see which layer owns the time. Where the EHR vendor controls the core, ask for its performance tooling and logs before guessing.

How do you tune the EHR database?

Tune the EHR database by finding the queries that consume the most time at peak and fixing those first. A handful of statements usually accounts for most of the load.

• Top queries: Rank statements by total time, not single execution time, since a fast query run a million times can cost more than a slow report.
• Query plans: Check plans for full scans on large clinical tables, and add or adjust indexes for the patient, encounter and date filters screens actually use.
• Statistics: Keep optimizer statistics current, especially after large data loads or migrations that change table sizes.
• Separate reporting: Move reports and extracts to a read replica or reporting database so they never compete with clinical transactions.
• Locks and transactions: Keep transactions short, and find the long-running ones that block note signing or order entry.
• Archiving: Move old audit and message tables to cheaper storage on a schedule, with retention rules agreed with compliance.

On a vendor-hosted EHR, much of this belongs to the vendor, but the customer still controls custom reports, extensions and integration queries. Those are frequently the source of the problem and are fully in the customer's hands.

How should EHR APIs handle large reads?

EHR APIs should page interactive reads and move population-sized reads to asynchronous bulk export. An app that requests every observation for a patient in one call will be slow for the user and expensive for the server.

The FHIR R4 search specification defines _count as the number of results per page and states that servers shall not return more resources than requested, but may return fewer. The FHIR http page adds that page links are opaque to the client and that the client must use the server-supplied links to move between pages. Clients that build their own paging URLs break when the server changes its paging method.

For large data sets, the HL7 FHIR Bulk Data Access guide defines an asynchronous pattern. The client starts an export, the server answers with 202 Accepted and a Content-Location header for a status endpoint, and the client polls it. The guide says clients should back off exponentially, servers should send a Retry-After header, and a server should answer clients that poll too often with 429 Too Many Requests.

• Ask for less: Filter by date and category, and request only the resource types the screen needs.
• Page by default: Set a sensible page size and follow next links only when the user scrolls or the job needs them.
• Cache reference data: Practitioners, locations and value sets change rarely and should not be fetched on every request.
• Go asynchronous: Use bulk export for population work, and schedule it outside clinic peaks.
• Respect limits: Honor 429 responses and Retry-After headers rather than retrying immediately.

How do you keep EHR interfaces from falling behind?

Keep interfaces current by measuring queue depth and age, sizing throughput for the peak hour, and isolating slow destinations so they cannot block others. An interface that is up but an hour behind is a clinical problem.

• Queue age alerts: Alert on the age of the oldest message in each queue, not just on whether the connection is up.
• Peak sizing: Size for the busiest hour, such as morning lab draws and admissions, not the daily average.
• Isolation: Give each destination its own queue, so one slow receiver does not hold messages bound for others.
• Acknowledgments: Check HL7 v2 acknowledgment handling, since a receiver that is slow to return ACKs throttles the sender.
• Ordering: Preserve order per patient where it matters, such as admit before transfer, and parallelize across patients.
• Error queues: Route failed messages to a reviewed error queue instead of retrying forever at the head of the line.

Message transformations are a common hidden cost. A mapping that looks up reference data in a database for every field of every message works in testing and stalls at peak volume; cache the lookups or precompute them.

How do you test performance before an upgrade?

Test performance before an upgrade with a load test that replays realistic clinical activity against a production-sized copy. Functional testing on an empty test environment will not find the problems users will feel.

• 1. Workload model: Build the test from production logs: which tasks, how often, at what peak concurrency.
• 2. Data volume: Use a copy with production-scale tables, de-identified where possible, because small tables hide missing indexes.
• 3. Baseline: Run the test on the current version first, so you compare like with like.
• 4. Peak and soak: Run at peak load, then for several hours to find memory leaks and queue build-up.
• 5. Interfaces included: Replay inbound message volume during the test, since interfaces and users compete for the same database.
• 6. Go or no-go: Compare results with the agreed targets and fix regressions before the upgrade date, not after.

EHR performance failure points

• Averages only: The dashboard shows a good mean while one site waits ten seconds on every chart open.
• Reports at peak: A large report scheduled at 9 a.m. competes with clinic start.
• Chatty integrations: A third-party app makes hundreds of API calls per chart open.
• Unbounded searches: A patient search without filters returns every match to the client.
• Silent queue growth: Interface monitoring checks connections but not message age.
• Untested upgrades: A new version ships after functional testing only, and a changed query plan appears in production.

Most of these are scheduling and design choices, not hardware limits. Adding servers hides them for a while, but the same slow query or chatty screen returns as volume grows, so fix the cause before buying capacity.

How Agnotic can help

Agnotic Technologies traces slow EHR tasks end to end for clients, finds the layer that owns the delay, and fixes it, whether that means query and index changes on a custom EHR, paging and caching in an integration, or queue isolation and mapping changes in an interface engine.

For upgrades and new integrations, Agnotic builds realistic load tests and monitoring of task timings and interface lag, so a performance regression is found in testing rather than reported by clinicians.

Sources

• HL7 FHIR R4: Search, page count
• HL7 FHIR R4: RESTful API, paging
• HL7 FHIR Bulk Data Access IG v3.0.0: Export