I’m often struck by how little the fundamental architecture of care has changed in over a century — we still ask patients to come see a doctor in a clinic when they have a problem, and in hospitals, we still round room to room much as we did a hundred years ago. The Covid pandemic accelerated digital modalities such as telehealth, but the underlying architecture of care delivery — how we organize work, teams, engagement, and follow-up — remains largely the same.

In an earlier post — What if we had to care for twice as many patients? — I posed what I believe is an existential question for healthcare in our country: what would it take to double our capacity for care, without doubling our workforce or costs?

When I look at new capabilities such as AI or virtual care, I always go back to this core question. We can deploy AI models into workflows or increase the number of telehealth encounters, but without re-architecting the underlying system, we risk perpetuating the same legacy inefficiencies, except with new technologies that may actually add to costs.

Nevertheless, these technologies are critical building blocks for the transformations that we need. If we are to upgrade the underlying chassis of care delivery, we have to leverage capabilities such as AI and virtual care as enabling functions for the care models of the future. These technologies are not solutions in themselves; they are materials from which new systems can be built.

Designing Systems for Better Care

Imagine the care models of the future: care would be informed by better, more accurate information; delivered through processes unconstrained by time and place; and experienced by patients who are informed, empowered, and connected.
It would be a learning system that captures experiences from each interaction to improve the next. It would also be scalable — able to expand access and capacity without a proportional rise in cost or burden.

How would we engineer such a system?

We might think of it as having two fundamental layers: an intelligence layer that makes sense of information and guides action, and a delivery layer that executes those actions efficiently across people, time, and space.

AI provides the foundation for the intelligence layer — organizing and interpreting data, surfacing the right information, and supporting decisions in context. Virtual care (coupled with AI) supports a lower cost, scalable delivery layer — the channels, workflows, and human touchpoints through which care can be delivered independent of physical proximity and constraints. Virtual care also provides a more seamless digital medium for AI to be integrated into the care delivery experience.

In person care will continue to be necessary, both as standalone models for higher acuity care delivery and complements to virtual first care. However, the future of care delivery will depend on how seamlessly we integrate in-person and virtual layers into a unified, intelligent system — one that delivers the right level of care, in the right place, at the right time.

We are already beginning to see early examples of this architecture take shape within health systems. At my institution, Stanford Health Care, two new digital health programs — eConsult 2.0 and Stanford Health Care at Home — illustrate how the combination of AI and virtualization can enable entirely new systems of care delivery. Each begins with the following question: how might intelligence and virtualization of care allow us to scale expertise and capacity without scaling cost?

eConsult 2.0 — An AI-Enabled Specialty Consult Service

At Stanford Health Care, our eConsult program has long improved access to specialty expertise. An eConsult is an asynchronous virtual care model where a provider — often a primary care clinician — consults a specialist digitally rather than referring their patient to a specialty clinic. This model enables patients to receive specialist input within days instead of waiting months for a traditional appointment. But the real opportunity lies in reimagining eConsult as a tech enabled specialty care service — one in which AI is built into the architecture of how expertise is delivered, not simply layered on top of it.

Yet scaling this model across a health system has proved challenging. Specialists face high cognitive burden, limited compensation, and outdated consultation templates that required constant manual upkeep. The program’s success has depended not only on clinical expertise but on labor-intensive processes — gathering data, reviewing charts, and drafting responses — that don’t scale linearly with demand.

Our first experiments with AI focused narrowly on chart review, using large language models to surface relevant clinical data and reduce time to completion. The early success of these efforts prompted a deeper question: what if AI could do more than streamline a task? What if it could become a core design element of the care model itself?

That question led to the creation of eConsult 2.0 — a re-architected, AI-enabled clinical service built from the ground up as a tech-enabled system of care, not a digital add-on. Rather than deploying AI just to help with chart review, we began designing around AI as an enabling function—the intelligence layer that supports a continuously learning and scalable specialty consultation service that consists of three layers:

1. Knowledge Base — continuously updated, AI-assisted consultation templates that serve as the shared memory of the service.

2. Application Layer — a “one-stop-shop” interface, integrated into Epic, that uses large language models to summarize relevant chart data for the specialist and draft responses while continuously learning and updating the knowledge base.

3. Workforce Layer — specialists whose expertise is enhanced by AI, allowing more consults in less time and with higher consistency.

The redesign of the eConsult program demonstrates how intelligence can be embedded into the fabric of a clinical service — turning what was once a high-friction workflow into a scalable system for distributing expertise.

Stanford Health Care at Home — Expanding Hospital Capacity Through Virtual Care

If eConsult 2.0 reimagines how expertise is delivered, Stanford Health Care at Home reimagines where hospital care is delivered. The program was born from a pressing organizational need to expand hospital bed capacity, leading to the following question: what if patients who no longer require hospital-level intensity care could continue recovery safely at home, supported virtually by their care team?

In today’s system, inpatient providers often face a binary choice — keep the patient in the hospital, or discharge them into a full ambulatory environment that may not be sufficient to support their immediate post discharge care needs. Patients and providers often describe hospital discharge as “walking off a cliff” — a sudden drop in support that can lead to unnecessarily prolonged hospitalizations or, conversely, premature discharges that result in readmissions and other adverse outcomes.

Stanford Health Care at Home creates a third option: a virtual-first, home-based model that bridges the transition between inpatient and ambulatory care. Patients who are clinically stable but still need close monitoring — for example, those resolving sepsis, restarting medications, or awaiting culture results — can be discharged earlier and managed at home through a hybrid model of virtual physician visits, nursing support, and coordinated follow-up after hospitalization.

This design expands hospital capacity without building new beds. By virtualizing the “tail end” of hospitalization — the final days often defined by low-acuity, high-cost care — it converts fixed inpatient infrastructure into flexible, distributed capacity. Over 350 patients have been enrolled since the program’s launch six months ago, with overwhelmingly positive feedback from patients and families who describe it as a safe, high quality, and patient centered care experience.

A virtual care chassis for deploying AI

After demonstrating the feasibility of this virtual care model in providing high acuity care at home, the next step is to layer intelligence onto its virtual chassis. As the model grows in size and reach, it must find ways to scale care safely without inflating cost or staff burden — a challenge well suited to AI as the intelligence layer that learns from operations, anticipates patient needs, and orchestrates care across settings.

Because the program already operates through digital workflows and virtual touchpoints, it provides a natural substrate for integrating AI — data flows are continuous, interfaces are digital by default, and feedback loops can be instrumented directly into the care process.

In practice, this intelligence layer could take many forms. AI models could continuously synthesize remote monitoring data and patient messages to identify early signs of deterioration or unmet needs, prompting timely virtual interventions. AI agents can support care coordination tasks based on these needs. Generative models could summarize longitudinal data and encounters for the care team, reducing documentation burden while improving situational awareness. Predictive algorithms could help determine which patients are suitable for home-based care and dynamically adjust visit frequency based on evolving risk.

Together, these capabilities furthers Stanford Health Care at Home’s ability to become a re-engineered virtual extension of inpatient care at scale.

Why Health Systems Are Poised to Lead

I have always thought of health systems as the builders, rather than just consumers and implementers, of the tech enabled care delivery products of the future.

Both eConsult 2.0 and Stanford Health Care at Home reveal a deeper truth: the most transformative applications of AI in healthcare are not just technology deployments, but system designs. They require not just the technology, but the infrastructure, workflows, and broader care delivery systems of a health system to make them real. This is why health systems are uniquely positioned to lead. They already possess three key elements — the delivery environment, the clinical expertise, and the trust of patients and providers that enable AI to be developed, tested, and refined to redesign the ecosystems where care happens.

To build these systems, health systems must begin to see themselves not only as providers of care, but as engineers of care models. The next era of innovation will not be defined by who has the most sophisticated AI model, but by who can integrate intelligence into new architectures of care delivery.

Engineering the Care Models of the Future

We might imagine a new discipline: “Care Model Engineering” that fuses delivery science, clinical informatics, and product design into a unified practice. It treats care models the way technology organizations treat products: something that can be designed, tested, and iterated, with clear hypotheses about how structure and process drive outcomes. In this framework, AI becomes part of the design language of healthcare — a material for building systems that are more adaptive, equitable, and scalable.

For health systems, this represents an opportunity to truly bend the cost curve for healthcare by leaning into what they do well. With the right infrastructure — cross-functional product teams and a culture of iterative design that elevate the expertise inherent in all the frontline clinicians and operators who know where care breaks down — health systems can transform from slow adopters into the architects of new models of care delivery.

AI and virtual care are the tools that make reinvention possible. What we build with them — the new systems, the new architectures of care — will determine whether we finally make healthcare scalable, sustainable, and capable of caring for the people who most need it.

More than a century after the birth of modern hospitals and clinics, we find ourselves at a moment to define what the next phase of care delivery should be.

I remember sitting in a conference room listening to one of our ICU physicians describe a patient who had just been transferred: a middle age, otherwise healthy man with respiratory failure, intubated, with a positive COVID PCR test and classic findings on chest imaging consistent with COVID pneumonia. He was the first known case of severe COVID-19 infection at our hospital.

Those of us in the room — a group of clinicians and administrators — shared uneasy glances at each other, but continued the meeting with the level of equipoise healthcare professionals strive to maintain despite facing life or death crises. However, beneath the calm exterior, we all knew this was just the beginning.

Over the subsequent months as the COVID pandemic unfolded, our hospital transformed and innovated in an all hands on deck manner that was equally stressful and inspiring. Traditional boundaries dissolved as we mobilized every resource and idea we had, knowing there was no playbook for what we were facing. The constraints and sense of scarcity we encountered - limited PPE, hospital beds, staff shortages - didn’t paralyze us, but rather forced us to innovate that resulted in lasting transformations. For example, telehealth adoption increased from less than 10% to 90%; while this number has since equilibrated, telehealth and virtual care have evolved from being regarded as novelties to necessary tools for care delivery.

Looking back, the scarcity we faced didn’t just challenge us; it gave us a mandate to freely innovate, driven by an unprecedented sense of urgency that bound us together around a common mission.

The case for scarcity-driven innovation

The American healthcare system is fortunate to have survived through the worst parts of the COVID pandemic, but is slowly inching towards a crisis of greater magnitude. Ballooning healthcare costs are indebting households as well as our nation. Providers are burning out and as a population, we are not healthier.

Unlike COVID, this crisis is manifesting over years and decades rather than weeks and months, but shares the same accelerating, existential feel. And just as with COVID, addressing this crisis will require us to operate under hard constraints: our healthcare system needs to deliver better care for more people at a significantly lower cost.

Also unlike COVID, we have the benefit of time that should enable us to be more intentional and thoughtful at innovating without being forced to constantly react to immediate threats. The scarcity we face may not be as obvious or immediate, but are very real. We will need to decide whether to embrace this burning platform now, or wait until we have no choice.

How would we deliver high quality care to twice as many people at half the cost?

This is not just a thought experiment - it is a lens that forces us to fundamentally rethink care delivery and challenge assumptions and perceived barriers that systems of abundance often afford.

Scarcity forces us to challenge core assumptions about care delivery

When resources feel abundant, we rarely question basic assumptions about care delivery, especially if we have more to lose than to gain from changing the status quo. During the early days of the COVID pandemic, we initially continued the practice of having the entire medical team enter every patient’s room each morning for rounds, consuming precious N95 masks and gowns to maintain a ritual that added questionable clinical value on top of what could otherwise be monitored virtually. The looming PPE shortage forced us to reconsider when a physician truly needs to evaluate a patient at the bedside, and what instead could be substituted by a virtual interaction and asynchronous monitoring.

We eventually created a virtual rounding system where the team would evaluate patients via video while reviewing vital trends and other clinical data. The physician would enter the room when physical examination was truly necessary. COVID specific clinical teams were then developed that leveraged virtual interactions, asynchronous monitoring, and standardized care protocols which enabled a single physician to efficiently care for large numbers of COVID patients. The ICU proactively identified patients in the hospital who may require care escalation to avoid unanticipated transfers and intubations, which were risky for both the patient and providers involved. We did explore using AI to perform these predictions, although it turned out that simply following the rate of increase in the amount of oxygen needed provided an immediately effective solution at no additional cost.

This shift, born from necessity, revealed how many of our 'essential' practices were more ritual than requirement. The quality of care didn't suffer; in fact, many aspects improved. Teams spent more time discussing care plans and teaching. Patients weren't awakened repeatedly by large groups trooping through their rooms. What started as a response to PPE scarcity evolved into a more thoughtful approach to patient care.

Now on the other side of the pandemic, this experience has taught us to more broadly question fundamental assumptions about care delivery: does a given patient encounter need to be in-person with a physician versus delivered virtually? Does it require synchronous communication, or could it be handled asynchronously? Does this level of care truly require a hospital setting, or could it be safely delivered at home with the right monitoring and support? When we strip away historical assumptions and focus on what creates real therapeutic value, we often find that traditional care models are built more on convention than necessity, creating opportunities for transformation.

Shifting from a mindset of technology deployment to technology enabled care model design

Achieving this type of transformation, however, requires a shift in mindset. The current discourse around technology in healthcare suffers from a sense of abundance: we layer expensive new tools onto existing expensive care models. The net result is more cost, more complexity, attention grabbing headlines, and ritzy conferences, but not necessarily fundamentally better care.

Scarcity-driven thinking would force us to flip this approach. For example, instead of asking “How can we deploy AI into cardiovascular disease care,” we would ask “what would we need to do if we had to treat twice as many patients with congestive heart failure with half as much clinic space and staffing?”

Consider how these different mindsets play out in practice. The abundance approach might result in the addition of a fancy (and likely expensive) AI monitoring tool to existing heart failure clinic visits that may generate additional clinical encounters and interventions: all adding to cost while preserving the incumbent care model. The scarcity approach would force us to reimagine the entire care model since there simply would not be enough staff and space for the number patients we need to treat. We may design a system of using AI to continuously monitor patients at home, automatically adjusting medications within safe protocols or with asynchronous input from the clinical team, and reserving precious clinic time only for complex decisions that truly require in-person physician expertise. Same technology, but fundamentally different impact on care delivery and cost.

Embracing scarcity is more often a reality at the local level than for the healthcare system at large

Change is difficult when the scarcity is hidden. Healthcare can feel like the proverbial frog in slowly boiling water; despite mounting evidence of crisis — rising costs, debt, workforce shortages, burnout — our system continues to operate as if resources are infinite. Current incentives reinforce this mindset: fee-for-service revenue models, technology vendors promising additive solutions, and headlines celebrating the latest expensive innovations all suggest the pie will keep growing. It's hard to embrace scarcity thinking when the water feels comfortably warm.

Yet at the local level, scarcity is already a daily reality. Individual clinics struggle with staff shortages. Hospitals face space constraints. Primary care practices buckle under growing patient panels. These frontline challenges, while less glamorous than the latest AI breakthrough, are where real innovation often happens out of necessity.

This is why frontline teams need to be empowered to lead innovation at the local level. They intimately understand both the constraints and opportunities in their local systems, and are more likely to be driven by the problems they face rather than grand visions of technology transformation. Yet, there are challenges - we all naturally want to preserve or expand our resources, and the case for change is difficult when there isn’t a pressing crisis. But when given a clear mandate and permission to redesign care delivery, those who are closest to the work and experience the scarcity first hand often generate the most practical and impactful innovations.

We are in an all hands on deck moment

When working in the hospital, memories from Covid sometimes trigger me to wonder, what if we suddenly have to care for twice as many patients in our medical ward? What fundamental changes would need to occur in our workflows and care models that would make me confident our system would hold? What if one day in the future, we are faced with the real challenge of needing to care for twice as many patients at half the cost?

The tools and talent exist to tackle this question; what we need is the will to act before crisis forces our hand. My bet is that in doing so, we will also generate the best, most innovative ideas to improve healthcare.

What if this is no longer true with AI?

A recently published paper from colleagues at Stanford reports a single blinded randomized controlled trial assessing whether access to a large language model (LLM) chatbot improved physicians' diagnostic reasoning. 50 physicians were randomized to an LLM-assisted group (the physician had access to a LLM chatbot such as ChatGPT in addition to conventional reference tools) or a control group (no LLM but access to conventional reference tools) and asked to assess written clinical vignettes and generate lists of diagnoses that were then later scored by a group of expert physicians.

There was no significant difference in overall diagnostic performance scores between the physician + LLM group (76%) and control group (74%). However, the LLM alone (without any physician input) was by far the most accurate of the three groups with a median score of 92%.

The results were surprising to many in the field as it seemed to challenge the prevailing assumption that human + AI is better than human or AI alone. In fact, physicians interacting with the AI seemed to have had a negative effect on the AI’s ability to make accurate diagnoses!

What then, differentiates physicians from AI, and how do we teach it?

As an internal medicine physician, I have always taken great pride in our specialty's diagnostic reasoning skills. It is important to recognize that we cannot draw definitive conclusions from a single study. Further, generating a differential diagnosis from a pre-written clinical vignette is also an artificial and narrow task that does not fully capture the complexities and nuances of real-world diagnostic reasoning, which requires skill in collecting and synthesizing relevant information from disparate sources over time.

However, I believe it is time to acknowledge that superior diagnostic reasoning is no longer what differentiates our value in the era of AI. If the scaling laws for neural networks continue to hold true, it is highly probable that in the near future, AI will consistently outperform physicians.

I would also argue that superiority in this narrow cognitive task should not be the defining characteristic of a physician’s value.

A physician’s job is to improve the health of our patients by preventing, treating, and managing disease. While accurately identifying the correct diagnosis is undoubtedly a crucial step in this process, it is just one of many essential components.

What truly sets the best physicians apart from others is their capacity to deliver comprehensive, patient-centered care that goes beyond mere diagnosis. They cultivate trusting relationships with their patients, deeply understand individual circumstances, beliefs, and preferences, and guide their patients through complex medical decisions with empathy and compassion. They tailor their medical knowledge and expertise to the unique needs of each patient, ensuring that the diagnostic and treatment strategies are not only technically correct but also aligned with the patients’ values and goals and successfully executed within a complex healthcare system.

While some may label these qualities as the "art" of medicine, I believe this term undermines the fact that these qualities can be systematically identified, nurtured, and taught as core competencies in medical education.

As we train the next generation of physicians, we need to intentionally think about how to cultivate and prioritize these essential human skills alongside traditional medical knowledge. This means redesigning medical education to place greater emphasis on effective communication, empathy, shared decision-making, and managing complex systems. We must provide aspiring physicians with the tools and guidance to navigate complex patient interactions, build trusting relationships, and deliver personalized care that respects each patient's unique needs and values.

Nowadays, when I attend on the medical wards working with trainees, I start the week by telling them that it is not important for them to memorize any data or medical guidelines; they are encouraged to use the computer to look up any information they need, including medical references or even a LLM chatbot, when they discuss patients on rounds. Instead, I emphasize that the primary focus is for them to leverage these tools to confidently make an assessment, reach a decision that the patient is also comfortable with, and successfully carry out the care plan as a team. The ultimate goal is not simply getting the right diagnosis, but providing the best possible treatment to improve the patient’s health.

We need a new paradigm for building “human + AI” teams

Giving doctors access to an LLM chatbot is a start, but does not constitute a true human-AI team. Designing such teams and its enabling technologies is a wide open space for exploration. In a previous Byte to Bedside post, I discussed the concept of “cognitive integration" between AI and physicians, where the AI's capabilities are seamlessly integrated with the physician's skills, creating a complementary partnership that enhances the strengths of both.

As AI becomes more consistently proficient at diagnosis and reasoning tasks, we must consider how these capabilities can be leveraged to enable new healthcare delivery models that can provide high-quality, accessible care to a larger population at a reduced cost. For example, imagine a primary care practice where each physician is supported by a team of AI agents that can triage patient concerns, provide personalized health education, monitor chronic conditions, and even suggest evidence-based treatment plans. This AI-augmented approach could allow a single physician to effectively manage a much larger patient panel while maintaining high-quality, individualized care. Patients would benefit from improved access, reduced waiting times, and proactive, data-driven health management, all at a lower cost compared to how care is delivered today.

These new AI-enabled care models will bring drastically different unit economics and scalability. It is time to move past the current model that relies on a physician personally seeing every patient to render a diagnosis and treatment plan - an approach that is not meaningfully different from 100 years ago.

The fundamental theorem of informatics still holds true, but needs an update

Humans + computers > humans or computers alone, sometimes.

We need to better understand the following: 1) what the "human + AI" team looks like, and 2) what are the specific tasks for which this collaboration outperforms humans or AIs alone.

For the task of diagnostic reasoning from text vignettes where the human + AI team is just giving physicians access to a LLM chatbot, AI may be giving physicians a run for our money. But for the task of taking care of patients, I am betting on the human + AI team. The work now is to figure out how to be build the team.

References

Goh E, Gallo R, Hom J, et al. Large Language Model Influence on Diagnostic Reasoning: A Randomized Clinical Trial. JAMA Netw Open. 2024;7(10):e2440969. doi:10.1001/jamanetworkopen.2024.40969

What does model validation entail, and why is this software significant?

Consider the following example: a hospital interested in implementing a new readmission risk model must first ensure that the model accurately predicts readmissions for its patient population without significant biases. This process requires building a clean dataset of a sufficiently large cohort of patients and identifying the "true positives"—the patients who were actually readmitted—using a standard definition (i.e., inpatient readmission at 30 days). The ML model is then used to generate predictions for each patient from that cohort (typically a numerical score classified into "likely or unlikely to be readmitted" based on some pre-specified cutoff). The hospital must compare these predictions against the actual outcomes to assess the model's recall and precision (measures of accuracy), and potential biases across different patient subgroups.

This process is resource-intensive, requiring significant data management and analytical expertise. Epic's software automates key aspects of this process, making it more accessible for health systems that lack extensive data science resources, but can now leverage knowledge of local patient populations, clinical workflows, and organizational needs to better assess the model’s safety and effectiveness. For instance, local clinicians might know that certain socioeconomic factors or comorbidities prevalent in their community significantly influence readmission rates, and that workflow constraints require a certain level of model precision for the model to be effectively used. Real time monitoring of model performance also enables model and workflows to be quickly adjusted based on local needs.

The ability to assess the model locally empowers the users of these models — the clinicians and staff caring for the patients the AI intends to benefit — to have the necessary input in the application of AI into their work. Their input also enables the industry to gather valuable real-world experience needed to inform standards and frameworks for governing the use of AI in healthcare.

What’s in it for Epic?

It would be naive to assume that Epic does not have strategic motives behind this release. It has been interesting to see Epic’s evolution from a EHR company into a platform company, and I believe this move further solidifies their positioning as the dominant healthcare technology platform. Epic acknowledges that they may not be the sole producer of AI for healthcare, but they would like all producers and users of AI in healthcare to depend on Epic (or a standard that Epic establishes). I am interested to see the extent to which this validation tool will be adopted; given Epic’s level of scale, depth of workflow integration, and customer stickiness among health system, I would bet in their favor.

Many outside of healthcare underestimate how many tasks performed by highly trained experts simply involve summarizing and communication information to another individual. Offloading this chunk of work to AI will have a transformative impact on healthcare.

This study from Stanford describes an analysis comparing the performance of LLMs against medical experts in performing a set of text summarization tasks from the following data sources: radiology reports, progress notes, patient questions, and patient-provider conversations.

The performance metrics included completeness, correctness, conciseness, and prevalence of fabricated information. In 81% cases, the LLM generated summaries were rated either equivalent (45%) or superior (36%) than those generated by their human counterparts.

While more studies will need to be done to validate this result, I think this is an important milestone in establishing the viability of LLMs for safely and effectively summarizing clinical text, which is a foundational and extensible task that underlies many healthcare workflows. Importantly, the study highlights that the benchmark for LLM performance is not perfection, but rather human experts. As a practicing physician, I can say that we are far from perfect!

Amazon and Eli Lilly launching new programs that directly identify and provide care to patients with chronic diseases

The landscape of chronic disease management is changing. While primary care providers (PCPs) remain the primary frontline access points for healthcare, nontraditional industry players such as Amazon and Eli Lilly are creating their own direct channels to patients. Strategically, these companies are betting that they can deliver care more efficiently by bypassing traditional healthcare delivery channels and employ a more digital first, consumer directed approach. These tend to focus on simplicity and efficiency of access rather than solving for complex medical issues. For Eli Lilly and potentially other biopharma companies, this is also an extension of their sales and marketing strategy for blockbuster medications (eg. semaglutide) by removing barriers to patients being prescribed those drugs.

These efforts are currently limited and only represent a small sliver of healthcare delivery in the US. However, incumbent health systems need to take notice, if only to observe and assess the demand for such services, as it will likely come from patients disillusioned with the inefficiencies of existing systems and searching for alternatives. I see a likely rise in the number of strategic partnerships between incumbent health systems looking to outsource certain parts of care pathways to these digital first companies in exchange for maintaining referral channels to complex specialty care.

Yet, the key to success for these efforts is clinical integration. These “direct to consumer” digital first care models often fall short in serving patients with more complex medical histories and needs. Even for the patient who may be just looking for Ozempic to lose weight, they likely have other comorbid medical problems that need to be assessed and managed. How these digital first companies integrate their care with the rest of the healthcare ecosystem will be a critical factor towards their success. Further, it will be interesting to see how they manage healthcare data. Will they join nationwide efforts around interoperability and data exchange that have created significant progress towards enabling transparency and sharing of medical data among healthcare providers, or will new “walled gardens” be formed where medical data collected by Amazon clinics will be sequestered within the “Amazon health ecosystem”?

A framework for designing an AI guided tool for communicating prognosis

Physicians often navigate conversations with patients laden with complexity, uncertainty, and deep emotions that require more than simply knowing the correct information. For example, communicating prognosis for a patient diagnosed with cancer involves more than just conveying an accurate survival rate; it requires translating and framing statistical outcomes into a narrative that resonates with the broader context of the patient’s life, hopes, and fears.

There exist many machine learning models that predict survival with the intention of eventually being integrated into clinical workflows, such as communicating prognosis, but simply presenting a survival probability often falls short of what is actually useful to a physician. The key lies in designing software that harmoniously blends ML predictions with additional information and design features that help providers create the narratives needed to drive effective conversations.

The authors of this study from the University of Utah developed a tool aimed at assisting oncologists in discussing prognosis with patients facing advanced solid tumors using a user centered design approach to integrate 6 month survival predictions into a tool that addresses these broader needs. The team underwent several rounds of iterative design sessions with oncologists. What stood out to me was how they intentionally sequenced their design steps in partnership with the end users to build towards the final product:

1. Use of Initial Interfaces: In rounds 1 and 2, initial interfaces provided a common visual and terminology for facilitating discussions between the team and clinician input.

2. Content Determination and Model Clarification: These interfaces helped in deciding what content should be presented, clarified the function of the model, and established a suitable threshold for classifying survival risk.

3. Exposure of Misassumptions: Misassumptions among clinical and technical experts were exposed, such as the belief that the model output represented expected survival rather than a risk classification.

4. Triggering of Questions and Additional Information: The discussions prompted questions and led to the presentation of additional information by technical experts, enabling further exploration of the model and its applications.

5. Clinical Relevance and Feature Assessment: Clinicians on the study team assessed the clinical relevance, examined the features of the model, and reviewed the gold standard mortality data.

6. Advice on Data Pre-processing: Clinicians advised on data pre-processing, highlighting the importance of clinician involvement in AI system design.

7. Application of Design Decisions: Based on the findings from rounds 1 and 2, design decisions were applied to enhance the model and interface, focusing on trust and transparency and ensuring a match between the system and the real world.

8. Progression of Interim Interfaces: The evolution of interim interfaces through these rounds was documented, showcasing the iterative design process and improvements made.

This iterative, dyadic partnership model facilitates the optimization of critical design and engineering decisions early on, based on what is genuinely useful to oncologists. This approach is crucial as many insights from end users often emerge only when they are presented with a visual representation, allowing spontaneous comments to be transformed into specific technical requirements.

Here is an example of a comment from an oncologist during a design session after viewing an early user interface:

“As oncologists we sometimes have rose-colored glasses on and like to overestimate the benefits of second, third, fourth line treatment. And so, I think that this can maybe ground you and bring you back to reality like, hey, look it’s probably not such a good idea. Let’s think about alternatives.” (#7) “I think this would be useful for family members.” (#3) “…helpful in…patients who…see cancer as like a battle that they have to fight…often unwilling to stop treatment despite all evidence that treatment might harm them rather than help them.”

A key insight here is how this prognosis communication tool can add value by helping oncologists recalibrate expectations and confront optimistic biases towards aggressive treatment courses, which is a specific use case that may require tailored design choices.

Communicating with patients in high stakes situations is complex and requires the art of marrying data with human connection so that the patient not only receives the correct information, but also feels genuinely heard and supported. Digital and AI enabled tools that support these interactions need to be designed with a deep understanding of the nuances of patient-provider communication that can only come from a solid dyadic partnership between the end-users and technical teams established from the outset.

References

Van Veen, D., Van Uden, C., Blankemeier, L. et al. Adapted large language models can outperform medical experts in clinical text summarization. Nat Med (2024).

Catherine J Staes, Anna C Beck, George Chalkidis, Carolyn H Scheese, Teresa Taft, Jia-Wen Guo, Michael G Newman, Kensaku Kawamoto, Elizabeth A Sloss, Jordan P McPherson, Design of an interface to communicate artificial intelligence-based prognosis for patients with advanced solid tumors: a user-centered approach, Journal of the American Medical Informatics Association, Volume 31, Issue 1, January 2024, Pages 174–187

Subscribe now

I found this paper interesting because it offers a fresh perspective on applying AI and large language models (LLMs) to clinical decision support (CDS). Led by Siru Liu at Vanderbilt University Medical Center (VUMC), the study uses ChatGPT to generate suggestions for refining the logic (rather than the content) of CDS alerts. This approach is intriguing because it integrates AI into an existing human-driven process, making it a practical and potentially beneficial application in the near term for healthcare provider organizations.

To understand why this approach is significant, let’s first consider the “anatomy” of traditional CDS systems. These systems have a “backend” comprising clinical data, a knowledge base, and logic, and a “frontend” that includes the user interface and subsequent action. When we talk about integrating AI into CDS systems, it’s crucial to specify which part of this anatomy we’re optimizing. Often, the focus is on training the AI, but the intentional design of the CDS system is equally important.

An example of a set of logic for a CDS system to alert providers to avoid live virus immunizations for immunocompromised patients.

Source: Liu et al. JAMIA 2023

While AI is often touted as a potential replacement for knowledge bases and logic, the reality is that current machine learning models fall short in being able to be applied to CDS at scale. Yet, there remains a need to change how CDS systems are built; the process of creating and maintaining these knowledge bases is time consuming, involving synthesis and translation of expert knowledge into discrete knowledge artifacts and rules. This is a task that seems well-suited for a large language model.

The study at VUMC provides a great example of this intentional design led approach to applying AI to CDS. The researchers used seven alerts from the Epic EHR system and transformed the documented alert logic into ChatGPT prompts. They then mixed LLM-generated suggestions with those previously generated by clinical informaticians, randomizing the order of suggestions. The suggestions were rated by a group of physicians and pharmacists on eight different perspectives, including understanding, relevance, and usefulness.

The results of the study were promising. LLM-generated suggestions scored high in understanding and relevance, suggesting that AI can provide valuable insights that can enhance the effectiveness of CDS alerts. However, the study also highlighted some challenges with AI-generated suggestions, including lack of knowledge management and implementation understanding. These findings underscore the need for further research and refinement of LLMs for CDS optimization.

Looking ahead, the integration of AI into CDS optimization could pave the way for more dynamic, responsive, and effective CDS systems. As we continue to explore this opportunity, it is clear that the journey is just as important as the destination.

Reference: https://academic.oup.com/jamia/article/30/7/1237/7136722

Aetna and Oshi collaborate to provide virtual care for digestive disorders

This is news back from April, but it recently caught my eye. In a move towards vertical integration into specialty care, Aetna announced a value based collaboration with Oshi Health, a virtual digestive health provider. Oshi’s digital care model in involves connecting patients with specialized providers via telehealth visits, and continuously adapting and refining care plans based on monitoring of symptoms, food intake, and bowel movements with the support of health coaches and nutritionists. Early results presented in a clinical study look promising in terms of member satisfaction and cost savings. The partnership will provide Aetna commercial members with in-network access to Oshi’s services. It is unclear whether/how Aetna is building in any features to “navigate” its members towards these virtual care options versus traditional specialty referrals.

This partnership follows its recent acquisitions of Signify Health (home health), and Oak Street Health. At $8 billion and $10.6 billion, respectively, these are much more aggressive and higher conviction moves than the partnership with Oshi. However, the trend and strategy is clear: CVS/Aetna is betting on vertical integration of its payer business with virtual first provider capabilities, which now includes not just supportive and primary care, but specialty care services.

To those in the health technology space, this presents unique opportunities and problems to be solved, ranging from referral optimization, care coordination, and even clinical decision support at a very different scale than with traditional provider organizations. The breadth and depth of products (and the data that will drive these products) will be different. I’ll be keeping my eye out for products and companies that emerge in this space.

Reference: https://www.cvshealth.com/news/virtual-care/aetna-and-oshi-collaborate-to-provide-virtual-care-for-digestive-disorders.html

79% of Consumers Want to Pay All Medical Bills From Single Digital Platform

A survey of 2,034 consumers in the United States revealed that participants by and large prefer a unified digital platform to help with financial transactions related to healthcare, including payment of medical bills, financing options, and HSA investment options.

Of note, this study was conducted by a healthcare fintech company Lynx and Pymnts, a fintech news outlet, so I cannot speak to its degree of bias and validity. Nevertheless, it highlights two interesting trends that I believe those of us in health IT should continue to track closely: 1) the experience of paying for healthcare is a major pain point, and 2) patients are looking for more control and convenience over the process, rather than deferring it to the provider organizations.

Managing their own healthcare becomes an arduous labyrinth for patients juggling multiple providers, health systems, and pharmacies, each with its unique policies, paperwork, and billing processes; a mounting frustration that only exacerbates the stress of navigating their medical problems. I think the sentiment from this survey represents a desire for a future state towards a model where patients manage healthcare transactions on their terms — not just the payment process, but also financing, access to tax deductible investment accounts, and I would also guess price transparency (which is not explicitly mentioned in the survey).

This may also imply a shift in preferences in the tradeoff between privacy and convenience. Traditionally, privacy has been a paramount concern in healthcare. Still, the growing demand for a simplified and unified payment system may cause consumers to compromise on this front.

Patients are expressing their frustration with legacy health systems and processes, and as health IT professionals, we need to be listening. The desire for control and convenience is redefining the way we must think about our systems, processes, and the products that we are building for the future. Perhaps patients are telling us something a bit more nuanced about the tradeoffs that they are willing to make: while they undoubtedly value their privacy, their increasing desire for convenience, control, and an integrated healthcare experience suggests that they might be open to a more flexible model of data management where transparency, security, and user-friendliness coexist.

Reference: https://www.pymnts.com/healthcare/2023/79percent-of-consumers-want-to-pay-all-medical-bills-from-one-digital-platform/

Subscribe now

Whether it is figuring out a diagnosis, formulating a treatment plan, or simply learning about a patient’s life, we construct narratives to understand and exchange ideas in order to provide care. At the core of this interaction is human language, which enables the rich and high dimensional information exchange that we have evolved to be naturally good at.

Amidst all the buzz about large language models (LLMs) and system such as ChatGPT, what stands out to me the most is not the their information retrieval capabilities (which is impressive albeit with limitations) or that it even represents a new form of “intelligence.” Yann LeCun, Chief AI Scientist at Meta and an early pioneer of convolutional neural nets, articulates these limitations well:

Rather, it is that LLMs now enable humans to exchange complex ideas with AI systems in a way that is more like how we talk to each other. This is a big change from other machine learning (ML) models that only give quantitative predictions or discrete classifications.

In other words, LLMs provide a new “high fidelity API” between humans and AI.

“Cognitive integration” and why it is difficult with current AI systems

In a previous Byte to Bedside post, I wrote about the concept of “thought partnership” and “cognitive integration” of AI into physician workflows.

“Traditional workflow integration strategies focus on deploying technologies based on how they can streamline physician tasks. However, this task oriented approach misses a critical source of value for AI solutions, which is the integration of AI into how physicians think (and vice versa). This “cognitive integration” will be increasingly relevant as AI systems become more intelligent. The use case described above is a good example of how AI and physicians can team up as “thought partners” to enhance each other’s performance. “

True “thought partnership” requires a bidirectional, collaborative relationship where each party brings a unique perspective to tackle a complex problem. The output is greater than the sum of its parts because of the dynamic “back and forth” that leads to new and sometimes unexpected insights. This is what makes being a physician challenging and fun – we are surrounded by thought partners (our fellow clinicians, support staff, and patients and their families), which allows us to continuously learn and tackle the complex problems we encounter in our practice.

It is difficult to achieve this type of thought partnership with ML models that only produce predictions and classifications. The predictions may be highly accurate and come from complex, high dimensional models, but the output is still one dimensional: a single number. Regardless of how accurate that number is, it is far from able to enable the complex, dynamic high dimensional information exchange that human beings expect and need in order to collaboratively solve difficult problems.

This limitation, in my view, is a key reason why many clinician-facing AI systems in healthcare have not gained adoption – the unidirectional deployment of a number (regardless of how accurate it is) does not fit into the complexity of patient care. It also does not seem very “intelligent.”

Language as a “high bandwidth” interface between humans and AI systems

Soon after its launch, ChatGPT spread like wildfire among physician circles. This was something special – after long years of AI innovators struggling to find use cases and gain traction in healthcare, physicians instead were excitedly sharing self discovered use cases in their practice with ChatGPT. This post by a urologist, David Canes, is one of my favorites – a great mix of real world clinical and operational uses inspired by the needs of a practicing physician.

What is different this time? ChatGPT is indeed impressively accurate, but no more accurate than a high quality web search. It does not generate new information or predictions (even though it seems like it does sometimes). The difference is that we can now interact with an AI system with human language. It feels more accessible and attractive because our brains are wired that way — we evolved to communicate, learn, and innovate through language. ChatGPT unlocked an exponentially higher bandwidth link between humans and AI systems.

An example of “thought partnership” with Chat GPT

Consider the following example of how I, as a physician, may use a LLM application such as ChatGPT. I also look forward to trying this out with Google’s Med-PaLM!

I start by consulting ChatGPT about a hypothetical patient I am caring for with heart failure.

The output is fairly accurate, although reads like a laundry list of generic recommendations. However, I focus on step #5 given the patient’s complaint of chest pain, which reminds me that I may be missing a myocardial infarction (heart attack).

The exchange continues:

The conversation takes a turn. I know how to treat an MI so do not necessarily need ChatGPT to tell me specifically which medications to administer. However, its output reminded me that beta blockers may need to be used with caution in a patient with both heart failure and myocardial infarction. I am unsure about the evidence, so ask it to synthesize the latest research. Here, it would have been great if I could directly navigate to those papers (or see snippets of summaries) – a feature I am sure is in the works by some company out there.

Based on my assessment, I do decide to administer beta blockers to the patient, but I remember that his son had expressed anxiety and hesitancy to me when I had mentioned beta blockers earlier.

These explanations are pretty good and incorporate the use of patient friendly language that many physicians are not good at applying.

ChatGPT then helps me and the patient’s son remember that the patient was previously on a medication called labetalol. It also reminded me that there is a beta blocker named levobunolol (as an internist, I often forget the names of eye drops…).

The purpose of this example is to illustrate three points:

1) a patient encounter can consistent of a complex, non linear set of tasks and decisions,

2) back and forth dialogue between a physician and an AI system can help navigate through these tasks and decisions, and

3) the richness of information conveyed through language that far exceeds what would otherwise be possible if the AI system was only capable of putting out a discrete classification or quantitative prediction.

A call to designers and builders: create AI enabled products that can facilitate thought partnership with language.

We will like using it because this is how our brains are wired. The accuracy of the output from the AI system is of course important and sources, bias, errors will need to be transparently conveyed while preserving usability. However, the capability to actively exchange information via human language is, in my view, what is transformative.

What features, designs, and UIs will enable true “thought partnership” between physicians and AI systems? I look forward to finding out.

Having just announced the launch of the Life Sciences Program, its new clinical trials matching solution, the electronic health record (EHR) company is making aggressive moves to capitalize on three of their core assets to become a platform business:

1. healthcare data

2. sticky health system relationships

3. the ecosystem of digitized transactions and interactions that drive patient care.

Epic describes the following key features (quoted from the announcement)

• “Matching participating providers with clinical trial opportunities suited to the makeup of their patient populations.

• Sending participating providers purpose-built Cosmos searches to help them validate whether a trial is right for them without the need to develop their own queries.

• Making clinical trials accessible to more provider groups by lowering the technical and staffing barriers to study activation.

• Increasing clinical trial efficiency by eliminating duplicative workflows and connecting researchers, care teams, patients, and sponsors through a single system.

• Supporting clinicians with point-of-care insights into when their patients might qualify for a clinical trial and applying predictive models to assist with the timing of therapy administration.”

I wrote in a post last year about how EHR systems are beginning to look like platform businesses because of three core characteristics:

1. A high percentage of mission critical processes in healthcare delivery involve the EHR, making it an incredibly sticky product.

2. EHRs accumulate rich data with each additional interaction occurring on its system.

3. “EHR integration” is a favorite word among healthcare technology vendors. What this means is if the EHR, rather than being a barrier, becomes a facilitator for this integration (and not just with the healthcare provider, but also between vendors), it could unlock a lot of value.

Epic’s Life Sciences Program is an example of how an EHR system can stitch together these components into a powerful product if executed well. For example, Epic can aggregate data from documented clinical encounters (sourced from mission critical care delivery processes) and create large cohorts across health systems (data aggregation). Pharmaceutical companies running clinical trials can partner with Epic to access these cohorts and cross reference with their trial eligibility criteria to look for potential trial participants. A provider using Epic can also proactively look up potential clinical trials for their patient at the point of care while using Epic during the clinical encounter (a mission critical process). The addition of the patient (and associated clinical documentation) also adds to Epic’s database to facilitate future clinical trial matching opportunities (data accumulation). All of this facilitates interactions between the patient, provider, and pharmaceutical company recruiting for a clinical trial that otherwise may not have occurred.

Many in the industry emphasize Epic’s advantage in aggregating healthcare data (some have predicted that Epic may eventually become just a healthcare database company), but often underestimate the importance of sticky health system relationships and mission critical healthcare transactions and interactions that Epic owns. A successful platform needs to not only facilitate data exchange, but enable value added transactions between different entities that would otherwise not occur.

Epic’s announcement includes the following quote from Alan Hutchinson, Vice President at Epic: “The Life Sciences program is designed to create a seamless connection between participant patients, healthcare providers, and research sponsors through the use of a single system. Unifying clinical research with care delivery and building a direct connection to study sponsors will help accelerate the development of new therapies by making studies more efficient, more accessible, and more effective.”

Sounds pretty platform-y to me.

I discuss in this post an example of a recently published AI system for colonic polyp classification that approaches “integration” in what I believe to be a clever way: not just into physician workflow tasks, but also into how the physician thinks. I refer to this concept as “cognitive integration.”

The problem: reduce errors in routine, but high stakes procedures

Colorectal cancer screening using optical colonoscopy (OC) is one of the most effective and highest yield preventative clinical interventions in modern medicine. Unlike most other screening tests, OC can also be therapeutic; if a precancerous lesion such as polyp is identified, it can also be removed during the same session. Therefore, it is critical for polyps to be accurately detected and classified by the physician during a colonoscopy procedure.

For a well trained gastroenterologist, performing a screening colonoscopy is a relatively routine procedure, and some may even think of it as a rote task. However, the stakes are still very high, as a missed polyp can turn into metastatic colon cancer. This combination of high stakes and routine repetition can be a dangerous pair in medicine. Human error and cognitive biases will afflict even the most seasoned physicians, and the relatively routine and repetitive nature of the task may actually amplify some of these biases and potential for error.

An AI system that leverages Bayesian thinking to integrate into physician workflow

Current AI capabilities are still far from being able to completely automate screening colonoscopies, which can often be complex and require human expertise. Rather than attempting full automation, Biffi et al in their article in NPJ Digital Medicine describe an AI enabled computer aided detection (CAD) system that functions as a “thought partner” with a human gastroenterologist to reduce errors in polyp detection and resection. The system, which has two components, functions in the following steps (Figure 1):

1. A continuous video stream is fed into the CAD system as the endoscopist performs the colonoscopy

2. The first component of the CAD system initially marks potential areas of interest in the colonic mucosa where there could be a polyp to guide the endoscopist

3. The endoscopist navigates the scope towards areas of interest (does not necessarily have to be where the CAD system marked) and exposes the colonic musoca to better visualize the polyp

4. The second component of the CAD system then automatically activates when a polyp is consistently brought into frame by the endoscopist

5. The CAD system then generates in real time a classification for the polyp in the frame as adenomatous (possible cancer) versus benign, and displays the results of the classification on the screen next to the framed polyp

6. The CAD system then disengages if the endoscopic resects the polyp or navigates away from it

The AI system includes two sets of machine learning (ML) models: the first is a convolutional neural network (CNN) that classifies each detected polyp within a single video frame as “adenoma” or “non-adenoma” and the second is a CNN that generates an image quality score. A key milestone this AI system achieves is the ability to track a polyp across multiple frames in a colonoscopy video and produce a temporally weighted decision (frames that are in focus for longer periods of time are given a higher weight), which is important for real world usability, as images of polyps dynamically change as the endoscopist navigates the scope.

The authors employ a clever strategy of pairing the complementary capabilities and limitations of the AI system and the human physician. The system leverages a Bayesian-guided approach where the AI system, rather than generate predictions independent of any insights that come from the physician and then shows the results to the physician (which is how most AI systems in healthcare operate), actually incorporates prior physician insights into its predictions.

In Bayesian statistics, probabilities are sequentially “updated” with information (priors) to calculate new probabilities that better reflect reality. This is best highlighted in step #4: the CAD system leverages the prior probability generated by the human endoscopist when they navigate to and focus on a suspected lesion, and then deploys the AI classification model on that chosen polyp to generate a conditional probability of whether the lesion is adenomatous or benign. In principle, this conditional probability should more accurately reflect whether a polyp is truly adenomatous than if the AI system naively classified all lesions visualized in the colonoscopy, because it is conditional on the endoscopist focusing on the polyp in the first place, which incorporates their expertise and human instincts.

The study included 513 prospectively acquired polyps from 165 human subjects that were examined histologically to generate ground truth labels. In their primary analysis, the CAD system was non-inferior to expert endoscopists in accurately detecting adenomatous lesions (OR 1.211 [0.766-1.915]) and superior to the accuracy of non-expert endoscopists (OR 1.875 [1.191-2.052]).

“Cognitive integration” of AI into physician workflows

Traditional workflow integration strategies focus on deploying technologies based on how they can streamline physician tasks. However, this task oriented approach misses a critical source of value for AI solutions, which is the integration of AI into how physicians think (and vice versa). This “cognitive integration” will be increasingly relevant as AI systems become more intelligent. The use case described above is a good example of how AI and physicians can team up as “thought partners” to enhance each other’s performance. The CAD system “interprets” the endoscopists’ focus on a lesion as a desire to learn more, and then deploys its AI capabilities on top of insights that the endoscopist already surfaced, which in principle increases its classification accuracy since it incorporates the priors generated by the endoscopist. The endoscopist then uses the AI generated prediction to further hone in on their assessment of the polyp, which also increases their diagnostic accuracy.

When implemented well, this form of cognitive integration between AI and human experts could in theory synergistically enhance the performance of both entities in order to a produce a superior shared result. However, if designed poorly, it could very well amplify biases and lead to poorer performance and other downstream consequences.

The takeaway: when designing AI systems for physicians, consider a cognitive integration strategy that allow the AI and the physician to “make each other smarter.”

References

Biffi, C., Salvagnini, P., Dinh, N.N. et al. A novel AI device for real-time optical characterization of colorectal polyps. npj Digit. Med. 5, 84 (2022). https://doi.org/10.1038/s41746-022-00633-6

Subscribe now

Examples of AI in healthcare typically involve machine learning (ML) models that can perform the same task a human expert performs manually (eg. diagnosing pneumonia on a chest X-ray). The hope is that these systems can be useful for augmenting (or even replacing) existing workflows for clinicians, but more or less preserve the same structure and approach towards diagnosing and treating disease.

I am intrigued by the next generation of how AI can impact healthcare: not by just performing a task that a human already is doing, but enabling new tasks that previously did not exist and fundamentally changing the structure of how healthcare can be delivered to expand access to high quality care.

Over the next few posts, I will be highlighting several examples of ML in published literature that I believe represents this potential opportunity. This post will describe an example of a use case in medical imaging.

First generation of AI in imaging: augment existing diagnostic tasks

Early examples of ML image classifiers in healthcare demonstrated promise in performing tasks that could potentially augment or even replace the workflows of human expert clinicians, such as identifying pneumonia on chest X-rays, pulmonary embolism on CT scans, or skin cancer from photos of skin lesions. The idea is that an AI system could help radiologists and dermatologists perform these existing diagnostic tasks more quickly and efficiently. There are already examples of these capabilities being operationalized into clinical workflows: Viz.ai developed ML classifiers that detect ischemic stroke and large vessel occlusions on head CT images and has even been successful at attaining a Medicare reimbursement code for their technology when used on hospitalized patients.

Next generation: AI enabling new diagnostic tasks

The earlier examples of AI all performed tasks that already existed in clinical medicine (eg. radiologists already routinely diagnose pulmonary emboli and strokes on CT scans, the AI is trained to perform the same task). Yet, we may only be scratching the surface in understanding the complex, hidden relationships between the information from imaging studies and an individual’s physiological and disease state.

The disease phenotypes that we traditionally diagnose from these studies are simply from the accumulated experiences of expert physicians who learned to interpret these images under existing mental models and knowledge structures (as well as the limitations of the human eye). What if we allow an AI system to take a second look, which has the benefit of accessing and interpreting every pixel, voxel, and frame of an imaging study, as well the ability to learn without these pre-existing mental models?

The following study illustrates one example of attempting to apply AI to enable a new diagnostic task on a CT scan: Automated coronary calcium scoring using deep learning with multicenter external validation.

A new way of detecting coronary artery calcification on routine non gated chest CTs

Measuring coronary artery calcium (CAC) can be a useful non-invasive method for detecting coronary artery disease and help risk stratify for treatment decisions. Calcium is radio-opaque, so can be visualized on CT scans. However, because the heart is a dynamically beating organ, the coronary arteries and surrounding muscle and tissue are not stationary, which makes it difficult for radiologists to precisely quantify CAC on regular CTs. To solve this problem, “cardiac gating” is added to the CT image acquisition process, which means that the CT scan is triggered during a specific portion of the cardiac cycle (ie. a point in time during the heartbeat) using attached electrocardiogram leads. Medications to slow down the patient’s heart rate are also typically given during the scanning process.

This specialized CT scan, known as a “gated coronary CT,” is currently required for patients who need to measure their CAC, but are much less widely available (and more expensive) compared to regular CT scans, which do capture coronary calcium but cannot be formally interpreted by radiologists to measure CAC. The result is a significant underutilization of CAC screening to detect latent coronary artery disease, representing a missed opportunity in the early detection and prevention of cardiovascular disease.

What if AI can calculate CAC from non gated routine CT scans?

This is what the research team that published this paper demonstrated with some early data. They trained a deep learning model that automatically calculates the CAC score from regular non gated chest CTs using data from Stanford Health Care, a tertiary academic medical center, and the Multi-Ethnic Study of Atherosclerosis (MESA) study, a multi-center prospective cohort. In a validation set of 42 patients from Stanford (which is also where the data for the training set came from) who also received gated coronary CTs, there was almost perfect agreement between the AI generated CAC score from regular CTs and the radiologist interpreted score from the gated coronary CTs. Agreement was moderate in a validation set of 46 patients from the MESA study. External validation at other sites also showed moderate to substantial agreement. The models also performed well in a binary classification task of detecting CAC greater or equal to 100.

The authors also reported the development and validation of a ML model that automatically calculates CAC from gated coronary CTs with high concordance with radiologist interpretations, which is exciting work and represents the opportunity to augment an existing diagnostic task.

I am, however, particularly excited about the results from the non gated CT model, which indicate the potential for AI to enable new diagnostic tasks and workflows, rather than just augment existing ones. Under the current standard of care, access to CAC screening is fairly limited, especially among more vulnerable populations (who are also often at higher risk of cardiovascular disease). Relying on only gated coronary CTs also misses all the opportunities for CAC detection from regular non coronary CT scans that people receive for other reasons. An AI system that could capture diagnostic and screening information from these regular CT scans could fundamentally change how we screen for CAC: by shifting from a centralized system gated (no pun intended) by a limited number of specialized centers to a more distributed system that can spread much more widely in the community.

There is much more work to do beyond this proof of concept paper. Models have to be developed on larger, more representative datasets and assessed for generalizability. Implementation feasibility, ranging from technical and clinical integration, will need to be explored and tested. It may even be possible that it turns out the ML is not as good as expected when stress tested under other conditions. However, I believe this foundational concept of AI extracting insights from previously untapped diagnostic tests to enable new workflows that broadly expand access to care is will drive important future work in AI.

Reference

Eng, D. et al. (2021). Automated coronary calcium scoring using deep learning with multicenter external validation. Npj Digital Medicine, 4(1). https://doi.org/10.1038/s41746-021-00460-1

Two seemingly unrelated headlines caught my attention recently: one is the widely discussed Oracle acquisition of Cerner, and the other is an article in NPJ Digital Medicine describing key challenges and opportunities for leveraging the electronic health record (EHR) to enhance the Sentinel Initiative, the FDA’s medical product safety surveillance program. To me, these are both chapters of the larger story of how the EHRs are transforming from software for medical records into a platforms for healthcare.

Platforms are both technical products and business models

As a technical product, a platform can be thought of as a system of hardware and software on which different applications and processes can be deployed. Historically, platforms involved on-premises architecture that supported the myriad of enterprise applications needed for a business. Much of this has since migrated to the cloud as platform-as-a-service (PaaS) solutions. In healthcare, large cloud players such as Microsoft Azure, Amazon AWS, and now increasingly Google Cloud offer PaaS products in addition to their infrastructure services that allow healthcare customers to deploy applications and analytics on its technology stack. Oracle has been a PaaS leader in many industries, but not healthcare.

The broader way of thinking about platforms is as a type of business model. Platform businesses enable exchanges between different entities by facilitating connections and transactions. Value creation therefore does not rely on a linear supply chain (build, ship, and sell a product to the customer), but from the cumulative connections and interactions that occur on the platform. Revenue is generated per interaction rather than per product unit, which is a powerful driver for economics of scale. Successful platform businesses can create network effects, meaning each additional entity joining the platform creates more value for the rest of the platform. For example, each additional driver and passenger who joins the Uber platform increases the total number of available drivers and customers, which then increases the chance of a value generating match.

EHR systems are beginning to look like platforms

The EHR is traditionally thought of as a piece of software for documenting, organizing, and accessing patient health records. The interaction is mainly limited between the user (clinician) and the EHR software. However, the scope of transactions that EHRs support have rapidly expanded to other mission critical services, such as revenue cycle management, clinical research, regulatory reporting, clinical communication, and patient engagement. These expanded services also come with an exponential increase in both the volume and diversity of interactions occurring through the EHR. Clinicians are no longer the only users of EHRs; patients, researchers, government regulatory agencies, non clinical healthcare staff, and medical device and digital health vendors are all now part of a growing list.

However, EHRs are not platforms yet. EHR companies still typically follow a linear SaaS business model, deriving most of their revenue from enterprise contracts with healthcare provide customers. While there are indeed a large number of interactions with the EHR system by different types of entities, these interactions typically occur directly with the EHR system, rather than between the entities themselves. Plenty of healthcare software vendors try to “integrate with the EHR” to reach users, but the EHR is often seen as a barrier to get through, rather than a facilitator for the interaction, which is what a true platform is supposed to offer. EHR systems are now starting to integrate different services and applications, such as clinical care, patient engagement, and revenue cycle in a “platform-like” manner; that is, they provide the technical back-end for these applications to interact with each other, but they ultimately still occur within the walled gardens of individual enterprise customers. I am interested in seeing what comes out of the Epic Research Network and the Cosmos program, which is working towards aggregating patient data from different health system customers to support research and discovery, which can potentially facilitate value generating interactions between health systems, vendors, and researchers.

Nevertheless, I believe EHRs are powerfully positioned to become platform businesses because:

1. A high percentage of mission critical processes in healthcare delivery involve the EHR, making it an incredibly sticky product.

2. EHRs accumulate rich data with each additional interaction occurring on its system.

3. “EHR integration” is a favorite word among healthcare technology vendors. What this means is if the EHR, rather than being a barrier, becomes a facilitator for this integration (and not just with the healthcare provider, but also between vendors), it could unlock a lot of value.

What does this have to with Oracle’s Cerner acquisition and the FDA Sentinel Initiative?

My view is that they are examples of growing supply and demand for EHRs to become platforms.

I can only speculate, but one version of the strategy behind Oracle’s acquisition of Cerner may be to create a true healthcare technology platform that facilitates interactions between entities within the healthcare ecosystem, including patients, providers, healthcare provider organizations, payers, third party software vendors, and government organizations. Oracle has the cloud, middleware, and analytics stack — all building blocks of a platform solution — and Cerner has the data and reach into healthcare services to cultivate a customer base and ecosystem.

On a parallel note, this article lays out a set of barriers to scaling the FDA Sentinel Initiative for medical product surveillance. Currently, there does not exist the infrastructure and analytics stack needed to leverage data from multiple EHR systems, payers, and medical devices fragmented across the industry in order support a surveillance program at the necessary scale. A healthcare platform that weaves together these entities can make it happen.

There are elements of healthcare that will present barriers to allowing platform businesses to grow in the same way as they have in other industries. However, I am excited to see the growth of both supply and demand, which makes me optimistic that the secular trend is there.

I recently came across a nice publication describing an example of a real world implementation of remote patient monitoring (RPM) for patients with Covid-19 at the Mayo Clinic. There are a few aspects of this paper that I particularly liked that I will discuss, but it also led me to think about a more fundamental question of whether provider organizations should approach RPM as a set of technologies, or a care model?

RPM refers to digital technologies that allow for the capture of health data from patients remotely (eg. at home) and the transmission of that data to providers in order to guide the diagnosis and management of health conditions. At a high level, the technology is broken down into the following components: hardware that detect the health data (eg. glucometer, blood pressure cuff, scale, pulse oximeter, ECG tracing), software that organizes and at times analyzes the health data, and the capability to transmit the health data and insights to the provider, often via an online portal or integration with an existing system such as the electronic health record (EHR). The value proposition for RPM has mostly centered around disease prevention through early detection and decreasing healthcare utilization, although the Covid-19 pandemic has surfaced the additional benefit of decreasing unnecessary in-person patient/provider interactions, which has greatly accelerated the interest and adoption of RPM.

A frequently noted challenge and barrier to adoption for RPM companies is “integration” into care delivery. The barrier is often seen as technical, with a common one being integration of data from the RPM system into the provider’s EHR. This problem, in fact, is often more easily solved than expected, as there are a variety of methods for integrating external data into EHRs. I believe that a more important question is how RPM integrates with the care model it is meant to improve.

Coffrey et al. describes in the latest issue of npj Digital Medicine a RPM program for managing patients with Covid-19 at the Mayo Clinic. The technology component of the program is fairly simple: a set of equipment provided by Mayo to patients for monitoring vitals signs at home (thermometer, blood pressure cuff, pulse oximeter) that deliver patient reported data to providers via either manual entry or passive collection from bluetooth connected devices.

What caught my attention about this paper was not its RPM technology, but how they presented the RPM implementation as a comprehensive care model. The components of the RPM care models are summarized in this table. The care models were centered on a specific patient population (Covid-19) and detailed in a granular fashion the value added steps needed to deliver care for those patients. The technological component was only a piece of an overall tech enabled process that includes care pathways and care team engagement methods specific to this care model.

This way of presenting a RPM implementation is important because it highlights that the implementation is actually that of a tech-enabled care model rather than just a technology. The endpoints they propose to evaluate the RPM program were also appropriately chosen to capture the processes of this care model.

RPM evaluation endpoints (from https://www.nature.com/articles/s41746-021-00490-9/tables/4)

Recognizing what it is that we are actually implementing is critical for understanding the barriers and facilitators to implementation and the expected impact on care delivery. Often, what may initially appear as an implementation of a technology such as RPM is actually an implementation of a new care model. And implementation barriers, such as data integration challenges many RPM companies face with provider organization clients may appear to be technical on the surface, but in reality arise from the lack of a clear RPM enabled care model.

Getting the data in is easy, knowing how to use it is harder.

*Reposted* — originally published on 7/12/2021 on byte2bedside.com

One of the revolutionary advances in software and internet services is the emergence of application programming interfaces (APIs) that allow for processes to occur between software applications in a consistent manner that can be easily scaled.

APIs make it possible for consumers to conduct and receive all sorts of services such as online banking and ordering merchandise with a consistent experience that is high quality and low cost. At the foundation of these services lies a series of data exchanges and processes carried out between different software applications that must be consistently executed and easily scaled. APIs provide the interaction points between software applications to allow this to happen.

Imagine if next time you order an item from Amazon, after clicking the “order” button, you are instead instructed to wait for a phone call from the merchant to confirm your order. The phone call comes in three days (although there is a 20% chance that it may never come), which ends up going to your voicemail. You check your voicemail and call the merchant back, only to be greeted by someone who was not aware that you had even placed the order, and asks for you to go through the order information again. You describe to the representative the item that you want to order, but it turns out that the item originally listed on the website is no longer available, but there is an alternative brand that can ship in three weeks, but they are unable to tell you anything more about the product, or even how much it costs. And it turns out that if you want to buy a different item, you will have to go through a different lengthy and complicated process that changes depending on what item you order.

The above scenario is not far from the realities of what patients have to go through to receive services in healthcare, such as scheduling an appointment, getting a referral, or getting medical records. Similar to software processes, healthcare services also involve interaction points between people, software, and organizations that require multiple exchanges of information that results in some action (eg. an appointment getting scheduled). There are of course some key differences between getting a referral for an orthopedic surgeon for a knee replacement and ordering trash bags from Amazon, but the underlying need for consistency, efficiency, and scalability applies to healthcare services just as much (if not more so) as online shopping. Countless medical errors and unnecessary waste occurs in healthcare due to the lack of these qualities.

When thinking about the potential for informatics in healthcare, I am particularly excited about the opportunities to “API-fy” healthcare services; that is, to leverage data, software, IT infrastructure, and processes to create “APIs” (both literally and figuratively) that can make healthcare interaction points more consistent, efficient, and scalable. What if a patient with a worrisome skin lesion could secure a referral with an available dermatologist within minutes, rather than having to play a months long game of back and forth phone tag with insurance companies and schedulers that may result in delays in care that could turn out to be deadly? There are many interactions and processes in the back end that would need to take place for this to occur, many of which could be addressed by actual software-software APIs, and others by human and organizational driven processes that can still follow the principles of software APIs to deliver the needed consistency, efficiency, and scalability.

Just as how software APIs have evolved from just code into products, I envision these healthcare “APIs” to also emerge from disparate processes into packaged products and services that involve software, data, and organizational mechanisms.

There is much excitement about AI in healthcare, but we still don’t quite understand how it can produce impact at a meaningful scale.

Discussions about AI often jump to examples of machine learning (ML) models that perform eye catching tasks such as interpreting X-rays and diagnosing disease. However, although there is no shortage of published papers describing highly accurate ML models that predict all sorts of clinical outcomes, there is a dearth of actual AI products that are widely adopted and deliver value.

Common explanations for this gap between research and real world application include low risk tolerance in healthcare, complexity and messiness of healthcare data that limit the ability to train ML models, lack of IT infrastructure for deploying ML, and unclear ways to integrate ML models into clinical workflows. In essence, the problem, as described, centers around limitations in being able to train and deploy ML models and understanding what to do with them.

These explanations tell part of the story, but I think there is a deeper gulf of understanding that precludes the use of AI in healthcare in a way that delivers meaningful impact. To explain further, I find it useful to draw from the history of cloud computing.

The concept of the cloud was born out of a technology known as virtualization, which for a non-IT professional like myself, can be simplified as the ability to duplicate the functionality of a physical computer into multiple entities beyond the original hardware. So if I have a computer with 500GB of hard drive space, 2.3GHz CPU, and 32GB RAM that contains a set of files and software, virtualization would allow me to distribute the storage space, processing speed, and memory across multiple other “guest” computers via virtual machines that can run the same software and access the same files located on the original host physical computer. This functionality, which was first developed decades ago and iterated over time, is foundational to the ability to flexibly distribute and scale IT resources and construct what is commonly referred to as the “cloud.”

Cloud computing has now made its way well beyond concept into being a core component of the modern economy. To appreciate its full impact, we need to look beyond just the traditional cloud service providers (eg. AWS, Azure, GCP) to the vast array of businesses and products that are made possible by cloud architectures such as infrastructure as a service (IAAS), platform as a service (PAAS), and software as a service (SAAS). While a company like Netflix may incorporate cloud computing into its tech stack to build its products, its business value is generated from what is enabled by the cloud, rather than directly from the cloud itself. Netflix did not start its business sitting on a bunch of virtual machines and wondering what to do with them; rather, they identified a set of unaddressed needs in the market and realized that cloud computing would enable a suite a products that fulfilled those needs.

I find it useful to compare AI to cloud computing in that both ML and virtualization are significant methodological advances that can deliver new functionalities and enable products and business models that previously were not possible. But just as the early developers of virtualization software probably did not envision the creation of Netflix, it is also difficult for the AI community to fully appreciate what future products and business models can be made possible by AI. We need to look beyond the immediate applications of ML models to the higher order derivatives that may emerge from functionalities that AI enables. By re-framing the question from “what can we do with a more accurate ML model” to “what do we need to change in healthcare, and what future state products, care processes, and business models needed to deliver these changes can be made possible by AI,” we can greatly expand the opportunity space for AI in healthcare.

AI enthusiasts will point to the novel deep learning classifier that detects atrial fibrillation from captured ECG waveforms, while others will speak to the sensing capabilities of the hardware or the usability of the app.

The ECG app on the Apple Watch Series 4 detects signals from your pulse that is fed into a deep learning classifier and detects the presence of atrial fibrillation. In a study of 419,297 participants over a median duration of 117 days, the app was found to have a positive predictive value of 84% for detecting atrial fibrillation.

https://www.apple.com/healthcare/apple-watch/

The iPhone and Apple Watch as illustrative examples

When Steve Jobs first unveiled the iPhone in 2007, he cryptically began his introduction by describing three separate products: “a widescreen iPod with touch controls, “a revolutionary mobile phone”, and “a breakthrough internet communications device.” Although the applause from the audience grew with the announcement of each separate “product,” the punchline was of course when he revealed that they are actually features of one product: the iPhone. Jobs then moves on to describe three enabling technologies that made the iPhone revolutionary at the time: the multi-touch screen, a powerful operating system and suite of software, and syncing capabilities with other products in the Apple ecosystem.

The purpose of this post is not to promote Apple products, but to illustrate a concept that I think Apple understands very well: breakthrough innovation does not come from advances in just one type of technology, but from the integration of multiple streams of technologies that creates something greater than the sum of its parts. The same concept applies to the Apple ECG app. The AI, digital health, and hardware components are of course all advanced in their own right, but it is the integration of these capabilities into a product that allows us to think about how these individual technologies can impact health. This is not an easy task, and is part of the great filter that sits between new technologies and great products.

In the case of the Apple ECG app, integration needed to occur both in technology and design. On the technical end, the AI needed to be integrated into the software and hardware systems that ingest and derive the right data into model features at runtime, and enable the delivery of the predictions in a way that creates a viable user experience. A model prediction, however accurate it may be, must also be integrated into a user experience that drives desired behavior changes in order to be impactful on health. The Apple ECG app is innovative precisely because it is not simply just a smartwatch, an AI model, and a sensor. The integration of these three technologies created something that is greater than the sum of its parts.

The AI model predictions generate snippets and clinical interpretations of ECG waveforms that can be saved into the Apple Health Record, which is a digital personal health record that aggregates data from electronic health records from APIs. A notable gap here is the ability to upload data from Apple Health Records into the EHR systems used by physicians (as indicated here, a PDF has be generated and emailed or printed for the physician).

https://support.apple.com/en-us/HT208955

Innovation as an emergent property

In systems science, an emergent property is a property of an entity that cannot be derived from just the sum of its individual parts. For example, a neuron in a human brain is comprised of individual units such as a lipid membrane, organelles, DNA, and neurotransmitters, each with its set of properties and functions. However, as the neuron fires and ultimately leads to a complex emotion such as love or sadness, this “emergent” phenomenon cannot be explained simply be adding up the functions and properties of the individual units.

I like to think of innovation as an emergent property that comes from the interactions between people, processes, and technology. This is important to keep in mind in technology driven fields such as health IT, where it can be easy to fall into the trap of equating innovation with the novelty of a particular technology. Organizations that are looking to update their tech stack with the latest AI, cloud, and digital capabilities need to think about how these technologies interact with each other, and with the people and processes that they are looking to service and improve. Rather than just assessing each technology separately, innovators need to take a step back and look at big picture: what emerges when these components of the tech stack interact with each other and integrate within the ecosystem of people, technologies, and processes where the problems they aim to solve exist?

Apple and Jobs understood this concept well. Otherwise, they may as well have ended up separately developing a phone, music player, and mobile internet browser rather than the iPhone.

Why this is relevant now with AI in healthcare

The recent advances in AI and large language models are impressive, but represent only one of the building blocks for the types of innovation that will truly change healthcare. These capabilities need to be integrated with the rest of the healthcare ecosystem in ways that will allow these innovations to emerge. What they will look like can be anyone’s guess — but likely not just an AI chatbot that answers medical questions.