Dossier électronique du patient suisse : brancher l’API FHIR CH EPR
Guide d’implémentation FHIR du DEP : CH EPR FHIR 5.0.0, identifiant EPR-SPID, transactions MHD / PIXm / PDQm, métadonnée languageCode, et ce qu’il est interdit de stocker.
Ala Ben Aicha
Réponse directe
Le DEP suisse reste opérationnel. L'API FHIR à pinner est CH EPR FHIR 5.0.0. L'identifiant national est l'EPR-SPID (OID 2.16.756.5.30.1.127.3.10.3). Un serveur FHIR générique n'est pas une connexion DEP.
FHIR d'abord, SOAP ensuite
La page anglaise Swiss EPD integration décrit le contrat IHE historique (XDS.b, PIX/PDQ V3, XUA). Celle-ci est le contrat FHIR publié par eHealth Suisse : CH EPR FHIR (R4) 5.0.0 (DSTU 5 Ballot 1, version publiée courante, active au 18 décembre 2025). URL officielle : http://fhir.ch/ig/ch-epr-fhir/ImplementationGuide/ch.fhir.ig.ch-epr-fhir. Package : ch.fhir.ig.ch-epr-fhir#5.0.0 sur FHIR R4.0.1.
Le DEP reste un système fédéré de communautés. Un patient a une communauté de référence ; des documents peuvent aussi être publiés ailleurs. La réforme E-GD n'est pas, à elle seule, une API de production. Vérifiez le statut d'exploitation et l'architecture de la communauté choisie (en Suisse romande, souvent CARA — à confirmer dans le contrat d'onboarding, pas par un blog).
Ordonnance : ODEP, RS 816.11. L'IG dit explicitement qu'il doit être lu avec les volumes IHE ITI.
L'identifiant qui ne se stocke pas dans le registry
Chaque patient a un EPR-SPID actif. CH Core le profile comme EPR-SPID Identifier : identifier.system fixé à urn:oid:2.16.756.5.30.1.127.3.10.3. Contraintes du profil : la valeur commence par 76133761, 18 chiffres, contrôle modulo 10.
Il n'y a pas de ressource Patient adressable nationale. Les références patient sont logiques (identifiant EPR-SPID), d'où PIXm et PDQm $match plutôt que MHDS/PMIR. Les systèmes ne sont pas autorisés à stocker l'EPR-SPID dans les dépôts ou registres de documents : l'IG renvoie à l'art. 10 al. 3 ODEP-DFI (RS 816.111). Vous nourrissez un localID + EPR-SPID vers la communauté pour résoudre plus tard ; vous n'écrivez pas l'EPR-SPID dans les métadonnées XDS/MHD persistées.
Les professionnels sont identifiés par le GLN, également en référence logique (pas un Practitioner.id national).
N'inventez pas un EPR-SPID « valide » dans vos captures. Le motif et le modulo 10 suffisent pour un test de validateur ; une valeur qui passe le checksum n'est pas pour autant un identifiant de fixture publique.
Transactions MHD (et l'extension nationale)
| Transaction | Code | Ressource / opération | Équivalent XDS.b | Piège |
|---|---|---|---|---|
| Provide Document Bundle | ITI-65 | POST Bundle transaction : DocumentReference + Binary (+ SubmissionSet) |
ITI-41 | Patient = identifiant EPR-SPID logique, ressources contained pour les démographies locales |
| Find Document References | ITI-67 | GET /DocumentReference |
ITI-18 | Filtrer sans languageCode en Suisse romande = documents introuvables côté métier |
| Retrieve Document | ITI-68 | GET /Binary/{id} |
ITI-43 | Ce n'est pas un Composition REST |
| Update Document Metadata | CH:MHD-1 | Extension nationale CH EPR FHIR | (pas dans MHD IHE de base) | Un PATCH FHIR générique n'est pas CH:MHD-1 |
| PIXm Identity Feed / Query | ITI-104 / ITI-83 | Feed Patient ; query identifiants | PIX V3 ITI-44/45 | Stocker l'EPR-SPID dans le registry |
PDQm $match |
ITI-119 | Parameters in / out |
PDQ V3 ITI-47 | Un GET /Patient?name= national |
languageCode n'est pas cosmétique. Le codesystem eHealth Suisse (ch-ehealth-codesystem-language) couvre l'allemand, le français, l'italien et le romanche. Un document publié sans langue, ou avec en par défaut de framework, casse les vues patient et les contrôles de métadonnées.
AuthN/AuthZ : l'IG sépare client (signature de message ou mTLS) et utilisateur (SAML 2.0 ou OpenID Connect JWT selon l'annexe 8 ODEP-DFI), avec IUA. Un Bearer token « SMART sandbox » n'est pas une assertion DEP.
Profils nationaux dans le même IG : CH:PPQm (politiques de consentement) et CH:ATC (piste d'audit patient). Un MHD qui ignore PPQm publie dans le vide juridique du dossier.
Checklist communautaire, pas un certificat eHealth Suisse
- Contrat d'interface de la communauté (transactions réellement exposées, version d'IG, environnement de test, certificats). Un IG publié ≠ un endpoint de production.
- CapabilityStatement des acteurs MHD Document Source / Consumer / Recipient / Responder CH, plus PIXm/PDQm.
- Fixtures : Bundle ITI-65 de-identifié,
languageCode=fr, GLN auteur, pas d'EPR-SPID dans Binary/registry. - Refus d'accès et urgence : 403 / deny de politique, accès d'urgence audité (CH:ATC), pas un retry silencieux.
- SOAP en parallèle. Beaucoup de communautés exposent encore XDS.b. Voir la page IHE et l'article C-CDA / documents. MHD n'est pas un substitut magique.
Ce que cette page n'est pas
Ce n'est pas une certification de communauté, pas un onboarding CARA ou AD Swiss, pas un avis sur l'E-GD, pas un conseil juridique ou clinique. Implémenter CH EPR FHIR 5.0.0 dans un labo ne vous autorise pas à écrire « connecté au DEP » sur une plaquette. Je ne représente pas eHealth Suisse ni une communauté.
Si vous avez besoin du câblage MHD / PIXm sur un SI existant, c'est l'interopérabilité en santé numérique. Pour un spike borné, utilisez le contact avec intention projet.