flowchart LR
accTitle: Two ways to use the same model
accDescr: Flowchart with two boxes. Left, Chatbot, your prompt leads to the model writing text, then to you copying what you want. Right, Coding agent, your goal leads to plan a step, then act by writing a file or running code, then observe the result, which loops back to plan a step or ends by showing you what it built.
subgraph C["Chatbot"]
direction TB
p1[Your prompt] --> t1[Model writes text]
t1 --> u1[You copy what you want]
end
subgraph A["Coding agent"]
direction TB
p2[Your goal] --> plan[Plan a step]
plan --> act[Act: write a file, run code]
act --> obs[Observe the result]
obs --> plan
obs --> done[Show you what it built]
end
8 Agentic coding: build a clinical tool in an hour, then find what is wrong with it
About 85 minutes
TipIn short
- The idea. A chatbot can now build a working clinical calculator from a plain request in about ten minutes. The arithmetic is usually right. The skill that matters is checking the rest: its rules, its edge cases, and which version of the score it uses, against the original paper and MDCalc.
- What you do. Build a calculator for a score from your specialty, then run three made-up patients through it, MDCalc, and the paper.
- What you keep. Your tool, and a table of three checked cases with the one change you would make before anyone else used it.
- Short on time? Do Parts A and B of the Do first (about an hour). Then read “Three ways the tool you just built can be wrong”.
NoteWhat you’ll learn
By the end of this chapter you will be able to:
- Say what a coding agent does that a chatbot does not, and why that changes who is responsible for checking the result.
- Build a working single-page clinical calculator from a plain-language prompt, in a browser, with no install.
- Check your tool against the original publication and MDCalc on three made-up cases, including an edge case, and say where it agrees and where it does not.
- Explain why your tool is a study aid, and name what would have to change before anyone relied on it.
Course competencies: AIM-5 (clinical use), AIM-2 (critical appraisal), AIM-4 (ethics, law, and regulation).
What you need. Your university ChatGPT Edu or Copilot account, and one tab open on MDCalc, the free calculator website most residents use. Nothing to install. Made-up patients only. The Do takes about an hour; the video is optional.
Build first if you like. The Do works without the reading. Go to Part A of the Do, build your tool, then come back and read while you check it.
8.2 Why this matters
You will see a tool like the resident’s within the year. They are cheap to make, and every team has someone who makes them. More and more, they are built by describing what you want to a model and accepting what comes back. That part now works: in a three-hour workshop, all three groups of medical students built a working health app by prompting (Quispe et al., 2026). The person who built it is usually proud of it. The attending is usually pleased. Nobody has been asked to check it, because checking a colleague’s tool is not a job anyone is assigned.
In intern year you will be the intern with the bookmark, or the intern who built it. Either way the skill you need is the same. Take a tool that seems to work, decide what it would take to trust it, and go and look.
8.3 How it works
8.3.1 A chatbot answers; an agent acts
Everything you have used so far in this course is a chatbot. You type, it writes, you copy what you want out of the reply. A coding agent is the same kind of model wrapped in a loop. It plans a step. It takes an action in the world: writes a file, runs a program, reads the output. It looks at what happened, and plans the next step. The actions are real. Files change, code runs. Because the actions are real, agents run with permissions, a list of what they are allowed to touch. Figure 8.1 shows the two shapes.
The tools you will use today are somewhere between the two. Your chatbot opens a side panel, writes a web page into it, and shows you the running page. That is the smallest possible version of the loop: the model wrote a file and the browser ran it. You are the one watching the result. The full agents work inside a folder of files on your own computer. They are mentioned at the end of the chapter and are not used here on purpose. They need an install and a terminal, and neither is the point.
The point is what changes when the output is something that runs. A wrong sentence in a chatbot reply sits there until you read it. A wrong rule in a calculator does its work silently, on every patient, until somebody compares its answer to another source. The error comes from the same place as in the critical appraisal chapter: the model writes plausible text, here plausible code, unless it is given a source to check against. But now the error sits inside a tool that runs on every patient, where nobody reads it.
A useful way to think of the model is as a capable but junior colleague. It is fast, fluent, and willing, and it needs clear instructions and review. Review its work the way a senior reviews a junior’s. Do not trust the confident tone; check the parts that would hurt someone if wrong.
8.3.2 Three ways the tool you just built can be wrong
A generated calculator can fail in three ways, and each can happen on its own. Each has a matching check in the Do block.
| Failure | What it looks like | How you catch it |
|---|---|---|
| The rule | A point value, cutoff, or coefficient is wrong, or a rule that comes with the score is missing (the dialysis rule; the sodium limits; whether a score is only applied above a threshold) | Compare every rule to the original publication, not to your memory of it |
| The edge | The tool does something the builder never imagined, for inputs the builder never tried: nothing checked, two boxes checked that cannot both be true, a value outside the range the score was built on | Try the inputs the builder did not: empty, contradictory, extreme |
| The version | The score has more than one published form, and the tool does not say which one it uses (Wells’ criteria exist in a three-tier and a two-tier form; the transplant system replaced MELD-Na with MELD 3.0 in 2023) | Ask which version, and check that against what your team, and MDCalc, actually use |
The first row is where the evidence is clearest. In late 2023, researchers gave ChatGPT 48 kinds of medical calculation. It got about one answer in three wrong, even though it could already write and run its own code (Goodell et al., 2025). More than half of its mistakes were in the rules: the wrong points for an item, or an item missed or made up. On the ten hardest calculations, with new test cases and a newer model, the team then tested what helps. Letting the model write and run code helped only a little: wrong answers fell from about 64 to 54 percent. Giving it MDCalc’s written instructions helped much more. Giving it calculators that people had built and checked, which it could call, cut wrong answers to 4.8 percent.
So writing code does not make a model reliable. Rules from a checked source do. Your tool will usually do its arithmetic correctly. But its rules are only as good as the model’s memory of the score, and a rule it leaves out leaves no trace. That is why you check it against MDCalc and the paper.
The second row is where non-programmers are weakest: they test the cases they thought of. The medical students whose apps all worked added no protection for the data the apps collected. The authors concluded that easier building has to come with training in data security (Quispe et al., 2026). An editorial in the laboratory medicine literature gives the pattern a name you will recognise from the wards, the illusion of competence. Code that is correctly written and looks professional is most convincing to the people least able to find its flaws. There is a real difference between code that runs and code that is safe to run on patients (De Bruyne et al., 2026).
A tool that is mostly right is the hardest case. A nursing research group used a coding agent to run a statistical analysis (a logistic regression) and compared its output with a published reference. The coefficients and p values matched. An error in one confidence interval was missed on the first review and found only later (Tolentino et al., 2026). The tool was mostly right, which is the condition under which people stop checking.
8.3.3 What “checked” looks like
The counterexample is worth knowing because it shows the standard can be met. A cardiology group built a web calculator for three acute coronary syndrome risk scores, with ChatGPT writing the code. They then compared its output against 226 registry patients whose scores had been computed independently. They report complete agreement (r = 1.000 for both scores that had a registry comparison), with the registry named (Egaimi et al., 2025). That is not a large study. It is not clinical validation either, which would mean showing the tool helps patients; the authors say that further clinical validation is needed. It is what a technical check looks like: an outside source of truth, a fixed set of cases, and a written result.
The resident’s tool in the workroom had none of those. Yours, in half an hour, will have a small version of all three.
8.3.4 Four questions before anyone else uses it
A 2026 framework for software that clinicians build this way names the main hazard comprehension abdication (Alqheedan & Alzughaibi, 2026). It means handing your understanding over to the tool that wrote the code, so that you cannot say what it does for every input. The framework rates a tool’s risk with four questions: does it touch patient data, does its output inform a treatment decision, can the person using it check the output, and does it reach one person or a whole institution?
8.3.5 Where a toy becomes a device
Toy, not device. Your tool carries a banner saying so, written into the prompt before the tool exists. If a page like this is ever used for real care, it may count as a regulated medical device, which the ethics chapter covers. Either way, a score in your note is yours: record where it came from, and make that the paper or MDCalc.
8.4 Watch or listen (optional)
Video. Andrej Karpathy, Software Is Changing (Again), keynote at Y Combinator’s AI Startup School, San Francisco, 17 June 2025 (published 19 June 2025; 39 min). https://www.youtube.com/watch?v=LCEmiRjPEtQ. YouTube’s captions are automatic and adequate.
Fifteen minutes is enough: skip the opening on “Software 3.0” and go to the middle third. There he describes partial autonomy apps and the autonomy slider. The useful question about an AI tool is not whether it is autonomous. It is how much freedom you have given it for this task, and how fast you can check what it did. For the tool you are about to build, ask where that setting is, and who checks the result.
Instead, or as well. The author’s slides, From Chatbots to Coding Agents (June 2026), go through the plan-act-observe loop in Figure 8.1 with examples. A recording from October 2025, from this course’s predecessor, shows a calculator being built in front of a class, with the mistakes left in.
8.5 Do
Made-up patients only. What counts as patient information. Every number you type is one you invented: if a test case needs a sodium of 118, invent a patient with a sodium of 118. Put nothing in your page worth stealing: no passwords, no names, no real data.
TipWhich tool
ChatGPT Edu (your university account). Ask for the page and it should open in the canvas side panel, which shows the page you built, running, with a preview button. If canvas does not appear, your workspace may have canvas code turned off; use the fallback below.1
Fallback, which also works in Copilot. Ask for “a single HTML file”. Copy the whole code block into a plain text editor (Notepad, or TextEdit in plain-text mode). Save it as calc.html and double-click it. Your browser opens it. Nothing is installed. You have made a file, which is what an agent would have done for you.
8.5.1 Part A: build it (20 minutes)
Step 1. Pick a score. Choose the one closest to your specialty from Table 8.2. Each has an original publication you will check against, and each has at least one edge the model tends to miss. If none fits, use CHA₂DS₂-VASc; it is the one the worked example below is written for.
Step 2. Paste the starter prompt, with your score substituted, into a fresh conversation. Use it word for word the first time. The safety wording is inside it on purpose. What comes back depends on how the request is phrased, and the same prompt produces different code on different days. Using the fixed text means your result reflects the model, not how fluently you write prompts. If English is not your first language, that is the point.
Build a single-page web app, as one self-contained HTML file, that calculates the
<score>. Show each input as a checkbox or numeric field with its point value or coefficient visible. Display the running total and the interpretation the original publication attaches to it. Add a prominent red banner: “Educational prototype only. Not validated for clinical decision-making.” In a footnote, cite the original publication for the score and say exactly which version of the score you implemented, so I can independently verify every rule against MDCalc and the paper before I trust the output. Open it in canvas so I can preview it.
Step 3. Ask for two changes. Whatever comes back, ask for two changes, one at a time. Watch what the model does to the rest of the page each time:
- “Colour the interpretation by risk tier.”
- “Add a ‘clear all’ button, and tell me what the score shows when nothing is entered.”
The second request is really a check, phrased as a feature. Read the answer.
You now have a working tool. It took about ten minutes, and it probably looks better than the resident’s. Do not share it yet.
8.5.2 Part B: break it (30 minutes)
Open MDCalc and the original paper from Table 8.2 side by side with your tool. Run three invented cases through all three sources and record the results in the template below.
Case 1, ordinary. A patient clearly inside the population the score was made for, with nothing unusual. All three should agree, and usually will. If they do not, you have found a rule error. Note it and continue.
Case 2, the edge. Take the edges column for your score and build a patient whose values fall on one of them. For example:
- MELD-Na: a patient on dialysis, or a sodium of 118
- qSOFA: a Glasgow score of 14
- Fleischner: a 6 mm subsolid nodule in a patient under 35
- CHA₂DS₂-VASc: a 74-year-old, then a 75-year-old
Compare the three sources.
Case 3, the nonsense. Give the tool something no patient has. Both age bands ticked. A negative creatinine. Every box checked and then every box unchecked. A blank form. The question is not whether the tool refuses (it usually will not). The question is whether you can say, before pressing anything, what it will do, and whether what it does is safe or silent.
TipWorked example: what to expect, and what to look for
Expected behaviour, not a recorded run. The two examples below are built from the failure patterns in Table 8.2, not from what a particular model produced on a particular day. Run the prompt yourself and compare.
CHA₂DS₂-VASc, expected. The page will usually get the eight point values right and add them up correctly. That is the easy part. Look instead at three places. First, the two age boxes. If both “65–74” and “≥75” can be ticked at once, the page can produce a score of 3 for age, which no patient has. Second, the stroke-risk percentages beside each score. The page will print a column of numbers with a footnote naming Lip et al. 2010. But the numbers most tools print come from a different group of patients (Friberg et al., 2012), and the two tables disagree. If the footnote does not say which, that is the version failure. Third, the “female sex” box. It scored 1 in the 2010 paper and is treated differently by newer guidelines. A page that scores it without saying which guideline it follows has chosen for you.
MELD-Na, expected. The formula will be right. What tends to be missing is exactly what the opening scenario depended on. No dialysis field, so creatinine is never set to 4.0. Values below 1.0 are not raised to it. No limits on sodium, so a sodium of 118 enters the equation as typed. No check that the sodium term applies only above the MELD threshold. And if it does limit sodium, no word on whose limits it uses, the 2008 paper’s or the transplant system’s. Ask the page for a patient on dialysis and one with a sodium of 118, then compare to MDCalc.
Your run will differ from these expectations in both directions. Models change monthly, and the same prompt produces different code on different days. The pattern is what to look for. The arithmetic is usually right; the rules at the edges are where to read.
Record it. Copy this into a document. It also answers question 2 of your learning journal: one time you checked the AI, how, and what you found.
Tool used: ___________________ Model version if shown: ____________
Score built: __________________ Version the tool says it implements: ________
Case Inputs (invented) My tool MDCalc Paper Agree?
1 ordinary _______________________ _____ _____ _____ Y / N
2 edge _______________________ _____ _____ _____ Y / N
3 nonsense _______________________ _____ _____ _____ Y / N
Difference or edge failure found ("none" needs the edges you tried):
________________________________________________________________________
Which of the three failures in the table is it: rule / edge / version?
________________________________________________________________________
The one change I would make before letting anyone else use it:
________________________________________________________________________“None found” is a good result, if you can say which edges you tried. It is still not validation: the tool has been tested on three cases.
The one sentence. Write the sentence you would say to a co-intern who shows you a calculator they built last night. It should contain a verb that means compare against something outside the tool.
8.5.3 Part C (optional): explain it, then place it (10 minutes)
The comprehension test. In four sentences, without opening the code, write what your tool does for: an ordinary patient, the edge case, the nonsense case, and a blank form. If you cannot write the fourth sentence, ask the model “what does the page show when nothing is entered, and why?”. Read the answer against the page, and then write it. This is the test the resident never took.
Where it sits. One paragraph. Is your tool, as it is, a study aid or something a team could rely on? Say why, using the word “banner”. Then answer the four questions from “Four questions before anyone else uses it” for your tool, and name what would have to change before anyone else used it.
8.6 Check
Score yourself against this before moving on.
| You have | Meets | Falls short |
|---|---|---|
| The chatbot-versus-agent distinction (objective 1) | You can say what the loop adds (acts on real files, observes, repeats, inside permissions) and why a running tool hides errors a reply does not | “An agent is a smarter chatbot” |
| A working tool (objective 2) | Runs in a browser, shows inputs and total, carries the banner, cites the paper and names the version | Runs, but the banner or citation is missing, or the version is unstated |
| Three recorded cases (objective 3) | Each compared against MDCalc and the original paper; any difference named and sorted as rule, edge, or version, or, if all agree, the edges you tried listed | “It matched MDCalc” with no edge case tried |
| The one sentence | Contains a verb meaning compare against an outside source | “Be careful with it” |
| The comprehension test (Part C, optional) | Four sentences, including the blank form, written before opening the code | The fourth sentence is missing or copied from the model |
| Where it sits (Part C, optional; objective 4) | Says why it is a study aid now, answers the four questions for your tool, and names what would have to change before anyone else used it | “It’s not a device because it’s just a prototype” |
8.7 What this changes for you
What does this change about how you’ll practice? Write it down before you close this chapter. Two specifics. First, go back to the workroom. The coordinator is on the phone, the team’s number is 24, hers is 32, and the bookmark is on every computer. What do you say to her? What do you say to the resident who built it? What happens to the bookmark? Second, think of the next tool you build yourself, or are handed by a colleague. Name the three cases you will run through it before it touches a decision, and the outside source each one is compared against. One word is not an answer to either.
8.8 Go deeper
Papers
- VIBE-HI, the governance framework behind the four questions, with its four risk tiers mapped to regulation (Alqheedan & Alzughaibi, 2026); and the laboratory-medicine editorial on the illusion of competence (De Bruyne et al., 2026).
- The clinical-calculation study (Goodell et al., 2025): code the model wrote for itself helped a little, and calculators built and checked by people helped most. Also the cardiology group’s technical validation of a ChatGPT-built calculator against a registry (Egaimi et al., 2025), which shows what your Part B could become.
- Two views of the same practice from inside medicine: an editorial arguing it opens biomedical software to everyone (Moore & Tatonetti, 2025), and a medical-education piece that built two teaching simulations this way (Chow & Ng, 2025).
- The one evaluated medical-education app built by prompting, an ECG tutor compared against control sites, with mixed and inconsistent effects on exam performance (Al Janabi & Bland, 2026). Building fast is not the same as building something that works.
- Two studies of code written with AI help, both from before current models. About 40 percent of programs from an early coding assistant, in security-relevant scenarios, had a vulnerability (Pearce et al., 2022). People using an assistant wrote less secure code and were more confident that it was secure (Perry et al., 2023). Hence the rule in the Do: put nothing in your page worth stealing.
Talks
- From Chatbots to Coding Agents and AI Agents for Biomedical Knowledge Work, the author’s slides this chapter’s approach comes from; the second has the privacy-and-trust section in full.
If you want to go further
- The full agents (Claude Code, Codex, Gemini CLI, and GitHub Copilot in an editor) need a local install and a terminal, and most need a paid plan. Try one after the course, on a project with nothing in it worth stealing.
- Google Colab runs Python notebooks in a browser with a Google account and no install. Its built-in agent can run a whole data analysis, start to finish, from a prompt. This course’s predecessor used it for a public insurance-cost dataset. The completed notebook is a good thing to appraise: ask what the agent decided without being asked, and what you would want to know before believing its R².
Al Janabi, I., & Bland, T. (2026). Harnessing “Vibe Coding” to Rapidly Develop Tailored Educational Apps: A Generative AI-Driven ECG Interpretation Tool in Medical Education. AI, 7(6), 223. https://doi.org/10.3390/ai7060223
Alqheedan, A., & Alzughaibi, S. (2026). The VIBE-HI framework: A conceptual model for evaluating vibe coding appropriateness, quality, and safety in health informatics. Frontiers in Artificial Intelligence, 9, 1882814. https://doi.org/10.3389/frai.2026.1882814
Chow, M., & Ng, O. (2025). From technology adopters to creators: Leveraging AI-assisted vibe coding to transform clinical teaching and learning. Medical Teacher, 47(12), 1927–1929. https://doi.org/10.1080/0142159x.2025.2488353
De Bruyne, S., Rommes, S., Fiers, T., Volders, P.-J., & Maes, B. (2026). Vibe coding and the illusion of competence: Why laboratory medicine specialists shouldn’t trust their AI-generated code for clinical deployment. Clinical Chemistry and Laboratory Medicine. https://doi.org/10.1515/cclm-2026-0887
Egaimi, M., Corvo, P., Al Houri, H., Chang, J. M., Seo, H., Almorraweh, A., Choi, W., Badreldin, H., Bashir, S., Serour, M. H., Merghani, L., Al Natour, M., Mukhtar, M., & Clementi, F. (2025). Development and Technical Validation of an Integrated Risk Calculator for Acute Coronary Syndrome Using ChatGPT-Assisted Coding. Cureus, 17(5), e83410. https://doi.org/10.7759/cureus.83410
Friberg, L., Rosenqvist, M., & Lip, G. Y. H. (2012). Evaluation of risk stratification schemes for ischaemic stroke and bleeding in 182 678 patients with atrial fibrillation: The Swedish Atrial Fibrillation cohort study. European Heart Journal, 33(12), 1500–1510. https://doi.org/10.1093/eurheartj/ehr488
Goodell, A. J., Chu, S. N., Rouholiman, D., & Chu, L. F. (2025). Large language model agents can use tools to perform clinical calculations. NPJ Digital Medicine, 8(1), 163. https://doi.org/10.1038/s41746-025-01475-8
Kamath, P. S., Wiesner, R. H., Malinchoc, M., Kremers, W., Therneau, T. M., Kosberg, C. L., D’Amico, G., Dickson, E. R., & Kim, W. R. (2001). A model to predict survival in patients with end-stage liver disease. Hepatology (Baltimore, Md.), 33(2), 464–470. https://doi.org/10.1053/jhep.2001.22172
Kim, W. R., Biggins, S. W., Kremers, W. K., Wiesner, R. H., Kamath, P. S., Benson, J. T., Edwards, E., & Therneau, T. M. (2008). Hyponatremia and mortality among patients on the liver-transplant waiting list. The New England Journal of Medicine, 359(10), 1018–1026. https://doi.org/10.1056/nejmoa0801209
Kim, W. R., Mannalithara, A., Heimbach, J. K., Kamath, P. S., Asrani, S. K., Biggins, S. W., Wood, N. L., Gentry, S. E., & Kwong, A. J. (2021). MELD 3.0: The Model for End-Stage Liver Disease Updated for the Modern Era. Gastroenterology, 161(6), 1887–1895.e4. https://doi.org/10.1053/j.gastro.2021.08.050
Kroenke, K., Spitzer, R. L., & Williams, J. B. (2001). The PHQ-9: Validity of a brief depression severity measure. Journal of General Internal Medicine, 16(9), 606–613. https://doi.org/10.1046/j.1525-1497.2001.016009606.x
Lip, G. Y. H., Nieuwlaat, R., Pisters, R., Lane, D. A., & Crijns, H. J. G. M. (2009). Refining clinical risk stratification for predicting stroke and thromboembolism in atrial fibrillation using a novel risk factor-based approach: The euro heart survey on atrial fibrillation. Chest, 137(2), 263–272. https://doi.org/10.1378/chest.09-1584
MacMahon, H., Naidich, D. P., Goo, J. M., Lee, K. S., Leung, A. N. C., Mayo, J. R., Mehta, A. C., Ohno, Y., Powell, C. A., Prokop, M., Rubin, G. D., Schaefer-Prokop, C. M., Travis, W. D., Van Schil, P. E., & Bankier, A. A. (2017). Guidelines for Management of Incidental Pulmonary Nodules Detected on CT Images: From the Fleischner Society 2017. Radiology, 284(1), 228–243. https://doi.org/10.1148/radiol.2017161659
Moore, J. H., & Tatonetti, N. (2025). Vibe coding: A new paradigm for biomedical software development. BioData Mining, 18(1), 46. https://doi.org/10.1186/s13040-025-00462-9
Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. 2022 IEEE Symposium on Security and Privacy (SP), 754–768. https://doi.org/10.1109/sp46214.2022.9833571
Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2785–2799. https://doi.org/10.1145/3576915.3623157
Quispe, C. K., Berhongaray Kenny, E., Gamez, I., Couce, A., Brusco, L. I., & Giunti, G. (2026). Vibe Coding to Democratize Dementia mHealth Development: Preliminary Findings. Studies in Health Technology and Informatics, 338, 601–605. https://doi.org/10.3233/shti260915
Seymour, C. W., Liu, V. X., Iwashyna, T. J., Brunkhorst, F. M., Rea, T. D., Scherag, A., Rubenfeld, G., Kahn, J. M., Shankar-Hari, M., Singer, M., Deutschman, C. S., Escobar, G. J., & Angus, D. C. (2016). Assessment of Clinical Criteria for Sepsis: For the Third International Consensus Definitions for Sepsis and Septic Shock (Sepsis-3). JAMA, 315(8), 762–774. https://doi.org/10.1001/jama.2016.0288
Tolentino, D. A., Kohout, E., Boy, P., & Siddiq, H. (2026). Vibe Coding for Statistical Analysis Using Large Language Models. Nursing Research. https://doi.org/10.1097/nnr.0000000000000942
Wells, P. S., Anderson, D. R., Rodger, M., Ginsberg, J. S., Kearon, C., Gent, M., Turpie, A. G., Bormanis, J., Weitz, J., Chamberlain, M., Bowie, D., Barnes, D., & Hirsh, J. (2000). Derivation of a simple clinical model to categorize patients probability of pulmonary embolism: Increasing the models utility with the SimpliRED D-dimer. Thrombosis and Haemostasis, 83(3), 416–420. https://www.ncbi.nlm.nih.gov/pubmed/10744147
VERIFY: run the starter prompt in the CU ChatGPT Edu workspace with a university login and confirm the canvas preview appears; OpenAI’s admin documentation says canvas code execution is a workspace setting, checked 2026-09-08↩︎