Swiss electronic patient file: connect the FHIR CH EPR API
DEP FHIR Implementation Guide: CH EPR FHIR 5.0.0, EPR-SPID identifier, MHD / PIXm / PDQm transactions, languageCode metadata, and what is prohibited from storing.
Ala Ben Aicha
Direct answer
The Swiss DEP remains operational. The FHIR API to pin is CH EPR FHIR 5.0.0. The national identifier is the EPR-SPID (OID 2.16.756.5.30.1.127.3.10.3). A generic FHIR server is not a DEP connection.
FHIR first, SOAP next
The English page Swiss EPD integration describes the historical IHE contract (XDS.b, PIX/PDQ V3, XUA). This is the FHIR contract published by eHealth Switzerland: CH EPR FHIR (R4) 5.0.0 (DSTU 5 Ballot 1, current published version, active as of December 18, 2025). Official URL: http://fhir.ch/ig/ch-epr-fhir/ImplementationGuide/ch.fhir.ig.ch-epr-fhir. Package: ch.fhir.ig.ch-epr-fhir#5.0.0 on FHIR R4.0.1.
The DEP remains a federated system of communities. A patient has a community of reference; documents may also be published elsewhere. The E-GD reform is not, on its own, a production API. Check the operating status and thearchitecture of the chosen community (in French-speaking Switzerland, often CARA — to be confirmed in the onboarding contract, not through a blog).
Order: ODEP, RS 816.11. The IG explicitly says that it should be read with the IHE ITI volumes.
The identifier that is not stored in the registry
Each patient has an active EPR-SPID. CH Core profiles it as EPR-SPID Identifier : identifier.system fixed at urn:oid:2.16.756.5.30.1.127.3.10.3. Profile Constraints: Value starts with 76133761, 18 digits, modulo 10 control.
There is no national addressable Patient resource. The patient references are logical (EPR-SPID identifier), hence PIXm and PDQm $match rather than MHDS/PMIR. The systems are not authorized to store the EPR-SPID in document deposits or registers: the IG refers to art. 10 para. 3 ODEP-DFI (RS 816.111). You feed a localID + EPR-SPID to the community to resolve later; you do not write the EPR-SPID in the persisted XDS/MHD metadata.
Professionals are identified by GLN, also in logical reference (not a Practitioner.id national).
Don't invent a "valid" EPR-SPID in your captures. The pattern and modulo 10 are sufficient for a validator test; a value that passes the checksum is not necessarily a public fixture identifier.
MHD Transactions (and National Extension)
| Transaction | Code | Resource/operation | XDS.b equivalent | Trap |
|---|---|---|---|---|
| Provide Document Bundle | ITI-65 | POST Bundle transaction: DocumentReference + Binary (+SubmissionSet) |
ITI-41 | Patient = logical EPR-SPID identifier, resources contained for local demographics |
| Find Document References | ITI-67 | GET /DocumentReference |
ITI-18 | Filter without languageCode in French-speaking Switzerland = documents not found on the business side |
| Retrieve Document | ITI-68 | GET /Binary/{id} |
ITI-43 | It's not a Composition REST |
| Update Document Metadata | CH:MHD-1 | National extension CH EPR FHIR | (not in basic MHD IHE) | A generic FHIR PATCH is not CH:MHD-1 |
| PIXm Identity Feed / Query | ITI-104 / ITI-83 | Feed Patient ; query identifiers | PIX V3 ITI-44/45 | Store the EPR-SPID in the registry |
PDQm $match |
ITI-119 | Parameters in/out |
PDQ V3 ITI-47 | A GET /Patient?name= national |
languageCode is not cosmetic. The Swiss eHealth codesystem (ch-ehealth-codesystem-language) covers German, French, Italian and Romansh. A document published without language, or with en by framework default, breaks patient views and metadata controls.
AuthN/AuthZ: the IG separates customer (message signing or mTLS) and user (SAML 2.0 or OpenID Connect JWT according to ODEP-DFI Annex 8), with IUA. A “SMART sandbox” Bearer token is not a DEP assertion.
National profiles in the same GI: CH:PPQm (consent policies) and CH:ATC (patient audit trail). An MHD who ignores PPQm publishes in the legal void of the file.
Community checklist, not an eHealth Switzerland certificate
- Community Interface Agreement (actually exposed transactions, IG version, test environment, certificates). A published GI ≠ a production endpoint.
- CapabilityStatement actors MHD Document Source / Consumer / Recipient / Responder CH, plus PIXm/PDQm.
- Fixtures : Bundle ITI-65 de-identified,
languageCode=fr, GLN author, no EPR-SPID in Binary/registry. - Refusal of access and emergency :403/policy deny, audited emergency access (CH:ATC), not a silent retry.
- SOAP in parallel. Many communities still expose XDS.b. See the IHE page and the article C-CDA / documents. MHD is not a magic substitute.
What this page is not
This is not a community certification, not a CARA or AD Swiss onboarding, not an opinion on E-GD, not legal or clinical advice. Implementing CH EPR FHIR 5.0.0 in a lab does not allow you to write “connected to DEP” on a placard. I do not represent eHealth Suisse or a community.
If you need MHD/PIXm cabling on an existing IS, this is interoperability in digital health. For a bounded spike, use the contact with project intention.