The Business Architecture Behind Physician-Centered AI

The default pitch in healthcare AI is still replacement. Models will read the inbox. Models will write the note. Models will, eventually, see the patient. Clinics keep buying the demo and then refuse to let the software talk to anyone unsupervised.

What does make it into clinical use is usually narrow. Kaushal Kulkarni is an ophthalmologist and health-technology co-founder. In a June 2026 MedCity News piece, he argued that the first wave of scaled enterprise AI should stay focused. Those targets include ambient documentation, inbox triage and message routing, chart summarization, and prior-authorization support. All of it built into workflows that already exist.

Those tools share one property. A human still owns the final action, and the tool lives inside a workflow the clinician already has open. It is less a product category than a design rule. Companies that take it seriously end up building an approval system, not a chatbot.

Abhinav Kejriwal's company is built on that rule. He is a co-founder of PreventiveHealth.ai, a startup whose core system is a physician-specific digital twin: software trained on how one doctor actually writes and decides. When a patient asks a question, the twin produces a first reply in that physician's voice. The physician revises it, approves it, or rejects it. Nothing goes out until a human approves it.

That sequence is the company. Kejriwal argues it is also the only architecture outpatient practices will adopt at serious scale.

"Clinicians hit hard limits on time and attention," he says. "Software with no licensed physician in the loop can sound polished and still be wrong. That is not something a practice should put in front of patients."

He adds that the combination is the point: "Nothing reaches the patient until a physician signs off. Final clinical authority stays with the doctor."

An Engineer's Starting Point

Kejriwal approaches the problem from systems, not medicine. He studied computer science at Berkeley. A summer at Adobe went into anomaly detection and a data pipeline. That is the kind of unglamorous plumbing a clinical drafting tool depends on. It depends on that far more than any demo does.

He does not practice medicine, and the company is organized around that fact. The clinical work sits with specialists whose careers are in menopause care, nutrition, genomics, and functional medicine. Engineers own the software. His co-founder, Nickhil Jakatdar, is a multi-time founder whose earlier companies were in video and semiconductors. The architecture reflects that division of labor. Clinicians define what a good answer looks like. The software's job is to produce it faster without taking the decision away.

Physician-Specific Learning, Not a Generic Chatbot

Kejriwal's case for DrKai does not rest on a bigger model. It rests on how the system is grounded in one clinician's voice, how it improves from that clinician's corrections, and how its drafts never leave the practice without a licensed signature.

"It lives in the browser, which sounds unglamorous until you remember where doctors actually work: the inbox, the portal, the EHR, Gmail," he says.

"A clinician can highlight a patient's question, get a draft in their own tone, and paste it back into the thread they were already in. The tool is built to work inside existing systems rather than to replace them, and to keep patient data inside a physician-controlled channel."

A customer describes the same design from the other side of the screen. Forum Health, a functional-medicine network, has used the company's tools since October 2025. In a statement supplied through the company, Dr. Shilpa Saxena, Chief Medical Officer of Forum Health, put it this way: "The avatar drafts each reply in the provider's own voice and clinical approach, and DrKai lets us bring it into whatever we're already working in, whether that's email, messaging or the patient record."

Grounding a model in one physician has a consequence beyond tone. Kejriwal points to the company's menopause community, where women write in about hot flashes, night sweats, and the rest of the perimenopausal list. Clinicians used to spend a long time on each answer, and each answer was only as good as what that clinician held in working memory that afternoon: "With the twin, the draft is faster, and it includes patterns from how that same clinician has handled similar questions before," he says.

In one case, he recalls, a clinician had not thought to order an additional test alongside bioidentical hormone therapy until the draft raised it. He says: "That is the intended shape of the tool: the model surfaces, the expert decides. Neither works as well alone."

It is a single anecdote, supplied by the company, but it shows the intended design. In this telling, the software's value is not that it knows more than the physician. It recalls what the physician already knows when the question arrives, then steps back.

The Feedback Loop

The learning is deliberate. Every edit becomes a training signal for that physician's twin, not for a generic assistant. Kejriwal says: "The system is supposed to learn from the edits. Over time, the draft should sound less like a model and more like that specific person. The clinician retains final judgment. The aim is a faster workflow, reduced cognitive load, and more clinical time."

The design choice matters. Each twin stays narrow. It sounds like one doctor, not all of them. That is the line a cautious medical director wants drawn. The design also turns the physician from a user into the system's teacher. The intended result is a doctor who stops composing from a blank page and starts supervising a first draft that already knows how they talk.

The same loop carries the architecture's main risk. A system that learns from corrections can only learn from corrections that are actually made. If a physician starts approving drafts without reading them, the model receives the same signal it would get from a perfect draft. The loop improves the product only as long as the review stays real.

Liability, Safety, and the Approval Layer

Kejriwal is direct about why the approval step comes first: "The architecture matters more than the model underneath it. A general chatbot that answers patients is easy to ship and hard to defend. Liability is unclear. Hallucinations are a clinical event."

Who answers for an automated sentence that turns out to be wrong is still unsettled across much of healthcare, and a product that cannot answer that question is hard for a practice to buy. The company's answer is built into the workflow. The twin proposes. The physician disposes. Drafts remain drafts until a licensed clinician approves them, which keeps accountability with the person who already carries it.

Saxena presents that step as a benefit rather than a hedge: "As an added safety benefit, nothing reaches a patient until the provider has reviewed and approved it," she says.

A rule is only as strict as the review behind it, though, and that is where Kejriwal himself locates the risk.

He is blunt about where that design can fail: "A burnt-out physician who waves through every draft is not real oversight. A demo that looks clever and dies in a clinic is still the industry's default failure mode. If you want this software inside a real practice, you have to build the approval step first and the model second."

The admission matters, because it points to the least proven part of the system. An approval step is a safety mechanism only if you use it as one. Whether review habits hold up over months of heavy message volume is a question for the practices using the tool, and it is where any serious evaluation of the product should begin.

Business Adoption Logic

The business case follows from the same architecture. A practice will not adopt software that adds friction to a clinic day that is already running behind. It will not adopt software that creates an unclear liability trail.

And it will not adopt software that asks a medical director to surrender the final say to a model. Workflow integration, the human approval layer, and physician-specific learning are not product flourishes. They are the adoption logic.

"If the last word moves to the model, the sale dies in the medical director's office," Kejriwal says. "If the last word stays with the doctor, the software can sit in the workflow without triggering the liability and trust concerns that have stalled so much of this category."

"Physicians use the system to handle patient questions with less strain and without giving up the final say," he adds. "The twin drafts; the doctor approves. That is the core service."

That framing also explains who the buyer is. The physician uses the tool, but the medical director and the practice's leadership decide whether it stays, weighing risk and productivity together. An architecture that keeps the signature where it already sits lets them approve a new tool without rewriting who is responsible for what.

He frames the product as a business system rather than a research result, partly as a matter of discipline: "Software is cheap to stand up now. It is easy to build the product you imagined and discover that nobody asked for it." In his view, clinics do not buy intelligence; they buy a way to be present in more conversations without giving up control.

That is also why the company does not sell the twin in isolation. Describing one partner, a multi-clinic functional-medicine group, Kejriwal says: "What they adopted is a bundle, not a single widget: the physician twin, the acquisition work, the dashboard, and the adjacent consumer programs."

The architectural bet is that an approval-first drafting tool earns the trust that lets the rest of the relationship happen. The fuller bundle is his description; the clinic statement quoted earlier speaks only to the drafting tools. Kejriwal does not claim the pattern is proven: "Whether other groups copy the whole stack is a later question."

The limits should stay in view. The company is early. A twin is only as good as the physician it is trained on, and only as safe as the review habit it depends on. Those are constraints the design acknowledges rather than solves.

Kejriwal's shorthand for the company is "It is in the trust business more than the chatbot business." The architecture described here turns that sentence into software. A model drafts. A physician decides. A feedback loop works only if the second step actually happens.

The next wave of healthcare AI will be tested at scale. Message volume will rise. So will the temptation to skip review. Whether that step survives is the real question.

About the Author

Sandra Kelembeth is an experienced content writer known for her strong attention to detail and clarity in communication. She specializes in crafting engaging, well-structured, and informative content across various topics. Her writing focuses on breaking down complex ideas into simple, easy-to-understand language, making information accessible to a wide audience. With a reader-first approach, she aims to educate, inform, and empower individuals to make better, more informed decisions through clear and impactful storytelling.