Your Epic System Has No Index

But there is a tool sitting in your Epic system that can fix that

Something breaks. A sepsis alert critical for quality metrics stops firing. A report returns numbers that do not match what the clinical team is seeing on the floor. IT gets the ticket and asks the question that precedes weeks of Epic project management archaeology: what broke, who built this, and why?

The problem is that the original build was in 2016. Someone then added a rule in an adjacent workflow. Now nothing works. Who owns it now? Why is the original build so stale? Who validated it when it went live? Which operational leader is responsible for reviewing the data? Did an operational owner even validate it at all?

In most health systems, the answer to those questions lives in someone’s memory, an 8-year-old email thread, a SharePoint folder with no URL, or a project file from an engagement on a consultant’s laptop 2000 miles away. The system itself has no idea.

This is not a technology failure. It is a documentation failure that compounds in every Epic system across the country while everyone remains focused on the next implementation, the next optimization project, the next upgrade cycle. We don’t have PDSA cycles (Plan-Do-Study-Act, the standard quality improvement loop). We have PDPDPDPDPD trajectories.

THE POLICY MANUAL NOBODY INDEXED

Epic is not a single application. It is tens of thousands of configuration decisions accumulated over decades. There are order sets, clinical decision support alerts, dashboards, quality metrics, flowsheet templates, documentation tools that all reflect a choice made at a specific moment by a specific person for a reason that may or may not be recorded anywhere.

Think of it as a policy manual for how your organization delivers clinical care, written collaboratively by dozens of people over fifteen years, with no table of contents, no version numbers, and no author names. The policies are all still technically in effect. Some conflict with each other. Some reflect workflows that no longer exist. Some were built around regulatory requirements that have since changed. You cannot tell which is which by reading them.

Epic actually built a solution to this problem into the Epic itself. It is called a Metadata record. They are structured records that can be attached to any Epic record. These records can hold the operational owner, the date the content was last reviewed, the clinical purpose it serves, the stakeholders who validated it, the strategic initiative it supports and even a hyperlink to an email thread from 8 years ago. Every report, every dashboard, every order set can be intimately connected to such a record and carry this information with it.

It is rare that any Epic health system has these populated at scale. It is actually exceptional that an organization has any populated at all.

ORGANIZATIONAL FIBRILLATION

I have had a version of the same conversation with IT leadership at health systems across the country. They do not need to be convinced this is a problem. They have a name for it — build drift, configuration sprawl, technical debt. I call it organizational fibrillation: it is ventricular fibrillation at the organizational level — every team contracting on its own, nothing coordinated, the system burning energy without moving anything forward.

The symptoms accumulate quietly. The same optimization project gets completed twice because no one documented what the first engagement changed and why. A strategic initiative around reducing readmissions or improving sepsis outcomes launches, and someone has to manually trace which Epic tools are actually connected to it — a process that takes weeks and may still be incomplete when it finishes. A new analyst opens a report and cannot determine whether the data is correct, who originally validated it, or whether the workflow it reflects still exists.

These are not hypothetical costs. They are real labor hours, repeated across every department, every upgrade cycle, every new initiative. They are also largely invisible on any dashboard a CFO or COO typically reviews.

WHAT HAPPENED WHEN WE COULD SEE WHAT WE HAD

When I was CMIO at what was Edward Elmhurst Health (now Endeavor Health), we built Metadata governance into our order set program. Order sets are the pre-configured bundles of medications, labs, imaging orders, and care instructions that guide clinical decision-making at the point of care. They are among the most consequential build in any Epic system. They are also among the most likely to drift out of alignment with current evidence and current workflow, quietly, without triggering any alert.

The governance process required tagging every order set with structured information: clinical owner, last review date, intended clinical purpose, stakeholders with sign-off authority. The analysts initially pushed back. It got in the way of closing the immediate ticket. Filling out those records for an entire order set library would be tedious, time-consuming work with no immediate visible payoff. The form-filling happens now. The benefit arrives later, maybe much later. It is difficult to explain why delayed gratification is worth the present pain.

But then the gratification came.

Laying out the full order set inventory with its metadata visible, we could see relationships between content that had always been invisible. We could plan our build and governance with similar order sets reviewed and built at the same time. The preoperative order sets for hernia repair, minor surgery, and hemorrhoidectomy turned out to be nearly identical. They had been built separately, reviewed separately, maintained separately for years. They were essentially the same order set carrying three different names.

We eliminated roughly a third of our total order set count through consolidation. But organization and visibility is what unlocked the process. Build time for a new or revised order set dropped from several hours to approximately thirty minutes on average. The analysts who had been most resistant became the program’s loudest advocates. They still build that way. They would not go back.

That result did not come from a more talented team or a better project methodology. It came from being able to see in an organized manner what we had built, how we built it, why we built it and who we needed to bring into the content and governance conversation.

THE ACTIVATION ENERGY PROBLEM

The reason this remains largely undone at most health systems is not ignorance. It is the economics of the work itself.

Standing up metadata governance at scale requires identifying an operational owner for each piece of content, establishing a review cadence, tagging clinical purpose and stakeholder accountability, and maintaining that information through every upgrade cycle and workflow change. For a health system with thousands of configuration records, the initial investment runs into hundreds of person-hours before a single downstream benefit is visible.

Consideration of this work effort is where this sort of proposal dies. Initially there is a collective nodding of heads but then there is far less enthusiasm once people realize the tedious and grinding effort this entails. Even if it gets out of a board room, the effort fades away like a New Year’s exercise resolution.

I remember pushing this at a sizable health care system not long ago. The analysts all looked excited and gave me verbal feedback that this is just what they needed to help them bring order to the build. Then the next ticket arrived. And the one after that. The metadata project never got a second meeting. Nobody killed it. It just stopped having a timeslot.

The payoff is real. It is also delayed, hard to quantify on a project charter, and easy to deprioritize when an urgent optimization request arrives — which it always does.

So the IT teams who understand the value surface it in strategy meetings, get agreement in principle, and then watch the bandwidth disappear into the next urgent project. The metadata records stay empty. The organizational fibrillation continues. The next optimization engagement starts from scratch.

THE CALCULATION IS ABOUT TO CHANGE

Epic is deploying a tool called Agent Factory — an AI toolset currently in use by Epic’s internal teams and expected to be broadly available to health systems within the year. I have pitched a specific use case for it at an Epic hackathon later this year, because I think it directly addresses the activation energy problem that has kept this untapped.

As I noted, the most painful part of metadata governance has always been the intake work: filling in dozens of discrete structured fields for each piece of content. It is a clerical exercise. It is not intellectually demanding. It is just relentlessly tedious, which is why it does not get done.

Agent Factory can change that. It can collect the normal data produced by a build project — the emails, the meeting notes, the ticket history, the Slack threads between the analyst and the operational owner — and use that material to populate the metadata record automatically. The governance decisions still require human judgment. The form-filling does not.

What this can create on the other side is something health systems have been approximating with expensive manual BI work: an infrastructure that can answer questions at the speed of a query rather than the speed of a consulting engagement. Questions like: which Epic tools are connected to our current sepsis reduction initiative? Which order sets have not been reviewed in the past eighteen months? We implemented this clinical decision support alert alongside this documentation template to reduce unnecessary imaging — is it working, and if not, who do we contact to adjust it? No one considers doing this now because the data does not exist in a usable form. Leveraging AI to create such a comprehensive Metadata data set can solve that problem.

Right now, answering any of those questions requires assembling a team and spending weeks tracing the build manually. With a well-maintained metadata layer and modern LLM tools, it becomes a question you can ask and get back an answer within minutes.

That is not an incremental efficiency gain. That is a different category of organizational capability.

THE ASK IS NOT TECHNICAL

Many IT teams at your Epic health system have probably already tried to start this. They understand the value. They have likely raised it in a strategy meeting at some point and watched it get deprioritized.

What they need is not a new budget line or a consulting engagement. It is an operational leader who decides this work is worth protecting from the constant pull of urgent tickets and quarterly deliverables.

That means shielding a small number of your most experienced analysts for a defined period to build the governance foundation before Agent Factory capabilities are widely deployed — so that when those tools arrive, there is something for them to build on. It means holding that space through several quarters where there is nothing visible to show for it. It means treating the configuration architecture of your Epic system as a strategic asset, not a utility that someone else maintains.

The CMO who is serious about connecting clinical initiatives to measurable outcomes in Epic needs this. The COO who is tired of getting different answers from different reports needs this. The CEO who wants to know which strategic investments have actually touched the build needs this.

None of them currently have it.

The question to ask your CIO or CMIO is not technical. It is simply: do we know who owns our build? And if not, what would it take to find out?

Your IT team will know what you are asking for. They have been waiting for a leader with the authority to help them give it to you.

John Lee is an emergency physician and Epic consultant who helps health systems bridge the gap between Epic’s capabilities and operational reality. He specializes in data architecture, registry optimization, and making Epic’s tools actually deliver results.

If you need help configuring your Epic environment to support these capabilities, connect with him on LinkedIn or via his website.