EHR implementation challenges: a practical guide for hospital innovation teams

Some of the issues with EHR are technical, many are about how the organization is set up, and the most important ones often involve more than one of these areas. People in charge of innovation, CMIOs, and EHR project managers usually spot these problems straight away. The trickier question is which patterns can help reduce them. This article walks through the most common problems hospital innovation teams encounter in EHR implementation, with practical patterns for each.

What EHR implementation involves today

The way EHRs are set up will be very different by 2026 than it was in the previous decade. The first step back then was to get hospitals to start using electronic records. The current trend is to add new features to existing systems. Technology such as AI can help with a lot. For example, with documentation, clinical decision support, ambient scribes, predictive analytics, patient portals, and third-party tools.

There are three main things that shape this work today. The vendor landscape is concentrated, with Epic, Oracle Health, and Meditech accounting for most acute care deployments. This means that other institutions can use most patterns and lessons. Clinicians are very busy, and paperwork is one of the main reasons why they get so tired of their job. The rules on AI and data exchange are becoming stricter, making it more difficult to govern, even as new tools appear more quickly. Each of these things is the reason why almost every challenge described below exists.

{{banner}}

The current EHR vendor landscape

The U.S. acute care market is dominated by three vendors. According to the most recent KLAS report, Epic now holds 42.3% of acute care hospitals and 54.9% of beds. Oracle Health holds 22.9%, while Meditech holds 14.8%, with the remainder split across smaller platforms. For innovation teams, this concentration is helpful in some ways. For example, communities of practice exist, vendor extension points are well documented, and peer health systems often face similar problems on the same platforms.

Each time the system is installed, it is a bit different. One health system uses Epic at one campus, while another uses Meditech in ambulatory care or in a recently acquired facility. Even in one Epic installation, things are set up differently depending on the specialty, the service line, and the decisions made when it was first used. This is why patterns that work in one institution sometimes need to be changed before they can be used in another. Innovation teams usually create their own internal guides rather than relying completely on vendor documentation.

Common problems with EHR implementation for hospital innovation teams

This section focuses on the challenges that recur across most hospitals, regardless of size or specialty. They are presented in the order in which they typically surface during a deployment or an integration project.

Data quality and migration are harder than the project plan assumes

Almost every EHR project includes a data migration component. The data that arrives at the migration step rarely looks the way the project plan assumed, ending in:

• missing fields;
• inconsistent units;
• the same lab test coded differently across two campuses;
• structured fields often disagreeing with the free-text notes that accompany them;
• discharge times and statuses remaining unstable for several days after a patient encounter.

The introduction of AI tools on top of an EHR makes this more visible. Take a model that performs well on a clean, controlled dataset. If we use it in the real world, where data is messy, it can easily lose accuracy. When teams wait until after deployment to validate performance, they often realize the problem too late. By then, clinicians may have already started to lose trust in the system.

Every health system has a different mapping, a different way of recording the attributes. A practical approach is to plan validation as a parallel workstream, rather than as the final stage. Reconciliation checks should be carried out before, during, and after migration. For AI tools in particular, it helps to test the model early by running it on historical, de-identified data, well before starting any real clinical pilot. This allows them to understand the model’s performance on local data and complete any necessary retraining before clinicians interact with the system.

Every installation is configured differently, even within the same vendor

Innovation teams that have worked across more than one health system tend to recognize this challenge first. Two institutions running the same EHR can have meaningfully different field structures, ordering pathways, alert rules, and documentation flows. Devices that feed the EHR — Philips, GE Healthcare, Drager, Spacelabs, and others — each speak their own dialect. Thus, integrations that work in one ICU often need rework in another. Even a vendor upgrade within the same institution can change the assumptions on which an integration was built.

For internal AI and digital tools, scaling is affected more than initial deployment. For example, a clinical decision support tool built for one cardiology department may require significant modifications before it can be extended to another department. Such variations are rarely visible until the second or third deployment.

“You don’t feel the complexity on day one — you feel it when you try to scale.”

A common approach is to add an internal adapter layer between source systems and the products built on top of them. This usually includes a unified, canonical schema, separate translation modules for each source, and a dedicated test suite for every adapter, so a change in one place doesn’t ripple through the entire system. The investment is rarely justified by the first deployment, but it pays back repeatedly once a tool is asked to scale across service lines or campuses.

Clinical workflow disruption is the leading cause of failed adoption

Most EHR implementation teams have experienced some version of the same pattern. A new module, integration, or AI tool is deployed on schedule and passes IT and security reviews, but then fails to gain adoption because it creates obstacles for clinical staff.

The thing is, studies prove that ambulatory physicians already spend an average of 5.8 hours on the EHR for every 8 hours of scheduled patient time, and a meaningful share continue working in the system after hours. Any tool that adds clicks, windows, or context switches has to clear a high bar before clinicians choose to use it.

The most common signs of poor workflow integration are:

• tools requiring separate logins;
• dashboards displaying data that clinicians already have elsewhere;
• alert systems triggering too frequently;
• documentation flows not matching how clinicians structure visits.

Although these issues are not caused by the technology itself, they are the reason why powerful tools fail to deliver value at the bedside.

The patterns that work are already pretty clear. New tools are built directly into the EHR using things like Epic Hyperspace, Cerner SMART on FHIR, or Meditech Greenfield, and single sign-on is treated as a basic requirement, not a bonus.

Before any design work starts, teams take time to understand how clinicians actually work. And when it comes to visuals, the goal is to fit in seamlessly with the existing EHR. Innovation teams that lead with this discipline — often supported by dedicated healthcare UI/UX design practices — typically see adoption curves that earlier deployments could not produce.

Change management is more decisive than technical readiness

Change management is one of the most discussed but least funded parts of EHR implementation. Many innovation teams know how important it is, but the work is often put off until the final weeks before the site goes live. As a result, it is not used evenly. People keep finding ways to get around the problems, and there are lots of small problems that take up a lot of attention long after the official project has ended.

The most effective change management focuses on people. When doctors and nurses are comfortable with new systems, they tend to spot issues early and help their colleagues adjust. Training, in turn, works best when it’s tailored to specific roles, rather than trying to cover everyone at once. And when leaders like the CMO, CMIO, or CNIO are visibly involved, it signals that the change is here to stay.

{{banner-2}}

Interoperability still requires more work than the standards promise

According to the ASTP/ONC Data Brief No. 79 from August 2025, 70% of U.S. hospitals had enabled FHIR-based patient app access by 2024. The 21st Century Cures Act has also raised the baseline for what hospitals need to support. Thus, innovation teams now have more options than before for patient-facing apps and read-only integrations.

Even so, the daily work of interoperability still involves significant effort. For instance, write access is more constrained than read access and varies significantly by vendor and by configuration. Field-level mapping is still required between systems that both claim to support the same standard. Furthermore, devices, ancillary systems, and third-party applications introduce their own protocols on top of the EHR.

As a result, for innovation teams scaling AI or digital health tools across a network, integration work tends to remain a continuous engineering investment rather than a one-time effort.

AI governance has become a new core competency for innovation teams

In the last few years, AI review boards have become a standard fixture across U.S. health systems. They typically include the CMIO, CNIO, CIO, legal counsel, privacy officer, clinical leaders, and increasingly a dedicated AI ethics representative. Their role is to evaluate proposed AI tools, both vendor-procured and internally built.

For innovation teams, this changes the shape of how new tools are introduced. The questions an AI review board asks — about training data, retraining strategy, model versioning, drift monitoring, equity testing, and adverse-event handling — are now central to the implementation plan.

Internal teams that build their own AI tools typically benefit from preparing this documentation before the board asks for it. Teams that evaluate vendor AI find that the same questions are useful for procurement, since vendors that cannot answer them in depth often struggle once the tool reaches a clinical environment. For internal AI builds, this often involves dedicated AI integration work to align governance documentation with the system architecture before clinical pilots begin.

Clinician trust depends on explainability, not accuracy alone

Even when an AI tool is accurate, clinicians often choose not to rely on it when the results cannot be explained. If you have no context, a risk score of 78 percent provides little actionable information. The clinician who bears legal responsibility for the patient cannot delegate that responsibility to a model. So what they do is avoid the tool and eventually stop using it altogether.

“There is no one-size-fits-all in healthcare. The winner is the company that can adapt.”

There are three common patterns in tools that help to keep trust over time. Instead of showing confidence scores as single numbers, they are shown as limits. This means that clinicians can see uncertainty alongside the prediction. Each output includes a short reasoning trace, designed to be scanned in two or three seconds. The time it takes is shown next to the current value. In urgent care, how things change over time is often more important than the exact reading at that moment. Teams that make it a basic requirement when they are working with suppliers or creating their own systems tend to see much better results.

Demonstrating value is its own implementation discipline

Most EHR-related projects, especially those involving AI or new digital tools, eventually need to prove their value to a CFO or a value analysis committee. However, the metrics that matter at that stage are often different from those used in the initial pilot. While time saved per encounter is an easy concept to grasp, it doesn’t always translate cleanly into financial terms. As a result, finance teams tend to focus more on measurable outcomes like:

• freed FTE capacity;
• reduced claim denials;
• lower readmission penalties;
• faster discharges;
• fewer out-of-network referrals.

The challenge of framing value for non-clinical stakeholders is one Halo Lab has encountered directly. On the Develop Health platform, the design work focused on making the workflow immediately legible to both the physicians using it and the administrators evaluating it. The value case for prior authorization automation is about returning physicians’ attention to patient care. The design system was intentionally built to make that distinction immediately clear.

How Halo Lab supports hospital innovation teams

Halo Lab works with hospital innovation teams in two main scenarios, both centered on the user experience layer of EHR-connected products.

The first is supporting internal teams that are building AI or digital health tools on top of an existing EHR. In this setup, the institution typically carries the clinical and technical workload, while UX, interface design, and adoption-focused product work are done in close collaboration. The second is redesigning dashboards, modules, or clinician-facing surfaces that sit on top of an EHR, often as overlays in Epic or as embedded SMART on FHIR applications.

Our work on a Laboratory Information System for a multi-branch diagnostics provider could serve as a good example. In their case, the legacy system worked at a single site but couldn’t scale across multiple branches. Workflows were fragmented, reporting and billing had gaps, and onboarding developers took weeks.

Our work process included:

• rebuilding the platform with a modular front end, role-based access, per-branch configuration, and a unified data schema;
• workflow sessions involving lab technicians, pathologists, and administrators;
• designing more than fifty screens;
• delivering core modules for patient management, test accessioning, insurance, and physician records.

The platform now supports daily operations across multiple branches and is built to scale further.

Strategic notes for hospital innovation teams

EHR setup has improved over time, but the hardest problems haven’t gone away. Data quality and migration still matter, and integration costs vary widely depending on the vendor and configuration. More often than not, the real challenge is disruption to clinical workflows. As a result, areas like change management, interoperability, AI governance, clinician trust, and value measurement have become specialized disciplines of their own. And problems there resurface every time a new module or AI tool is added to the system.

Teams that treat EHR implementation as an ongoing program often develop internal ways of working to handle this complexity. They build habits around managing change, introducing new tools safely, and gathering feedback from clinicians and patients early. It’s this work that often separates health systems that consistently get value from their EHR investments from those that don’t.