Wu et al.: Rebuilding a Case Report Into a Chain of Decisions — Fukai Reads

TL;DR

A clinical case report — the staple teaching text of medical school — describes a patient's course from presentation to diagnosis to treatment, written flatly from a vantage point where the answer is already known. The reader is told the ending before they start. This paper proposes MedGame, a framework that mechanically rebuilds that static text into a branching story game in which the reader is forced to make decisions along the way.

It works in two stages. The first engine converts the case text into a three-level script of Acts, Scenes, and Decision Nodes; the second converts that script into a dependency graph of image, audio, and video generation tasks. The authors build a 5,000-case evaluation set, and fine-tuning open-source language models to this format lifts the rate of structurally valid output from 79.4% to 99.1%. Medical accuracy scores, however, barely move under fine-tuning.

Introduction

Today's paper is arXiv:2607.21570, "MedGame: Storytelling Gamification Empowered by Large Language Models for Medical Education." Eleven authors: Qian Wu, Xinrong Zhou, Zizhan Ma, Kai Chen, Zheyao Gao, Xun Lin, Hongqiu Wu, Longfei Gou, Yixiao Liu, Ann Sin Nga Lau, and Qi Dou. The lead affiliation is the Chinese University of Hong Kong (CUHK), joined by Southern Medical University, Peking University, and Tencent. Last author Qi Dou leads the med-air lab at CUHK.

Submitted 23 July 2026, filed primarily under cs.CL with a cross-listing to cs.HC. **It is an arXiv preprint and has not been through peer review.** The authors themselves note on the arXiv listing: "Work in Progress; an explorational design and study." It is a design proposal with early validation rather than a finished study, and being days old, it has not yet been widely discussed.

A word on why a puzzle site is reading a medical-education paper. I chose it not out of interest in medical curricula, but because **the problem it sets — mechanically converting a linear explanatory text into a structure with decision points along the way — has almost the same shape as designing a puzzle or adventure game.** Strip away the clinical context and the script format and evaluation metrics the authors built read directly as tooling for turning teaching material or documentation into something interactive.

Background: the gap between reading a case and solving one

The authors open by noting that existing attempts to use language models in medical education stay at the level of localized interactions: answering an individual question, giving feedback on a single dialogue turn, playing a simulated patient. All are one-shot or short exchanges; none assemble the **trajectory** by which a case moves from presentation to resolution. In their phrasing, existing work does not handle "a complete, decision-centered trajectory across an entire clinical encounter."

The case report as a document format contains that whole trajectory, yet the way it is read flattens it. As the paper puts it, case summaries encode rich diagnostic and therapeutic knowledge in a single coherent episode, yet are consumed as static text that presents the reasoning process only in retrospect. Active clinical reasoning unfolds sequentially: interpret partial information, decide what to ask or test next, update as evidence emerges. **This mismatch between static delivery and dynamic reasoning is the paper's starting point.**

Puzzle designers will find this familiar. A walkthrough written by someone who knows the answer is a different object from the experience of groping toward it — a point that recurs in tutorial design and in strategy writing. The authors frame it as a constrained structured generation problem: the output must be faithful to the source case, expose meaningful decision checkpoints, remain medically plausible, and stay machine-executable, all at once.

Approach: splitting screenwriter from director

MedGame's core design splits generation into two engines. The authors invoke the film industry's continuity script — a single document that bridges narrative intent and on-set execution. The Medical Narrative Designer plays screenwriter, turning the case text into a structured script; the Story Director plays director, turning that script into an execution plan. **The script itself is the handoff artifact between them**, and making that handoff an explicit data structure is, as I read it, the paper's central move.

The script has three levels. An Act organizes a macro-stage of the clinical pathway — the paper's example: "diagnostic workup for a patient with unexplained fatigue." A Scene localizes one clinical step and its state transition — "ordering laboratory tests after history taking and examination." A Decision Node is the learner-facing checkpoint — "selecting which laboratory tests should be ordered next." In the formalization, a state is "the accumulated clinical world state after a sequence of confirmed observations and decisions," and a decision node is a gate "that must be resolved before the clinical state can advance."

Crucially, the script is **defined as a Pydantic schema — a machine-checkable written-down shape for the data.** A generated script can therefore be rejected automatically for being malformed before any human judges its quality. The authors further constrain the model to pick characters and settings from a fixed pre-built list: six clinical locations and five medical staff roles. Three reasons are given: visual consistency; asset efficiency (pre-rendered backgrounds and character sprites remove the need for per-story image generation); and narrative coherence.

The Story Director then converts the script into a directed acyclic graph (a dependency diagram whose arrows only ever move forward). Nodes are units of image, audio, or video generation; edges record dependencies. The reason for making dependencies explicit is concrete: **if the same patient appears in Act 1 and Act 3, they must have the same face.** The paper shows a chain where character_gen creates the patient's canonical portrait in Act 1, Act 2 uses modification with that output as input image, and Act 3 inherits from Act 2's output. The authors call this identity propagation.

Findings: fine-tuning fixes form, not substance

MedGame Bench draws 5,000 cases from PMC-Patients (patient summaries derived from PubMed Central case reports), sampled evenly across eight specialties — cardiology, endocrinology, gastroenterology, hematology/oncology, nephrology, neurology, respiratory and critical care, rheumatology — at **625 cases each**, split 4,000 train / 1,000 test. Reference scripts were generated by Gemini-3-Pro, and the authors state explicitly that these references "are not treated as direct evidence of clinical correctness."

The 5,000 generated scripts contain **35,452 decision nodes** in total: single_choice 15,027 (42.4%), interactive 13,249 (37.4%), batch 7,176 (20.2%) — respectively for clinical decision assessment, information gathering through patient interviews, and multi-selection scenarios like ordering several tests. The orchestration side totals 119,886 tasks: fusion 102,260 (85.3%), modification 12,602 (10.5%), character_gen 5,024 (4.2%).

On structural validity the commercial models dominate. Per Table 2, Strict validation is 100.0% for Gemini-3-Pro and 99.5% for Claude-Sonnet-4.5, against 79.4% for Qwen3-32B and below 60% for Gemma-3-27B and MedGemma-27B. On the orchestration task (Table 3) the gap widens: open-source models reach 56.50–80.30% sample-wise validation while the commercial models exceed 99%.

Fine-tuning almost erases that structural gap. Qwen3-32B goes from 79.4% to 99.1% Strict validation, and its Character & Scene Usage score jumps from 5.41 to 8.50. Fine-tuned Qwen3.5-27B reaches 99.5% Strict and slightly edges out Claude-Sonnet-4.5 on the sum of content-oriented indicators (59.83 vs. 59.08). **Medical accuracy, by contrast, stays stubbornly put.** The paper notes that "even the best-performing Gemini-3-Pro achieving scores around 7.0," and the conclusion concedes medical accuracy "remains a bottleneck." Full expert revision lifts Gemini's medical accuracy / educational quality from 6.40 / 6.45 to 8.07 / 7.95 — that gap is filled by humans.

The learner-side evidence is small: **eight senior medical students** rated the same **five cases** under three conditions (original case text, text-only MedGame, multimodal MedGame) on 1–5 Likert items. Overall perception was 4.19 multimodal, 3.79 text-only, 3.19 original, with the multimodal-over-text advantage significant under a one-sided paired Wilcoxon signed-rank test on student-level means (p = 0.0039). The authors state plainly that "these results do not establish downstream learning gains," and report **a mild cognitive-load trade-off** from the multimodal rendering.

Where this is usable, if you build games

One. **Use it as a template for converting tutorials or explanatory articles into something with decision nodes.** If you build puzzle games and write rule documentation or solution write-ups, the three-level structure transfers directly: Acts are the large concepts you want taught, Scenes the steps within them, Decision Nodes the moments where the reader must choose. What the paper shows is that separating these into a schema lets you **reject malformed output automatically, independently of whether the content is any good.** Throwing away 40 of 100 generated drafts before a human reads them is a real operational win.

Two. **Guarantee asset consistency at planning time rather than after generation.** If you generate backgrounds or NPC art for hyper-casual PCG (Procedural Content Generation — automatic content creation), the Story Director's dependency graph is directly borrowable. Bake the rule "make one canonical image first, then only ever produce variants via modification taking it as input" into the plan, and you prevent the same character becoming a different person in act three structurally, before anyone compares outputs. That is what I take the authors to mean by calling identity propagation "the most critical dependency type."

Three. **The use of a closed, finite element list as a constraint.** The paper permits a startlingly small fixed set — six locations, five roles. The asset-efficiency rationale they give is exactly the indie developer's constraint: let a generative model invent freely and you need new art every time; make the choices finite and pre-generated assets are reusable. **Lowering generative freedom improves both quality and operating cost** — a trade-off puzzle designers will recognize. If I were building a Sokoban-like, I would generate only the layout and fix the tile vocabulary up front.

Four, more cautiously. **Keep the reported cognitive-load trade-off in mind when deciding how much presentation to add.** With eight students it cannot be treated as a general law, but the direction — engagement and presence up while the cognitive-load item alone worsened once audio and video were added — is worth remembering. It is at least consistent with the workshop intuition that making a puzzle flashier can make it harder to follow.

Limitations

The authors concede two points in their Limitations section. First, the work **does not measure long-term pedagogical outcomes**; assessing knowledge retention, clinical reasoning improvement, or skill transfer would require controlled studies with rigorous institutional oversight, and is left to future work. Evaluation is confined to generation quality and perceived experience. Second, the image, audio, and video modules are **treated as external tools, and their performance's effect on the framework is not systematically studied**. The focus is squarely on the language-model side.

What I would point out here is, first, the implication of **the judge being a language model.** All content-oriented indicators are scored 1–10 by GPT-5.2 as LLM-as-a-Judge. The authors do check human agreement: strong for narrative generation (avg. r = 0.81), only moderate for story direction (avg. r = 0.61). And the human side is three medical PhDs on 50 narrative cases and two game developers on 50 direction cases. I would discount the story-direction scores accordingly.

Second: **Gemini-3-Pro writes the reference scripts, open-source models are fine-tuned to imitate them, and GPT-5.2 does the grading.** The authors are careful to say the references are not evidence of clinical correctness, but "how close to what Gemini would write" and "how much better as teaching material" are still not cleanly separated. That fine-tuning moved the structural metrics dramatically while barely moving medical accuracy reads as a natural consequence of that setup — and Table 16, where only full expert revision raises the content scores, can be organized as the same fact seen from the other side.

On the student study, the authors themselves call it a pilot and flag the small sample. Eight students and five cases is a single small-sample observation with no replication. The accurate reading is not "learners prefer multimodal" but "these eight rated it this way, on these five cases, under these conditions."

Fukai reads it this way

This is my own reading. I would place this paper in the current that **reuses "game-ness" as a structural language rather than as entertainment decoration.** The line "gamification is not merely an entertainment layer; it serves as a structural interface" is, to me, the whole study. What the authors did was not add story to make something fun; it was **to extract, into machine-tractable form, a chain of states, choices, and consequences that was already hidden inside the prose.** In the vocabulary of design criticism this is less "turning reading into experience" than "excavating the decision tree buried in a text." And whether the excavation succeeds turns out to depend not on clever generation but on the strictness of the schema — the fact that structural metrics rose to 99% under fine-tuning while content scores stayed flat draws, unintentionally but cleanly, the line between what in this work can be automated and what cannot.

Closing

The paper's related work also reaches into general-domain narrative generation. StoryVerse (Wang et al., 2024) and CoDi (Wang et al., 2025) are cited specifically as hierarchical planning frameworks that address the tension between narrative freedom and coherence via Director-Actor architectures; MedGame's dual-engine design sits in that lineage. If you want automated narrative for games, reading those two first makes it clearer what MedGame specialized for medicine.

Code and platform are released at github.com/med-air/MedGame (work in progress). The stack is React + TypeScript on the front end and FastAPI on the back; story trees, character videos, dialogue audio, and scene images are all pre-generated and served as static files, so there is no runtime generation overhead. That "pre-generate everything and ship it" shape is itself worth borrowing when thinking about delivering a daily puzzle.

Once more, to be clear: this is a preprint that has not been peer reviewed, and the authors label it work in progress. That the medical accuracy scores stall around 7 and rise only under expert revision is, I think, the most important number they honestly left on the page.

References

Papers and resources referenced in this article:

・MedGame: Storytelling Gamification Empowered by Large Language Models for Medical Education (Qian Wu, Xinrong Zhou, Zizhan Ma, Kai Chen, Zheyao Gao, Xun Lin, Hongqiu Wu, Longfei Gou, Yixiao Liu, Ann Sin Nga Lau, Qi Dou, 2026, arXiv preprint arXiv:2607.21570)

・DOI: 10.48550/arXiv.2607.21570 (arXiv-issued DOI, not a peer-reviewed venue DOI)

・Released implementation (med-air/MedGame, work in progress)

・Dataset: PMC-Patients (Zhao et al., 2023), the source of MedGame Bench's case summaries

・Related: StoryVerse: Towards Co-authoring Dynamic Plot with LLM-based Character Simulation via Narrative Planning (Wang et al., 2024), hierarchical Director-Actor narrative planning