Module 2 · 60 min · 2 chapters
Anatomy, Tools & Healthcare Integrations
Two chapters. First the parts you are actually buying or building: model and orchestrator, instructions and policies, governed knowledge, memory versus workflow state, identity and permissions, tracing, and when a second agent helps. Then how agents act through systems: tool contracts and schemas, read versus write, FHIR and EHR integration at leader level, provenance, least privilege, idempotency and safe failure.
The hook · Harbour Day Surgery
Open the hood: the model is one component of many
A fictional day-surgery team prepares roughly sixty upcoming patients a week across four systems. What determines whether an agentic version of that work is safe, useful and auditable is almost never the model — it is everything drawn around it.
Architecture
The Clinical AI System
The shared mental model for this course. Select a layer to expand it; later sections mark where they sit.
An agent is not just an LLM with tools. It is a system. The application layer around a model is often called a “harness”. It is useful industry shorthand, not a formal technical standard — expect the boundaries to be drawn differently from team to team.
One pass of pre-procedure coordination, drawn as components rather than as a chat.
- 01
Trigger & goal
Procedure in 10 days; make the case ready
- 02
Orchestrator
Runs the loop, picks what is allowed
- 03
Context & policy
Approved instructions, case facts, rules
- 04
Tools
Read the EHR, look up slots, send a template
- 05
State
What is done, waiting, due, chased
- 06
Verify & trace
Gate outcome, result, record
- 07
Human escalation
Anything clinical or ambiguous
Read left to right, then down. The model sits inside the orchestrator box, proposing the next step. Every property you can enforce — what is reachable, what is checked, what is recorded, where it stops — lives in the other boxes. The final node is amber because clinical judgement leaves the system entirely.
What good could look like
Fewer manual re-checks of who still needs what, work-in-progress that is visible as a queryable record rather than in two coordinators’ heads, routine preparation information going out on time and in the right version, and people spending their attention on the exceptions.
These are potential operational benefits to test in your own setting — not guaranteed performance, savings or clinical outcomes.
Boundary
Diagnosis, interpretation of new symptoms, medication changes and fitness to proceed stay with clinicians. This module designs the machinery around administrative coordination only.
Six diligence questions that separate a proposal from a demo
1. Which tools exist, and which are side-effecting?
2. Under what identity does it act, with which scopes?
3. What state does it keep, and can a human inspect it?
4. Which rules are enforced deterministically?
5. Can I reconstruct a specific run afterwards?
6. What makes it stop?
Notice what is absent from the list: “which model?” It is a real decision that moves quality, but it is rarely the one that determines exposure.
Why the architecture, not the model, carries the properties you care aboutThe longer argument, including one honest limit on what good architecture can achieve.
From Module 1, you already have the operational mental model: a system can pursue a goal across steps, choose among allowed actions, hold state and stop or escalate within a boundary. This module moves one layer underneath that idea. The proposal on your desk is an architecture, and almost every property you care about is a property of the architecture rather than of the model inside it.
The single most common misreading in procurement is treating model choice as the decision. It is a real decision, and it moves quality. But two organisations running the identical model can end up with completely different exposure, because one exposed four narrow read tools under a scoped identity with a deterministic gate on every outbound message, and the other exposed a general-purpose EHR write capability under a shared service account with the boundary written in a prompt. Reliability in production is mostly a property of the surrounding system: tool design, state, permissions, deterministic checks, retries, budgets, stop conditions and observability.
So the diligence questions that separate a serious proposal from a demo are structural. Which tools can it call, and which of those change something? Under what identity, with what scopes? What state does it keep, where, and can a human read it? Which rules are enforced in code rather than requested in text? Can I reconstruct a run six weeks later when someone complains? 'Which model?' rarely makes the top of that list.
One honest limit before we start. Good architecture does not make a probabilistic system deterministic. The model will still occasionally choose a reasonable-looking wrong step. What the surrounding system does is constrain what a wrong step can lead to, catch a class of them before they take effect, recover from failures, and leave a record that lets you find out. Constraining consequences and removing uncertainty are different achievements, and any vendor who conflates them is telling you something about their engineering culture.
The honest limit
Architecture constrains what a wrong step can lead to, catches a class of errors before they take effect, and leaves a record. It does not make a probabilistic system deterministic. Constraining consequences and removing uncertainty are different achievements.
Fictional educational case. Harbour Day Surgery, its systems, policies and volumes are invented for teaching purposes and do not describe any real organisation. Nothing here is clinical, legal or procurement advice.
Sources & evidence · 8 sources
This module cites public or consensus guidance, scholarly literature, vendor documentation.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
OpenAI, A practical guide to building agents (2025).
The clearest vendor description of the component split used in this module — model, instructions, tools, orchestration and guardrails — with concrete patterns for tool design. It describes how these systems are commonly built; it is not a neutral standard.
Open sourceAnthropic, Building effective agents (19 December 2024).
A useful vendor engineering perspective supporting the simplest architecture that works, with added components justified explicitly; not independent evidence or a neutral taxonomy.
Open sourceXinzhe Li. A Review of Prominent Paradigms for LLM-Based Agents: Tool Use, Planning (Including RAG), and Feedback Learning. Proceedings of COLING 2025, pages 9760–9779.
Independent survey offering a unified taxonomy across tool use, planning and feedback-learning paradigms. Architecture background; it does not show that any single- versus multi-agent decomposition is universally optimal.
Open sourceNIST AI 600-1, AI Risk Management Framework: Generative AI Profile.
General risk-management and monitoring background. It is not an agent architecture specification and does not address tool use, permissions or tracing directly — read it as framing for the observability and governance discussion, not as a control set.
Open sourceModel Context Protocol — specification, protocol revision 2026-07-28 (released 28 July 2026).
The official description of MCP clients, servers, tools, resources and prompts. Read it as an integration standard: it defines how capability is exposed and discovered, not whether using that capability is authorised or safe. Revision-pinned; checked 10 September 2026.
Open sourceA2A (Agent2Agent) Protocol v1.0.0 (announced 12 March 2026).
The official specification for communication between independent agent systems. Useful for the agent-to-agent axis; it takes no position on whether a multi-agent design is warranted. Version-pinned; checked 10 September 2026.
Open sourceAnthropic, Effective context engineering for AI agents (2025).
Vendor engineering guidance on curating what enters the model's context at each step, and why more context is not automatically better.
Open sourceAnthropic, Equipping agents for the real world with Agent Skills (2025).
Vendor description of packaging procedural knowledge as loadable skills. Helpful for the vocabulary; not a standard and not a substitute for tool permissions.
Open source
Sources & evidence · 12 sources
This module cites standards and specifications, public or consensus guidance, scholarly literature, vendor documentation.
Content reviewed: September 2026. Publication dates of the individual sources are shown in each citation.
OpenAI, A practical guide to building agents (2025).
The clearest vendor description of the component split used in this module — model, instructions, tools, orchestration and guardrails — with concrete patterns for tool design. It describes how these systems are commonly built; it is not a neutral standard.
Open sourceAnthropic, Building effective agents (19 December 2024).
A useful vendor engineering perspective supporting the simplest architecture that works, with added components justified explicitly; not independent evidence or a neutral taxonomy.
Open sourceXinzhe Li. A Review of Prominent Paradigms for LLM-Based Agents: Tool Use, Planning (Including RAG), and Feedback Learning. Proceedings of COLING 2025, pages 9760–9779.
Independent survey offering a unified taxonomy across tool use, planning and feedback-learning paradigms. Architecture background; it does not show that any single- versus multi-agent decomposition is universally optimal.
Open sourceNIST AI 600-1, AI Risk Management Framework: Generative AI Profile.
General risk-management and monitoring background. It is not an agent architecture specification and does not address tool use, permissions or tracing directly — read it as framing for the observability and governance discussion, not as a control set.
Open sourceModel Context Protocol — specification, protocol revision 2026-07-28 (released 28 July 2026).
The official description of MCP clients, servers, tools, resources and prompts. Read it as an integration standard: it defines how capability is exposed and discovered, not whether using that capability is authorised or safe. Revision-pinned; checked 10 September 2026.
Open sourceA2A (Agent2Agent) Protocol v1.0.0 (announced 12 March 2026).
The official specification for communication between independent agent systems. Useful for the agent-to-agent axis; it takes no position on whether a multi-agent design is warranted. Version-pinned; checked 10 September 2026.
Open sourceAnthropic, Effective context engineering for AI agents (2025).
Vendor engineering guidance on curating what enters the model's context at each step, and why more context is not automatically better.
Open sourceAnthropic, Equipping agents for the real world with Agent Skills (2025).
Vendor description of packaging procedural knowledge as loadable skills. Helpful for the vocabulary; not a standard and not a substitute for tool permissions.
Open sourceHL7 International. FHIR R5 (v5.0.0, STU) — current published release.
The authoritative definition of FHIR resources, exchange formats and RESTful API patterns, including profiling. R5 is the current published release; R4 and R4B remain in production use — verify the release implemented by the local system. It defines the standard; it does not describe what any local implementation actually exposes. Release-pinned; checked 10 September 2026.
Open sourceOWASP. GenAI Security Project — agentic security guidance (moving community resource).
Community guidance on risks introduced by tool use, excessive agency and untrusted content in LLM applications. Useful for control design; not a certification or compliance framework. The project page is continuously updated rather than versioned; checked 10 September 2026.
Open sourceHL7 SMART App Launch.
The OAuth-based authorisation, authentication and launch-context specification for apps integrating with FHIR systems. Read scopes and launch context as the access-control layer FHIR alone does not provide. Checked 10 September 2026.
Open sourceHL7 CDS Hooks Implementation Guide v2.0.1 (STU 2 Release 2, R4 IG).
Defines workflow-triggered calls from an EHR to external decision-support services, and the optional SMART app link. A CDS integration pattern, not a general agent protocol. Current official IG is v2.0.1, STU 2 Release 2 (R4 IG); checked 10 September 2026. Note: the URL is the moving current IG page, not an immutable pinned version.
Open source