Visual Guides
Printable overview sheets
One-page editorial explainers you can print and keep next to you. Each guide condenses a topic taught here into a single A4 landscape sheet.
Visual Guide 01 · Technical / GenAI
FHIR · API · MCP · RAG · LLM
Five terms. Five different jobs. A more connected healthcare.
Healthcare AI Learning
| Term | FHIRHealthcare data standard | APISoftware interface | MCPAI integration protocol | RAGArchitecture pattern | LLMAI model |
|---|---|---|---|---|---|
| What is it? | HL7 standard for representing and exchanging healthcare data. | An interface that lets systems request data or perform actions. | Open protocol standardising how AI/LLM applications connect to external context, data sources and tools. | Retrieval-augmented generation: retrieve external information and supply it as model context. | Large language model trained to process and generate language, and often other content. |
| Main purpose | Structure and exchange health data consistently. | Communication between systems. | A consistent AI-facing integration layer. | Provide relevant, current or private information at runtime. | Understand, reason over and generate output from prompt and context. |
| Key capabilities | Standardised resource models (Patient, Observation, Condition); several exchange paradigms — REST, documents, messaging. | Request/response, authentication and authorisation, structured exchange. | MCP servers can expose resources, prompts and executable tools. | Search, retrieve, rank and supply relevant content. Vector search is one possible mechanism, not the definition. | Summarise, classify, transform and generate content, depending on model and input. |
| Healthcare example | Patient + Observation (HbA1c) + Condition records. | A FHIR API endpoint retrieving the latest lab results. | An MCP server exposing a “get patient observations” tool that internally calls an approved API/FHIR service. | Retrieve a current guideline plus relevant patient context before a model drafts a response. | Draft a concise clinical summary from supplied context. |
| Often confused with | An API, or a database. | A data standard, or an AI model. | A replacement for APIs or FHIR. | A model, a database, or a training method. | A source of truth, or a database. |
| What it is NOT | Not an AI model, and not limited to REST APIs. | Not a data standard, and not a data source on its own. | Not an EHR, not a healthcare data standard, not a model. | Not a model, not the same as a vector database, and no guarantee of correctness. | Not automatically connected to hospital data; it does not know private or current organisational data unless that is provided through context, retrieval, tools or another integration. |
How they work together in practice
Healthcare data sources
EHR, lab, imaging, devices, notes
Interoperability layer
FHIR, APIs, SMART on FHIR, DICOM, terminologies
Access & retrieval
RAG, MCP, direct API, context assembly
AI application
LLM, agent, tools, guardrails, evaluation
Output & impact
Reviewed output used in the workflow
Paths overlap. An MCP tool can call an API — including a FHIR API — and RAG can retrieve through APIs.
Common misconceptions
- “FHIR is an API.” Not quite. FHIR is a healthcare data standard and exchange framework; REST APIs are one major way to use it.
- “MCP replaces APIs.” No. MCP standardises the AI-facing integration layer and may call existing APIs underneath.
- “RAG is a database.” No. It is a retrieval-plus-generation pattern; a vector database is one possible retrieval component.
- “An LLM knows our hospital data.” Not unless that data is supplied or connected through context, retrieval or tools.
- “If we have FHIR, our data is AI-ready.” No. Relevance, timing, provenance, coding consistency, missingness and task fit all still matter.
FHIR R5 (5.0.0) is the current published core FHIR release. · Many real deployments still run R4/R4B. · SMART App Launch 2.2 is based on FHIR R4. · Always inspect the actual server CapabilityStatement and implementation guide.
Guide 01
FHIR · API · MCP · RAG · LLM
A side-by-side terminology map of the five terms most often confused in healthcare AI conversations.
Visual Guide 02 · Foundation / Technical / Builder
How an AI Healthcare Application Fits Together
From healthcare data to real-world impact — the building blocks, the flow and the safeguards.
Healthcare AI Learning
AI supports workflows and outcomes; it is not the endpoint.
Example flow
Example task (synthetic): summarise a patient's latest HbA1c in the context of diabetes follow-up.
1. Retrieve relevant patient data via an approved FHIR/API path
2. Retrieve contextual or guideline information where needed (RAG / approved source)
3. Assemble a bounded context
4. LLM creates a draft
5. Clinician reviews and validates
6. Output used in the workflow — better-informed care
Key takeaways
- It is a system, not a single technology.
- Context quality matters more than model choice.
- Healthcare adds safety, privacy and governance requirements.
- The goal is measurable real-world value, not AI for its own sake.
Guide 02
How an AI Healthcare Application Fits Together
The six layers between a hospital's data and a clinical outcome, with the governance that applies across all of them.
Visual Guide 03 · GenAI / Agentic / Builder
LLM · RAG · Fine-tuning · Tools · Agents
Five building blocks. Different jobs. Better AI systems.
Healthcare AI Learning
| Term | LLMAI model | RAGArchitecture pattern | Fine-tuningTraining method | ToolsExternal capabilities | AgentsSystem pattern |
|---|---|---|---|---|---|
| What is it? | Pretrained model that processes and generates language or other content. | Retrieve external information and give it to the model as context. | Continue training or adapt a pretrained model on task or domain examples to change its behaviour. | Defined functions or services an AI application can invoke to get data or perform actions. | An AI system that can choose and sequence steps and tool use toward a goal, within boundaries. |
| Main purpose | General reasoning, understanding, transformation and generation. | Bring relevant, current or private information into a response without retraining the model. | Improve format, style, task behaviour or domain performance when examples teach the desired pattern. | Read, search, calculate, write, or call external systems. | Multi-step tasks that benefit from iterative planning, action and feedback. |
| Runtime / training | Uses prompt and context at runtime. Internal knowledge comes from training and does not automatically include current or private local data. | Runtime mechanism. Does not change base model weights. | Training-time adaptation: updates model parameters or adapters. Not retrieval. | Runtime. Can be exposed through APIs or MCP. Fixed workflows can use tools without being agents. | Terminology varies. In this learning platform an agent is a system that can direct at least some of its own process and tool use in a loop, rather than following only a fixed script — with stopping rules, permissions and oversight. |
| Healthcare example | Draft a clinical summary from supplied patient context. | Retrieve a current guideline plus recent HbA1c and condition context before drafting a response. | Train toward a consistent structured documentation format using approved labelled examples. | Call a FHIR endpoint, calculate a score, create a draft workflow task. | Gather approved context, use approved tools, draft a result, check conditions and escalate when permissions or quality rules require it. |
| What it is NOT | Not a source of truth, and not a hospital database. | Not a model, not a database, and not a guarantee of correctness. | Usually not the primary mechanism for rapidly changing or traceability-sensitive facts. | Not the same thing as an agent. | Not automatically better than a simpler workflow. |
Runtime flow
Task / user goal
RAG / context
LLM
Tools
Agent / workflow (when appropriate)
Common misconceptions
- “RAG and fine-tuning solve the same problem.” No — runtime context versus training-time adaptation.
- “If a model uses tools it is an agent.” Not necessarily. Fixed workflows can use tools.
- “Agents are always better.” No. Use the simplest safe architecture that meets the task.
- “Fine-tuning is how you teach the latest facts.” Generally not, for frequently changing or traceability-sensitive knowledge; retrieval is usually better suited.
- “RAG removes hallucinations.” No. Retrieval and generation can still fail, so evaluation stays necessary.
Guide 03
LLM · RAG · Fine-tuning · Tools · Agents
What each GenAI building block actually does, at runtime or at training time, and when to reach for which.
Visual Guide 04 · Foundation / Technical / Data
The Healthcare Data Landscape
Where healthcare AI gets its data — systems, formats, standards and meaning.
Healthcare AI Learning
Band 1
Source systems
- EHR / EPD / HIS
- LIS / laboratory
- RIS / PACS / imaging
- Pharmacy & medication systems
- Monitoring, devices, wearables
- Patient-reported data / PROMs
- Registries, claims, administrative data
- Guidelines, literature, protocols
Band 2
Data types
- Structured coded fields
- Clinical notes / free text
- Documents
- Images
- Waveforms / signals
- Measurements / time series
- Genomics / omics (selected settings)
Band 3
Exchange & interoperability
- FHIR — Healthcare data standard: resource model plus exchange framework
- HL7 v2 — Event/message-based exchange, widely used in existing hospital environments
- DICOM / DICOMweb — Medical imaging information standard and web services
- APIs — Software interfaces exposing data or actions
- SMART on FHIR — App authorisation and launch patterns around FHIR systems
Band 4
Semantics / terminologies
- SNOMED CT — Clinical concepts
- LOINC — Observations, measurements, tests and documents
- UCUM — Units of measure
- ICD — Classification for reporting, statistics and reimbursement contexts — not interchangeable with SNOMED CT
End-to-end
Source
Representation & exchange
Semantics
Quality & context
AI use
AI-readiness lens
Standardised ≠ complete, current, consistent or AI-ready.
Common misconceptions
- “FHIR replaces HL7 v2 everywhere.” No. Many environments run both, often for years.
- “SNOMED CT and LOINC do the same job.” No. They cover different semantic roles.
- “Structured data is automatically high quality.” No. Coding practice, timing and completeness still vary.
- “DICOM is just image pixels.” No. DICOM covers imaging-related information, metadata and services.
- “Standardised means AI-ready.” No. Task fit, permissions and context still decide.
Guide 04
The Healthcare Data Landscape
A map of source systems, data types, exchange standards and terminologies — plus the readiness lens that decides whether data is usable for AI.
Visual Guide 05 · GenAI / Agentic / Builder
From Prompt to Agent
A practical ladder from one-shot generation to bounded agentic workflows.
Healthcare AI Learning
| Level | What it is | Who chooses the next step | Typical use | Healthcare example | Main control need |
|---|---|---|---|---|---|
| 1Prompt | One request, one model response. | User or system defines the task. | One-off generation or rewriting. | Rewrite a patient-facing explanation from supplied text. | Input and output review. |
| 2LLM application | Prompt plus UI, bounded context and output formatting. | Software defines the task shape. | Repeatable single-step tasks. | Structured summarisation assistant. | Output validation and formatting rules. |
| 3Context / RAG-enabled application | Runtime retrieval supplies relevant information to the model. | Retrieval logic is defined by software. | Answers that need current, private or approved sources. | Retrieve approved guideline sections before drafting an answer. | Source allowlist, grounding checks, provenance. |
| 4Tool-enabled AI | The model or app can call defined external functions and services. | Model may select from a defined tool set. | Tasks needing data lookup, calculation or actions. | Retrieve a FHIR Observation, calculate a score, create a draft task. | Tool allowlist, permissions, argument validation. |
| 5Fixed workflow | Steps and branching are primarily predefined by software, with model or tool calls inside. | Software chooses the sequence. | Known, repeatable multi-step processes. | Intake → retrieve → summarise → validate → human review. | Deterministic sequence, checkpoints, audit trail. |
| 6Bounded agentic workflow | The system can choose and sequence at least some steps or tool use toward a goal, within explicit boundaries. | System chooses within permissions and stopping rules. | Tasks that genuinely benefit from iteration and feedback. | Gather approved context, choose allowed tools, check quality rules, escalate when required. | Permissions, stopping conditions, logging, escalation, monitoring. |
More agentic ≠ better. Use the simplest architecture that safely meets the task.
Common misconceptions
- “Tool use means it is an agent.” Not necessarily — fixed workflows use tools too.
- “A workflow is an agent.” Not necessarily — predefined steps are not self-directed.
- “An agent is fully autonomous.” Not in this learning platform’s bounded definition.
- “Multi-agent is more advanced, so better.” Not inherently; it adds failure modes.
- “Agentic systems remove human oversight.” No. Oversight and escalation stay required.
Guide 05
From Prompt to Agent
Six levels of AI system design, what chooses the next step at each level, and the controls each level requires.
Visual Guide 06 · Evaluation / Foundation / Builder
AI Evaluation in Healthcare
From model metrics to safety, workflow value and real-world performance.
Healthcare AI Learning
A
Predictive / classification models
- Sensitivity · specificity
- PPV / NPV (prevalence-dependent)
- AUROC / AUPRC where appropriate
- Calibration
- Threshold-dependent errors / confusion matrix
Choose metrics from the intended use and the consequences of false positives and false negatives.
B
Generative AI
- Factuality / correctness
- Grounding to supplied sources
- Relevance · completeness
- Robustness to phrasing and context
- Consistency where it matters
- Harmful or unsafe output rate
Grounding does not automatically equal truth: retrieval can be wrong or incomplete.
C
Tools / agents / workflows
- Task success
- Tool-call correctness
- Permission adherence
- Step completion
- Invalid or harmful action rate
- Escalation behaviour
- Latency · cost / resource use
A fluent final answer can hide a failed process or tool call.
D
Real-world clinical & operational value
- Adoption and use
- Time saved · error / rework rate
- Safety incidents
- Workflow burden
- Clinician and patient experience
- Subgroup performance / equity
- Patient or clinical outcomes where relevant
- Financial and operational impact
Good model performance ≠ clinical value.
Evaluation lifecycle
Offline test set
Silent / shadow evaluation where feasible
Controlled pilot
Production monitoring
Incident review, revalidation, change control
Pitfalls
- One aggregate accuracy number
- AUROC without the operating threshold or use case
- Judging generative output only by “looks good”
- No subgroup or error analysis
- No workflow or human-factors evaluation
- Launch without monitoring for drift and change
Evaluation is a system: technical quality + safety + people + workflow + impact.
Guide 06
AI Evaluation in Healthcare
Four distinct evaluation families, the lifecycle from offline test set to production monitoring, and the pitfalls in between.
Visual Guide 07 · Governance / Foundation / Practitioner
AI Governance in Healthcare
A practical map of accountability from idea to production.
Healthcare AI Learning
- What problem and use case?
- Who owns clinical, business and product decisions?
- Who can stop use?
- Lawful basis and appropriate governance
- Minimisation, access, retention
- Data quality and provenance
- Sensitive-data controls; GDPR where personal data is processed
- Intended population and performance
- Subgroup analysis and limitations
- Validation and documentation
- Change control
- Identity and access, secrets
- Tool permissions
- Vendor and supply-chain risk
- Logging, resilience, cybersecurity
- Who reviews and who acts
- Escalation and override
- Accountability and training
- Usability and human factors
- EU AI Act: obligations depend on risk, role and use case; phased over time
- Do not assume all healthcare AI is high-risk
- MDR / IVDR: software may be regulated when intended purpose and classification bring it in scope
- Local, national and organisational requirements may also apply
- Post-deployment monitoring
- Quality and safety signals, complaints
- Drift and change
- Incident response, revalidation, retirement
Who needs to be in the room?
Governance is continuous, not a one-time approval gate.
Guide 07
AI Governance in Healthcare
Seven governance domains, an EU reality check for Sep 2026, and who needs to be in the room.
Visual Guide 08 · Implementation / Practitioner / Builder
From Healthcare Problem to Scaled AI Solution
A practical path from pain point to measurable, governed real-world value.
Healthcare AI Learning
1
Problem
What specific pain point or outcome are we solving?
Problem statement + baseline
2
Workflow & users
Where does the problem occur and who is affected?
Current-state workflow / user needs
3
Value hypothesis
What measurable improvement would matter?
Target metrics: clinical, operational, experience, financial as appropriate
4
Does this need AI?
Is AI actually better than rules, process redesign or standard software?
Simplest viable approach decision
5
Data & integration readiness
Do we have the right data, permissions, interfaces, timing and ownership?
Data / integration map + gaps
6
Prototype
Can we prove the core workflow safely with synthetic, de-identified or approved data as appropriate?
Bounded prototype + failure modes
7
Evaluate & validate
Does it work for the intended users, population and workflow, and is it safe enough for the intended use?
Evaluation evidence + go/no-go criteria
8
Deploy & adopt
Who owns rollout, training, workflow integration, support and escalation?
Deployment / adoption plan
9
Monitor & scale
Does performance and value persist, and can it scale operationally, economically and governably?
Monitoring, ownership, economics, support, change control + scale decision
Decision gates
Need
Feasibility
Safety & evidence
Adoption
Economics & ownership
Scale
The pilot trap
A successful pilot is not a scalable product.
Scale also needs ownership, integration, training, support, monitoring, governance, economics and procurement — plus a change and retirement plan.
The best next step is usually the smallest step that removes the biggest uncertainty safely.
Guide 08
From Healthcare Problem to Scaled AI Solution
Nine implementation stages, each with one core question and one artefact, plus the decision gates and the pilot trap.