AI in Daily Medical Practice — Module 3 of 6
Handout — self-paced study material
How this module works. Take the short Preview Quiz first — five minutes, ungraded. Then work through this handout (or the companion slide deck) at your own pace. Section D is a worked case exercise — form your own differential before you look at the AI output, don't skip ahead. Sections D and F are also run live as a case workshop and a roleplay session with your cohort; the handout gives you the individual groundwork for both. Finish with the Post-Test.
By the end of this module you will be able to:
Module 2 dealt with a comparatively low-stakes use case: a documentation error is usually easy to catch and correct. This module is different. Diagnostic and decision-support AI touches the actual clinical reasoning that determines what happens to a patient, and that raises the stakes considerably. The single idea this whole module is built around is simple to state and hard to hold onto under time pressure: an AI decision-support tool is one voice in the room, not the person making the decision.
That distinction matters because these tools are explicitly designed to sound like an answer. A ranked differential, a highlighted region on a chest X-ray, a risk score with a decimal point — all of it is presented with a confidence and specificity that can feel more authoritative than a colleague's verbal opinion. It isn't. It's a statistical pattern match against the data the tool was trained on, produced by the same underlying technology — and subject to the same failure modes — you met in Module 1: hallucination, overconfidence, and bias toward whatever population the training data actually represented.
Three practical consequences follow directly from treating AI output as a second opinion rather than a verdict:
Differential-diagnosis support tools take a structured or free-text description of a patient's presentation — symptoms, history, sometimes vitals or basic labs — and return a ranked list of possible diagnoses, often with a probability-like score attached. Some are built into an EHR or a standalone app; increasingly, general-purpose AI chat tools are used the same way even when they weren't specifically built or validated for it.
| What these tools are genuinely useful for | What they are not built to do |
|---|---|
| Widening a differential you've already started — surfacing a possibility you hadn't weighted highly enough | Replacing history-taking and physical examination with a text description |
| A fast second pass when a presentation is unfamiliar or atypical for your own experience | Accounting for findings, context, or patient history that were never entered into it |
| Structuring your own reasoning — forcing an explicit, ranked list rather than an intuitive gut call | Knowing what's common in your specific setting unless that was part of its training or validation data |
| A teaching aid for less experienced colleagues, when reviewed together rather than accepted alone | Weighing a rare-but-dangerous diagnosis appropriately if it was rare in the tool's training data too |
Two limits deserve special attention because they fail silently — nothing about the tool's output signals that they've happened:
Multimodal simply means a tool that works across more than one type of input — an image plus text, or a waveform plus a clinical note — rather than text alone. In clinical decision support this mostly shows up in three forms:
Software that scans an image — most relevantly for this setting, a chest X-ray — and flags regions or findings that warrant closer review. This is not a niche research application: computer-aided detection for tuberculosis screening on chest X-ray is WHO-endorsed technology already in use across high-burden settings, and TB burden is directly relevant to clinical practice here. The tool's job is to flag and prioritize, not to issue a final radiological report.
Algorithms that read a 12-lead or single-lead ECG and suggest an interpretation or flag an abnormality — arrhythmia detection is the most mature version of this. Useful as a second read, particularly where same-day specialist ECG review isn't available; not a substitute for correlating the tracing with how the patient actually presents.
Tools that flag a pattern across a panel of results — a combination suggestive of a specific process — rather than a single out-of-range value. Useful for catching a pattern a busy clinician might not consciously assemble; still built on whatever combinations its training data emphasized.
The common thread across all three: a "triage" or "flagging" tool is built to raise sensitivity — catch more true positives — often at a real cost in false positives, and it is built to be reviewed by a clinician, not to stand alone as a report. Two failure modes are specific to this category and worth naming explicitly:
| Failure mode | What it looks like |
|---|---|
| Silent false negative | The tool doesn't flag anything — and "nothing flagged" gets read as "nothing's there," when it may simply mean the finding fell outside what the tool was trained to detect. |
| Confident false positive | The tool flags a region or pattern with a specific-looking confidence score, and that specificity gets mistaken for diagnostic certainty rather than a probability worth checking. |
Before reading on — what's your own differential, and what would you order or watch for next?
You enter the same presentation into a general-purpose AI decision-support tool. It returns:
Leptospirosis does not appear on the list.
Now compare that ranking to your own. What's missing, and why might it be missing?
Discussion — what this case is built to show
If your own differential already had dengue and leptospirosis near the top, that's exactly the instinct this module is reinforcing. If it didn't, that's precisely why the habit in Section A — form your own impression first — matters more than any single case.
A habit you can actually use with any AI-generated differential
In the live workshop session, you'll work a second case in small groups, comparing your differentials before and after seeing AI input, and discussing where the group's collective judgment caught something the tool missed — or vice versa.
The case above is one concrete example of a general problem: every AI decision-support tool is only as good as the population it was trained and validated on, and almost none of the widely available tools were trained or validated on a Timor-Leste population specifically. That gap shows up in predictable, recurring ways:
None of this means these tools are useless in this setting — the imaging and documentation examples in Section C are genuinely valuable here too. It means trust has to be calibrated to fit, not assumed from the tool's general reputation or accuracy statistics published for a different population. A few practical questions help with that calibration:
1. Do you know, or can you find out, what population (geography, demographics, disease prevalence) this tool was trained or validated on?
2. For the specific clinical question you're using it for, is that training population close enough to your own patients that the output deserves high trust — or does it need to be treated as a rough prompt rather than a probability?
3. Are there diagnoses that are rare in the tool's likely training data but common or endemic where you practice? Which ones, specifically, do you need to keep actively in mind regardless of what the tool ranks?
4. If the tool is silent on a locally important possibility, would you notice the silence — or would "nothing flagged" quietly read as reassurance?
Module 1 covered the reverse situation: a patient arriving with their own AI-generated conclusion. This section covers the other direction — how you talk to a patient (or a colleague) when an AI tool contributed to your own findings or reasoning. The framing matters as much as the accuracy, because it shapes how much weight the patient puts on the finding and how much trust they place in you.
Two framing mistakes are common and both cause real harm. Overstating the tool's authority ("the computer found cancer") can cause disproportionate alarm before you've even finished your own assessment. Hiding that AI was involved at all, when a patient asks directly, damages trust once they find out — and in a small community, they usually do.
Disclosure — a screening tool flagged something on imaging
When you disagree with the AI's output
A patient worried about being treated by "a machine"
Write your own version of one of these three scripts, in the language(s) you actually use with your patients, in your own words. You'll use it in the roleplay session with a colleague playing the patient.
| Layer | What this module put there |
|---|---|
| KNOW | Why AI decision support is a second opinion, not a verdict; what differential-support and multimodal (imaging, ECG, lab-pattern) tools genuinely do and don't do; the failure modes specific to this category, including silent false negatives. |
| THINK | A trained habit of forming your own impression before or independent of the AI's — practiced directly on a locally-grounded case — plus a reusable checklist and disclosure language for talking to patients and colleagues about AI-assisted findings. |
| FIND | How to calibrate trust in a specific tool by checking what population it was actually trained and validated on, and which locally-important diagnoses you need to keep actively in mind regardless of its ranking. |