The patient arrived just before 5 p.m., in that uneasy hour when the emergency department is already full, and the night hasn’t yet brought its highest volume.
By the time the resident opened the chart, the screen looked less like a medical record and more like a novel, or several hundred of them. Years of clinic visits. Outside hospital records. Scanned PDFs. Specialist notes that ran for pages. In the words of Aditya Sharma, Senior Manager of Data Engineering at Stanford Medicine, a single patient’s text record (excluding multimodal data) can amount to “about 250 novels’ worth of data.”
It's like every person walking into the hospital is carrying their own private library."
- Aditya Sharma
In a setting where minutes matter, that much information can be a blessing and a burden. The more data clinicians have, the better their decisions can be. But they only have so much time and attention.
On that afternoon, instead of scrolling note by note, the resident typed a question into a new Stanford-created tool embedded in the electronic health record: ChatEHR. Within moments, the system returned a concise summary of the patient’s relevant history: the key diagnoses, the medications that mattered, the recent admissions that might change the plan.
“Think about a scenario where a patient is arriving by ambulance to the emergency department with an exhaustive chart,” said Satchi Mouniswamy, Senior Director of Integration, who works closely on ChatEHR. “Reading all the external continuity of care documents takes a huge amount of time. The patient is critically sick. But ChatEHR summarizes everything — it’s like your augmented assistant. You throw one question at it, and it gives back exactly what you want.
“It’s not only helping that one patient,” he added. “It helps reduce provider burnout and keeps the ED moving faster.”
ChatEHR is Stanford Medicine’s attempt to answer one of the most pressing questions in modern healthcare: in a world of overwhelming digital data and accelerating AI, how do you actually put these technologies to work, safely and at scale, inside a complex health system?
The real story here is not only the software. It’s the system — the cross-functional way a group of data scientists, engineers, informaticists, product managers and clinical staff are trying to build a replicable model for AI.
“There’s no playbook for how you work in this environment,” said Sharma. “It’s like standing in front of a soundboard with a billion knobs. Which levers do you pull to be most effective?”
This is their attempt to write that playbook.
Part One: How Stanford Built This Team — And What Makes It Work
The Problem Worth Solving
Electronic health records were supposed to make medicine more efficient. In many ways, they did. But in others, they’ve created a new kind of overload.
Healthcare professionals now confront a volume of information that would have been unimaginable just a decade ago: labs, imaging, notes, consults, messages, outside hospital records, all piled into a single digital chart.
Every additional note, scan, or lab result is potentially useful; almost none of it is optional. The result is a chronic tension: more data can mean better care, but only if someone can find and interpret it in time.
Within Stanford Medicine, the Technology & Digital Solutions (TDS) team heard the same complaint from different corners of the hospital: the information is in there; it’s just too hard to get to and synthesize into something useful.
They knew they were not alone; health systems across the country are wrestling with the same problem. A wave of AI tools promises to help, but most end up as pilots that never leave the lab.
ChatEHR grew out of a simple question: could an AI assistant sit within the EHR and help clinicians cut through that noise without adding yet another portal, login, or workflow?
At first glance, ChatEHR looks like something familiar: a chat window, embedded into the EHR, where healthcare professionals can type questions in plain language.
What’s different is what it can see, and what it’s designed to become.
ChatEHR can scan across structured and unstructured data, surfacing the pieces that matter for the question at hand: “Has this patient ever had a positive biopsy?” “What were their last three A1c readings, and when?” “Summarize the last 12 months of cardiology notes.”
Behind that simple interface is a carefully constructed set of pipelines into the underlying EHR and related systems. The aim is not to replace judgment but to reduce the cognitive and logistical burden of finding the right information at the right moment.
“We’ve already seen ChatEHR assist in multiple cancer diagnoses,” said Duncan McElfresh, Product Manager. “It’s still early, but when you see it help catch something that might have been missed, you realize this is not a toy — it’s a serious tool.”
Inside the team, ChatEHR is described not just as a product but as a platform: specialized automations tuned for particular tasks or departmental needs are being layered on top. Automations are scoped applications of ChatEHR for routine tasks scaled across many users and patient records, delivered in the workflow for action. They are delivering value today to surface patients eligible for sites/services, accelerating referral and billing processing, and improving clinical experience.
“We had to kind of get in there and let it be a little messy,” said Nerissa Ambers, Director of Health Informatics Transformation. “You learn, then iterate and validate and go through these cycles. You can’t really know what it’s going to be until you actually make it.”
Building on Solid Ground
If ChatEHR is the visible tip of the iceberg, the larger mass lies hidden in data engineering, integration work, and infrastructure.
In practice, building ChatEHR meant:
- Establishing secure, governed access to clinical data at scale.
- Designing pipelines that could unify information from multiple EHR instances and external systems.
- Embedding the chat interface directly inside the EHR so healthcare professionals wouldn’t have to toggle between tools.
Those decisions required more than technical skill. They demanded institutional willingness to invest in modern, secure infrastructure, and to let a cross-functional team work across traditional boundaries between IT, analytics, and operations.
Without that bedrock, the team argues, no amount of AI experimentation will make it into everyday practice.
“At Stanford, we’re very fortunate in that we have access to so much,” Juan Banda, Lead Data Scientist, remarked. “It has to be HIPAA-compliant and secure, of course, but I’m not limited to, ‘Oh, you need to use this janky thing from 1980, and that’s the only thing you get.’ That investment from leadership makes my job possible. Otherwise, I’d just be sitting here with this cool thing on my computer that we can’t put anywhere.”
Evaluation and the Reality of Workflow
In the broader tech world, success is often measured by launch dates and feature counts. In healthcare AI, those metrics barely scratch the surface.
The TDS team treats evaluation as both a scientific and a practical discipline. On one level, they measure things like accuracy, hallucination rates, and response times. On another, they focus on questions clinicians and operational staff actually care about: Does this save time? Does it help catch important details? Does it slot into existing workflow, or does it add friction?
“Before, it was easy to build something for a paper or a grant and let it die there,” Banda said. “Here, the question is, how do we build something meaningful that actually delivers real value for patients and providers — and then measure it?”
The team studies how ChatEHR is used in the wild: which questions healthcare professionals ask, at what points in their workflow, and how often they accept or override the system’s outputs. That data informs both model tuning and product design.
At the same time, they align their work with emerging frameworks for clinical AI oversight, including approaches like the FURM assessment framework and MedHELM, an evaluation framework for assessing LLM performance for medical tasks. Post-deployment monitoring, for performance, safety, and equity, is treated as a core part of the product’s life cycle, not an afterthought.
Many Org Charts, One Mission
If the technology behind ChatEHR is complex, the human organization that supports it is arguably more so.
The core team includes:
- Data scientists and machine-learning specialists
- Data engineers and integration experts
- Nursing informatics professionals
- Product managers and UX designers
- Clinical champions and operational leaders who co-own the work
They report up through different parts of the institution: IT, operations, nursing, and compliance. No single department “owns” ChatEHR. Instead, the product sits at the intersection of many lines of authority.
“Within Stanford, the people on the business and ops side, the clinician side — everyone really wants to solve problems together,” said Abby Pandya, Senior Manager of Data Science Product Management. “That’s why we’re all here.”
Nerissa Ambers spends much of her time making sure the human workflows around ChatEHR keep pace with the technology: training, documentation, feedback channels, and the inevitable process changes that come with any new tool.
“You’ve got to be the human in the loop,” Ambers said. “I don’t just let AI write for me, and we don’t just let it run the show here either. It’s always about people working together around these tools.”
“Nothing you do in a health system is one person, or even one group,” as Pandya put it. ChatEHR is as much a social product as a technical one.
"The technology itself is only half the equation; the true breakthrough is the organization we are delivering to enable it," said Nikesh Kotecha, Head of Data Science. "We are intentionally spending the time to build a cohesive, cross-functional system across our data science, technology, and healthcare operations groups. Delivering that foundational organization is critical—without that time investment, these innovations simply never reach the patient."
Beyond Go-Live: The Culture That Holds It Together
For many health IT projects, the moment of go-live is the end point. For ChatEHR, it’s the beginning of a long, and sometimes exhausting, middle.
“We have this really special opportunity right now,” McElfresh said. “And I feel like we are sort of balancing on a couple of different knife edges.”
One is what he calls the “build a faster horse” trap. “The easy thing to do, and we see this a lot in the tech industry, is just trying to build a better horse, a faster horse,” he said. “I think the opportunity that we have and the most value we can get is by trying to build something like the first car or the first iPhone. That’s a very different task. Even our team does a lot of building faster horses, partially because it’s a quick way to build credibility and provide value. But if we just build faster horses for the next five years, our team doesn’t have much of a future.”
The other is the “only focus on ROI” trap. “If all we ever do is ask, ‘What’s the immediate financial return?’ we’ll only build things that are easy to measure and justify in the short term,” he said. “Some of the most important things we’re learning don’t show up as clean ROI right away. They show up as new workflows, new capabilities, new ways of thinking about the enterprise.”
That balancing act — between incremental improvements and transformative change, between speed and safety, between innovation and institutional realities — is not unique to Stanford. But the team’s willingness to talk openly about it hints at the cultural work that accompanies the technical work.
Ask the team what has made their work possible, and they don’t start with algorithms. They talk about leadership.
“Access to the right technology is one part,” Banda said. “But leadership also has to create the space for cross-functional teams to actually work — not just on paper, but in how projects are funded, staffed, and evaluated.”
That means:
- Allowing teams to experiment with new tools and architectures, within clear security and compliance guardrails.
- Measuring success in terms that reflect reality: adoption, safety, workflow fit, and patient outcomes, not just short-term financial returns.
- Accepting that some projects will fail, and that the lessons learned can be as valuable as a success.
It also means grappling with deeper cultural questions. How much risk is acceptable when you’re dealing with patient care? How do you encourage bold thinking without encouraging recklessness?
In retrospect, McElfresh wishes he had tilted a bit further toward boldness.
“If I could go back, I would have told myself to be less cautious,” he said. “Ask for forgiveness, not permission more often. Be less risk averse. Be bold.”
There is no single answer to how bold a health system should be with AI. But the team’s experience suggests that absolute caution carries its own risk: the risk of falling behind, of letting promising ideas wither in the name of compliance with rules that were never written with modern AI in mind.
Part Two: How Others Could Replicate It
From Flagship to Foundation
For now, ChatEHR is the flagship. But inside Stanford Medicine, it is increasingly seen as a foundation.
Other teams are beginning to build on its infrastructure — the secure data access, the integration patterns, the governance processes — to develop their own AI-enabled tools. The idea is not that every department will reinvent the wheel, but that they’ll share a common chassis.
“We’re sitting in Silicon Valley with plenty of opportunities,” Mouniswamy said. “But we stayed because we’re doing something good for the community. It’s different when what you build actually reaches patients.”
That ethos extends beyond Stanford’s walls. Several members of the team talk about an “open-source” mentality; not necessarily in licensing code, but in sharing patterns, lessons, and frameworks that other health systems can adapt, even as academic medical centers weigh which tools to keep open and which to eventually commercialize. What they can control is the robustness of the model they’re building — not the AI model, but the organizational model.
“We’ve had to pave a new path here and a new way of doing things,” said Pandya. “A lot of the existing environment is vendor-driven, so it’s meant changing the mindset — moving upstream to really understand workflows and problems, empathize first, then design and iterate. That’s the kind of model other health systems will need to create too.”
A Playbook in Progress
Strip away the specifics of ChatEHR, and a set of principles emerges — a rough playbook for health systems trying to operationalize AI:
- Cross-functional by default. Data science, integration, product, nursing informatics, and clinical operations are not afterthoughts; they are co-owners.
- Modern, secure infrastructure. Without it, AI remains stuck in the lab.
- Embedded evaluation and monitoring. From design through deployment, the team asks: How will we know if this is working? And for whom?
- Leadership sponsorship and air cover. Teams need access, latitude, and a tolerance for complexity.
- Human-in-the-loop by design. AI augments clinicians and staff; it does not replace them.
ChatEHR began as a pragmatic attempt to tame the overwhelm of the EHR. It now serves as something more: a test case for how a health system might bring AI out of the lab and into the ward, the clinic, and the emergency bay, without losing sight of the people on both sides of the screen. The team is quick to say they haven’t figured it all out, and there’s no guarantee their model will work everywhere, or even that it stays the right one for Stanford in five years.
But as patients keep arriving with hundreds of “novels” worth of data in their charts, the need for something like ChatEHR, and the organizational machinery that makes it real, is unlikely to fade. The question now is whether other health systems treat AI as a series of pilots, or as the beginning of a new kind of infrastructure.
If I could go back, I would have told myself to be less cautious. Ask for forgiveness, not permission more often. Be less risk averse. Be bold.”
- Duncan McElfresh
