Synthetic Patient Simulation: What It Is—and What It Is Not

Synthetic patient simulation, as Patientic is being built, is a governed world for synthetic, educational, or otherwise permitted scenarios. It is a place to keep state, move time, branch, and inspect what an actor did. It is not a system for diagnosing anyone, recommending treatment, or standing in for professional medical judgment. The boundary is the product decision. Everything else in the design is meant to stay inside it.

That sentence is easy to put in a footer and then ignore in the writing. This essay is the longer form of it. It says what the initial scope includes, what it refuses, why identifiable real-patient data is out by default, and why any later use would need its own validation gate rather than a quiet expansion of this one. No study is cited here, because none is being claimed. The boundary is a design commitment, not a result.

What it is

A synthetic patient is an authored world. Someone specifies the situation, the facts the world holds, the facts an actor may see, and the rules for how commits move time. The patient persists. Sessions come and go. Agents propose actions through a permissioned surface, and the world records what was accepted. Branches keep more than one future without merging them into a single official story. A receipt can name the seeds and versions so a run can be repeated.

The legitimate material for that world, at the start, is narrow on purpose. It includes scenarios written as fiction, material made for education, and other sources that are permitted for this use. "Permitted" is doing real work in that sentence. It means the right to use the material for simulation was actually obtained, not that the material was interesting and therefore fine. A vignette written for teaching can be a scenario. A file copied out of a care setting because it would make a vivid demo cannot.

Within that scope, the system is for exploration and evaluation of behavior inside the simulation. A person can ask what a fork does under the stated rules. A builder can watch whether an agent gathered a disclosed fact before committing. A reviewer can replay the events. Those are uses of a model of a situation. They are not uses of a patient.

The persistent object that makes those uses possible is described in What Is a Persistent Virtual Patient?. Persistence does not widen the boundary. A durable fictional patient is still fictional. Durability makes the fiction inspectable. It does not make it a record of care.

What it is not

It is not a diagnostic system. Nothing in the design produces a diagnosis, and nothing in the writing around it should report one as if it had. If a model, inside a scenario, utters a label for the fictional situation, that utterance is an event in the simulation. It is not a finding about a person.

It is not a treatment planner. Commits in a branch are moves inside a scenario: what the actor did next under the rules, and how the simulated state responded. They are not orders, recommendations, or optimizations of care. A comparison between two branches says how those branches differed in the simulation. It does not say which one a clinician ought to prefer for someone who is actually ill.

It is not a prediction engine. Controlled uncertainty, seeds, and replay exist so a specified run can be repeated and compared. They do not estimate what will happen outside the scenario. A branch that "turns out" one way has turned out that way because the scenario and the commits said so. Treating that ending as a forecast is a change of subject, and the product is not making that change.

It is not a place to process identifiable real-patient data by default. The default world does not contain a real person's record, and the path into the product is not an upload of one. De-identification is not a switch you flip after the fact to bless a file that started as someone's chart. If a source is identifiable, it is outside the initial boundary even when the story would be more convincing with it included. Convincing is not the criterion. Permission and design scope are.

Patientic currently uses synthetic, educational, or otherwise permitted scenarios. It is not intended to diagnose, treat, or replace professional medical judgment.

That is the operational wording. It applies to the essays in this set, and it applies to the product surface they describe. A page that shows a branch, a receipt, or an agent trace is still inside the sentence. The presence of clinical-looking detail in a scenario does not create an exception.

Why the default is refusal

Refusal by default keeps the slide from "synthetic" to "based on a real case" from happening as configuration. There is no mode, in the initial design, whose job is to accept a real chart and return a recommendation. There is no evaluation score whose job is to declare an agent clinically effective. There is no branch view whose job is to tell a reader what would have saved a patient, because the system does not have patients in that sense. It has scenarios.

The same refusal keeps the engineering honest. State, permissions, forks, and receipts are worth building because they make a simulation inspectable. They are not worth building as a costume for a chatbot that gives advice. If the only thing a reviewer can audit is the advice, the machinery was theater. The machinery earns its place by making the boundary checkable: what was disclosed, what was committed, which versions ran, and which claims the run does not support.

Separate gates for later uses

Some later uses might be legitimate and still be out of scope now. A research collaboration with its own approvals. An educational deployment with material licensed for it. A validation effort that studies simulation fidelity against a question defined in advance. Each of those would be a new gate: a stated purpose, a stated data rule, a stated claim, and evidence matched to that claim. None of them is accomplished by reusing this essay's vocabulary and hoping the boundary stretched.

The gate has to be separate because the evidence does not transfer. A replayable synthetic branch shows that the branch is replayable. It does not show that the scenario matches a population, that an agent's commits are safe, or that a metric inside the sim predicts anything outside it. Using the replay as if it were that evidence is the error the receipt is supposed to make harder. The receipt says what was run. It does not say the run was sufficient for a new purpose. Sufficiency is the new gate's problem, and it has to be argued there, not borrowed from the fact that the software exists.

Until such a gate exists and is actually satisfied, the public description stays where it is. People can explore a patient world. Agents can be evaluated inside it on the path they took, as discussed in How to Evaluate AI Agents in a Patient World. Builders can read what is being constructed, including the limits, without being asked to pretend the limits are temporary fine print.

How to read the rest of the work

Read the other essays in this set as descriptions of a system design, not as reports of a finished clinical capability. Persistent state, environments, branching, receipts, and evaluation are the design. They are described in the present tense where the idea is stable, and as "being built" where the product is concerned, because a clear design is not the same thing as a claim that every part is already shipped.

The practical check is short. Can you name the scenario as synthetic, educational, or otherwise permitted? Can you point at the commit instead of a recommendation? Can you open the receipt? Can you say, in one sentence, that this is not diagnosis, treatment, or a replacement for professional judgment? If a page fails that check, it is outside the initial product, regardless of how carefully it is designed. The place those checks are meant to hold is Patientic.

Related reading

• What Is a Persistent Virtual Patient?
• How to Evaluate AI Agents in a Patient World