Stanford Medicine deploys diagnostic agents.

The Stanford AI Lab handoff: how research becomes deployment

The Stanford Artificial Intelligence in Medicine and Imaging centre — AIMI — has operated since 2018 as the formal bridge between the university's computer science faculty and the clinical enterprise. Under its founding director, Dr. Curtis Langford, AIMI developed a translation pipeline for model work: research outputs move from laboratory validation to clinical simulation to a staged deployment environment before any capability touches a live patient encounter. The pipeline predates the current agent programme by five years. When Venkataraman's office began scoping the diagnostic agent initiative in early 2023, AIMI's infrastructure was already in place.

The critical output of the AIMI handoff is not a model. It is an eval package. Each capability arriving from the research side carries a standardised documentation set: training data provenance, out-of-distribution performance on the Stanford patient population, failure mode taxonomy, and a written escalation logic specification that the clinical informatics team uses as the basis for the governance permission tier assignment. Venkataraman's office reviews the eval package; the Clinical AI Standards Committee — a standing body that includes representation from bioethics, legal, nursing informatics, and four clinical departments — approves the tier designation. A capability does not receive a tier designation until both sign off. The process takes between six and fourteen weeks depending on specialty complexity.

The result is a deployment cadence that is slower than vendor-led programmes and more defensible on the back end. Stanford's first live capability — a differential diagnosis advisory agent for the emergency department, built on a model developed in collaboration with the Ng Lab and integrated through a framework partnership with Nuance Communications — cleared the committee in November 2023 and went live in the Stanford Hospital emergency department on 28 January 2024. That date is not ceremonial. It is the date recorded in the capability's Clinical AI Register entry, which functions as the audit anchor for every subsequent monitoring report.

Radiology, pathology, and the ED: the three initial verticals

Stanford's initial deployment scope covers three clinical verticals selected by Venkataraman's team on the basis of existing measurement infrastructure, specialty willingness, and regulatory profile. Radiology leads the deployment in volume of capability types: four distinct agent functions went live across the radiology department between January and April 2024, covering structured report prefill for chest CT, incidental finding flagging for abdominal MRI, pulmonary nodule risk stratification advisory output, and a notification routing agent that surfaces time-sensitive findings to ordering clinicians without requiring radiologist manual contact. The radiology deployment runs primarily through Nuance's DAX Copilot platform, extended with AIMI-developed model components in the pulmonary nodule stratification layer.

Pathology represents Stanford's most distinctive deployment choice. No other academic medical centre in the United States has moved an agent capability into the surgical pathology sign-out workflow at the institutional scale Stanford has attempted. The capability — developed in partnership with Paige AI, the computational pathology company backed by Microsoft — provides a structured pre-annotation layer for whole-slide images in prostate and colorectal cases. Pathologists review the pre-annotation before dictating; the agent's output is visible in the workflow but explicitly not included in the patient record unless the pathologist actively incorporates its language. The governance architecture is precise on this point: the agent contributes to cognition, not documentation. The distinction matters legally, and Venkataraman's team built it into the Clinical AI Register entry as a capability-level constraint rather than a general policy.

The emergency department capability — the differential diagnosis advisory agent — is the programme's most closely watched deployment, both inside the institution and in the broader clinical informatics community. The agent receives a structured input derived from the triage note, vital signs, chief complaint, and the first set of ordered labs, and returns a ranked differential with associated evidence citations drawn from UpToDate and the AIMI-curated clinical knowledge base. It does not generate orders. It does not produce a plan. It produces a ranked list and a reasoning trace, both visible to the attending and the resident but not documented in the chart. Forty-three per cent of attending physicians in the first 90 days of deployment reported reviewing the differential before completing their own assessment. The informatics team treats this as a workflow adoption signal, not a quality metric.

Stanford's governance model: the Clinical AI Standards Committee and the Register

Stanford's governance approach is constructed around two instruments that function in tandem: the Clinical AI Standards Committee and the Clinical AI Register. The Committee is the approval authority. The Register is the institutional memory. Together they operationalise a principle that Venkataraman articulates without hedging: every clinical AI capability deployed at Stanford Medicine must be individually approved, individually logged, and individually monitored — no blanket platform approvals, no inherited permission tiers from a parent vendor's FDA clearance, no assumed continuity from one capability version to the next.

The Committee meets monthly for standard reviews and can convene an emergency session within 72 hours if a monitoring signal requires expedited review. Its standing membership includes Venkataraman's office, the department chief medical information officers for radiology, pathology, emergency medicine, and oncology, a clinical ethicist from the Center for Biomedical Ethics, a nurse informaticist from the nursing shared governance structure, and Stanford's Chief Privacy and Compliance Officer. Two external advisors — both clinical informatics faculty from peer institutions, rotating annually — sit in on a non-voting basis. The external advisor structure is a deliberate transparency mechanism: it creates an institutional record that the programme has been reviewed by qualified outside parties, which compresses the due diligence burden in regulatory correspondence.

The Clinical AI Register assigns each deployed capability one of four permission tiers. Tier 0 covers summarisation and documentation assistance with no clinical content generation. Tier 1 covers advisory outputs — differentials, risk scores, flagging — where clinician acknowledgment is required before any action. Tier 2 covers workflow automation with defined rule sets, where the agent acts without individual clinician acknowledgment on each instance but within a pre-approved protocol. No Tier 3 capability — defined as agent-initiated action with clinical consequence — has been approved. Venkataraman's public position is that Tier 3 will not be considered before Q3 2025, and only after the Committee has completed a liability architecture review with outside counsel. The position is consistent. It is also, practically speaking, the same position every large academic medical centre with active legal exposure has taken.

Vendor partners and the co-development distinction

Stanford's vendor relationships sit in three categories that the programme distinguishes carefully. Co-development partners — currently Nuance Communications for the ambient documentation and ED advisory layers, and Paige AI for computational pathology — have access to de-identified Stanford patient data under a data use agreement that specifies model improvement rights, publication rights, and a first-look clause on AIMI-initiated capability proposals. These relationships are bidirectional: Stanford contributes data and clinical validation; the vendors contribute model infrastructure, regulatory track record, and integration engineering. The co-development agreements were structured by Stanford's Office of Technology Licensing, not by Venkataraman's office, and the distinction matters: technology licensing manages IP; clinical informatics manages deployment. The two functions report independently to the Dean of Research.

Integration partners occupy a second category. Epic Systems — which runs Stanford's EHR — functions as the integration substrate rather than an AI development partner. The Epic CognitoClinical AI framework is the primary API surface through which AIMI-developed and co-development-partner outputs surface in the clinician workflow. Stanford's informatics engineering team, a group of fourteen engineers reporting to the Associate CMIO for Clinical Systems, manages the Epic integration layer and owns the mapping between the AIMI capability outputs and the Epic presentation templates. A third vendor category — evaluation partners — includes two firms Stanford does not discuss publicly by name in press materials, but which are identifiable in the AIMI publication record: Aetion, the real-world evidence analytics platform, for post-deployment outcome monitoring, and Leuko Medical, the AI diagnostics company, for a prospective pilot in haematology that remains in the pre-production evaluation phase.

The vendor landscape reflects a deliberate architectural philosophy: no single commercial platform controls the capability layer. Stanford's CMIO office made this choice explicitly in the vendor selection process, rejecting a proposal from one major ambient intelligence platform — unnamed in the institutional record — that would have consolidated documentation, advisory, and workflow automation capabilities under a single contract. Venkataraman's stated rationale is competition and accountability. An institution with one vendor has leverage only at renewal. An institution with three co-development partners and two integration relationships has leverage continuously, because switching costs are distributed across the stack rather than concentrated at a single integration point.

Stanford versus Mayo and Cleveland Clinic: three approaches, one sector

The comparison between Stanford, Mayo Clinic, and Cleveland Clinic is instructive precisely because the three institutions have converged on similar governance instincts while diverging sharply on implementation architecture. Mayo built the Clinical AI Reliability Standard — CARS — as a centralised, prescriptive framework with fixed performance thresholds applied uniformly across its 340-hospital network. Cleveland developed the Adaptive Clinical Intelligence Standard — ACIS — as a ceiling-floor model that gives local medical informatics leads calibration authority within enterprise-set limits. Stanford's Clinical AI Register model is neither: it is capability-level individualism, where each deployed function has its own permission tier, its own monitoring schedule, and its own Committee-approved escalation logic. No two capabilities share a generic permission profile.

On evaluation methodology, the three institutions reflect different epistemological priorities. Mayo's CARS framework runs a subtraction battery — removing single input variables to test graceful degradation — and requires 87 per cent agreement on primary recommendation and 94 per cent on escalation trigger before a capability advances. Cleveland's adversarial concordance testing constructs synthetic case variants and measures whether the agent's output shifts in the direction a subspecialist would predict. Stanford's AIMI eval packages use a different approach: counterfactual simulation across the Stanford patient population with demographic stratification, testing not just accuracy but equity — whether the capability's performance holds across age, sex, race, and insurance status. The equity dimension is explicit in the AIMI methodology documentation and was a Committee requirement from the programme's first governance session. Neither Mayo nor Cleveland has published a comparably granular equity testing protocol at the programme level.

The academic-clinical handoff is Stanford's structural differentiator. Mayo and Cleveland source primarily from commercial vendors with FDA clearance records and negotiate governance terms into procurement contracts. Stanford co-develops with its own research infrastructure, which means the institution controls the evaluation methodology, the equity testing protocol, and the publication rights — and bears the additional liability of having produced the model rather than merely deployed it. Venkataraman's office has been explicit that this trade-off was made consciously. The upside is a tighter feedback loop between clinical performance data and model improvement. The downside is that Stanford's legal exposure, if a co-developed capability produces a consequential error, sits differently than an institution's exposure to a vendor's FDA-cleared product. That exposure question has not been tested in court. It will be.

What to watch

Stanford's programme is eight months into its first live deployments and approaching its first full annual monitoring cycle. The governance architecture is holding. The clinical adoption numbers in radiology and the ED are within the range the informatics team projected. The questions that will determine whether this programme becomes the reference model for academic medical centre clinical AI — or a cautionary note about the liability exposure of co-development — arrive in the next two quarters.

• Whether the Paige AI computational pathology capability in surgical sign-out generates the first Committee-triggered capability review: the pre-annotation layer is the most cognitively proximate deployment in the programme, and the governance constraint — agent contributes to cognition, not documentation — depends on clinician discipline that has never been stress-tested at production volume across a full academic calendar.
• Whether AIMI's equity testing protocol produces a public disparity finding; if the demographic stratification data surfaces a performance gap on any deployed capability, Stanford will face a disclosure decision that no other health system has yet navigated in real time — publish the finding and model transparent governance, or remediate quietly and avoid the reputational exposure that publication creates.
• Whether Venkataraman's office files Pre-Submission correspondence with the FDA's Digital Health Center of Excellence on the differential diagnosis advisory agent before the end of 2024; Mayo's proactive regulatory engagement has given it a governance credibility advantage with federal health agencies, and Stanford's programme — despite its research pedigree — has not yet built the same correspondence record.
• Whether the co-development model's liability architecture survives legal scrutiny as Tier 2 capabilities move toward approval; the Office of Technology Licensing's IP separation from Venkataraman's deployment authority is structurally clean but legally untested, and outside counsel's Q3 2025 liability review will be the first formal stress test of whether the architecture holds under the assumption of a consequential clinical error.
• Whether Stanford publishes the AIMI eval package methodology — including the equity testing protocol and the counterfactual simulation framework — as a standalone clinical informatics publication; if it does, it creates a public standard that peer institutions can adopt, cite, and compare against, which would give Stanford the same outside-world credibility that Mayo's CARS framework has accrued through FDA correspondence and that Cleveland's adversarial concordance methodology is beginning to build through conference presentation.

Frequently asked

What is the AIMI handoff, and why does it matter for deployment quality?

AIMI — the Stanford Artificial Intelligence in Medicine and Imaging centre — functions as the translation layer between the university's AI research output and the clinical enterprise. Every capability arriving from the research side carries a standardised eval package: training data provenance, out-of-distribution performance data specific to the Stanford patient population, a failure mode taxonomy, and a written escalation logic specification. The Clinical AI Standards Committee uses this package as the primary input for permission tier assignment. The eval package is not a vendor deliverable — it is produced by AIMI before any commercial partner enters the governance process. This gives Stanford's deployment approvals a level of internal methodological accountability that vendor-led programmes at peer institutions do not have by default.

How does Stanford's four-tier permission model work in practice?

Each deployed capability is assigned to one of four tiers by the Clinical AI Standards Committee and recorded in the Clinical AI Register. Tier 0 covers documentation assistance and summarisation with no clinical content generation. Tier 1 covers advisory outputs — differentials, risk scores, flagging — requiring clinician acknowledgment before any downstream action. Tier 2 covers protocol-defined workflow automation where the agent acts within a pre-approved rule set without per-instance acknowledgment. Tier 3 — agent-initiated action with clinical consequence — has not been approved and is not under active consideration before Q3 2025. Tier assignments are capability-specific: a single vendor can have capabilities across multiple tiers, and a capability cannot inherit a tier designation from a related deployment.

What distinguishes Stanford's evaluation approach from Mayo's CARS framework?

Mayo's CARS framework applies fixed institution-wide performance thresholds — 87 per cent agreement on primary recommendation, 94 per cent on escalation trigger — and stress-tests capabilities through a subtraction battery that removes individual input variables to measure degradation. Stanford's AIMI eval packages use counterfactual simulation with demographic stratification, testing performance across age, sex, race, and insurance status as a formal equity requirement. The Stanford approach does not set fixed numeric thresholds at the programme level; threshold adequacy is a Committee determination made on a capability-by-capability basis. This creates more deliberation per capability and less institutional consistency across the portfolio — the trade-off that the programme's first annual monitoring cycle will begin to quantify.

Why did Stanford choose pathology as a deployment vertical, when most peer institutions have avoided it?

The choice reflects the Paige AI co-development relationship and Stanford's existing computational pathology research investment through AIMI. Surgical pathology sign-out carries a distinctive governance characteristic: the output is a document, not a real-time clinical action, which creates a review window between the agent's pre-annotation and the pathologist's final dictation. The Committee's governance constraint — agent contributes to cognition, not documentation — is architecturally possible in pathology in a way that it is not in acute settings where the clinical action follows the recommendation immediately. The pathology deployment is also the programme's highest-profile co-development asset: if Paige AI's pre-annotation layer performs across Stanford's case volume, it becomes a reference dataset for the computational pathology field.

What is the liability exposure from co-developing rather than deploying vendor-cleared products?

When a health system deploys an FDA-cleared device from a commercial vendor, the primary liability for model performance sits with the device manufacturer under the applicable clearance. When a health system co-develops a capability — contributing data, validation methodology, and clinical integration — the liability distribution is more complex. Stanford's Office of Technology Licensing structured the co-development agreements to distinguish IP rights from clinical deployment responsibility, but this separation has not been tested in litigation. Venkataraman's office has scheduled a formal liability architecture review with outside counsel for Q3 2025, prior to any Tier 3 capability consideration. The review's conclusion will determine how aggressively the programme can expand its co-development model into higher-acuity settings.