FHIR implementation guides by country: EU member states, AU, US, UK
There is no single FHIR. This hub maps selected EU member-state IGs plus AU Core, US Core 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, FR Core 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 of selected EU member-state programmes plus AU, US, UK and Switzerland. It is not a catalogue of all 27 EU member states. Germany 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 |
|---|---|---|---|---|
| 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 |
| France | FR Core 2.2.0 (trial-use, 25 Mar 2026); INS; CI-SIS | INS-NIR (urn:oid:1.2.250.1.213.1.4.8) |
Qualified INS via INSi, then the named CI-SIS volet | FR Core, INS and CI-SIS |
| Netherlands | MedMij + Nictiz BgZ; zib2017/STU3 vs zib2020/R4 (informatiestandaarden.nictiz.nl) | BSN (http://fhir.nl/fhir/NamingSystem/bsn) |
MedMij PHR / BgZ patient summary | MedMij, BgZ and zibs |
| Belgium | eHealth Federal Core 2.2.0; Patient Dossier 1.0.0 | SSIN / NISS-INSZ (https://www.ehealth.fgov.be/standards/fhir/core/NamingSystem/ssin) |
BePatient, then named CareSets | Belgian Federal Core |
| 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 |
| Sweden | NLL package se.electronichealth.fhir.nll.r4 1.3.1 (release 21.18, 31 Aug 2026) |
Personnummer (http://electronichealth.se/identifier/personnummer) |
National Medication List MedicationRequest / MedicationDispense | Swedish National Medication List |
| Denmark | DK Core 3.7.0 (30 May 2026); MedCom; eHealth Infrastructure 10.0.1 | CPR (urn:oid:1.2.208.176.1.2) |
MedCom message, or eHealth telemedicine API — not both as one server | DK Core and MedCom |
| Finland | Finnish Base Profiles 2.0.0 (STU 2, 5 Oct 2025) | PIC / HETU (urn:oid:1.2.246.21) |
FI Base Patient; Kanta remains largely HL7 v3 | FI Base and Kanta |
| Austria | ELGA CDA/IHE in production; HL7 AT Core R4 2.0.0 (STU2) | Social security number (urn:oid:1.2.40.0.10.1.4.3.1) |
ELGA document query (XDS / CDA), not a FHIR EHR | ELGA and Austrian FHIR |
| Italy | IT Core 0.2.0 (STU, 2026); FSE 2.0 still CDA | Codice fiscale (http://hl7.it/sid/codiceFiscale) |
FSE document feed (CDA R2); FHIR for IT Core / telemedicine IGs | IT Core and FSE |
| 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 |
| 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 |
| 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 |
Spain omitted: no single national FHIR IG to pin. ÚNICAS is a rare-diseases draft, not an SNS core. Do not treat regional EHR fragmentation as a national FHIR contract.
Canonical URLs for IGs this cluster implements against (member-state articles hold the rest):
- HL7 Europe Base/Core:
http://hl7.eu/fhir/base/ImplementationGuide/hl7.fhir.eu.base(v2.0.0) - FR Core:
https://hl7.fr/ig/fhir/core/ImplementationGuide/hl7.fhir.fr.core(v2.2.0) - ISiK:
https://gematik.de/fhir/isik/(Stufe 5 published 1 July 2025) - AU Core:
http://hl7.org.au/fhir/core/ImplementationGuide/hl7.fhir.au.core(v2.0.0) - US Core:
http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core(v9.0.0) - 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. A French CI-SIS volet is not “close enough” to ISiK because both use Patient.
- Separate identity from clinical content. INS-NIR, BSN, SSIN, KVNR, personnummer, CPR, HETU, Austrian SSNr, codice fiscale, IHI, NHS number and USCDI demographics 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. MedMij is patient/PHR exchange. NLL is the Swedish medication list. ELGA production is still document exchange. 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, ANS, MedMij 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
- France — FR Core, INS and CI-SIS: French FHIR layers
- Netherlands — MedMij, BgZ and zibs: Dutch FHIR layers
- Belgium — Federal Core and Patient Dossier: Belgian FHIR
- Sweden — National Medication List: NLL FHIR
- Denmark — DK Core and MedCom: Danish FHIR
- Finland — FI Base and Kanta: Finnish FHIR
- Austria — ELGA versus FHIR: Austrian FHIR
- Italy — IT Core and FSE: Italian FHIR
If you need help pinning an IG version, mapping identifiers, or designing the hybrid v2-plus-FHIR path that most hospitals still run, start a project. That is the digital health interoperability work I do.