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

Auteur: Ala Ben Aicha

Page de référence: https://alabenaicha.me/fr/insights/dossier-patient-suisse-fhir

Mise à jour: 2026-09-17

## 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](https://alabenaicha.me/fr/insights/swiss-electronic-patient-dossier-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](https://fhir.ch/ig/ch-epr-fhir/) (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](https://www.e-health-suisse.ch/fr/le-dep/dossier-electronique-du-patient/exploitation-developpement) et l'[architecture](https://www.e-health-suisse.ch/fr/technique/interoperabilite-technique/architecture-dep-suisse) de la communauté choisie (en Suisse romande, souvent CARA — à confirmer dans le contrat d'onboarding, pas par un blog).

Ordonnance : [ODEP, RS 816.11](https://www.admin.ch/opc/fr/classified-compilation/20111795/index.html). 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](https://fhir.ch/ig/ch-core/StructureDefinition-ch-core-epr-spid-identifier.html) : `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

1. **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.
2. **CapabilityStatement** des acteurs MHD Document Source / Consumer / Recipient / Responder **CH**, plus PIXm/PDQm.
3. **Fixtures** : Bundle ITI-65 de-identifié, `languageCode=fr`, GLN auteur, pas d'EPR-SPID dans Binary/registry.
4. **Refus d'accès et urgence** : 403 / deny de politique, accès d'urgence audité (CH:ATC), pas un retry silencieux.
5. **SOAP en parallèle.** Beaucoup de communautés exposent encore XDS.b. Voir la [page IHE](https://alabenaicha.me/fr/insights/ihe-profiles-european-healthcare-integration) et l'article [C-CDA / documents](https://alabenaicha.me/fr/insights/c-cda-to-fhir-document-exchange). 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](https://alabenaicha.me/fr/services/digital-health-interoperability). Pour un spike borné, utilisez le [contact avec intention projet](https://alabenaicha.me/fr/contact?intent=project).