Advocating for EHR Development Using Stories and Data
Written By: Aracely Sosa, PharmD; Emily Gamroth, PharmD; Elizabeth Hartell, PharmD, MHI, Laleh Javanbakht, PharmD, BCPS
Introduction
The continuous optimization and development of electronic health records (EHRs) is a requirement that stems not only from legislative mandates such as those from the HITECH Act, 21st Century Cures Act, and more, but also from a system need to have and use EHRs that are up-to-date, consistent, and flexible to meet current clinical practice while also incorporating the variability of practice across healthcare institutions.
Advocating for EHR development or change from an EHR vendor can be a distinct process depending on the EHR vendor, the healthcare organization requesting change, and the overall ask. Most EHR vendors give the ability for organizations to internally customize base/foundation EHR settings to support their specific institutional needs. Depending on the vendor, organizations may also have the option to submit requests for development of new functionality which could benefit their own institutions along with others across the nation. It is important to note, however, that the openness of the vendor toward input from customers varies as well as the capability of a vendor to customize their EHR.
Fortunately, there have been instances where EHR vendors have accepted and implemented changes. Below we have highlighted some stories where organizations have successfully pushed for new EHR developments and worked together with their vendors to create innovative tools that were much needed in the field.
Advocating for change naturally has its challenges to overcome. Challenges with making changes from the EHR vendor perspective include prioritization of development requests and being conscientious of differences in needs/wants between their customers. There are also inherent technical limitations that may exist within the EHR. For institutions, it may be difficult to quantitatively justify change or conceptualize their change request. These topics will be discussed at length within this blog.
Challenges stories
Inpatient Medication Orders Default Count Type: Doses vs. Days
An internal medication safety report at an integrated healthcare system (Advocate Health, Wisconsin/Illinois Division) related to incorrect duration of therapy being ordered (e.g., 3 doses instead of 3 days) on inpatient medication orders prompted the discussion of whether the default duration count type should be updated within the EHR. A retrospective review of all wrong duration errors reported in 2022 showed the following:
- - 39 events where a duration using ‘doses’ count type instead of ‘days’, 90% of which were orders for anti-infective agents.
- - 4 events where a duration using ‘days’ count type instead of ‘doses’, 50% of which were orders for anti-infective agents.
- - 13 events where a duration using ‘days’ count type instead of ‘hours’, 50% of which were for intravenous maintenance fluids.
Clinical subject matter experts (SMEs), as part of the organization’s pharmacy governance process, led the initiative and were given an overview of available default options within the EHR (i.e., doses, days, or hours). Additionally, they were advised that it would be problematic to have considerable complexity in agents having differences in default count type, both in terms of end-user training as well as future maintenance of EHR build necessary for these defaults. Due to resource limitations within the pharmacy informatics team, no comprehensive testing or investigation on implications of the build concept were completed. Ultimately, it was decided to update the inpatient default duration count type to ‘days’ for most medications with the rationale that this count type made sense for most therapies and the ordering user maintains the ability to manually update the order to a different count type than what is selected by default.
The default duration count type was updated for most formulary medication orders from ‘doses’ to ‘days’. This change was implemented on 9/19/2023. Scope of change:
- - Inpatient ad hoc orders (i.e., orders placed outside of use case specific pathways such as order sets).
- - All patient populations (i.e., pediatric and adult patients)
- - Specific medications were approved by clinical SMEs to maintain the ‘doses’ default when the general use of the agent warranted it (e.g., albumin, nitroglycerin ointment, alvimopan, etc.)
- - Maintained existing standard of all emergency department non-continuous infusion ad hoc orders defaulting to ‘1 dose’.
Prior to the intervention, outpatient orders already defaulted the duration count type to ‘days’, while inpatient orders generally defaulted to ‘doses’. These respective settings were those provided by default from the EHR vendor (i.e., no previous work had been done to supersede the settings provided by the EHR vendor).
Due to the change, there were unintended consequences due to technical limitations. The EHR allows users to modify active orders. If the active order has a defined duration (e.g., 5 days) and the frequency is modified (e.g., from every 12 hours [Q12H] to every 8 hours [Q8H]), the duration count type would revert to that of the EHR vendor default for inpatient orders (i.e., ‘doses’). In other words, if an order was initially placed for 5 days, then the order frequency was later modified, the duration field automatically cleared and default the count type updated to ‘doses’. Additionally, no warning would pop up for the end-user as an indication that a change from the initial ordered duration took place. Discussions with the EHR vendor yielded acknowledgement by the vendor that this is undesirable behavior and subsequently, the vendor submitted internal documentation to develop improved functionality.
The vendor’s initial development to alleviate the above issue consisted of an in-line alert when a user modified an order frequency where-in the user was prompted to select discrete options of ‘Previous end date’, ‘Previous duration (# doses)’, or ‘Until Discontinued’. Upon testing these options, focusing on the ‘Previous end date’ since it was the only option to maintain the default count type of ‘days’, it was found that there were inaccuracies in how the EHR calculated durations of therapy. High level, the issues found included:
- Changing an order frequency to be higher than previously (ex: Q12H to Q8H) put the patient at risk of not receiving enough doses.
- Clinical concern: cutting the duration of therapy short for an anti-infective regimen could result in under-treatment.
- Changing an order frequency to be lower than previously (ex: Q8H to DAILY) put the patient at risk of receiving too many doses.
- Example of clinical case concern: anticoagulant therapy extending longer than intended increases the risk of adverse event without need and/or possibly may result in delays in care (e.g., if the patient needs to be off anticoagulant therapy to have a procedure done).
Following discussion with the EHR vendor on the discovered inaccuracies, urgent development was done to allow for an override alert where-in users were presented with a warning that the order frequency had changed and to prompt review of the ordered duration. This alert did not include any discrete options for users to select.
Another issue identified post go-live was persistent confusion for end-users in having the default count type of ‘days’. This resulted in increased safety events reported for wrong duration errors. It is notable that the increased communication/education circulated to clinicians in preparation for the change may have had a role in increasing the attention paid to ordered durations, thereby making it more likely that errors would be noticed and reported. Ultimately, the decision was to revert the change for all medications except anti-infective agents. The reversion was implemented on 7/16/2024.
This case example illustrates the point that interventions to the EHR should be cautious of using strong evidence in a specific area to justify broader, sweeping changes. In this case, the strongest evidence for making the default count type of ‘days’ was from anti-infective orders, but the rationale used to justify changing the default for most other medications was based on the assumption that this finding could be applied to non-anti-infective orders. More regular involvement from the pharmacy informatics team, especially for more analysis and testing of functionality, during the decision-making process would have enabled decision makers to know more of the nuances in the EHR resulting from choosing one path versus another.
Drug-Drug Interaction Alert Customization
This challenge story highlights clinical decision support surrounding high risk medications like chemotherapy, particularly busulfan and high dose methotrexate, which require pharmacist intervention at the time of verification, and ongoing monitoring to ensure safe and effective therapeutic use. Part of this assessment includes evaluation of certain drug-drug interactions (DDIs) that can be detrimental to the patient’s course of therapy. In addition, the workflows related to oncology ambulatory workflows may be different in relation to how the orders are ordered and prepared, that present challenges in the EHR for the best time to alert for these orders. A PGY2 oncology yearlong project aimed to address these issues by requesting a customized DDI alert to help support pharmacist assessment in these situations.
EHR platforms may not be equipped to handle more nuanced and targeted interactions, necessitating custom alert build that requires increased resources for testing and ongoing maintenance burden. In addition, certain DDIs may benefit from more patient-specific information (lab values, certain doses, administration schedule) to be taken into account for the best alert experience.
Given these challenges expressed by oncology subject matter experts, a customized alert was proposed by this stakeholder group as the best option given limitations of the current DDI alert infrastructure, and ongoing reports of manual review required by pharmacists to gather the necessary information for DDI assessment. Additionally, the limited timeframe allotted for a PGY2 yearlong project to gather pre and post data could be utilized to support the value of utilizing this customized alert framework for potential future alerts.
Ultimately, a customized alert within the EHR that incorporated patient-specific information (dose, drug levels, and start dates) was created through collaboration with oncology specialists. The alert was piloted at a single site as part of the PGY2 yearlong project and was evaluated for impact.
There were multiple lessons learned during this project. First, the importance of integrating (a dedicated) builder early in the process to scope the best solution and bring through appropriate governance groups, especially with other large enterprise initiatives occurring simultaneously during a large health system merger. In addition, creating a customized alert to the exact precision may in theory be ideal but also relies on ideal situations for it to function “as designed”. This can lead to reworking and redesigning and potential over-engineering for an alert (especially when the alert is homegrown and not within the confines of the EHR DDI infrastructure). Another challenge with this project was the overall resources put into the evaluation of the proposed solution, testing, may not actually yield the true value and benefit – i.e. a (customized) alert may not always be the right answer. Resources and time are a big component of ensuring an alert is well designed. With the resources needed for this build, along with competing priorities at the time of the request, the turnaround time for the build felt rushed, which can lead to a suboptimal product. The feedback from end users reflected this, noting that “as this alert was completely developed within a one-month timeframe, it is still somewhat rough around the edges...”. While the overall feedback was that this alert did fill a gap, the current EHR DDI medication alerts do not; further refinement is needed to make it impactful to the masses, not just to one site. Further discussions are needed to determine the applicability of this build to future clinical scenarios, and if this framework is sustainable going forward with the resources it takes to create and maintain this customized build.
To help ease some of the customized build burden that needs to be done to truly target the workflow, more nuanced build options within the framework of the EHR would help support the builders in intaking these requests.
This challenge story illustrates overall how medication warnings would benefit from additional EHR development and through collaboration with EHR vendors as potential opportunities for improvement.
Success stories
HCPCS code requirement optimization request
A recent change in Medicare’s HCPCS code requirements created a significant challenge for analysts working within the Epic electronic health record (EHR). When Medicare began mandating manufacturer‑ or NDC‑specific HCPCS codes, it introduced a level of maintenance and complexity that hadn’t previously been considered.
At University of Utah Health, analysts attempted to address this by building a manufacturer‑specific override rule at the medication record (ERX) level, but the workaround wasn’t always reliable and often led to billing issues.
Recognizing the need for a long‑term solution, two pharmacy technician analysts specializing in medication billing partnered with their Epic technical solutions (TS) engineer to advocate for a permanent fix. Through ongoing collaboration with their TS and Epic developers, they helped design a new Epic functionality that consistently replicates-and improves upon-the original override logic, greatly reducing errors and simplifying HCPCS maintenance for specific manufacturers. This enhancement was eventually incorporated into future Epic upgrades, allowing other healthcare organizations to benefit from the improved functionality.
Enhancing Renal Dose Adjustment: Integrating eGFR into EHR Clinical Decision Support
Effective EHR optimization can often depend on teamwork among healthcare systems, drug database providers, and EHR vendors. A recent collaboration between healthcare systems, First Databank (FDB), and EHR vendors is a notable example. In response to customer requests to provide enhanced renal dose adjustment data using estimated glomerular filtration rate (eGFR), FDB initiated enhancements to their Dosage Range Check Module for renal impairment (DRC Renal), incorporating eGFR-based dose adjustments alongside those based on CrCl.
The requests to enhance the DRC Renal data were triggered by the extensive integration of eGFR into routine clinical practice, which prompted the U.S. Food and Drug Administration (FDA) to recommend eGFR as a preferred measure for assessing renal function in pharmacokinetic studies.1 While the FDA deemed both eGFR and CrCl as suitable measures for evaluating renal function, it was apparent that healthcare systems required a way to differentiate between renally adjusted dose screening based on eGFR vs. CrCl.
To address the need for clear differentiation between eGFR and CrCl-based renal dose adjustments, the FDB clinical team undertook a comprehensive review of drug labeling to identify medications with recommendations specific to eGFR. As a result, an eGFR indicator field was introduced within the FDB DRC Renal data tables. This field designates, with an indicator value of 1 (Preferred), those drugs for which product labeling supports eGFR as the basis for renal dose adjustment. FDB is actively collaborating with EHR vendors to implement these enhancements. This initiative exemplifies the ongoing collaboration necessary for successful EHR development and enhancement.
Overarching Themes
Challenges:
EHR design often lacks empiric evidence to support one design option versus another or evidence that a certain design option should not be pursued. Initiatives presented as medication safety improvements often result in changes to the EHR without sufficient evaluation of whether the change will meaningfully improve outcomes or lead to intended behavior changes. Unintended consequences resulting from any design option are rarely given sufficient time or attention to be uncovered prior to implementing a change in the EHR. Along those same lines, the risks inherent to over-engineering a system to achieve a desired build design are rarely given serious consideration.
These challenges can be caused by various factors, but two to focus on here include technical resource limitations and tendency to defer design choices to clinical SMEs without guardrails. It is fitting that clinical SMEs are the primary source of change requests to the EHR, as they are ones who use the system to provide patient care, but there should be corresponding guidance provided by those with technical expertise. Ideally, those in clinical and technical roles collaborate to produce the most robust design option. Lack of balanced input from the clinical and technical arms is more likely to produce an EHR design that either fails to alleviate the core issue prompting the need for change or results in unintended consequences due to technical limitations. It is notable that to achieve this level of collaboration, there must be sufficient resource allocation by the organization.
Success:
Successfully advocating for EHR optimization requires a strategic, relationship-driven approach that balances a single institution’s needs with broader system impact. Start by clearly defining the problem using data that highlights workflow inefficiencies, clinician burden, or patient safety risks to build a compelling, evidence-based case. Whenever possible, frame requests as scalable solutions that could benefit multiple health systems, as vendors are more likely to prioritize changes with wide applicability. Engaging in user groups or collaborative forums can also amplify your voice and align your request with health institution trends across the nation. For example, Epic Systems Corporation © maintains a website for customers to submit ideas which are publicly broadcast and can be voted on by others across the nation who find the idea to be beneficial and impactful. Equally important is building trustworthy relationships with EHR vendor technical support specialists, who often act as spokespeople that advocate for their respective customers to the EHR vendors. Maintaining positive, professional relationships with these individuals could significantly influence how your request is prioritized and communicated internally. Additionally, aligning your proposal with regulatory requirements, interoperability standards, or vendor product roadmaps can further strengthen your case. By combining these strategies, organizations can significantly improve their chances of achieving meaningful EHR enhancements.
Conclusion
In conclusion, successful advocacy for EHR optimization with vendors is entirely possible when proposing enhancements using data-driven insights and with consideration of a broader scope of applicability. However, be aware of the potential challenges that could be encountered and identify strategies to mitigate these risks if possible.
References
- U.S. Food and Drug Administration, Center for Drug Evaluation and Research (CDER). Pharmacokinetics in Patients with Impaired Renal Function – Study Design, Data Analysis, and Impact on Dosing: Guidance for Industry. Draft guidance. Revision 2. September 2020.