EU Core vs US Core FHIR: What Changes When You Build for the European Market

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:

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.

// 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:

// 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.