EU Core vs US Core FHIR : quels changements lorsque vous construisez pour le marché européen

Introduction

Si vous avez créé des applications de santé basées sur FHIR pour le marché américain, vous connaissez probablement US Core, le profil HL7 FHIR qui définit les attentes de base pour les implémentations FHIR aux États-Unis. Lorsque vous vous développez sur le marché européen, vous rencontrez EU Core (anciennement le guide européen de mise en œuvre du FHIR) et un paysage de profils nationaux qui fonctionnent différemment de manière subtile mais importante.

Ce guide compare les contrats d’implémentation américains et européens. La prise en charge d’un profil ne donne pas à elle seule accès à un réseau national d’échange.

Le paysage des profils

Aux États-Unis, la hiérarchie des profils FHIR est relativement simple :

FHIR R4 Base
  └── US Core (HL7 US Core IG)
        └── Implementation-specific profiles
              (Da Vinci, CARIN, Argonaut, etc.)

En Europe, la situation est plus complexe :

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

Cela signifie que la construction de « l’Europe » n’est pas un objectif unique : il s’agit d’un profil de base (EU Core) auquel s’ajoutent des adaptations spécifiques à chaque pays. Comprendre cette superposition est la première décision architecturale que vous devez prendre.

Différences clés

1. Identification Patient

US Core s'appuie fortement sur :

• Numéro de dossier médical (MRN) – identifiants attribués par l’hôpital
• Numéro de sécurité sociale (utilisé avec parcimonie, pour faire correspondre)
• Identifiants du plan de santé
• Numéros de permis de conduire

Profils de base et nationaux de l’UE utiliser des identifiants fondamentalement différents :

Si votre système traite des patients de plusieurs pays européens, vous devez prendre en charge plusieurs systèmes d'identification nationaux simultanément. Ceci est architecturalement différent des États-Unis, où MRN + assurance ID couvre la plupart des cas.

// 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. Différences terminologiques

C’est là que réside la plus grande divergence pratique.

Mandats américains de base :

• Norme Rx pour les médicaments
• CIM-10-CM pour les diagnostics (modification clinique américaine)
• CPT pour les procédures
• LOINC pour les observations en laboratoire
• SNOMED CT (Édition américaine) pour les résultats cliniques

Utilisation des profils de base UE/nationaux :

• ATC (Anatomical Therapeutic Chemical) pour la classification des médicaments – et non pour le codage des médicaments individuels
• Codes nationaux des médicaments pour des médicaments spécifiques (PZN en Allemagne, CIP en France, GTIN en Suisse)
• CIM-10 (Version OMS ou extensions nationales comme la CIM-10-GM)
• SNOMED CT (Édition internationale) — mais l'adoption varie considérablement selon les pays
• LOINC pour les observations en laboratoire (conforme aux États-Unis)
• Codes de procédures nationaux (OPS en Allemagne, CCAM en France, CHOP en Suisse)

La différence de codage des médicaments est la plus importante. Aux États-Unis, une ordonnance de médicament fait référence à un code RxNorm spécifique qui identifie le médicament exact, sa forme posologique et son dosage. En Europe, il n’existe pas d’équivalent unique. Vous devez gérer à la fois la classification thérapeutique ATC et l’identifiant du médicament spécifique au pays.

3. Extensions et éléments indispensables

US Core définit mustSupport éléments que les systèmes DSE américains doivent pouvoir envoyer et recevoir. Exemples clés :

• Patient.race et Patient.ethnicity — Extensions spécifiques aux États-Unis requises par US Core
• Patient.birthsex — sexe administratif à la naissance

EU Core n'inclut pas les extensions liées à la race ou à l'origine ethnique (la collecte de ces données est restreinte ou interdite dans de nombreux pays de l'UE en vertu des lois anti-discrimination). Au lieu de cela, les profils européens et nationaux ajoutent :

• Nationalité extensions — pertinentes pour l’éligibilité aux soins transfrontaliers
• Couverture d'assurance extensions — mappées aux systèmes nationaux d’assurance maladie
• Langue préférences – plus cruciales dans une Europe multilingue
• Cantonal/régional extensions — dans les systèmes fédérés comme la Suisse

4. Profils de documents

US Core s'aligne avec le Royaume des États-Unis C-CDA (Consolidated Clinical Document Architecture) pour l’échange de documents.

EU Core s'aligne avec le Résumé international Patient (IPS) pour l'échange transfrontalier de documents. L'IPS comprend :

• Une définition Composition structure avec les sections requises
• Obligatoire Coding à partir de terminologies internationales
• Sections obligatoires : médicaments, allergies, affections, vaccinations
• Sections facultatives : procédures, résultats de diagnostic, dispositifs médicaux

Différence structurelle clé :

// 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. Authentification et autorisation

US Core les implémentations utilisent généralement SMART on FHIR (basé sur OAuth2) pour l'autorisation de l'application. Epic, Cerner et d'autres DSE américains prennent en charge les séquences de lancement SMART.

Systèmes européens utiliser un mélange de :

• SMART on FHIR — de plus en plus adopté, en particulier dans les implémentations les plus récentes
• IHE IUA (Autorisation de l'utilisateur Internet) - Profil basé sur OAuth2 utilisé avec IHE MHD
• SAML 2.0 / XUA — toujours dominant dans les infrastructures basées sur l'IHE (EPD suisse, ELGA autrichienne)
• eIDAS — le cadre d'identification électronique de l'UE pour l'authentification des citoyens

En pratique, vous devrez probablement prendre en charge plusieurs mécanismes d'authentification en fonction des systèmes européens auxquels vous vous intégrez.

6. Conformité et tests

US Core la conformité est testée à travers :

• Programme de certification ONC Health IT — obligatoire pour les fournisseurs de DSE
• Tests Inferno — l'outil de test de conformité standard
• Galerie d'applications SMART — écosystème d'applications certifiées

Conformité UE varie selon les pays :

• Connectathon IHE — tests d'interopérabilité entre fournisseurs (événements européens annuels)
• Gazelle — la plateforme de tests de conformité IHE
• Certification nationale — chaque pays a son propre processus de certification (par exemple, certification EPD suisse, approbation gematik allemande)
• Certification EHDS — à venir d'ici mars 2027 pour les systèmes DSE

Recommandations pratiques

Créer une application à double marché

Si vous devez prendre en charge les marchés américain et européen, voici le modèle d'architecture que j'utilise :

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

Décisions de conception clés :

1. Abstraction de la couche de profil — la logique de votre application principale doit fonctionner avec un modèle interne commun, et non directement avec les ressources US Core ou EU Core
2. Créer une cartographie terminologique — investir dans la cartographie bidirectionnelle entre les éditions RxNorm/ATC, ICD-10-CM/ICD-10 et SNOMED CT
3. Configurer les identifiants par déploiement — les systèmes d'identification des patients doivent être configurables et non codés en dur
4. Gérer l'authentification par marché — SMART on FHIR pour les États-Unis, SMART + XUA/IUA pour l'Europe

Utilisez l'IPS comme votre Lingua Franca

Le résumé international Patient (IPS) est conçu pour être neutre en matière de juridiction. Si vous avez besoin d’un format de document unique qui fonctionne sur les deux marchés, l’IPS est le meilleur choix. US Core et EU Core peuvent être mappés vers et depuis IPS.

Conclusion

Passer du US Core au EU Core FHIR n’est pas seulement un changement de profil : cela nécessite de repenser l’identification des patients, la terminologie, l’authentification et les normes documentaires. Le paysage européen est plus fragmenté (plusieurs profils nationaux sous l’égide de l’EU Core), mais l’EHDS s’oriente vers la convergence. Les développeurs qui comprennent les deux marchés et peuvent créer des architectures flexibles et adaptées aux profils seront bien placés à mesure que les soins de santé deviennent de plus en plus mondiaux.

Si vous développez une application basée sur FHIR sur le marché européen et avez besoin de conseils sur l'adaptation de votre profil, je serai ravi de vous aider.