FHIR Pattern Languages

Introduction

FHIR has become the practical integration substrate for health information exchange across jurisdictions, vendors, and care settings. Yet engineering effort remains high as teams repeatedly solve similar problems in authoring FHIR specifications and building distributed integration architectures.

These pattern languages capture proven practice as structured, reusable guidance. Each pattern documents recurring problems, the forces that shape solutions, and the trade-offs involved. Patterns are linked into navigable networks that support decision-making across the full lifecycle of FHIR-based systems.

Three Pattern Languages

FHIR Implementation Patterns

Focuses on building distributed systems that exchange FHIR reliably across organizational and technical boundaries. Includes patterns for integration components and message flows—capability facades, asynchronous invocation, brokered messaging, legacy adapters, and imaging bridges—together with forces and trade-offs that guide selection and adaptation.

FHIR Authoring Patterns

Focuses on producing and maintaining high-quality FHIR specifications. Targets governance and delivery practices around profiles and extensions, terminology strategy and layering, implementation guide build and release pipelines, and pragmatic conformance checkpoints and validation gates. Makes specification work more repeatable, easier to review, and easier to sustain.

IG Authoring Patterns

Focused patterns for authoring FHIR Implementation Guides with build pipelines, validation gates, and publication workflows. Addresses the practical concerns of IG development teams working with FHIR tooling and continuous integration.

Background

Based on research by Jörn Guy Süß (CSIRO), Michael Osborne (CSIRO), John Carter (HL7 New Zealand)

Problem Statement

Digital health integration programmes face recurring problems. Similar integration and specification decisions are revisited across projects, teams, and vendors, often with limited explicit rationale. Specialised expertise in terminology, implementation guide tooling, interoperability testing, and integration architecture is not always available when decisions must be made. Solutions that are not designed with explicit forces and trade-offs can become brittle when requirements or organisational boundaries change.

Patterns as a Response

Architectural and process patterns provide a structured way to capture recurring solutions to recurring problems, including the forces that shape those solutions and the trade-offs they entail. A pattern language links patterns into a navigable set that supports decision-making across a lifecycle.

Each pattern is expressed with a consistent structure—problem context, forces, solution, and consequences—and is complemented by diagrams and code-oriented guidance where appropriate. Patterns make design forces explicit, support reuse of recurring design insights, and provide a shared vocabulary for communication across teams and vendors.

Pattern Language Structure

A pattern language is not a flat catalogue; it is a structured network that helps readers navigate from context to decision. Each pattern makes the forces explicit—the tensions that must be balanced in a given context (for example, timeliness versus consistency, central control versus local autonomy, or simplicity versus flexibility).

Patterns are grouped into categories that represent coherent decision areas. Relationships between patterns make the language actionable: some patterns depend on or use others as building blocks, forming typical solution stacks. Other relationships capture alternatives and complements.

Methods: Model-Driven Publication

Pattern content is treated as structured data rather than as a single rendered document. Pattern languages are authored in a machine-readable form and converted into an explicit model, enabling repeatable transformations into different output formats—including static websites, EPUB, and DocBook XML.

The repository implements a staged pipeline: (1) author and validate the pattern language, (2) materialise a stable EMF/XMI model, (3) render diagrams and other assets, and (4) generate self-contained deployment projects for multiple output formats. This approach aligns to model-driven engineering practices where models serve as a primary artefact and generators produce multiple views.