How to Improve an EHR

How do you improve an EHR that is already live?

To improve a live EHR, run a standing optimization program with four parts: a governance group that ranks problems, analysts who fix the build, role-based training for the people a change affects, and analytics from audit logs that show whether each fix worked. Repeat the cycle on a fixed schedule rather than in one-off projects.

Optimization assumes the product stays. Whether to replace an EHR is a separate decision, and this program is what an organization runs once it has chosen to keep the system and make it work better.

Usability testing feeds the program but is not the program. Tests show where a task is hard. The program decides which hard tasks to fix first, who fixes them and how the result is checked.

Who should govern EHR optimization?

A small group with clinical, operational and technical members, and the authority to say no, should govern it. Without that authority, requests are handled in arrival order and the loudest department wins.

• Clinical chair: A practicing physician or advanced practice provider with protected time, who decides between competing clinical requests.
• Nursing lead: Nursing documentation, medication administration and flowsheets carry much of the build, so nursing needs its own voice.
• Pharmacy and laboratory: Reviewers for any change that touches medication orders, interaction checks or results.
• Revenue cycle: A reviewer for changes that affect charges, coding or claim edits.
• EHR and integration analysts: The people who estimate effort, flag upgrade risk and own the build.
• Data analyst: The person who sets the baseline measure for each request and reports the result after release.

Rank each request on patient safety risk, the number of users affected, the time it would save and the effort it needs. Publish the ranked list, so requesters can see where their item stands and why.

Keep a release calendar alongside the list. A predictable schedule lets departments plan training and lets analysts batch related build changes into one tested release.

Which build fixes pay off first?

Fixes that remove work for many users at once, or remove a safety risk, come first. Changes to shared content usually beat new tools, because they reach every user on the next release.

• Note templates: Remove sections nobody uses and default text nobody reads. Since 1 January 2021, CMS has let practitioners choose office and outpatient E/M visit levels by medical decision making or total time, with history and exam performed as medically appropriate, so templates built to count history and exam elements can be trimmed.
• Order sets: Merge duplicates, remove orders nobody selects, and align defaults with current clinical guidance.
• Interruptive alerts: Review each rule's firing and override counts, then retire or retarget the ones users nearly always override.
• Inbox routing: Send results and messages to the right role the first time, so clinicians stop forwarding items staff could handle.
• Worklists: Build role-specific lists so users stop searching for the patients they are responsible for.
• Interface gaps: Fix unmapped codes and missing results that force manual entry or phone calls.

Each fix gets a before measure, a change and an after measure. A fix that cannot be measured should at least have a named group of users who confirm it helped.

Some fixes need more than configuration. When a request needs data from another system or logic the EHR cannot hold, route it to the extension work covered under EHR customization, with the same ranking and measures.

How should training change after go-live?

Training after go-live should be short, role-specific and tied to the changes being released, not a repeat of the original course. Clinicians who learned the system once need help with the work they do every day.

• Release notes by role: A short note for each role describing what changed and why, sent before the release goes live.
• At-the-elbow sessions: A trainer or super user sits with a clinician during real clinic work and sets up preferences and shortcuts.
• Personalization: Preference lists, favorites and personal phrases set up with each user, which take little time and are easy to skip at go-live.
• New-hire path: A role-based course for new staff that reflects the current build, not the build from go-live.
• Super user network: A named, trained person in each department who passes on changes and reports problems back.

Use the analytics to target training. Users who spend far more time in the record than peers in the same role and visit type are good candidates for a personal session.

What should EHR analytics measure?

Analytics should measure the burden and safety signals the program is trying to change, by role and department, on a regular schedule. EHR audit logs are the main data source, and the HIPAA Security Rule's audit controls standard at 45 CFR 164.312(b) already requires systems that hold ePHI to record activity.

• Time in the record: Minutes per visit or per shift, by role and department.
• After-hours work: Documentation time outside scheduled hours.
• Inbox load: Items per clinician per day and the time taken to clear them.
• Alerts: Firing and override counts for each rule.
• Order set use: The share of orders placed through order sets rather than one by one.
• Interface health: Unmapped codes and interface errors per week.
• Help desk: Tickets by category, so recurring problems show up as requests.

Report the same measures every month and mark each release on the chart. A trend that moves after a release is the program's evidence, and a trend that stays flat tells the group to revisit the fix.

Keep the measure definitions fixed. When a vendor changes how its logs count time, note the change and restate the baseline, or the program will report improvements that are only a change in counting.

How does one request move through the program?

A single request passes through all four parts in order: governance ranks it, analysts fix it, trainers explain it and the data analyst checks it. Following one example shows where each part does its work.

• 1. Intake: Primary care physicians report that routine result notifications fill their inbox and push urgent messages down the list.
• 2. Baseline: The data analyst pulls inbox items per physician per day, split by message type, and the time taken to clear them, for the previous three months.
• 3. Ranking: The governance group rates the request high on users affected and time saved, and checks the safety side: normal results must still reach someone who reviews them.
• 4. Design: Nursing, laboratory and the clinical chair agree a routing rule, for example normal results for stable patients go to a nurse pool with a clear escalation path.
• 5. Build and test: Analysts change the routing in a test environment and run real scenarios, including an abnormal result that must still reach the physician.
• 6. Training: Nurses in the pool get a short session on the new queue, and physicians get a release note explaining what they will no longer see and why.
• 7. Measure: The same inbox measures are reported for the months after release, next to a count of escalations from the nurse pool.

If the inbox numbers fall and escalations stay manageable, the change stays. If not, the request goes back to step 4 with the data attached, rather than being argued about from memory.

Which federal requirements overlap with the program?

No federal rule requires an optimization program, but some requirements land on the same work and are easier to meet inside one.

• SAFER Guides: CMS Promoting Interoperability programs require an annual attestation to a SAFER Guides self-assessment, and the ASTP/ONC guides themselves are voluntary checklists that point to safety-related build fixes.
• Audit data: The audit controls standard behind the analytics means the activity data already exists, so the program's work is defining measures on it, not collecting it.
• Documentation rules: The E/M visit-level change described under build fixes is one federal documentation change that template work can act on, and coding staff should review any template before trimmed sections go live.

Feed the annual SAFER self-assessment into the ranked list. Items the assessment flags become requests like any other, each with an owner and a target release.

Why optimization programs lose momentum

• No baseline: Changes go live without a before measure, so nobody can show they helped.
• An unranked backlog: Every request stays open and none is finished.
• Fixes without training: A better build that users do not know about changes nothing.
• Dashboards nobody reviews: Measures are built but never discussed at the governance meeting.
• Upgrades crowd out fixes: Each vendor upgrade absorbs the analyst team, and optimization pauses until it is over.
• A chair without time: The clinical lead has no protected time, and meetings are cancelled.

Reserving part of the analyst team for optimization, separate from upgrade work, keeps the program moving between releases. Without that reserve, every upgrade resets the backlog.

How Agnotic can help

Two parts of an optimization program often need engineering the EHR team cannot spare: analytics built on audit-log and interface data, and the extensions or integrations for fixes configuration cannot reach. Agnotic Technologies builds both for the client: reporting pipelines with fixed measure definitions, inbox and worklist tools, SMART on FHIR apps and interface fixes for unmapped codes.

Agnotic works alongside the governance group, taking the ranked items that need software rather than configuration and returning before and after measures with each release.

Sources

• CMS: Evaluation and Management Services booklet (MLN006764)
• ASTP/ONC: SAFER Guides
• CMS: Promoting Interoperability programs
• 45 CFR 164.312: HIPAA technical safeguards, including (b) audit controls