# EU Core vs US Core FHIR: What Changes When You Build for the European Market > A practical comparison of EU Core and US Core FHIR profiles — the key differences in patient identification, terminology, extensions, and implementation patterns that developers encounter when building for both markets. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/eu-core-vs-us-core-fhir-comparison Updated: 2026-10-05 ## Introduction If you have built FHIR-based healthcare applications for the US market, you are likely familiar with US Core — the HL7 FHIR profile that defines the baseline expectations for FHIR implementations in the United States. When you expand to the European market, you encounter **EU Core** (formally the European FHIR Implementation Guide) and a landscape of national profiles that work differently in subtle but important ways. This guide compares the implementation contracts used in US and European settings. Profile support does not itself establish access to a national exchange network. ## The Profile Landscape In the US, the FHIR profile hierarchy is relatively straightforward: ``` FHIR R4 Base └── US Core (HL7 US Core IG) └── Implementation-specific profiles (Da Vinci, CARIN, Argonaut, etc.) ``` In Europe, it is more layered: ``` FHIR R4 Base └── International Patient Summary (IPS) └── EU Core (European baseline) └── National Profiles ├── CH Core (Switzerland) ├── DE Core (Germany) ├── FR Core (France) ├── NL Core (Netherlands) ├── BE Core (Belgium) └── ... (other countries) └── Implementation-specific profiles ``` This means that building for "Europe" is not a single target — it is a base profile (EU Core) plus country-specific adaptations. Understanding this layering is the first architectural decision you need to make. ## Key Differences ### 1. Patient Identification **US Core** relies heavily on: * Medical Record Number (MRN) — hospital-assigned identifiers * Social Security Number (used sparingly, for matching) * Health plan identifiers * Driver's license numbers **EU Core and national profiles** use fundamentally different identifiers: | Country | Primary Identifier | System OID/URI | | ----------- | -------------------------------- | -------------------------------------------------------------- | | Switzerland | AHV/OASI Number | urn:oid:2.16.756.5.32 | | Germany | Krankenversichertennummer (KVNR) | | | France | NIR (Numéro de Sécurité Sociale) | urn:oid:1.2.250.1.213.1.4.8 | | Netherlands | BSN (Burgerservicenummer) | | | Belgium | NISS/INSZ | | | Austria | Sozialversicherungsnummer (SVNR) | urn:oid:1.2.40.0.10.1.4.3.1 | If your system handles patients from multiple European countries, you need to support **multiple national identifier systems** simultaneously. This is architecturally different from the US, where MRN + insurance ID covers most cases. ```typescript // US Core Patient — single identifier system is common const usPatient = { resourceType: 'Patient', identifier: [ { system: 'http://hospital.example.org/mrn', value: 'MRN-12345' } ] }; // EU Patient — multiple national identifiers const euPatient = { resourceType: 'Patient', identifier: [ { system: 'urn:oid:2.16.756.5.32', // Swiss AHV value: '756.1234.5678.90' }, { system: 'http://fhir.de/sid/gkv/kvid-10', // German KVNR value: 'A123456789' } ] }; ``` ### 2. Terminology Differences This is where the biggest practical divergence lies. **US Core mandates:** * **RxNorm** for medications * **ICD-10-CM** for diagnoses (US clinical modification) * **CPT** for procedures * **LOINC** for lab observations * **SNOMED CT** (US Edition) for clinical findings **EU Core / National profiles use:** * **ATC** (Anatomical Therapeutic Chemical) for medication classification — not individual medication coding * **National drug codes** for specific medications (PZN in Germany, CIP in France, GTIN in Switzerland) * **ICD-10** (WHO version or national extensions like ICD-10-GM) * **SNOMED CT** (International Edition) — but adoption varies dramatically by country * **LOINC** for lab observations (consistent with the US) * **National procedure codes** (OPS in Germany, CCAM in France, CHOP in Switzerland) The medication coding difference is the most impactful. In the US, a medication order references a specific RxNorm code that identifies the exact drug, dose form, and strength. In Europe, there is no single equivalent. You need to handle both the ATC therapeutic classification and the country-specific drug identifier. ### 3. Extensions and Must-Support Elements **US Core** defines `mustSupport` elements that US EHR systems must be able to send and receive. Key examples: * `Patient.race` and `Patient.ethnicity` — US-specific extensions required by US Core * `Patient.birthsex` — administrative sex at birth **EU Core** does not include race or ethnicity extensions (collecting this data is restricted or prohibited in many EU countries under anti-discrimination laws). Instead, EU and national profiles add: * **Nationality** extensions — relevant for cross-border care eligibility * **Insurance coverage** extensions — mapped to national health insurance systems * **Language** preferences — more critical in multilingual Europe * **Cantonal/regional** extensions — in federated systems like Switzerland ### 4. Document Profiles **US Core** aligns with the **US Realm C-CDA** (Consolidated Clinical Document Architecture) for document exchange. **EU Core** aligns with the **International Patient Summary (IPS)** for cross-border document exchange. The IPS includes: * A defined `Composition` structure with required sections * Mandatory `Coding` from international terminologies * Required sections: medications, allergies, conditions, immunizations * Optional sections: procedures, diagnostic results, medical devices Key structural difference: ```typescript // US Core DocumentReference — references a C-CDA document { resourceType: 'DocumentReference', type: { coding: [{ system: 'http://loinc.org', code: '34133-9', display: 'Summarization of episode note' }] }, content: [{ attachment: { contentType: 'application/hl7-v3+xml', // C-CDA url: '/Binary/cda-document-123' } }] } // EU/IPS — FHIR Document Bundle { resourceType: 'Bundle', type: 'document', entry: [ { resource: { resourceType: 'Composition', type: { coding: [{ system: 'http://loinc.org', code: '60591-5', display: 'Patient summary Document' }] }, section: [ // Medications, Allergies, Conditions, etc. ] } } ] } ``` ### 5. Authentication and Authorization **US Core** implementations typically use **SMART on FHIR** (OAuth2-based) for application authorization. Epic, Cerner, and other US EHRs support SMART launch sequences. **European systems** use a mix of: * **SMART on FHIR** — gaining adoption, especially in newer implementations * **IHE IUA** (Internet User Authorization) — OAuth2-based profile used alongside IHE MHD * **SAML 2.0 / XUA** — still dominant in IHE-based infrastructure (Swiss EPD, Austrian ELGA) * **eIDAS** — the EU electronic identification framework for citizen authentication In practice, you will likely need to support multiple authentication mechanisms depending on which European systems you integrate with. ### 6. Conformance and Testing **US Core** conformance is tested through: * **ONC Health IT Certification Program** — mandatory for EHR vendors * **Inferno testing** — the standard conformance testing tool * **SMART App Gallery** — ecosystem of certified apps **EU conformance** varies by country: * **IHE Connectathon** — cross-vendor interoperability testing (annual European events) * **Gazelle** — the IHE conformance testing platform * **National certification** — each country has its own certification process (e.g., Swiss EPD certification, German gematik approval) * **EHDS certification** — coming by March 2027 for EHR systems ## Practical Recommendations ### Building a Dual-Market Application If you need to support both US and EU markets, here is the architecture pattern I use: ``` Application Logic │ ▼ ┌──────────────────────┐ │ FHIR Abstraction │ │ Layer │ │ ┌────────────────┐ │ │ │ Profile Router │ │ ◄── Selects profile based on jurisdiction │ └────────────────┘ │ │ ┌────────┬────────┐ │ │ │US Core │EU Core │ │ │ │Adapter │Adapter │ │ │ └────────┴────────┘ │ │ ┌────────────────┐ │ │ │ Terminology │ │ ◄── Maps between code systems │ │ Mapping │ │ │ └────────────────┘ │ └──────────────────────┘ │ ▼ FHIR Server / EHR API ``` Key design decisions: 1. **Abstract the profile layer** — your core application logic should work with a common internal model, not directly with US Core or EU Core resources 2. **Build terminology mapping** — invest in bidirectional mapping between RxNorm/ATC, ICD-10-CM/ICD-10, SNOMED CT editions 3. **Configure identifiers per deployment** — patient identifier systems must be configurable, not hardcoded 4. **Handle authentication per market** — SMART on FHIR for the US, SMART + XUA/IUA for Europe ### Use the IPS as Your Lingua Franca The International Patient Summary (IPS) is designed to be jurisdiction-neutral. If you need a single document format that works across both markets, the IPS is the best choice. Both US Core and EU Core can map to and from IPS. ## Conclusion Moving from US Core to EU Core FHIR is not just a profile swap — it requires rethinking patient identification, terminology, authentication, and document standards. The European landscape is more fragmented (multiple national profiles under the EU Core umbrella), but the EHDS is pushing toward convergence. Developers who understand both markets and can build flexible, profile-aware architectures will be well-positioned as healthcare becomes increasingly global. If you are expanding a FHIR-based application to the European market and need guidance on profile adaptation, I am happy to help.