AI Needs a Place to Land: Building the Connectors Missing in Healthcare
What does it take to engineer the intelligent care models of the future?
It is 11pm. A hospitalist needs subspecialty input for a patient whose condition is evolving in a direction she doesn’t fully understand. She pages the consult service. The on-call fellow, managing eight other active consults, calls 30 minutes later only to notify her that she needs to call another consult service which manages this condition, an institution-specific nuance the hospitalist forgot. She then calls the second consult service, which is equally busy and takes another 45 minutes to respond. After taking time to manually review the patient’s extensive medical records in the EHR, having several back and forth conversations with the care team, and finally seeing the patient, the consultant is able to pass along a recommendation four hours later.
The above is a typical scenario that currently exists across hospitals across the country. Healthcare’s specialty consultation system — the mechanism by which a generalist physician transfers a complex clinical question to a specialist — was designed for a world of cognitive scarcity. The system that emerged from those constraints and leads to persistent gaps in access to care is built on queues, bottlenecks, and the assumption that medical knowledge and reasoning is always the rate-limiting resource.
AI changes that assumption. We are entering an era of cognitive abundance, in which many of these resources are no longer scarce and constrained by the availability of human experts. This abundance, however, requires care model infrastructures that can reliably carry this intelligence into where the care actually happens.
Current systems of care delivery in healthcare are not designed to effectively accommodate this cognitive abundance.
Care Model Engineering as a Discipline
This post is about a discipline that bridges that gap. I’ve started calling it care model engineering, an organizational capability that healthcare is not yet building.
Engineering is the disciplined practice of translating those ideas into systems that work reliably at scale under real-world constraints with defined performance criteria. Care model engineering, as I envision it, is the emerging practice of designing, building, testing, and iterating on the systems through which care is actually delivered with the same rigor we apply to the technologies embedded within them.
Rather than deploying AI tools into existing workflows, we ask a more fundamental question: given cognitive abundance, how should the care model be designed, and how do we connect the intelligence into it?
AI is redefining what is scarce and abundant, which should drive care model design
Design principles in healthcare are fundamentally changing.
For most of healthcare’s history, care models were designed around scarcity of human resources. The underlying logic was: given limited cognitive resources, how do we triage and allocate them?
AI changes this founding constraint. We are entering an era of what might be called cognitive abundance, in which the capacity for knowledge retrieval, synthesis, reasoning, and task execution is no longer always the rate-limiting variable. The design principles that follow from this shift are different. Instead of asking “how do we allocate scarce cognitive resources most efficiently?”, care model engineering asks “given that reasoning capacity is increasingly abundant and inexpensive, what is the new optimal architecture?” The answer will look fundamentally different from what we built when intelligence was scarce.
Analysis of value chains in healthcare reveals leverage points for transformation: an illustrative example in specialty consultation
The first step in care model engineering is not to reach for an AI tool; rather, it is to map the value chain of the care process you intend to redesign. A value chain analysis breaks a care model into discrete steps, maps where value is and isn’t generated, and identifies the specific failure modes that account for the gap between what the system should deliver and what it actually does.
Take specialty consultation during a hospitalization, a care model that has changed little in decades. The value generating steps of the consult value chain includes the following: the decision to consult at the right time in the patient’s care, identifying the right consult service, framing a high yield clinical question, initiating the consultation by the requesting clinician, orienting the consultant, the consultant performing a high quality clinical assessment, communicating the recommendation, and closing the feedback loop. In current practice in most hospitals, most steps in this chain are manual, unstandardized, and largely invisible to operational analytics, resulting in many workflow steps distributed across the chain that do not generate value and result in delays in care. Primary teams lack shared definitions of which service covers which clinical question. Consult requests arrive without the information the consultant needs to act, forcing time-consuming back-and-forth. Consultants spend a disproportionate share of their time reconstructing a clinical narrative from scattered chart data, leaving less time for the reasoning that is their actual contribution. The consultation note is written for the medical record; the patient often receives only a brief verbal summary, if any at all. And the system as a whole rarely learns from one encounter to the next, with similar errors and care gaps recurring over time.
Once the value chain has been mapped and the gaps identified, we can begin to imagine how to scale the parts of the value chain that actually generate value, while reducing or disintermediating the steps that do not.
Early lessons from AI enabled transformation of the eConsult care model at Stanford
By leveraging cognitive abundance as a core design principle, we can intentionally engineer a “care model stack” that delivers an improved value chain. The stack has four layers — Knowledge, Intelligence, Application, and Workflow — each of which must be deliberately engineered, and each of which must be designed to inform and reinforce the others.
We illustrate this in practice with our ongoing work at Stanford to re-engineer the ambulatory physician to physician eConsults model into an AI native “eConsult 2.0” model , which is described in more detail in a previous post and this paper, and is already being piloted in clinical practice. This principle is now being extended more broadly to transform inpatient specialty consults at our organization.
The eConsult program is a specific version of specialty consultation that offers a distinctly favorable environment in which to first apply this framework. It is an EHR-native care model with a defined workflow, a structured question-and-response format, a bounded group of participating physicians on both the referring and specialist sides, and a consultation interaction that already lived inside the digital infrastructure of the health system. These properties form a surface on which the AI could be connected into the care model to solve for the pain points experienced by the consultants.
The early success of the eConsult clinical transformation reveals an important principle: clinical transformation with AI requires connections into an intentionally designed infrastructure for AI to propagate its intelligence into where care is being delivered.
What we need to build: connectors that propagate intelligence from AI models into where care delivery happens
I propose the concept of care model connectors for AI.
A connector is a component of a tech-enabled care model that propagates intelligence from AI into where care delivery happens. The term is borrowed deliberately from the infrastructure that AI and software companies have already built: the integrations that connect foundation models to calendars, email clients, CRMs, productivity suites, and enterprise applications. Those connectors solved the problem of making AI useful in general knowledge work by linking model intelligence to the tools and data flows through which work actually happens. Care model connectors solve the analogous problem in healthcare: linking model intelligence to the workflows, relationships, knowledge structures, and care processes through which clinical work actually happens.
The analogy is instructive precisely because it reveals what healthcare has not yet built. When a software company connects an AI model to a calendar, the calendar already exists as a structured, observable, standardized environment: defined fields, clear data types, API access. The connector can flow intelligence into it immediately. When a health system tries to connect an AI model to its specialty consultation process, it often finds no such environment waiting. The consultation process is scattered across EHR message pools, phone calls, informal pages, and hallway conversations, all of which are unstructured, unobservable, and inaccessible to the AI. In order for AI to propagate its intelligence into the care model, the environment it needs to connect to must first be engineered and built.
How is care model engineering and building connectors different from traditional ways of integrating AI into workflows?
The current pre-dominant approach for integrating AI into healthcare is task-centric and AI-first: identify a specific workflow step where AI can reduce friction — e.g. a documentation burden, prior auth queue, or triage decision — and deploy an AI model there. The question driving the work is “how do I bring AI into this task?” Each integration is designed in relative isolation and optimized for its specific friction point without necessarily considering the broader care model it operates within.
Care model engineering starts from a different question: what are the attributes of this care model as a complex sociotechnical system, and how should it be redesigned given that intelligence is now abundant where it used to be scarce? Rather than optimizing individual tasks, it maps the people, processes, and technologies of the care model, the relationships and obligations between them, and the leverage points where redesign generates the most value. Connectors are then built at those leverage points to propagate AI intelligence into the components of the system where it can change the care that is delivered. And critically, they are designed with the rest of the care model in mind.
This orientation also reveals that the design principles for a given care model tend to generalize. The architecture for connecting AI into eConsults — knowledge base generation, EHR data retrieval, application and UX, feedback capture and monitoring — is not specific to Stanford or to ambulatory eConsults. It is derived from what consultation structurally is as a care model: a transfer of diagnostic uncertainty from one physician to another, resolved through specialized reasoning, with a feedback loop that should generate institutional learning. Any institution building a specialty consult care model using AI needs those connectors, because the underlying care model logic is the same.
Care model connectors are the reusable components of the care model infrastructure needed to connect AI into where care delivery happens.
Building connectors for AI enabled specialty consults: what this looks like in practice
The traditional eConsult care model (“eConsults 1.0”) had a few key constraints that limited the ability for consultants to deliver timely consultations at scale. Templates were created to guide requesting physicians to ask appropriate clinical questions and include relevant data, but they relied on manual curation and were often incomplete and difficult to maintain. Consultants spent most of their time reconstructing the clinical picture from scattered chart tabs before they could begin reasoning and form their recommendations. Knowledge was siloed in individual consultants. And the system did not learn from one exchange to the next.
The connectors we built for eConsult 2.0 were designed to enable AI to change each of these constraints.
At the knowledge layer, we built an AI enabled pipeline to generate and continuously refine specialty templates grounded in evidence and specialist validation with an accountability structure for maintenance. We also built tooling that matches incoming eConsult questions to the relevant sections of the knowledge base, pulls the pertinent EHR data, and surfaces it in a way that is explicit and auditable so the specialist can see exactly what the model is drawing on and why.
At the intelligence layer, there is tooling that enables the AI to complement rather than replace specialist judgment. For dermatologists, for example, the clinician continues to assess photos of skin lesions using their own expertise, the AI supplements that assessment by surfacing the relevant EHR data in response to what the specialist is actually looking at, rather than presenting everything upfront. This was key to generating physician trust and adoption.
At the application layer, tooling allows the AI workflow launches from within the existing eConsult build in Epic with pre-fetched data (triggered by the system’s detection of a new eConsult question) so the AI inference is completed well before the user opens the application, ensuring no lag time. This is designed so that completing an eConsult with AI assistance feels like a natural extension of the existing experience rather than a context switch.
At the workflow layer, we are still developing what the full transformation looks like. We anticipate that as AI handles more of the synthesis and drafting work, the roles of eConsultants and program staff will evolve, with more capacity to focus on complex cases, and new roles emerging around knowledge base stewardship and system oversight that tooling can be built around for AI to support.
And to enable continuous feedback and a learning system, we are building ways to capture specialist responses and custom benchmarks that go beyond general clinical AI benchmarks to evaluate performance on tasks specific to the eConsult workflow. The purpose is to not assess whether the clinical reasoning is sound, but whether the model is doing the right things at each step of the consultation process, and how those insights can be surfaced to improve the system over time.
The success of the eConsult 2.0 work did not come from deploying any specialized AI model, but from the connectors that we built to land the AI into the clinical interactions that already had meaning to the physicians practicing in the care model.
To apply this blueprint to inpatient specialty consults in hospitals, the care model architecture needs to be engineered for a much less structured environment. A structured consult initiation connector — the one eConsults had by virtue of its existing EHR-native workflow — is what we are building first: migrating consult initiation from informal paging into structured EHR orders, establishing shared standards for what a well-formed consult request looks like, and building specialty-specific knowledge bases that encode each service’s consult logic. These efforts will create the surface on which AI can eventually connect into and operate, and through which it can eventually transform the care model the way eConsult 2.0 demonstrated in the ambulatory setting.
Guiding principles for building care models with AI
The journey from a broken consult value chain to an AI-native specialty consultation system is an illustration of the broader journey that healthcare as a whole needs to make. It highlights why care model engineering must be recognized as a discipline in its own right and what that discipline demands of health systems and the AI industry alike.
AI needs a place to land. AI projects fail in healthcare rarely due to limitations in model capabilities; it is the absence of the clinical and operational infrastructure that would allow model intelligence to reach where care happens. Invest in modernizing the care model infrastructure to maximize the “return on intelligence” of AI.
Components of the care model need to be intentionally designed for AI to work. I refer to these as components (which can be both technical and non-technical) as “care model connectors,” – e.g. workflow integrations, application designs, knowledge bases, custom benchmarks, feedback capture mechanisms, etc – that are designed for the intelligence from AI to propagate to the people within the care model in a way that is useful and meaningful. Designing and building these connectors should be approached with the same rigor as engineering work, not as just “last mile” implementation overhead.
We need to design AI in healthcare for care models, not just for individual clinicians. The general-purpose connector ecosystem linking foundation models to calendars, CRMs, and productivity suites is maturing rapidly. Healthcare needs the equivalent: e.g. care model-aware agent frameworks and benchmarks, monitoring systems, UX designs, all of which can be modular, shared, and scaled in care model connector libraries.
Care model engineering enables the learning health system. A care model engineered with well-designed connectors gets better with scale. For example, each AI-assisted consultation exchange generates signals – e.g. specialist modifications, escalation decisions, response time changes, patient outcome – that reinforce the quality of the future consultations. With an AI “cognitive abundance” mindset, high volume does not necessarily translate to higher work burden and stress; rather, volume can enable improvement at scale and transformation.
The return on intelligence of AI in healthcare is a function of AI model capability and the quality of the connectors that carry and compound that capability into better care. Intelligence from a frontier model with no connectors into care delivery is wasted. The organizations that understand this and invest accordingly in the discipline of care model engineering will be the ones that finally deliver on the promise of AI in healthcare: better care, for more people, at lower cost.