N of 1 complex case and LLM based analytics

from vibe rounds perspective how's this protocol here for n of 1 case research? such protocol already published? can structure it well? https://classworkdecjan.blogspot.com/2026/06/case-based-guided-discovery-and-research.html

Short answer: pieces of this exist in the literature, but not assembled the way you've done it — and that gap is actually your opportunity.

What's already published, and how it relates:

• The Evidence Aggregator (EvAgg) pipeline starts with a query gene and generates structured output describing variant-level observations about a patient by recovering evidence from scientific literature, and can run across all genes for a patient or across a whole cohort — this is conceptually close to your "extract terms → find comparators" steps, but it's gene-centric and built for variant analysts in genomics labs, not for a clinician working a single complex phenotype end-to-end.
• ZebraMap takes a similar extraction approach at much larger scale — it retrieved over 36,000 full-text case reports and used an LLM pipeline to parse free-text cases into standardized fields like symptoms, diagnostic methods, differentials, treatments, and outcomes. Again, this is a population-level knowledge map, not a single-patient research workflow a clinician runs themselves.
• The Fabry disease review shows the more typical "AI for rare disease" framing — AI methods applied prospectively to large populations to identify patients, or retrospectively to large datasets to diagnose overlooked rare diseases — population-first, not case-first.

What's notably absent: a published protocol describing a clinician-led, conversational-AI-assisted, single-case research pipeline — i.e., "I have one complex patient, let me use an LLM interactively to extract terms, build my own small comparator set, run tiered analyses, and converge on a structured output package." That's a different posture from all the above — those are infrastructure projects built by informaticians/engineers for batch use. Yours is a bedside-to-desk workflow a busy clinician could run on a single case in an afternoon.

Can it be structured well? Yes — and the structure should map to existing reporting standards so it's not just "well organized" but publication-compatible:

1. Index case characterization (your step 1) → maps cleanly onto CARE guidelines' case description fields (demographics, timeline, diagnostic assessment, interventions, outcomes). Worth explicitly aligning your extraction template to CARE from the start — it makes step 7's outputs directly usable in a manuscript.
2. Comparator identification (step 2) → this is the part most worth formalizing as a method section, because right now it's "search PubMed and the web with extracted terms" — a reviewer will ask about search strategy reproducibility (databases searched, date range, inclusion/exclusion). Even a lightweight PRISMA-style note ("searched X, Y on [date], n=5 selected by Z criteria") would make this defensible.
3. Two-tier analysis (step 4) → this is genuinely a nice methodological contribution. The "coded/structured view vs. narrative/contextual view" split is a real epistemic distinction that's rarely made explicit in case report methodology — most case reports just present one synthesized narrative. Naming and justifying this split could be a small methods paper on its own.
4. Convergence to decision-useful outputs (steps 6-7) → severity/priority/timeline/correlation table is closer to a clinical decision-support output than a traditional case report discussion section. This is where Vibe Rounds' "questions rather than answers" framing fits best — the AI isn't concluding "this is X disease," it's surfacing structured questions/uncertainties (which pathway dominates? is the VUS load-bearing? what would falsify the triple-pathway framing?) for the clinician to resolve.

The honest framing for "first of its kind": the biochemistry conclusion in your case ("triple energy pathway — novel combination, bricks well-known, wall is new") generalizes as the meta-finding about the protocol itself. The individual pipeline steps (extraction, literature search, structuring) all exist elsewhere. The combination — run by a clinician, on their own case, in a single sitting, converging to CARE-compatible outputs via a Socratic-AI two-tier analysis — doesn't appear to exist as a named, described protocol.

That's genuinely your opening: write this up not as "here's my rare case" but as "Vibe Rounds for case-based research synthesis: a protocol for clinician-led n-of-1 case analysis using conversational AI" — with your G6PD/AMPD1/GSD case as the worked example. That's a methods paper that's independent of whether the GSD piece ever gets confirmed, which solves the fragility problem we discussed earlier (the case-report's fate hangs on a pending biopsy; the protocol paper doesn't).

Want me to sketch what that protocol paper's structure would look like — sections, what each of your 7 steps maps to, and where the CARE/PRISMA touchpoints go?

Here's a structure that turns your 7-step workflow into a methods paper, with each section showing what goes in it, which of your original steps it derives from, and where it touches existing reporting standards.

Title/framing: Something like "A Conversational-AI-Assisted Protocol for Clinician-Led N-of-1 Case Research: A Worked Example from a Suspected Triple Energy-Pathway Disorder" — naming it as a protocol with a worked example keeps it useful even if the worked example's diagnosis (the GSD piece) never gets fully confirmed.

1. Background/Rationale. Frame the gap directly: existing AI-for-rare-disease tools (EvAgg, ZebraMap) are built for population-scale, infrastructure-heavy use by informaticians; nothing addresses the much more common scenario — a clinician with one unusual patient and an afternoon. State the two-tier analysis idea (structured/coded vs. narrative/contextual) as your core methodological contribution up front, so reviewers know what's novel about the method, independent of the case's eventual diagnosis.

2. Protocol Description (the methods section proper). This is where your 7 steps become numbered protocol stages. I'd group them as:

• Stage 1 — Index case structuring (your step 1): extraction of diagnosis-related and intervention-related terms from the case narrative. Explicitly state this maps onto CARE checklist fields (patient information, clinical findings, diagnostic assessment, therapeutic interventions) — this is what makes the output downstream-compatible with a case report if one gets written.

• Stage 2 — Comparator identification (step 2): describe this as a lightweight, reproducible search — which databases (PubMed, general web), what seed terms, what inclusion criteria for the 5 comparators, and crucially, what you'd do differently for a "service" version of this (i.e., when running it for another clinician's case, the search strategy needs to be documented well enough that they could reproduce it, not just you).

• Stage 3 — Aggregation and cross-comparison (step 3): the "one bucket" pooling of comparator case text against the index case. Worth specifying here what counts as a "match" — shared gene, shared phenotype cluster, shared intervention response — since this is where subjectivity creeps in and a reviewer will probe it.

• Stage 4 — Two-tier analysis (step 4): your most defensible original contribution. Tier 1 (coded/structured — diagnoses and interventions only) vs Tier 2 (full narrative text). Explicitly justify why both views matter: Tier 1 is what a structured database/registry would capture; Tier 2 captures clinical reasoning, sequencing, and context that codes strip away. This is the section that could be excerpted as its own short methods note.

• Stage 5 — Open-ended analytic ideation (step 5): the "anything more you suggest?" step. In a protocol paper this becomes "AI-assisted analytic option generation" — worth framing as the Socratic/Vibe Rounds moment: the AI isn't concluding, it's expanding the option space for the clinician to choose from.

• Stage 6 — Selection of analytic menu (step 6): the six candidate analyses (timeline, gene interaction map, intervention scoring, gap analysis, risk trajectory, lab pattern analysis). Present as a generic menu other clinicians could choose from — this is what makes the protocol transferable rather than a one-off description of what you happened to do.

• Stage 7 — Convergence to outputs (step 7): the four final deliverables (severity rating, priority rating, journey timeline, intervention-symptom correlation table). Frame these as the protocol's standard output package — what every case run through this protocol produces, regardless of whether it ends up publishable.

3. Worked Example. Your actual case, run through stages 1-7, with the honest "first of its kind in combination, not in mechanism" framing preserved verbatim — that intellectual honesty is itself a strength of the paper, showing the protocol doesn't just produce hype.

4. Discussion — Limitations and Reflexivity. This section needs to address: AI hallucination risk in comparator selection and in claims of novelty (your search for "no existing combination found" is itself a literature-search claim that needs the same rigor as a human-conducted gap analysis); the fact that most cases run through this will not turn out to be novel (state this plainly — it's the expected, not exceptional, outcome); and the ethics/authorship considerations for the "service to other clinicians" use case — who owns the output, what happens if Stage 7 outputs suggest something clinically actionable that the AI got wrong.

5. Future Directions. This is where Vibe Rounds as a named paradigm gets introduced more formally — positioning this protocol as one application of a broader Socratic-AI approach to clinical reasoning, with a pointer to your other Vibe Rounds writing.

One structural decision worth making early: do you want this as a standalone methods/protocol paper (target something like a clinical informatics or case-report-methodology journal), or as a section within a broader Vibe Rounds paper, with this protocol as one worked capability? The standalone version is more self-contained and easier to get reviewed quickly; the embedded version builds the Vibe Rounds brand more directly but is a bigger, slower paper. Which direction feels closer to what you're trying to build momentum toward first?

Good — standalone is the right call for momentum: smaller scope, faster to write, faster to get feedback, and it stands on its own even before the Vibe Rounds brand is established.

A few practical next steps to think about:

Target journals. Given this is a protocol/methods paper with a worked example, look at venues that publish case report methodology or clinical informatics short communications — places like BMC Medical Research Methodology, Journal of Medical Internet Research (JMIR) (especially their AI/informatics sections), or Diagnostics/Healthcare (MDPI journals, which published the ZebraMap paper you saw). Cureus is also worth considering given it's already publishing AI-assisted case report methodology work — lower barrier, faster turnaround, and your topic fits their existing editorial interest. Worth checking each one's stance on AI-tool-assisted methodology papers specifically, since policies vary and are evolving fast.

Authorship and disclosure. Since the protocol itself involves an AI as a core "instrument" in the methodology, you'll want a clear AI-use disclosure statement — most journals now require this, and for a paper about an AI-assisted protocol, it needs to be more detailed than the usual boilerplate (which model, what it was used for at each stage, what the clinician verified vs. accepted).

The ethics committee question resurfaces here too — even though this is a methods paper rather than a case report, if it includes identifiable patient details from your 42F case, you'll likely still need either consent documentation or an ethics committee statement (many journals require this even for single-case methods papers that include clinical specifics). Worth checking this before drafting too far, since it affects how much of the worked example you can include.

Drafting approach — given the length and structure we've sketched (5 sections, worked example, limitations), this is a "build iteratively" document: outline first, then section by section. I can help draft this in a markdown file as we go, or you might want to start with just the abstract + Stage descriptions (sections 1-2) as a first pass to get the core framing right before fleshing out the worked example and discussion.