From MediTutor to Patientic: Why a Patient Cannot Be a Disposable Chat Session

A patient cannot be a disposable chat session if the next encounter is supposed to depend on the last one. MediTutor showed that a synthetic encounter can be practiced, transcribed, and scored. It also showed the limit of that shape: when the session ends, the consequential history ends with it. Patientic is the design response. It is being built as a persistent patient world, not as a longer chat and not as a system that diagnoses or treats anyone.

What MediTutor is

MediTutor is a shipped virtual-patient product for healthcare learners. A learner meets a synthetic patient by voice or text, works through a structured encounter, and receives formative feedback. Korea is the first live commercial market. The product has been used by external learners, used more than once, and offered as early paid practice. The current Korean product includes a case library, sessions, transcripts, formative scoring, accounts, and payments.

That is a formative simulation product. It is not a clinical record system, and it does not autonomously diagnose, prescribe, treat, or replace professional judgment. A session can be useful for practice and still be the wrong object to carry a patient's history.

The early operating snapshot, as of 31 August 2026, was more than 300 users and more than 1,000 completed simulation sessions. Those figures are a rounded aggregate of early commercial use. They are not product-market fit. They are not clinical validation, not a measure of medical efficacy, and not evidence of how the product would perform in real care. They say that people finished synthetic encounters. They do not say that those encounters improved care, predicted an outcome, or proved a training claim.

What repeated practice helped the team notice

Repeated synthetic sessions, and formative feedback grounded in those session transcripts, informed the design direction behind Patientic. They did not train a foundation model, and they were not a study of how clinicians or real patients behave. Any use of transcripts for training or evaluation is subject to applicable consent, data rights, de-identification, and governance controls.

What the sessions made concrete was a product limit. A learner can ask questions, skip a question, explain a plan, and receive a score for that encounter. The score can point at what the rubric says was covered or missed. When the session is the whole patient, none of that has a later life. The next time someone opens a case, the world does not have to remember the omission, the explanation, or a change in trust. The team could see the encounter. It could not see the encounter's consequence, because the product kept case context inside the session.

That is a design observation, not a finding about real clinics. The interesting part was the shape of the tool. Session-level feedback is honest about one conversation. It is silent about the next one.

Why a resettable session loses history

A resettable session is a clean room. That cleanliness is part of why it is easy to run. Each learner can start from the same vignette. The transcript is a closed document. The rubric can be applied to that document. Nothing in the room has to survive until tomorrow.

Care, even in a simulation of care, is not a clean room. An earlier question can be the reason a fact was disclosed. An omitted question can be the reason it stayed hidden. An explanation can be the thing a later moment depends on. If the session is thrown away, those dependencies are thrown away with it. The next session can mention "last time" only if someone pastes a summary back in, and a paste is not a history. It is a new prompt that may already have edited the past.

Most virtual-patient tools reproduce one scenario and then reset. MediTutor's current patient model is case context within an individual session, with session-level formative scoring. That is a real product, and it is also the boundary the next system has to cross. Cross-encounter state, governed transitions, and evidence versions are the design being built. They are not a description of what the session product already stores.

synthetic interaction
  voice or text encounter
  session transcript
  formative feedback for that encounter
        |
        v
observed product limitation
  case context ends when the session ends
  a later encounter does not inherit the omission,
  the explanation, or the state change
        |
        v
persistent patient runtime
  state, clock, disclosure boundary
  committed history
  replayable branches

Read the diagram from top to bottom. The interaction is worth keeping. The limitation is that the interaction is the whole record. The runtime is the layer that makes a later encounter read stored state instead of starting from a fresh paste.

The Patientic design response

Patientic is being built so the patient is the durable object and the session is only a visit. State, time, hidden facts, and an append-only history stay after the window closes. A committed action is an event. A fork keeps the shared past and then diverges. Replay reads the events that were stored. The model may propose. It does not get to overwrite the world by speaking.

That split is the point of What Is a Persistent Virtual Patient?. A transcript remains valuable. It is evidence of what was said. It is not the authority for what the world now holds. Feedback can cite the transcript and the state change together, which is a different artifact from a score that exists only inside one session. Branches, commits, and replay are how a later encounter keeps the shared past.

None of this requires claiming that the longitudinal runtime is already the shipped MediTutor product. The session product is the evidence that synthetic encounters can be run and reviewed. The persistent runtime is the response to what those encounters could not carry.

The boundary that does not move

Synthetic, educational, or otherwise permitted scenarios are the material. The early MediTutor use was formative simulation for learners, not care. Patientic stays inside the same kind of boundary while it is being built. A branch is a simulated future under a specified setup. It is not a prediction about a real person, and it is not a recommendation a clinician should follow. The longer form of that limit is Synthetic Patient Simulation: What It Is—and What It Is Not.

The thousand sessions are allowed to count as use. They are not allowed to count as proof. What they support is a narrower sentence: a disposable session can teach a team that history has to live somewhere else.

Related reading

• What Branching Clinical Simulation Actually Means
• Why Every AI Patient Run Needs a Simulation Receipt