DAX Does Not Understand Clinical Hierarchy
DAX does not understand clinical hierarchy.
Clinical hierarchy is how clinicians naturally organize and prioritize clinical information — distinguishing between the chief complaint that brought the patient in, the symptoms they're experiencing, the working diagnosis, the differential considerations, and conditions that have been ruled out. Each category carries different clinical weight and requires different documentation treatment.
DAX doesn't make these distinctions. And that single fact explains most of the frustrating behavior clinicians encounter when building custom prompts: duplicate A&P sections, inflated problem lists, differential items treated as confirmed diagnoses, and notes that require more editing than they save.
Understanding why this happens changes how you approach prompt design entirely.
How DAX Actually Thinks
If you run DAX's "summarize my note" function, you can see its internal logic directly. It outputs clinical information under a flat heading like:
Medical Diagnoses: - Esophageal dysmotility - Esophageal obstruction - Achalasia - Aspiration pneumonitis - Dehydration
Five items. No hierarchy. No indication that the first three are all related to the same underlying problem. No distinction between a confirmed diagnosis, a differential consideration, and a secondary finding.
This is how DAX sees every encounter: as a list of labels.
When your prompt says "create an A&P for each problem," DAX takes this list literally. Five labels become five sections — each with its own assessment and plan — even when they should be grouped under a single complaint.
If you try to explain clinical hierarchy to DAX within your prompt, it often gets more confused, not less. Adding rules like "combine related diagnoses" or "don't duplicate similar conditions" creates inconsistent behavior.
The fix isn't better explanation. It's different structure.
What Clinicians Understand That DAX Doesn't
When you see a patient, your mind automatically categorizes clinical information:
- —Chief complaint — why the patient is here
- —Symptoms — what they're experiencing
- —Working diagnosis — your leading explanation
- —Differential diagnoses — alternatives you're considering
- —Ruled-out conditions — things you've excluded
- —Historical diagnoses — relevant past medical history
- —Incidental findings — present but not driving today's visit
These categories exist in relationship to each other. A chief complaint anchors the encounter. A differential diagnosis is a possibility being considered, not a conclusion. A ruled-out condition shouldn't appear in your active problem list.
DAX flattens all of this into a single list of "medical diagnoses" with no relational structure.
To DAX, chest pain (symptom), anxiety (contributing factor), ACS (ruled out), costochondritis (working diagnosis), and GERD (historical) are all equivalent items requiring equal documentation weight.
How Flat Architecture Creates Downstream Failures
When your prompt receives this flat list and includes an instruction like "Repeat for each problem," the model does exactly what you asked. Five items become five A&P sections — each with its own assessment, plan, and disposition.
This creates several problems:
1.Plan duplication — The same interventions appear under multiple "problems." Discharge instructions repeat. Follow-up appointments multiply.
2.False diagnostic precision — Items that were differential considerations now appear as confirmed diagnoses with their own treatment plans. "ACS" gets an A&P section even though it was ruled out.
3.Inflated problem lists — Symptoms get promoted to diagnoses. A patient with chest pain, dyspnea, and anxiety doesn't have three separate problems — they have one complaint with associated symptoms and a differential.
4.Documentation that misrepresents clinical thinking — The note suggests you diagnosed and treated conditions you actually excluded. This creates confusion for downstream providers and potential billing or liability concerns.
5.Editing burden — You now spend time deleting duplicate sections, merging plans, and correcting the diagnostic framing — defeating the purpose of AI-assisted documentation.
The Core Principle: Structure Over Rules
Many clinicians try to fix this with additional instructions: "Don't repeat the plan." "Combine similar diagnoses." "Only include confirmed diagnoses."
These rarely work consistently.
LLMs obey structure more than rules.
If your architecture creates a numbered section for each item DAX provides, the model will populate those sections — regardless of instructions telling it not to. The structure is the instruction.
This is why prompt engineering for clinical documentation is fundamentally an architecture problem, not a wording problem.
The Structural Solution: Complaint-Based Architecture
The fix isn't better rules. It's different structure.
Instead of organizing by diagnosis or problem, organize by primary complaint or system:
"Repeat this section for each primary complaint or system involved, not for each differential diagnosis or symptom mentioned."
Then build a Differential Diagnosis section directly into your A&P template. This gives the model a designated place to capture medical complexity:
[Complaint or System] Assessment: Differential Diagnosis: Plan:
This architecture forces the model to:
- —Group related items under one section
- —Place differential diagnoses in their own subsection (not as separate problems)
- —Keep ruled-out conditions in the clinical reasoning
- —Generate one plan per complaint, not per label
The result matches how clinicians actually think: Patient, Complaint, Assessment, Differential, Plan, Disposition.
Not: Patient, Label 1, Plan, Label 2, Plan, Label 3, Plan.
Why This Matters Beyond Duplication
Complaint-based architecture does more than prevent duplicate sections. It preserves something important: clinical uncertainty.
Diagnosis-based prompts force premature categorization. Every item DAX provides becomes a confirmed problem. Uncertainty disappears from the note.
Complaint-based prompts allow the documentation to reflect reality:
"Dysphagia — Assessment: progressive difficulty swallowing. Differential: achalasia most likely, esophageal dysmotility, mechanical obstruction less likely. Plan: GI consult, workup pending."
Instead of:
"1. Achalasia — plan... 2. Esophageal dysmotility — plan... 3. Obstruction — plan..."
The first reflects clinical reasoning. The second suggests three separate diagnoses were confirmed and treated. This isn't just documentation cleanliness. It's accuracy.
Applying This to Any Ambient Documentation Tool
This principle isn't DAX-specific. Any ambient transcription or AI documentation tool that outputs clinical items as a flat list will create the same problem if your prompt architecture treats each item as a separate section.
Whether you're using DAX, Abridge, Suki, or another tool — the structural principle holds: Your prompt must impose the clinical hierarchy that the tool doesn't provide.
The Practical Takeaway
If your DAX prompts are producing duplicate sections, inflated problem lists, or differential items treated as diagnoses — don't start by tweaking wording. Start by auditing your architecture.
Look for: - "Repeat for each problem" - "Create an A&P for each diagnosis" - Any structure that multiplies sections based on the number of items DAX provides
Replace with: - "Repeat for each primary complaint or system" - Add a Differential Diagnosis section within your A&P template - One plan per complaint
This single architectural decision — complaint-based instead of diagnosis-based — has been the most consistent fix across dozens of test cases.
Closing Thought
DAX is a transcription and summarization tool. It captures clinical content. It does not understand clinical reasoning.
That's not a flaw — it's a design reality.
Your prompt is where clinical hierarchy gets restored. If you don't build that structure explicitly, it won't exist in your output.
The clinicians getting the cleanest, most usable DAX notes aren't using better prompts. They're using better architecture.