FHIR implementation guides by country: AU Core, EU Core, US Core, ISiK, UK Core
There is no single FHIR. This hub maps AU Core, EU Core, US Core, ISiK and UK Core to the identifier and first workflow each market actually requires.
Ala Ben Aicha
Direct answer
There is no single FHIR. National IGs constrain resources, identifiers and search. Choose the IG for each market, then map country identifiers before you map Observation.
Why a generic R4 server is not a national product
FHIR R4 is a toolkit. A national implementation guide (IG) is a contract: which profiles are in scope, which identifier systems are valid, which search parameters must work, and which terminology bindings are expected. AU Core, HL7 Europe Base/Core, US Core, ISiK and UK Core all sit on FHIR R4, but they do not accept the same Patient.
I build HealthTech integrations for hospitals and vendors that sell into more than one of these markets. The first architectural question is not “do we support FHIR?”. It is “which IG is the buyer’s conformance target, and which identifier does every downstream feed have to carry?”
This page is a map. The five country articles hold the versions, canonical URLs and workflow notes. Switzerland is already covered on this site; it is linked from the table rather than duplicated.
National IGs at a glance
| Country / region | IG (named version) | Identifier to implement first | First workflow | Insight |
|---|---|---|---|---|
| Australia | AU Core R2 2.0.0 (28 Jan 2026); AU eRequesting R1 | Individual Healthcare Identifier (http://ns.electronichealth.net.au/id/hi/ihi/1.0) |
Community pathology / imaging request | AU Core implementation |
| European Union | HL7 Europe Base and Core 2.0.0 | EEHRxF category (patient summary and ePrescription first), plus each member-state identifier | Category 1 primary-use payload | EU Core and EHDS |
| United States | US Core 9.0.0 (USCDI v6 mapping) | USCDI Patient Demographics class on US Core Patient | TEFCA document query, then Facilitated FHIR | US Core and TEFCA |
| Germany | ISiK (https://gematik.de/fhir/isik/); not MIO, MII or HL7 DE |
Versicherten-ID / KVNR (http://fhir.de/sid/gkv/kvid-10) |
Hospital REST read/search (ISiK Basis) | ISiK, MIO and German FHIR |
| United Kingdom | FHIR UK Core R4 (STU2 sequence) | NHS number (https://fhir.nhs.uk/Id/nhs-number) |
PDS lookup, then the catalogue API for the use case | UK Core and NHS APIs |
| Switzerland (existing) | CH EPR FHIR; CH Core | EPR-SPID (urn:oid:2.16.756.5.30.1.127.3.10.3); AHV/AVS is a different identifier |
Community document query (MHD / XDS) | Swiss EPD integration |
Canonical URLs for the five IGs this cluster implements against:
- AU Core:
http://hl7.org.au/fhir/core/ImplementationGuide/hl7.fhir.au.core(v2.0.0) - HL7 Europe Base/Core:
http://hl7.eu/fhir/base/ImplementationGuide/hl7.fhir.eu.base(v2.0.0) - US Core:
http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core(v9.0.0) - ISiK:
https://gematik.de/fhir/isik/(Stufe 5 published 1 July 2025) - UK Core Patient:
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient
Do not copy profile text from those IGs into a sales deck. Pin the package version, validate examples against that version, and keep national identifier systems out of a shared “global Patient” model.
How to choose an IG when you sell into two markets
Treat each market as a profile pack and an identifier pack, not as a locale string.
- Name the buyer’s IG. A US health system that already exposes US Core is not a European Base/Core opportunity. An Australian diagnostic requester is not “close enough” to ISiK because both use ServiceRequest.
- Separate identity from clinical content. IHI, NHS number, KVNR, USCDI demographics and EPR-SPID are not interchangeable
identifier.valuestrings. If you collapse them, matching and consent break before Observation mapping starts. - Pick the first workflow the IG actually governs. AU eRequesting is community diagnostic requesting. ISiK is a hospital interface. TEFCA is network exchange, still hybrid with documents. UK catalogue APIs (PDS, EPS, e-RS, BaRS, MESH) are separate products from UK Core profiles.
- Do not dual-profile one FHIR server as “EU + US” without a router. The EU Core vs US Core comparison is the place to see why Patient extensions, terminology and must-support sets diverge.
If the second market is Switzerland, start from the EPD article rather than from EU Core. CH Core and CH EPR FHIR are Swiss contracts, not a member-state overlay of HL7 Europe.
What this page is not
This page is not a conformance certificate, an Inferno or gematik test report, or legal advice. Listing an IG here does not mean a product is certified, assured, or permitted to process health data in that country. National programmes change package versions; read the canonical IG and the current onboarding rules before you bid. I do not issue ISiK, ONC, NHS or EHDS certificates, and nothing on this site is a substitute for counsel or for the buyer’s own conformity assessment.
How to use the cluster
- Implementing Australia, including IHI and eRequesting: AU Core R2
- Implementing EHDS primary-use payloads on HL7 Europe Base/Core: EU Core and EHDS
- Implementing USCDI on US Core and TEFCA exchange: US Core and TEFCA
- Distinguishing ISiK from MIO, MII and HL7 DE: German FHIR families
- Wiring UK Core to PDS, EPS, e-RS, BaRS and MESH: UK Core and NHS APIs
If you need help pinning an IG version, mapping identifiers, or designing the hybrid v2-plus-FHIR path that most hospitals still run, that is the digital health interoperability work I do.