Home » Readers Write » Currently Reading:

Readers Write: The Operational Divide in Healthcare: Epic-First Health Systems Versus Real-Time Health Systems

January 12, 2026 Readers Write 4 Comments

The Operational Divide in Healthcare: Epic-First Health Systems Versus Real-Time Health Systems
By Buzz Stewart, PhD, MPH

Walter “Buzz” Stewart, PhD, MPH is CEO of Medcurio.

image

An ongoing split is forming across US healthcare, a divide that health system leaders are driving overtly or by default.

On one side are the organizations building real-time reflexes into their operations. On the other are the organizations whose pace is still dictated by vendor-defined data access paths, delayed data, and workflows that are constrained by the vendor architecture.

This divide isn’t philosophical. It is operational. And it is widening fast. This will be the competitive divide for the next decade.

Two Emerging Camps

Markets don’t stall because of a single vendor. They stall when incumbents limit the freedom for customers to move faster, choose better, and innovate on top of their own data. As modernization accelerates, health systems are sorting into two identifiable groups:

Real-Time Health Systems

These organizations are developing the ability to govern their own data access, sense operational signals as they occur, and route actions immediately. They are beginning to build reflex loops, which are lightweight, programmable logic that prevents revenue loss (fewer denials, reduced LOS), mitigates safety drift, reduces manual intervention, and stabilizes workflows before problems compound. They seek destiny control and predictable value creation.

These organizations lean toward independence in how they access and use their own data, and they treat delay as a form of waste rather than an unavoidable byproduct of enterprise IT.

Epic-First Health Systems

These organizations face the same challenges as real-time health systems, but move at the speed of vendor-mediated access. They depend on (costly) sanctioned interfaces, roadmap timelines, batch extracts, and manual processes to identify operational issues. Limited tooling to say the least.

These organizations treat delays as an avoidable byproduct of enterprise IT and accumulating operational drag is their norm

Why the Divide Is Forming

Four forces are driving the move to real-time health systems faster than the industry expected:

  • Labor costs in healthcare have risen faster than inflation for five decades, while inflation-adjusted revenue per encounter has steadily declined as commercial mix shrinks. There is no way out from under the current operating model, and no real way to differentiate in most markets if you keep playing the old game.
  • Operational latency is a margin killer. Discharge delays, denials identified too late, referrals never acknowledged, eligibility errors discovered only after work is performed. Growth in small lags produces large financial consequences.
  • Vendor-controlled access is mismatched to modern workflow demands. Today’s problems require continuous monitoring, immediate detection, and on-demand logic. Architecture designed for retrospective insight isn’t built for real-time operations. HL7/X12 alone doesn’t cut it, and FHIR resources and vendor-gated APIs are imprecise and overly narrow.
  • AI and automation cannot run on delayed signals. The industry is extremely optimistic about automation, but models and agents (and the workflows health systems are pointing them toward) are useless without upstream real-time detection. If an organization only learns that a problem occurred after the fact, no amount of workflow redesign can compensate.

These forces have shifted the strategic question from “What technology do we need?” to “How fast can we recognize and act on our own operational signals?” as the foundation for automation and innovation capabilities.

The Hidden Cost of Delay (Waiting is a Cost Center)

  • Throughput slowdowns that no one sees until the backlog materializes.
  • Denials that could have been prevented if noticed earlier.
  • Eligibility mismatches found only in downstream billing.
  • Referral leakage due to missed handoffs.
  • Safety triggers that surface only when reports are pulled.

Every service unit has its list, but they look remarkably similar across health systems.

While these issues rarely appear as technology failures, they often show up as operational realities. Every one of these problems is a real-time problem trapped in a legacy data access model. The cost of delay is not just inefficiency, but also lost margin, avoidable friction, patient harm, and workforce strain.

What Real-Time Reflexes Look Like

Organizations that operate in real time do not wait for dashboards to tell them what happened. They program their systems to notice and act on what matters in real-time:

  • Detecting a mismatch the moment it occurs.
  • Automatically triggering a task or action
  • Routing information directly to the workflow that requires it.
  • Logging the event without human intervention.
  • Measuring impact within hours, not quarters.

Acting and adapting fast, which few systems do well today, is a strategic market differentiator and quickly becoming a survival imperative as this divide widens. This is the identity high-performing systems realize they must rise to.

Claiming Control of Your Own Data

The executive unlock is straightforward.

  • Your vendor has an obligation to allow access to your data however you choose.
  • Your vendor has a legal duty not to interfere with your use of your data.
  • Acting on your rights does not mean being in conflict with your vendor.
  • Sovereignty is not about choosing one technology path over another. It is about ensuring that the parts of the health system that depend on real-time signals (care transitions, revenue cycle, safety, operations) are not forced into delay by design.

Crossing the Divide: A Simple Playbook

Health systems don’t need multi-year digital transformation programs to build real-time reflexes. They need clarity and sequence.

  1. Map your highest-delay workflows. Where do teams wish they had real-time visibility but are stuck with overnight insight?
  2. Evaluate control. What should be legitimately controlled by the vendor versus what should be governed by the health system. This is almost always the inflection point.
  3. Test one workflow in real time. Pick one workflow and simply measure what happens when teams get the signal immediately instead of a day later. No committees or giant work plan, just a clean before and after.
  4. Scale reflex logic across additional domains. Once a health system sees its first real-time win, the pattern becomes contagious.

A Narrow Window

Every health system will be forced to modernize its reflexes. The question is timing.

Organizations that move now will define the performance frontier and expand markets. Those that wait to modernize will fall further behind.



HIStalk Featured Sponsors

     

Currently there are "4 comments" on this Article:

  1. I’m not sure these two camps are anything new, or should be lumped into “Real time systems” vs “Epic-first”. These are operational and cultural factors of different organizations, some of which seem to rely more heavily on vendors vs their own homegrown tools and pushing the limits of what their tech can deliver. Most of the issues you attribute to Epic-first organizations don’t seem inherent to using Epic as your EMR. Agree that real-time reflexes are necessary, but the Epic-first angle seems like a strawman to just bring in Epic to the conversation and make them the scapegoat.

    • Appreciate the thoughtful pushback. Where I want to focus is on what “Epic-first” actually means in practice as it relates to interop. In many organizations, it describes a posture where real-time access is either very limited (and to legacy interfaces), or otherwise available only through heavily gated, costly APIs that are designed first for commercial control (not for continuous operational reflex).

      That’s not a criticism of Epic as an EMR. It’s a reality of how large platforms preserve moats and govern access. When health systems accept those boundaries as the outer limit of what’s possible (rather than something to be questioned or augmented) delay becomes structural. The winners are just simply moving outside of that confined box.

  2. I asked ChatGPT “What are the odds this article was AI-generated?” and pasted the article into it. It’s response:

    Short answer: moderate to high probability it was AI-generated or AI-assisted.

    Assessment:

    1. Stylistic signals (strong)
    – Repetitive parallel structures (“This divide isn’t… It is… And it is…”)
    – High density of declarative, absolutist claims without attribution
    – Marketing-essay cadence: short paragraphs, punchy headings, rhetorical certainty
    – Abstract nouns stacked together (“operational latency,” “destiny control,” “reflex loops”)

    These are common in LLM-generated thought-leadership prose.

    2. Content characteristics (moderate)
    – No concrete case studies, metrics, or named organizations
    – Vague technical critique (e.g., “FHIR resources and vendor-gated APIs are imprecise”) without specifics
    – Broad industry generalizations presented as inevitabilities

    This fits AI output or human marketing/strategy writing—but AI increases likelihood.

    3. Internal consistency (weak signal)
    – A few semantic slips (“These organizations treat delays as an avoidable byproduct…” appears inverted)
    – Redundant framing restated multiple times with new labels

    LLMs often do this; humans sometimes do, but usually clean it up.

    4. Human counter-signals (against AI)
    – Domain knowledge is real and coherent
    – Argument is internally aligned with a specific vendor posture (anti–vendor-mediated access)

    This suggests either a human author or an AI heavily guided by a human with intent.

    Estimated odds:
    – AI-generated or heavily AI-assisted: 65–75%
    – Fully human-written: 25–35%

    Confidence level: ~0.7
    No definitive proof without metadata, drafts, or author disclosure.

    I’d love to hear from the author one way or the other.

  3. The author here keeps introducing irrelevant ideas.

    It’s true that there are nimble organizations and bureaucratic ones. What is the difference? Well, this statement is wrong: “This divide isn’t philosophical.” Oh, I beg to differ! It is absolutely philosophical.

    A bureaucracy is prone to saying things like, “We have to maintain control”, or “Let’s have (someone) take a look at that”, or “every situation is unique”. Taking a look at the implications, this means human interventions. Every time. And they never, ever measure the cost of routing the matter to a supervisor. There is an all-consuming belief in process and not much interest in the consequences of that.

    Control is absolutely good, but there are different ways to achieve this. When you always hit the Pause button in order to maintain control, you’ve really lost your own perspective. When every situation is an Exception, you’ve lost your agency to understand and identify patterns.

    Technology here is a red herring. I mean, it can nudge you in one direction or another. But if your corporate culture is strong (meaning dominant, not in the sense of ‘good’)? The tech won’t change a thing.

Text Ads


RECENT COMMENTS

  1. RE: Surescripts survey finds that more than half of of patients have experienced delays or disruption in getting their prescriptions…

  2. In fairness to the person on the thread the other day: Now THIS is politics on the blog. :)

  3. Thank you for your comments on Amazon. Agree 100%

  4. For the broader community, Neil Pappalardo was an important person within the community well beyond the impact he had on…

  5. Move your quotes to where they should be and it's no longer politics-in-the-blog, but instead a fact that's true at…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.