We Keep Treating the Symptoms. AI Gives Us a Chance to Fix the Disease. Maybe.
For AI to work, it needs a "Phase 2"
Recently, Graham Walker wrote something on LinkedIn that resonates with any physician who has dealt with Dr. Google and Dr. ChatGPT. He described a patient, an elderly woman who came to the ER with classic transient nerve compression. The issue was benign. He reassured her thoroughly, they laughed together, and she left. The next day, she was back, convinced by ChatGPT overnight that she was hours away from hyperphosphatemia brought on by kidney failure. She had normal labs. She spent four more hours in the ER because ChatGPT triggered her to worry about what we in medicine call a “zebra.” It is the medical equivalent of Occam’s Razor. If you hear hooves, think of horses, not zebras. He called the phenomenon “competing trust.” Artificial intelligence is challenging patients' trust in us.
The comment thread that followed was predictable: smart people with real concerns and thoughtful observations. Almost universally, the proposed solutions included the usual suspects like patient education campaigns, AI disclaimers, vendor accountability frameworks, and regulatory guardrails.
I don’t think any of these addresses the actual problem.
Meanwhile, Andrew Lundquist offered a more optimistic take: clinicians should position themselves as “trusted interpreters” of AI-generated health information. The “Clinicianpreneur play,” he called it. I pushed back in my comments. I felt that there is value in that framing, but it also assumes that the current care model is relatively fixed and asks physicians to find their new job title within it. That’s not the real redesign we need.
Here’s what I keep thinking about instead…
The Void Didn’t Appear When ChatGPT Did
Graham’s patient didn’t turn to ChatGPT because she distrusted him. She turned to it because she was scared, it was 2 am, and there was nothing else there. The healthcare system had completed its transaction with her and moved on. ChatGPT was the only entity willing to stay in the room.
That void (the 23-hour period between an emergency room visit and the next point of contact) is not a new problem. It’s the defining structural feature of episodic, reactive, transactional care. We see patients when they show up. We document what happened during that window. We discharge them back into the rest of their lives, which we know almost nothing about, and we wait for them to return.
ChatGPT doesn’t win because it’s smarter than physicians. It wins because it is present and sounds competent. Those are two different things, and both matter. It’s there at 2 am. It remembers the conversation from two days ago. It doesn’t have a six-week scheduling backlog. It will never tell someone their concern is outside the scope of today’s visit. And when it responds, it does so with the confident, fluent authority of something that has read every medical textbook ever written. Whether that confidence is warranted depends entirely on the quality of the data and context it’s working from - a point I’ll return to - but in the moment, at 2am, with an anxious patient, “sounds competent” is” is doing a lot of work.
The “faster-horse” response to this is to train physicians to be better at “translating AI outputs” during the brief windows we already have with patients. The real opportunity lies in envisioning care as it would be if the health system operated continuously, proactively, and with genuine longitudinal context, similar to how ChatGPT engages with users.
To answer that question, we first have to reckon with how impoverished our current data picture actually is.
We Are Making Consequential Decisions on a Tiny, Unrepresentative Slice of Reality
Every shift I work in the emergency department, a thought crosses my mind with uncomfortable regularity: this patient didn’t have to be here.
This doesn’t apply to every patient and perhaps not even a majority, but, a substantial portion of them represents some kind of upstream failure: a patient whose primary care physician doesn’t have availability for two weeks; a patient whose chronic condition has been deteriorating between visits with no one watching; a patient who got conflicting information and anxiety-spiraled, like Graham’s phosphorus lady, because there was no tether back to a clinical relationship in the critical hours after discharge.
Here’s the hidden secret: I can’t give you a precise number. Nobody can. We don’t capture this. The ER, by design, is optimized to document what happened during the encounter and facilitate billing for it. Whether this visit was preventable, what upstream gap enabled it, which patients will cycle back next week…none of these are systematically encoded anywhere. It exists as heuristic knowledge, distributed through the heads of emergency physicians who notice the pattern every shift but have no mechanism to collect and aggregate that signal into something actionable.
Think about what that means for system improvement. We have rich, structured data about what happens during ER encounters. We have almost no structured data about why those encounters happened, whether they were necessary, or what would have prevented them. We’re running an enormous continuous quality improvement experiment with no feedback loop. Every ER visit that was a system failure disappears into a discharge summary and a billing code. The system never learns.
Now consider the areas in which AI truly excels. Not the fictitious artificial intelligence of five years from now, but the current tools that are accessible to any organization that wants to use them. The immediate opportunity isn’t to use these tools to replace clinical judgment. Despite the breathless coverage, that's not what they do well at scale. What they do extraordinarily well, right now, is synthesizing large volumes of heterogeneous data, identifying patterns across thousands of cases simultaneously, and surfacing signals that no individual clinician could see in the moment. This isn’t a promise. It’s a capability that’s running in production in other industries.
Applied to ER “failure data,” that capability can become something genuinely powerful: the ability to systematically identify preventable visits, characterize the upstream gaps that enabled them, and feed that signal back into the system in a way that could actually change the pattern.
But you can’t feed back what you haven’t captured.
The Data Infrastructure Problem Nobody Wants to Talk About
This is where I’m going to shift gears briefly, because understanding what’s possible requires understanding where the gap actually lives.
Most people assume the problem with healthcare data is that we don’t have enough of it. The opposite is closer to true. We generate enormous volumes of data constantly - clinical notes, vitals, lab results, imaging reports, device outputs, patient-reported information, claims data. The problem is that most of it is either locked in unstructured text, stored in formats that can’t talk to each other, or captured in ways that are idiosyncratic enough to make aggregation nearly meaningless.
For non-technical readers: imagine you’re trying to analyze customer behavior across thousands of retail locations, but every store tracks sales in a different spreadsheet format, some in different currencies, some with products named differently, and a substantial portion of the data is locked in handwritten notes in the store manager’s office. You technically have the data. You can’t do anything useful with it.
A representative example of this issue in healthcare is the way we record ejection fraction, a key indicator of heart function. At one facility, this measurement is derived from echocardiograms, while at another, it comes from cardiac catheterization reports. These two sources use varying formats, store the data in different fields, and apply distinct normal ranges, despite both representing the same clinical concept.
The data is irreconcilable without significant transformation work.
The technical solution to this is a data abstraction layer, which database people would call a purpose-built data mart with structured query logic sitting above the raw data, normalizing disparate sources into consistent, clinically meaningful metrics. Think of it as the difference between raw ingredients from twelve different farms and a standardized recipe that can be executed consistently regardless of which farm the ingredients came from.
Epic organizations have tools for doing exactly this that most of them barely use. The architecture involves attaching structured, governed data elements to clinical workflows so that documentation which would otherwise disappear into note text gets captured discretely and consistently. (See my previous posts on this: Epic Data Ingestion Solution, Epic Registries: Turning Raw Data into Actionable Insight.) Those elements feed into normalized data structures that can aggregate across thousands of patients and institutions. The aggregated data, normalized to shared definitions, can then feed machine learning pipelines with something that actually resembles a ground truth.
The organizations that use this infrastructure well - and there are a handful - can nimbly answer questions like “what percentage of our sepsis patients received reassessment documentation within two hours of resuscitation initiation?” not by paying abstractors to read notes for six months, but by querying structured data that was captured automatically during clinical workflows. The documentation burden on clinicians doesn’t increase because the data capture is embedded in how they already work.
Here’s the honest catch: this is an infrastructure play. It requires upfront capital and sustained organizational effort. The yield isn’t measurable at 90 days, and it probably isn’t measurable at 12 months either. What you’re building is a systematic, cultural, and operational capability - the kind of foundational asset that is notoriously difficult to connect back to a specific strategic project two years after the fact. In an environment where every initiative is scrutinized for its direct contribution to the bottom line, and where “reducing operational friction” barely registers as a budget category compared to “increasing revenue,” that’s a hard sell.
That friction is real. I’m not dismissing it. But it’s also exactly why most organizations are about to get lapped by the few that made this investment already. Most Epic organizations leave the vast majority of this capability untouched. They bought a sophisticated data infrastructure and use it as a billing platform. The tools for transforming messy, disparate clinical activity into normalized, queryable, AI-ready data exist. They’re just sitting there.
What This Actually Makes Possible
Let’s teturn to Graham’s patient. Or better, return to the pattern Graham’s patient represents.
Imagine a care model where the health system doesn’t disappear after discharge. The data captured during that ER visit - not just the diagnosis codes and the lab values, but a structured assessment of what upstream gap likely enabled this visit - feeds into a system that can identify patients at highest risk of cycling back. The physician seeing that patient in the ER can easily document, in a structured way that gets aggregated with thousands of similar flags across the system, that this visit was probably preventable.
Imagine accumulating that signal at scale to identify primary care access gaps that generate the most ER utilization, chronic disease management failures, and post-discharge follow-up windows that are most predictive of return visits. You can also determine which patient populations are most underserved by the current episodic model. For the first time, you would have actual data on the volume and character of system failures, rather than relying on the heuristic sense of their pervasiveness that every ER physician carries but cannot quantify.
Add the AI capabilities that already exist for synthesizing continuous patient data: remote monitoring, patient-reported symptoms between visits, behavioral signals. The picture gets more interesting, not because AI replaces the physician, but because we can maintain the kind of continuous, synthesized awareness of a patient’s trajectory that no individual clinician has the bandwidth to hold. It notices when the chronic heart failure patient’s weight has been trending up for two weeks and surfaces that to the care team before the decompensation that lands them in the ER. It identifies that three patients with the same PCP had the same pattern of preventable readmission, and flags that for a systemic intervention.
This is the path from Phase 1 to Phase 3, with AI as the enabling Phase 2 infrastructure in between. Phase 1 is the current state: episodic care, impoverished data, competing trust dynamics that emerge because patients are essentially alone between visits. Phase 3 is what the quadruple aim has always described and never achieved at scale: better outcomes, lower cost, better patient experience, better clinician experience.
Phase 2 - the part everyone keeps skipping - is building the data infrastructure that makes continuous, proactive, AI-enabled care actually possible.
If you’re not familiar with the Underpants Gnomes from South Park, the bit goes like this: Phase 1, collect underpants. Phase 2, question mark. Phase 3, profit. It’s a joke about business plans that have a confident start and an appealing finish with a conspicuous void in the middle. Healthcare’s AI strategy, in most organizations, is exactly this. Phase 1: acquire AI tools and announce the initiative. Phase 2: (something something data and AI). Phase 3: achieve the quadruple aim. The gnomes, at least, had the self-awareness to put a question mark there. Most healthcare AI strategies don’t even do that.
The competing-trust problem Graham described isn’t solved by teaching patients to be more skeptical of ChatGPT. It gets solved when the health system has richer, more accurate, and continuous context than ChatGPT does. When your physician’s AI already knows your trajectory because it’s been watching it continuously (not just in the 15-minute windows when you happened to be in the room) ChatGPT becomes one more data stream, not a competitor for your trust.
What This Requires
For health system leaders: Stop treating AI as a product you can procure and bolt onto existing workflows. The vendors selling “AI-powered” everything are happy to let you believe otherwise, but the value of AI is entirely contingent on the quality of the data you’re feeding it.
A sophisticated model trained on unstructured, ungoverned, episodic data produces sophisticated-sounding nonsense.
Your AI strategy is only as good as your data infrastructure strategy. Build the foundation first.
For Epic organizations specifically: The tools for building that foundation are already in your system: SmartData elements, Registry architecture. These tools for normalizing data can aggregate clinical meaning across thousands of encounters and make your data assets AI-ready. Most organizations are leaving well over 90% of this potential untapped. The question isn’t whether Epic can do this (it can). The question is whether you have people who understand both the clinical workflows and the data architecture well enough to build the abstraction layers that make it work.
For emergency physicians and clinical leaders: Start thinking about failure documentation as a quality improvement mechanism, not just an administrative burden. Every shift offers a continuous stream of signal about where the upstream system is breaking down. Right now that signal evaporates. It doesn’t have to. The tools to capture it structurally, aggregate it systematically, and feed it back into care delivery exist. We just haven’t built the workflows to use them.
For the broader conversation happening on LinkedIn and in healthcare policy circles: The “competing trust” framing is useful for describing a symptom. But the disease is data poverty and structural discontinuity in care. An elderly woman at 2 am shouldn’t have to choose between schlepping into the ED or ChatGPT because her physician access effectively ceased to exist the moment she walked out of the ER. That’s not a technology problem. It’s a care model problem that technology can now solve, but only if we’re willing to actually redesign the model rather than add another layer of guardrails to the existing one.
The organizations that will actually deliver on the promise of AI in healthcare aren’t the ones with the most sophisticated models or the most aggressive procurement budgets. They’re the ones that ask the harder question first: what would we need to know, and what data would we need to have captured, to make AI genuinely useful? And then they build that infrastructure before they buy the AI.
That’s not the faster horse. That’s the car.
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’re evaluating Epic’s AI announcements and need guidance on implementation strategy, or if you need help configuring your Epic environment to support these capabilities, connect with him on LinkedIn or via his website.




Thanks for this illuminating analysis of the profound shortcomings of our health care delivery system.
I fully agree with how you call attention to the “void” (that a patient is left with in between encounters with care providers) as “the defining structural feature of episodic, reactive, transactional care”.
I respectfully disagree, however, with your prescribed solution for “phase 2”, not because it’s wrong but because I find it incomplete. The “data abstraction layer” you mention is good practice and it should improve the management capabilities of the provider organization, but for the service delivery system to operate “continuously, proactively, and with genuine longitudinal context” – i.e., for the void to be properly filled and to realize Phase 2 of the plan – I see as obvious the need for a personal health system (PHS) owned and operated by the patient herself (with the coordinated participation of the "family support system" and other informal caregivers).
Now, this PHS would certainly have to leverage the power of AI technologies (what they already offer, let alone what we might expect from them in the future) but it would have to be much more than a “mere” chatbot powered by an LLM (such as ChatGPT) – a composite of different algorithmic breeds (not just next-token prediction) along with conventional rules-based, deterministic components. And it most certainly would not depend on the enshittification-prone platforms of Big Tech and so-called foundation models and “hyperscalers”.
Further, it would naturally be a distinct system from the corporate EHR (such as Epic), but fully interoperable with it (I see a fundamental need to recognize the "separation of concerns" between the individual and the organization).
Only the PHS can IMO bring into the new encounter the full reality (not just a slice of it) impinging on the patient’s health, and which no provider-based information layer can capture on its own: the narrative of the person’s feelings, symptoms, facts, events and fears; her socioeconomic background; the toxins and pathogens she may have been exposed to in her daily life; the health risks lurking in her workplace; the habits and practices from which disease-inducing behaviors might be detected and addressed, etc. No matter how much the provider’s capabilities are augmented, it will (for obvious reasons) never cover the “void” with the depth and continuity that a personal system could.
Provided its assured safety and reliability (operated under an appropriate system of governance), only a PHS can fill the void in such a way that the provider’s care is effectively enhanced and forewarned, guided to better outcomes with the right intervention effort while afforded the opportunity for systematized learning.
I’ll admit that my take on the problem critically depends on the very feasibility of the PHS as a tool and as a business model. That’s my goal. Additionally, to the extent it is in fact feasible, I find it much easier to scale such a solution across thousands and millions in the population sharing the same basic need than it would be to upgrade the data management practices and organizational culture of hundreds and thousands of highly diverse and reluctant health care providers.
In any case, thanks for this great piece.