Intégration avec le dossier Swiss Electronic Patient (EPD) : une plongée technique approfondie

Réponse directe

L'EPD suisse reste en activité pendant la transition E-GD. Les interfaces FHIR sont en EPDV-EDI depuis juin 2025. CH EPR FHIR est l'IG pour les transactions EPR basées sur FHIR. Vérifier opérations et développement ultérieur plutôt que de traiter E-GD comme un live.

Confirmer le contrat d’insertion pris en charge par la communauté

Commencez par la communauté certifiée ou la communauté de référence choisie, son processus d'intégration, les transactions prises en charge et son environnement de test. Distinguer l’EPR-SPID national des identifiants communautaires et locaux des patients. Le fonctionnaire Guide de l'interface eHealth Suisse décrit l'enregistrement des patients, la recherche d'identifiant et l'authentification professionnelle comme étapes d'intégration distinctes.

Créez une liste de contrôle de conformité avec des exemples de demandes, la gestion de l'expiration des certificats, le comportement d'accès refusé et la validation des métadonnées du document. Comparez le contrat d'interface sélectionné avec le Guide des profils IHE; ne présumez pas qu’un serveur FHIR générique est une connexion EPD.

Introduction

Le dossier électronique suisse Patient (Elektronisches Patientendossier, EPD) utilise une infrastructure d'échange réglementée. Le travail d’intégration doit distinguer les interfaces communautaires actuellement déployées des changements proposés à l’architecture nationale.

Ayant travaillé sur des projets d'interopérabilité des soins de santé impliquant des profils IHE et FHIR — les deux piliers de l'intégration EPD — je souhaite partager les connaissances techniques pratiques dont vous avez besoin pour construire des systèmes connectés EPD.

Comprendre l'architecture EPD

Contrairement aux systèmes nationaux centralisés de DSE (comme ceux de l'Estonie ou du Danemark), la DEP suisse suit un modèle de communauté fédérée. Il n’existe pas de dossier de santé national unique. Au lieu de cela, les patients choisissent une communauté de référence (Stammgemeinschaft) où leur dossier est hébergé, et les prestataires de soins rejoignent les communautés pour participer.

Swiss EPD Architecture (Federated Model)
┌───────────────────────────────────────────────────────┐
│                    Patient                             │
│              (chooses community)                       │
└────────────────────┬──────────────────────────────────┘
                     │
        ┌────────────▼────────────┐
        │    EPD Community A      │
        │   (Stammgemeinschaft)   │
        │  ┌───────────────────┐  │
        │  │  Document Registry │  │◄── XDS.b Registry
        │  │  (metadata index)  │  │
        │  └───────────────────┘  │
        │  ┌───────────────────┐  │
        │  │ Document Repository│  │◄── XDS.b Repository
        │  │  (clinical docs)   │  │
        │  └───────────────────┘  │
        │  ┌───────────────────┐  │
        │  │  Patient Identity  │  │◄── PIX V3 / PDQ V3
        │  │     Manager       │  │
        │  └───────────────────┘  │
        └────────────┬────────────┘
                     │
           Cross-community queries
           (XCA / XCPD profiles)
                     │
        ┌────────────▼────────────┐
        │    EPD Community B      │
        │   (Stammgemeinschaft)   │
        └─────────────────────────┘

Composants clés :

Communautés EPD — les organismes certifiés qui exploitent l'infrastructure (p. ex. CARA, AD Swiss, eHealth Aargau)
Registre des documents — index de métadonnées centralisé au sein de chaque communauté
Référentiel de documents — stockage des documents cliniques
Patient Gestionnaire d'identité — fait des références croisées aux identités des patients à travers les systèmes
Passerelle intercommunautaire - permet des requêtes dans les communautés à l'aide de XCA/XCPD

Profils IHE de base pour l'intégration EPD

L'EPD suisse s'appuie sur IHE (Intégrer l'Entreprise de Santé) profils d'intégration. Si vous venez d'un milieu exclusivement FHIR, c'est là que se situe la courbe d'apprentissage. L'EPD utilise un ensemble spécifique de profils IHE définis dans les extensions nationales suisses (annexe 5 de l'ordonnance EPD).

XDS.b — Partage de documents entre entreprises

XDS.b est l’épine dorsale de l’EPD. Il définit la manière dont les documents cliniques sont enregistrés, stockés et récupérés.

Transactions clés que vous mettrez en œuvre :

Opération	Code IHE	Objectif
Enregistrer un ensemble de documents	ITI-42	Enregistrer les métadonnées pour les nouveaux documents
Fournir et enregistrer un ensemble de documents	ITI-41	Télécharger le document + enregistrer les métadonnées
Requête stockée dans le registre	ITI-18	Recherche de documents par patient, date, type
Récupérer un ensemble de documents	ITI-43	Télécharger un document spécifique

Les documents de l'EPD sont stockés avec des métadonnées standardisées, notamment :

code de classe — classification des documents (par exemple, résumé de sortie, rapport de laboratoire)
typeCode — type de document spécifique
formatCode — format technique (document CDA, PDF, FHIR)
confidentialitéCode — niveau d'accès normal, restreint ou secret
langueCode — langue du document (critique dans la Suisse multilingue)

Tous les codes de métadonnées doivent utiliser les ensembles de valeurs suisses officiels publiés par eHealth Suisse.

PIX V3 — Références croisées d'identifiant Patient

Étant donné que les patients peuvent être connus sous différents identifiants dans différents systèmes, PIX V3 gère les références croisées :

Flux d'identité Patient (ITI-44) — enregistrer ou mettre à jour l'identité du patient
Requête PIX (ITI-45) — rechercher l'EPD-MPI-ID d'un patient à l'aide d'un identifiant local

L'EPD utilise un index principal Patient (MPI) qui attribue à chaque patient un EPD-MPI-ID unique (basé sur l'OID). Votre système doit mapper les identifiants locaux des patients à cet EPD-MPI-ID.

PDQ V3 — Requête démographique Patient

PDQ V3 permet de rechercher des patients par critères démographiques :

Requête démographique Patient (ITI-47) — recherche par nom, date de naissance, sexe, adresse

Ceci est utilisé lorsque vous n'avez pas l'identifiant local du patient et que vous devez le trouver dans l'EPD.

XUA – Assertion d'utilisateur inter-entreprises

L'authentification et l'autorisation dans l'EPD utilisent des assertions SAML 2.0 :

Les professionnels de santé s'authentifient via le fournisseur d'identité de leur communauté
Une assertion SAML (jeton XUA) est attachée à chaque transaction EPD
L'assertion comprend le rôle de l'utilisateur (professionnel de santé, assistant, patient), le numéro GLN et la finalité de l'utilisation.

Authentication Flow
┌──────────┐     ┌─────────────┐     ┌──────────────┐
│  Primary  │     │  Community   │     │    EPD        │
│  System   │     │  IdP (STS)  │     │  Infrastructure│
└─────┬────┘     └──────┬──────┘     └──────┬───────┘
      │                 │                    │
      │  1. Request     │                    │
      │  SAML Token     │                    │
      │────────────────►│                    │
      │                 │                    │
      │  2. Authenticate│                    │
      │  (HPC + PIN)    │                    │
      │◄───────────────►│                    │
      │                 │                    │
      │  3. SAML        │                    │
      │  Assertion      │                    │
      │◄────────────────│                    │
      │                 │                    │
      │  4. EPD Transaction + SAML Token     │
      │─────────────────────────────────────►│
      │                 │                    │
      │  5. Response                         │
      │◄─────────────────────────────────────│

Interfaces FHIR — La nouvelle voie

L'échange de documents basé sur FHIR est une option d'intégration à évaluer par rapport aux spécifications suisses actuelles et aux interfaces prises en charge par la communauté sélectionnée. La disponibilité d'un profil publié ne signifie pas que chaque communauté offre le même point de terminaison de production.

MHD — Documents de santé mobiles

MHD fournit une couche API RESTful FHIR au-dessus de l'infrastructure XDS.b :

Transaction MHD	Équivalent XDS.b	Fonctionnement FHIR
Rechercher des listes de documents	ITI-18	GET/Liste avec les paramètres de recherche
Rechercher des références de documents	ITI-18	GET /DocumentReference avec les paramètres de recherche
Récupérer un document	ITI-43	OBTENIR /Binaire/{id}
Fournir le document Bundle	ITI-41	POST /Bundle (transaction)

Évaluez MHD où la communauté réceptrice prend en charge les transactions et la version de profil requises. Confirmez sa disponibilité opérationnelle avant de le choisir plutôt qu’une interface SOAP établie.

Profils FHIR suisses (CH Core)

La Suisse gère des profils FHIR nationaux publiés par HL7 Suisse (FHIR CH) :

CH Noyau — profils de base pour les soins de santé suisses (CH Core Patient, CH Core Practitioner, etc.)
CH-EPR — profils spécifiques à l'intégration EPD
CH EMED — profils de médicaments électroniques
CH ORF — formulaires de commande et de référencement
CH VACD — profils de certificats de vaccination

Ces profils étendent les ressources de base du FHIR R4 avec des extensions spécifiques à la Suisse, telles que :

Numéro AVS/AVS (numéro de sécurité sociale suisse) comme identifiant du patient
GNL (Global Location Number) pour l’identification du prestataire de soins de santé
Ensembles de valeurs spécifiques à la Suisse pour les métadonnées du document
Prise en charge multilingue (allemand, français, italien, romanche)

Étapes pratiques d’intégration

Étape 1 : Choisissez votre communauté

Convenez du processus d’intégration et d’acceptation du logiciel avec la communauté sélectionnée. Ne confondez pas les contrôles de conformité des fournisseurs avec la certification statutaire d'une communauté. Le travail typique d'acceptation de l'intégration comprend :

Tests de conformité technique par rapport aux profils IHE
Évaluation de la sécurité et de la protection des données
Tests de connectivité avec l'infrastructure de la communauté
Validation de la conformité d'eHealth Suisse

Étape 2 : implémenter le moteur d'intégration

Je recommande d'utiliser Mirth Connect (ou un autre moteur d'intégration) comme middleware entre votre application et l'infrastructure EPD. Cela gère :

Construction de messages SOAP/XML pour les transactions IHE
Gestion et renouvellement des jetons SAML
Journalisation et audit des messages (profil ATNA)
Gestion des erreurs et logique de nouvelle tentative

Pour les intégrations basées sur FHIR (MHD), vous pouvez utiliser des clients HTTP standard, mais je recommande toujours une couche d'intégration pour la gestion des jetons et la journalisation d'audit.

Étape 3 : Gérer les formats de documents

L'EPD prend en charge plusieurs formats de documents :

ADC R2 — Architecture de documents cliniques HL7 (documents cliniques structurés)
PDF/A — pour les documents qui ne peuvent pas être structurés
Documents FHIR — de plus en plus pris en charge pour les données structurées

Pour une interopérabilité maximale, générez des documents CDA R2 en utilisant les spécifications du format d'échange suisse. Si votre système produit des ressources FHIR, convertissez-les au format de document CH EPR FHIR.

Étape 4 : Mettre en œuvre le consentement et le contrôle d'accès

L'EPD dispose d'un modèle de consentement sophistiqué :

Les patients contrôlent qui peut accéder à leur dossier
L’accès peut être accordé à des professionnels de santé, des groupes ou des rôles spécifiques
Les niveaux de confidentialité (normal, restreint, secret) contrôlent la visibilité des documents
L'accès d'urgence contourne les règles de consentement normales mais est audité

Votre système doit respecter ces contrôles d'accès et gérer correctement les cas où l'accès est refusé.

Pièges courants

Ignorer les exigences multilingues — La Suisse a quatre langues officielles. Les métadonnées des documents, les étiquettes de l'interface utilisateur et les affichages des ensembles de valeurs doivent prendre en charge au moins l'allemand, le français et l'italien.
Sous-estimer la complexité de l’IHE — Les transactions IHE basées sur SOAP ont des courbes de mise en œuvre abruptes. Prévoyez beaucoup plus de temps que pour les API REST.
Gestion des certificats — L'intégration EPD nécessite un TLS mutuel avec des certificats émis par la communauté. La rotation et la gestion des certificats sont une préoccupation opérationnelle que de nombreuses équipes négligent.
Infrastructure de test — les environnements de test EPD ne sont pas toujours disponibles ou stables. Planifiez les retards des tests d’intégration.

La réforme législative

Les propositions de réforme et les programmes de mise en œuvre ne doivent pas être traités comme des interfaces déjà opérationnelles ou des obligations de participation universelle. Vérifier Statut actuel du programme eHealth Suisse et la loi promulguée applicable avant de s'engager dans un contrat de livraison.

Conservez les hypothèses d'intégration de production actuelle et de migration future dans des documents séparés, avec un propriétaire et une date de révision pour chaque dépendance.

Conclusion

L'intégration à l'EPD suisse est techniquement exigeante mais de plus en plus indispensable. La combinaison de profils IHE pour l'infrastructure existante et d'interfaces FHIR pour les nouvelles intégrations offre une flexibilité aux développeurs. Revalider le contrat communautaire et le calendrier des réformes au lancement du projet.

Si vous avez besoin d'aide pour naviguer dans l'intégration EPD - de la mise en œuvre du profil IHE à l'échange de documents basé sur FHIR - je serai heureux de discuter de vos besoins spécifiques.