The seven generative AI patterns that actually ship in healthcare
Most healthcare AI conversations start with "what should we build?" That is the wrong question. The right one is "which of the seven proven patterns are we actually building, and why that one first?"
Generative AI in healthcare is not a blank canvas. After several years of production deployments globally, the shape of what works has converged on a small number of architectural patterns. They are well understood, increasingly well documented by hyperscale cloud vendors, and applicable to most realistic clinical and operational problems. Recognising which pattern your problem fits saves months of architectural debate and avoids the trap of building a custom solution to a solved problem.
This post walks through all seven patterns: what each one does, what data it needs, where the foundation model fits in the pipeline, and which clinical or operational question it actually answers. It is written for solution architects, engineering leads, and health tech founders making build decisions. Vendor and model choices are noted where they affect the architecture, but the patterns themselves are model-agnostic.
Why patterns matter more than models
The foundation model layer in healthcare AI is a commodity that changes every quarter. New models arrive, prices fall, capabilities improve. The retrieval pipeline, the data governance, the human-in-the-loop design, and the audit trail change far less often. Build for the pattern, swap the model when something better arrives.
Almost every clinical AI system in production today is some combination of three building blocks: a structured clinical data source (typically a FHIR-native store), a retrieval layer that pulls only the relevant context for a given question, and a foundation model that does the last-mile language work. The seven patterns below are variations on how those three blocks are wired together.
Pattern 1: Patient summarisation
What it does: Compresses a patient's full clinical record into a usable summary, often filtered by clinical question or care episode.
Primary user: Clinician, ahead of or during a consultation.
Data flow: FHIR resources plus unstructured clinical notes are pulled from the source store. A retrieval step extracts the relevant subset for the question being asked. The foundation model produces the summary, typically structured by sections (history of present illness, medications, allergies, recent observations, plan).
Where it fits: This is the single most common starting point for clinical AI, and for good reason. The risk profile is low (the clinician reads the summary, the AI is not making decisions), the time saved is high (5 to 15 minutes per patient is realistic), and the failure mode is graceful (a poor summary is obvious to a trained clinician).
Implementation note: Long patient histories often exceed model context windows. The standard solution is to chunk the record, summarise each chunk, then summarise the summaries. This map-reduce style of summarisation is well supported by orchestration libraries and is the right default for any record that does not fit in a single prompt.
Pattern 2: Longitudinal patient record narrative
What it does: Generates a continuous, time-ordered narrative across a patient's entire history: medications, appointments, procedures, observations, and visits.
Primary user: Clinician, patient, or payer, depending on access controls.
Data flow: All relevant FHIR resources for a patient are pulled, ordered chronologically, and passed to the foundation model with a prompt that asks for a narrative summary. The output is typically a structured timeline or longitudinal view.
Where it fits: This pattern is most useful when a patient has been seen by multiple providers across multiple settings and no single clinician has the full picture. It is also the foundation for patient-facing portal experiences, where the patient wants to understand their own history.
Implementation note: This pattern is conceptually similar to pattern 1 but differs in scope (entire history, not a specific question) and audience (often the patient themselves). Patient-facing outputs require additional care around clinical language, plain English explanations, and disclaimers about not replacing clinical advice.
Pattern 3: Virtual assistant for clinical Q&A
What it does: Provides a conversational interface over a patient's data, with multi-turn context (chat history) preserved across questions.
Primary user: Patient (asking about their own data), provider (asking about a specific patient), or payer (asking about coverage and history).
Data flow: User asks a question. Chat history is retrieved. The original question plus chat history is passed to a foundation model that rewrites the question into a standalone form. The standalone question is embedded and used to retrieve relevant context from the patient's record. The foundation model generates the answer. Chat history is updated.
Where it fits: This pattern is the right choice when the use case is exploratory rather than report-driven. Patients asking "what was my last blood pressure reading?" or providers asking "did this patient have any reaction to penicillin?" both fit this pattern.
Implementation note: Multi-turn handling is the hard part. The naive approach (concatenating chat history and resending it) breaks down quickly. The standard pattern is to use the model itself to rewrite ambiguous follow-up questions into standalone form before retrieval.
Pattern 4: Benefits enquiry and coverage prediction
What it does: Answers coverage questions by retrieving from plan documents, configuration data, and the patient's eligibility.
Primary user: Provider or member, typically through a payer's portal or claims operations system.
Data flow: A benefits enquiry triggers retrieval from three sources: the patient's plan and benefits data, policy documents (often unstructured PDFs), and configuration data from payer systems. The foundation model synthesises these into a coverage answer with reasoning.
Where it fits: This is the most directly applicable pattern for health insurers and payers in markets where coverage rules are complex enough that providers regularly need to ask "is this procedure covered for this patient?" In Australia and New Zealand the pattern applies to private health insurance, ACC determinations, and pharmaceutical benefits enquiries.
Implementation note: Policy documents are notoriously hard to retrieve from cleanly because exclusions and conditions are scattered across the document. Hierarchical chunking (preserving section context) typically outperforms naive chunking.
Pattern 5: Quality measure calculation
What it does: Computes care-quality measures across a patient population by combining structured clinical data with measure definitions.
Primary user: Care management team, quality and accreditation staff, or population health analysts.
Data flow: Patient resources (typically Patient, Observation, Condition, Procedure) are retrieved from the FHIR store. Measure definitions (for example, "hypertensive patients aged 18 to 85 with blood pressure controlled below 140/90") are stored in a vector database. The foundation model evaluates each patient against the measure criteria, producing a calculated measure result and an explanation.
Where it fits: In the US this pattern is anchored to HEDIS measures. In Australia and New Zealand the equivalent applications are Primary Health Network quality indicators, RACGP standards, and Health Quality and Safety Commission measures. The pattern is the same regardless of which measure framework is in play.
Implementation note: This is one of the few patterns where structured measure logic (the math) and generative AI (the explanation and edge-case handling) work together. The model is not calculating the measure; it is reasoning about whether a patient's data satisfies the criteria, with the actual calculation handled by code.
Pattern 6: Clinical decision support
What it does: Surfaces evidence-based recommendations at the point of care, grounded in the patient's data, clinical guidelines, and medical literature.
Primary user: Clinician, in workflow.
Data flow: Patient data is retrieved from the FHIR store. Clinical guidelines (local and international) are retrieved from a vector store. The foundation model synthesises recommendations and provides reasoning with citations back to the source guidelines. Recommendations are reviewed by the clinician before action.
Where it fits: This is the highest-clinical-risk pattern in the seven, and also the one with the most potential value. It is also the pattern most likely to be regulated as software as a medical device by the TGA in Australia or treated as a medical device under New Zealand's Medsafe framework.
Implementation note: This pattern absolutely requires human-in-the-loop review and a transparent audit trail. The model output is an input to clinical judgment, not a replacement for it. AHPRA professional guidance in Australia is explicit on this point.
Pattern 7: Prior authorisation (drafting and auto-approval)
What it does: Either drafts prior authorisation notification letters (lower risk) or makes auto-approval decisions on pre-authorised request types (higher risk).
Primary user: Payer operations, with downstream impact on providers and members.
Data flow (drafting): Authorisation decision, member plan and benefits, and clinical context are pulled together. The foundation model generates a notification letter explaining the decision in clear language.
Data flow (auto-approval): Provider submits a request. Clinical data is retrieved from the FHIR store. Plan and benefits data is retrieved. The foundation model evaluates the request against policy rules and either approves it or routes it for human review.
Where it fits: Drafting is straightforward and adds clear value. Auto-approval is far more sensitive and almost always requires a human-in-the-loop fallback for anything outside a tightly defined set of low-risk request types.
Implementation note: Auto-approval pipelines need explicit confidence thresholds and well-defined escalation paths. The pattern only works if the cost of incorrect approval (or denial) is well understood and the human review path is robust.
Choosing the right pattern: a decision framework
The seven patterns are not interchangeable. A useful way to think about which to start with is to plot them on two axes: clinical risk if the AI gets it wrong, and time or cost saved when it gets it right.
Patterns with low clinical risk and high value (patient summarisation, longitudinal record narrative, benefits enquiry) are the right place to start. They are well understood, the failure modes are graceful, and they return time to clinicians or members within weeks of deployment.
Patterns with high clinical risk and high value (clinical decision support, prior authorisation auto-approval) are worth building, but only after the lower-risk patterns are in production and the organisation has built up the governance, audit, and human-in-the-loop capabilities that the higher-risk patterns demand.
Patterns with high risk and low value should be avoided as first deployments, regardless of how interesting they are technically.
What ties all seven patterns together
Three things are common to every pattern in production:
Retrieval is the privacy boundary. The model should only see what the retrieval step gave it. If retrieval is loose, privacy is loose. Every pattern relies on this.
The FHIR store is the source of truth. Whether the store is AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API, or a self-managed FHIR server, the principle is the same: structured, interoperable, queryable patient data is the foundation of every healthcare AI workflow worth building.
The foundation model is the most replaceable component. Build the pipeline so the model can be swapped without re-architecting the retrieval layer, the data flow, or the audit trail. The model will change. Everything around it should not have to.
Healthcare AI is not magic, and the patterns that work are not secret. Recognise which of the seven your problem fits, get the retrieval boundary right, design the human-in-the-loop properly, and the technology question becomes far less daunting than it looks from the outside.
Easycoder is an AWS Advanced Partner working with healthcare providers, payers, and health technology companies across Australia and New Zealand on cloud, AI, and regulatory technology. If you are evaluating which of the seven patterns to build first, get in touch.
