Glossary

AI basics

Artificial intelligence (AI)

AI

An umbrella term for software that performs tasks normally requiring human judgement, such as recognising patterns, predicting outcomes or generating text.In healthcare, almost everything sold as “AI” today is machine learning trained on historical data, so the questions that matter are about the data, the task and the evidence — not the label.

Machine learning

ML

A method where a system learns patterns from historical examples rather than being programmed with explicit rules.The model inherits the population, coding habits and care pathways of the data it learned from, which is why the same model can behave differently in another hospital.

Deep learning

Machine learning using multi-layer neural networks, which learn useful representations directly from raw data such as images, signals or text.

Training

The process of fitting a model's parameters to historical data. Training happens once (or periodically); it is not what happens when a clinician uses the tool.

Inference

Running a trained model on new input to produce an output. This is what happens each time the tool is used in practice.

Generative AI

Fine-tuning

Further training an existing model on additional examples to adapt its behaviour to a specific task or style.Fine-tuning changes behaviour, not access to current facts. Local, current or patient-specific information should come from context or retrieval instead.

Generative AI

GenAI

Models that produce new content — text, images, audio or code — rather than predicting a label or a risk score.Generation is plausible-by-construction: the output can be fluent and wrong, so review and traceability matter more than with a score.

Large language model (LLM)

LLM

A model trained on very large amounts of text that predicts likely continuations, allowing it to answer, summarise, draft and reformat language.An LLM has no index, no date guarantee and no provenance trail of its own. Those properties have to be supplied by the surrounding system.

Foundation model

A large, general-purpose model trained on broad data and then adapted to many downstream tasks rather than built for one.A foundation model is one component. The clinical product is the system around it: context, tools, guardrails, evaluation and workflow.

Prompt

The instructions and context given to a generative model for a single request — the specification it is asked to satisfy.

Context engineering

Deciding what information a model is given for each request — instructions, patient context, retrieved passages, tool results — and in what form.

Hallucination

A confident output that is not supported by the input or by any source — an invented medication, date, guideline or citation.Hallucinations are reduced by grounding, source citation and human sign-off, not by asking the model to be careful.

Retrieval-augmented generation (RAG)

RAG

Retrieving passages from a governed source collection and giving them to the model so the answer can be based on — and cited back to — real documents.Retrieval fixes currency, locality and citability. It does not fix a poor source collection, a bad question or missing oversight.

AI agent

agent

agentic AI

A system that pursues a goal across multiple steps and itself chooses or sequences at least some of the next actions or tool calls based on intermediate results, within defined boundaries. Tool use alone does not make a system an agent: a fixed, pre-scripted sequence of tool calls is a workflow.Agentic systems can change the world, not just describe it, so permissions, approval gates, audit logging and stop rules are part of the design.

Model Context Protocol (MCP)

MCP

An open protocol for connecting a model-based application to tools and data sources through a standard interface.MCP is a connector standard inside the tools layer. It is not the agent, and it does not by itself grant, restrict or audit access.

Grounding

Supplying a model with authoritative source material — retrieved passages, records or guidelines — so its output is based on something checkable rather than on training memory alone.Grounding is an input-side design decision: what the model is given. Whether the output actually stays faithful to those sources is groundedness — a separate, measurable property.

Groundedness

The degree to which a generated output is actually supported by the sources it was given — every claim traceable to a supplied passage.Groundedness is an output-side quality you evaluate, for example by checking citations. A system can be grounded by design and still produce ungrounded sentences.

Embeddings

Numeric vector representations of text (or images) where similar meanings sit close together, enabling semantic search and retrieval.Embeddings power retrieval over guidelines and protocols, but similarity is not clinical equivalence — retrieval results still need source review.

Vector database

A store optimised for embeddings that finds the most semantically similar passages to a query.In a governed RAG system the vector database indexes only the approved source collection; it is infrastructure, not a source of truth itself.

Context window

The maximum amount of text a model can consider in a single request — instructions, retrieved passages and conversation history combined.A large window is not a memory strategy: important instructions and patient context can still be crowded out, which is why context engineering matters.

Tokens

The small chunks of text (parts of words) a model reads and writes; usage, cost and context limits are measured in tokens.

Temperature

A setting controlling output randomness: lower values make responses more predictable and consistent, higher values more varied.Clinical drafting favours low temperature for consistency, but no temperature setting guarantees factual correctness.

Structured outputs

Constraining a model's response to a defined schema (for example JSON fields) so downstream systems can parse it reliably.Schema enforcement guarantees the shape of the response, not its truth, grounding or clinical correctness.

Tool calling

function calling

Letting a model request that the surrounding system run a defined function — a lookup, calculation or action — and return the result.Tool calling is how a model gains access to current, patient-specific or external data; permissions and validation live in the system, not the model.

Agent2Agent (A2A)

A2A

An open protocol for letting independent AI agents discover, delegate to and exchange tasks with one another.A2A connects agents across system boundaries; governance of what each agent may do still has to be designed and audited separately.

Agent Skills

Skills

Packaged, reusable instruction sets (often with scripts or templates) that an agent can load to perform a specialised task consistently.Skills encode institutional know-how — a referral format, a discharge checklist — as versioned, reviewable artefacts rather than prompt folklore.

Agent harness

harness

The orchestrating code around a model that manages the loop: prompts, tool calls, retries, limits and stopping conditions.Two products on the same model can behave very differently because their harnesses differ; evaluate the system, not just the model.

Multi-agent system

A design where several specialised agents cooperate — for example a planner, a retriever and a checker — rather than one agent doing everything.More agents means more hand-offs to test, more failure modes and more audit surface; added complexity must earn its place.

Data

Electronic health record (EHR)

EPR

EMR

The digital record of a patient's care. Also called an EPR (electronic patient record) in several European systems.EHR data is a by-product of care and billing, not a research dataset: timing, coding and completeness reflect how the service works.

FHIR

An interoperability standard defining how health data is structured and exchanged between systems.FHIR carries the data. It does not decide what the clinical concepts mean.

SNOMED CT

A clinical terminology that gives coded meaning to clinical concepts such as diagnoses, findings and procedures.

Provenance

The record of where information came from: which source, which version, when, and through which process.Two senses are used in the curriculum — data provenance (where a dataset came from) and source provenance (which passage supports this sentence). Both must be inspectable.

Dataset shift

drift

The population, practice or data capture changes over time or across sites, so a model's performance in deployment differs from its performance in evaluation.

LOINC

A standard coding system for laboratory tests, measurements and clinical observations — what was measured.LOINC codes the observation itself; the result may still need units (UCUM) and reference ranges to be interpretable by a model.

ICD

The International Classification of Diseases — the WHO coding system for diagnoses, widely used for billing, statistics and registers.ICD codes reflect coding practice and reimbursement as much as clinical reality; models trained on them inherit those incentives.

UCUM

A standard for encoding units of measure (mg, mmol/L, mmHg) so quantities can be exchanged and compared unambiguously.Unit errors are a classic silent data failure: a value without a trustworthy unit is not safely usable by a model.

OMOP Common Data Model

OMOP

A research-oriented common data model that maps data from many sources into one standard structure and vocabulary for analysis.OMOP enables multi-site studies and external validation by making data comparable across institutions; it complements rather than replaces FHIR's exchange role.

SMART on FHIR

A standard way for third-party apps to launch inside or alongside an EHR and access FHIR data with the user's permissions.A common integration route for clinical AI: the app runs in the EHR context with a defined, auditable scope of access.

CDS Hooks

A standard for triggering clinical decision support at defined points in the EHR workflow, such as opening a chart or signing an order.CDS Hooks let an AI service be called at the right workflow moment and return suggestions as cards the clinician can accept or override.

Evidence & evaluation

External validation

Evaluating a model on data from a different site, population or period than the one it was developed on.Without it, a reported result describes the development setting, not yours.

Calibration

Whether predicted probabilities match observed frequencies — if the model says 20%, roughly 20 in 100 such patients should have the outcome.Discrimination (for example AUC) alone does not make a score safe to act on at a threshold; calibration does much of that work.

Positive predictive value (PPV)

Of the cases the tool flags, the proportion that truly have the condition or outcome. It depends heavily on how common the outcome is.

Shadow mode

Running an AI system live on real cases without showing its outputs to clinicians, to measure real-world performance before activation.Shadow mode reveals workflow-fit and data problems that offline evaluation cannot, at no clinical risk — but it is still prospective evaluation, not proof of benefit.

Silent mode

silent pilot

Like shadow mode, running the system in production without influencing care; often used specifically for alert-style tools to measure alert rates and timing first.Silent-mode results calibrate thresholds and workload expectations before anyone acts on the output.

Total cost of ownership (TCO)

TCO

The full cost of a system over its life: licences, integration, infrastructure, validation, training, monitoring, change management and decommissioning.For clinical AI, integration and ongoing monitoring usually dominate the licence fee; business cases built on licence price alone understate cost.

NASSS framework

A framework for explaining why health technologies succeed or fail in practice: Condition, Technology, Value proposition, Adopters, Organisation, System, and adaptation over time.NASSS predicts that complexity across several domains — especially organisation and system — is the strongest signal of non-adoption or abandonment.

DECIDE-AI

A reporting guideline for early-stage live clinical evaluation of AI decision support — the bridge between retrospective studies and trials.

TRIPOD+AI

TRIPOD-AI

A reporting guideline for prediction-model studies using regression or machine learning, covering development and validation reporting.Guideline-compliant reporting enables appraisal; it is not itself proof a model is safe or effective.

Safety & oversight

Human oversight

human-in-the-loop

meaningful oversight

A named human with the information, time and authority to check, override or stop an AI output before it affects a patient.A review click is not oversight if the reviewer cannot see what the output was based on or has no realistic time to check it.

Automation bias

The tendency to accept a system's output because it came from the system, and to under-weigh contradicting evidence.

Audit logging

A durable record of what the system did: inputs used, model and version, output produced, who reviewed it and what action followed.Audit logging is what makes an incident reconstructable months later. It is the practical core of traceability.

Monitoring

observability

Ongoing measurement of a live system — inputs, outputs, performance, override rates and workload — with named owners and stop rules.

Idempotency

A property of an operation where performing it twice has the same effect as performing it once — so retries do not create duplicates.Agent actions that write to clinical or administrative systems must be idempotent or guarded, otherwise a retried request can book or order twice.

Prompt injection

An attack where hostile instructions hidden in retrieved or user-supplied content try to override the system's own instructions.Any content the model reads — letters, web pages, patient messages — can carry injected instructions, so tool permissions must not depend on model judgement alone.

Regulation (EU)

Educational summaries of EU law, not legal advice. Checked against the primary texts between 25 August and 10 September 2026; obligations and dates change, so verify the article that governs your own case: AI Act, MDR, EHDS.

Software as a medical device (SaMD)

SaMD

Software intended for a medical purpose — diagnosis, prevention, monitoring, prediction or treatment — that is regulated as a device in its own right.The intended purpose you write down, not the technology, is what places a tool inside or outside the device route.

MDR / IVDR

The EU Medical Device Regulation and In Vitro Diagnostic Regulation — the European rules governing medical devices, including medical software.

EU AI Act

European regulation that classifies AI systems by risk and places obligations on providers and deployers accordingly.It classifies the use, not the technology, and applies alongside — not instead of — medical-device law and data-protection law.

GDPR

The EU General Data Protection Regulation, governing how personal data — including health data — may be processed.

European Health Data Space (EHDS)

EHDS

An EU framework for health data covering both access to one's own data and governed secondary use of health data for research and innovation.

DPIA

A Data Protection Impact Assessment — a GDPR-required analysis of privacy risks before processing likely to result in high risk, common for health AI.

FRIA

A Fundamental Rights Impact Assessment under Article 27 of the EU AI Act. It is not required for every high-risk deployment: the obligation falls on specified deployers of certain high-risk systems — bodies governed by public law, private entities providing public services, and deployers of the creditworthiness and life/health insurance risk-assessment uses in Annex III. For high-risk systems under Article 6(2), Article 27(1) excludes systems intended to be used in the area listed in Annex III point 2 (critical infrastructure).A public hospital deploying an in-scope high-risk system is a likely candidate; a private organisation outside those categories may not be. A FRIA complements, and does not replace, a DPIA and clinical safety assessment.

Notified body

An independent conformity-assessment body designated by an EU member state to carry out the assessment that MDR/IVDR require for certain device classes before CE marking.Not every device needs one. Simple Class I devices are generally self-declared by the manufacturer, while Class I sterile, measuring or reusable-surgical devices and the higher classes need notified-body involvement to the extent the applicable conformity-assessment route requires it. Where a notified body is involved, its capacity and timelines are a real project constraint.

CE marking

The mark showing a product conforms to applicable EU requirements — for medical software, the visible end point of the MDR conformity-assessment process, whether that route involved a notified body or manufacturer self-declaration.CE marking is anchored to a stated intended purpose and version; changing either can take the product outside what was assessed.