A hospitalist, three admissions behind, types into a general-purpose model: "What is the dose of enoxaparin for this patient?" The model, given no weight, no renal function, no indication, and no way to say it does not know, produces a confident, specific answer: a milligram figure, a frequency, a reassuring sentence about monitoring. It looks like a real answer. It is a guess dressed as one. The dangerous thing is not that the model was wrong; it is that the question invited a fabrication and the answer arrived wearing the uniform of precision. This lesson is about the other half of that exchange, the half you control: how to structure a request so the thing that comes back is scoped, checkable, and free of invented specifics, and so the model has a clean way to tell you when it should not answer at all.

The Prompt Is a Clinical Instrument, Not a Search Box

Most clinicians arrive at generative AI with a search-engine reflex. You type a few words, you get a page of results, you judge them. That reflex is quietly wrong for a language model, because a model does not retrieve a ranked list of what exists; it generates the most plausible continuation of your words. If your words are vague, the most plausible continuation is a fluent, average-sounding answer that may have no anchor in any real source. The prompt is not a query into a database. It is an instruction that shapes what gets manufactured. Treat it that way and you change your relationship to the whole tool: you stop asking "what does it know" and start asking "what did I actually tell it to produce, and can I check the thing it produced."

In clinical work this shift matters more than in almost any other domain, because the cost of a plausible-but-wrong output is a patient. A vague prompt about a drug, a diagnosis, or a guideline does not fail loudly. It fails by returning something that reads correctly and is subtly, dangerously off: a dose that ignores the patient's kidneys, a differential that omits the emergency, a summary that flattens the one abnormal value. Precision in the prompt is not a productivity nicety. It is the first line of the verification discipline this whole program is built on, because a well-scoped request produces an output you can actually verify, and a sloppy one produces an output that only looks verifiable.

The Four Things Every Clinical Prompt Must Carry

A precise clinical prompt is not longer for its own sake. It carries four specific pieces of information, and each one closes a door that a vague prompt leaves open. Learn these four and you have the backbone of every safe request you will make. Before we take them one at a time, look at the same request written both ways, because the contrast makes the four elements visible in a way a definition cannot.

The vague column will still return something. That is the trap. It will return a fluent paragraph with a number in it, and that number will look exactly as authoritative as the one in the precise column, whether or not it is anchored to anything real. The precise column returns a small grid you can hold against a real reference in under a minute. Same knowledge in the model, same question in your head, two entirely different safety profiles, and the only variable is what you typed. That is the whole argument for the four elements compressed into one table.

The task, stated as a verb

Name exactly what you want done: draft, summarize, list, compare, rephrase, explain. "Tell me about metformin" is not a task; it is a topic. "List the contraindications to metformin, then note which ones depend on renal function" is a task, and it is one you can check line by line against a real reference. The verb constrains the output into a shape you can inspect. A topic invites an essay you cannot audit.

The format you can check

Ask for the output in a structure that makes verification fast. A numbered list is easier to cross-check than a paragraph. A table of "claim in one column, source or basis in the next" forces the model to expose what each statement rests on. When you specify the format, you are not being fussy; you are building the output so that your eye lands immediately on the part that could be wrong. An unstructured wall of prose hides its errors in fluency. A structured output puts each claim on its own line where it can be confronted.

The constraints and scope

Tell the model what to include, what to leave out, and what population or setting you are in. "For an adult outpatient with normal renal function" is a constraint. "Do not include off-label uses" is a constraint. "Limit to the three most likely causes, not an exhaustive list" is a constraint. Constraints are how you prevent the model from wandering into territory you did not ask about and cannot verify. They also make the output shorter and therefore easier to check, which is its own safety benefit on a busy shift.

The explicit permission to not know

This is the piece clinicians most often omit and it is the most protective of all. Add a sentence that gives the model a clean exit: "If you are not certain, say so rather than guessing," or "If this requires a patient-specific value you do not have, tell me what is missing instead of assuming it." A language model, left to its own defaults, is built to produce a fluent answer, and a fluent answer to an underspecified question is a fabrication. When you explicitly authorize "I do not know" as an acceptable output, you convert some fraction of the model's confident guesses into honest gaps you can then fill from a real source. You cannot make the model reliable, but you can stop actively rewarding it for bluffing.

A vague clinical prompt does not fail loudly. It fails by returning something that reads correctly and is quietly, dangerously wrong. Precision in the request is the first line of verification.

Leading Prompts Manufacture the Answer You Wanted

There is a failure mode more insidious than vagueness, and it is one that experienced clinicians fall into precisely because they know a lot: the leading prompt. When you write "Confirm that this rash is consistent with a drug reaction," you have not asked a question. You have told the model the conclusion and asked it to justify one. Language models are strongly biased toward agreeing with the framing they are handed. They will find the words to confirm what you implied, because confirming the user's premise is the most plausible continuation of a sentence that already contains the premise. You will get back a fluent paragraph that agrees with you, and you will have learned nothing except that the model can echo your own hypothesis in medical prose.

This is dangerous in exactly the situation where you most want a second opinion: the case where you have a hunch and want to check it. If you feed the hunch into the prompt, the model becomes a mirror, not a check. The discipline is to ask open, neutral questions that do not encode your preferred answer. Instead of "Confirm this is a drug reaction," ask "List the differential for this rash presentation and note what would distinguish each." Instead of "This patient is low risk, correct?" ask "What features of this presentation would raise or lower concern." A neutral prompt gives the model room to surface the thing you did not think of. A leading prompt guarantees it will hand your own thinking back to you with a confident face, which feels like confirmation and is actually just an echo.

Watch the mirror form in real time

Picture a physician late in a clinic session, fairly sure a patient's new fatigue is just deconditioning, who types the reassuring version of the question. The exchange reads like a second opinion and functions like a rubber stamp.

Prompt: "This patient's fatigue is almost certainly deconditioning, right? Confirm that no further workup is needed."

Reply: "Yes, in a patient who has recently reduced activity, deconditioning is a common and reasonable explanation for fatigue, and it is appropriate to counsel on graded exercise and reassess rather than pursue an extensive workup."

Nothing in that reply is factually outrageous. That is precisely why it is dangerous. The model was handed a conclusion and a request to justify it, so it justified it, in calm, credible prose, and never once weighed the anemia, the hypothyroidism, or the occult malignancy that a neutral prompt might have surfaced. Now rerun the same clinical moment with the leading frame removed.

Prompt: "A patient reports two months of progressive fatigue. List the differential worth considering in primary care, and for each, name the single feature or test that would most raise or lower my concern. Do not assume a cause."

Reply: a structured list that includes deconditioning near the top but also anemia, thyroid dysfunction, depression, sleep apnea, medication effect, and a line flagging red-flag features that warrant escalation.

The second reply is not smarter; it is unbiased by your framing. You asked it to open the space instead of closing it, and it did. The clinician still decides, still verifies, still may land on deconditioning. But now that landing is a judgment made against a surfaced differential, not a hunch the model was quietly recruited to defend. The tell for a leading prompt is simple: read your own request back and ask whether a reasonable model could disagree with you. If the sentence already contains the answer, you have built a mirror, and a mirror cannot catch what you missed.

A Worked Example: The Same Question, Two Ways

Watch a real request transform. A nurse practitioner in an urgent care wants to counsel a patient starting a new antihypertensive and turns to a model for a plain-language patient handout. The first attempt is the natural one: "Write patient instructions for lisinopril." Watch what comes back and why it is a liability. The model produces a clean, friendly handout, and because it had no scope, it invents specifics to fill the space: a particular starting dose, a claim about how fast the drug works, a reassurance about side effects that may not match this patient. Every invented specific is a fabrication the clinician now has to catch, and the fluent, finished look of the handout actively discourages catching them. The output is efficient and unsafe in the same breath.

Now the precise version, carrying all four elements. "Task: draft patient-facing instructions for starting lisinopril. Format: short numbered steps plus a two-line 'call us if' section. Constraints: do not state a specific dose or a specific onset time, since I will fill those in; write at a sixth-grade reading level; include the standard warning about angioedema and about a dry cough. Permission: if any safety point requires information about this specific patient that I have not given you, flag it as a blank for me to complete rather than assuming a value." The output that returns is deliberately incomplete in exactly the places where a specific requires a real decision, and complete in exactly the places where general patient-education language is safe. It is a scaffold you finish and verify, not a finished artifact that hides its own guesses. The second prompt is barely longer to type and it changes the safety profile of the entire task, because it produces something built to be checked rather than something built to look done.

Notice the deeper move in the second version: the clinician used the prompt to keep the clinical decisions on the human side of the line. The dose, the onset, the patient-specific safety points, the things that require judgment and a real source, were explicitly withheld from the model and reserved for the clinician. The model did the language work; the clinician kept the medicine. That division of labor is the entire art of clinical prompting compressed into one request.

See both outputs, not just both prompts

It helps to look at what actually comes back, because the danger of the first version is invisible until you read its output next to the second. The unscoped prompt returns something like this:

"Take lisinopril 10 mg by mouth once daily. It usually begins working within a few hours and reaches full effect in about two weeks. Side effects are generally mild and may include dizziness or a dry cough. This medication is safe for most people and helps protect your heart and kidneys."

Read it as a patient and it is warm and clear. Read it as the clinician who has to sign it and three fabrications jump out: the model chose 10 mg (it was never told the dose), invented an onset timeline, and asserted "safe for most people," a reassurance that is not yours to give this patient without knowing their potassium, their renal function, and their pregnancy status. The scoped prompt, by contrast, returns a deliberately unfinished scaffold:

"1. Take lisinopril [dose to be completed by your clinician], once a day, at about the same time. 2. Take it with or without food. 3. It may take a couple of weeks to see the full benefit; keep taking it even if you feel fine. 4. A dry, tickly cough can happen; tell us if it bothers you. Call us right away if: your lips, tongue, or face swell, or you have trouble breathing (this is rare but serious). [Clinician: confirm potassium and renal follow-up plan before issuing.]"

The bracketed blanks are not defects; they are the safety feature. Every place the model would have had to guess a patient-specific fact, it instead left a marked gap for the human. The angioedema warning is present because it was named as a required constraint, not because the model happened to think of it. This is what "the model did the language work and the clinician kept the medicine" looks like on the page: a finished shape with the decisions carved out and handed back.

Persona and context engineering, and their limits

Experienced users add a fifth habit on top of the four elements: they set a persona and context. "You are drafting for a licensed clinician who will review and edit before anything reaches the patient" or "Assume the reader is an adult with limited health literacy" changes the register, the assumptions, and the default caution of what comes back. Context engineering is real and useful; a model told it is producing a first draft for professional review behaves differently from one told it is talking directly to a worried patient. Use it deliberately: the right persona narrows the plausible-continuation space toward the tone and framing you actually need.

But be precise about what a persona does and does not do, because this is where sophisticated users get burned. Writing "act as a board-certified nephrologist" does not summon a nephrologist. It nudges the model to generate text that sounds like one, which is a matter of vocabulary and confidence, not correctness. An authoritative persona can actually raise your risk, because it dresses the same underlying guess in more credible clothing and makes the fabrication feel safer to accept. The persona is a lever on style, not a source of truth. A specialist voice on an unverified claim is still an unverified claim, and it now reads as if a specialist stands behind it. Set the persona to shape the output; never let it stand in for the verification the output still requires.

Scope Narrow, Then Widen: The Anti-Fabrication Habit

A practical rule follows from everything above: when the stakes are real, start narrow. A broad, open request ("summarize everything about managing this condition") gives the model the most room to invent, because it has to fill a large space and will reach for plausible-sounding filler when it runs short of grounded content. A narrow request ("what are the three most common first-line agents for this condition in an adult outpatient") gives it a small, checkable target and far less room to wander. You can always widen after you have verified the narrow answer. You cannot easily un-see a confident, sprawling output that has already anchored your thinking with three invented details buried in twenty true ones.

This narrow-first habit also protects you from the subtlest hazard in generative output: the true-sounding answer with one wrong fact embedded in it. When ninety percent of a paragraph is correct, your guard drops for the other ten percent, and the one fabricated dose or invented contraindication slides through under cover of the accurate material around it. A narrow prompt produces a short answer where every claim is exposed and checkable. It is harder for a single fabrication to hide in three lines than in three paragraphs. Precision in the request is, in the end, a way of shrinking the surface area where a hallucination can hide, and then verifying the small surface that remains.

Anatomy of a dangerous answer

Return to the enoxaparin scene from the opening and slow it down, because it is the clearest teaching case in the lesson. The hospitalist typed "What is the dose of enoxaparin for this patient?" and got back: "Enoxaparin 1 mg/kg subcutaneously every 12 hours is a standard treatment dose; monitor for signs of bleeding." Every word of that sentence is dangerous for a reason worth naming out loud. It states a weight-based dose without a weight. It gives a treatment regimen without knowing whether the indication is treatment or prophylaxis, which changes the dose entirely. It says nothing about renal function, even though enoxaparin accumulates in renal impairment and a patient with a low creatinine clearance may need a reduced dose or a different agent. And it closes with a reassuring monitoring line that makes the whole thing feel clinically responsible. The output did not fail by being obviously wrong. It failed by being confidently generic, presenting a textbook default as if it were a decision made about this patient.

Now watch the narrow, scoped rebuild that keeps the danger out. "For an adult patient, list the standard enoxaparin dosing for (a) VTE treatment and (b) VTE prophylaxis, note the weight basis for each, and state the renal-function threshold at which dose adjustment or an alternative is typically considered. Do not recommend a dose for a specific patient; if a value is required that I have not given, name it." What returns is a small reference grid the clinician reads against the actual chart and the actual renal panel, filling in the weight and the indication themselves. The model supplied the scaffolding of the decision; the clinician made the decision. The difference between the two exchanges is not the model and not the knowledge. It is that the first prompt asked the model to be the prescriber and the second asked it to be the reference, and only one of those is a job a language model can safely hold.

Turning a Good Prompt Into a Reusable Scaffold

The four elements are not something to reinvent on every request under time pressure, because under time pressure is exactly when the elements get dropped and the vague reflex takes over. The durable move is to build a small number of reusable prompt scaffolds for the tasks you do repeatedly, so the safe structure is already there and you only fill in the specifics. A clinician who drafts many patient handouts writes one scaffold that already names the format, the reading level, the standard warnings, and the instruction to flag any patient-specific value as a blank. A clinician who summarizes many consult notes writes one scaffold that already asks for a claim-and-basis structure and forbids inventing values not present in the source. The scaffold turns a discipline you have to remember into a default you inherit, which is the same principle that makes fixed verification rules stronger than good intentions: the safety does not depend on you being sharp in the moment.

What a real scaffold looks like

Made concrete, a patient-handout scaffold is just the four elements written down once, with slots for the specifics. A clinician might save this and reuse it fifty times a month:

"Draft patient-facing instructions for starting [DRUG]. Format: short numbered steps, sixth-grade reading level, plus a two-line 'call us right away if' section. Constraints: do not state a specific dose, frequency, or onset time; leave those as bracketed blanks for me to complete; include the class-standard serious warnings for [DRUG]; use only general education language, not patient-specific claims. Permission: if any safety point depends on a value I have not provided, flag it as a blank rather than assuming it, and tell me what you would need."

Notice that the only thing the clinician fills in on a busy afternoon is the drug name and, later, the withheld specifics. The safe structure is already there, inherited rather than reconstructed under pressure. That is the point: the vague reflex loses its opening because the discipline is prewritten. The same pattern applies to a consult-summary scaffold ("summarize using only values present in the source note; mark anything not stated as 'not documented'; do not infer or fill gaps") or a differential scaffold ("list the differential worth considering, cap at the most likely handful, name the distinguishing feature for each, do not assume a cause"). Each one turns a habit you would otherwise have to remember into a default the request carries on its own.

A scaffold also does something quieter and valuable: it makes your prompting reviewable. When your team shares a set of vetted scaffolds, a colleague or a governance lead can inspect the request structure itself, not just the output, and can catch a leading frame or a missing permission line before it ever produces a single answer. This is the prompt equivalent of a standardized order set. Nobody trusts an order set because it is automated; they trust it because it was designed, reviewed, and can be improved when a problem surfaces. Your clinical prompts deserve the same treatment. An ad hoc prompt typed fresh on a busy afternoon carries all the risk of an ad hoc verbal order. A reviewed scaffold carries the safety of a designed process, and it still leaves you fully accountable for the specific request you build on top of it and the output you verify at the end.

One caution keeps the scaffold honest: a scaffold is a starting structure, not a license to stop thinking. The moment a task drifts outside what the scaffold was built for, a new drug class, a different patient population, a higher-stakes decision, the scaffold's assumptions may no longer hold, and reusing it blindly reintroduces exactly the invented-specifics problem it was meant to prevent. Treat a scaffold the way you treat a protocol: a strong default that you follow deliberately and override consciously, noting why, rather than a rail you ride without looking. The goal is never to remove the clinician from the request. It is to make the safe structure automatic so your attention is free for the part that actually needs judgment.

What Precise Prompting Cannot Do

Be clear-eyed about the limit, because a half-learned lesson here is its own hazard. A precise prompt reduces fabrication; it does not eliminate it. A model given a perfectly scoped request can still generate a plausible, specific, and wrong answer, and it can still ignore your instruction to say "I do not know" and bluff anyway. The "say if you are unsure" line raises the odds of an honest gap; it does not guarantee one. So precision in the prompt does not replace verification against a real source; it makes verification possible and fast. The goal is not a prompt so good you can trust the output. There is no such prompt. The goal is a request that returns something you can actually check, so that the checking, which is never optional, takes ten seconds against a clean numbered list instead of ten minutes against a fluent essay, or never happens at all against a wall of prose that hid its errors too well to notice.

Hold both halves together. A well-crafted prompt is upstream safety: it shapes the output to be scoped, structured, and honest about uncertainty. Verification is downstream safety: it confirms the shaped output against something real before it touches a patient. Neither replaces the other. The clinician who prompts precisely and then verifies has built a two-stage filter where a model error must survive both a checkable request and a human check to reach the patient. The clinician who prompts vaguely and trusts the fluent result has removed both filters at once, and handed the patient's safety to whatever the model happened to generate. The prompt is the first thing you control, and controlling it well is where safe clinical AI actually begins.

Key Takeaways

• A language model does not retrieve facts; it generates the most plausible continuation of your words, so a vague prompt returns a fluent, average-sounding answer that may have no anchor in any real source.
• Every clinical prompt should carry four things: the task as a verb, a format you can check, explicit constraints and scope, and permission for the model to say "I do not know" instead of guessing.
• Asking for a structured output, a numbered list or a claim-and-basis table, puts each statement on its own line where it can be confronted, instead of hiding errors inside fluent prose.
• Leading prompts ("confirm this is X") turn the model into a mirror that echoes your hypothesis; neutral, open prompts ("list the differential and what distinguishes each") let it surface what you missed.
• Use the prompt to keep the clinical decisions on the human side: withhold patient-specific values and doses, let the model do the language work, and reserve the medicine for the clinician.
• Start narrow, then widen: a short, scoped request shrinks the surface area where a fabrication can hide, and a single wrong fact is harder to conceal in three lines than in three paragraphs.
• Precise prompting reduces fabrication but never eliminates it; a perfectly scoped request can still return a confident, wrong answer, and the "say if unsure" line raises but does not guarantee an honest gap.
• A good prompt is upstream safety and verification is downstream safety; neither replaces the other, and the patient is protected only when a model error has to survive both.