# Integrating with the Swiss Electronic Patient Dossier (EPD): A Technical Deep Dive > A hands-on guide to integrating healthcare systems with Switzerland's EPD — covering IHE profiles, FHIR interfaces, identity management, and the architectural patterns that work in practice. Author: Ala Ben Aicha Canonical page: https://alabenaicha.me/insights/swiss-electronic-patient-dossier-integration Updated: 2026-09-17 ## Direct answer The Swiss EPD remains in operation during the E-GD transition. FHIR interfaces have been in EPDV-EDI since June 2025. [CH EPR FHIR](https://fhir.ch/ig/ch-epr-fhir/index.html) is the IG for FHIR-based EPR transactions. Check [operations and further development](https://www.e-health-suisse.ch/das-epd/elektronische-patientendossier/betrieb-weiterentwicklung) rather than treating E-GD as live. ## Confirm the community’s supported integration contract Start with the chosen certified community or reference community, its onboarding process, supported transactions and test environment. Distinguish the national EPR-SPID from community and local patient identifiers. The official [eHealth Suisse interface guide](https://www.e-health-suisse.ch/das-epd/epd-anbindung/relevante-schnittstellen) describes patient registration, identifier lookup and professional authentication as separate integration steps. Build a conformance checklist with example requests, certificate expiry handling, access-denied behaviour and document metadata validation. Compare the selected interface contract with the [IHE profile guide](https://alabenaicha.me/insights/ihe-profiles-european-healthcare-integration); do not assume that a generic FHIR server is an EPD connection. ## Introduction Switzerland's Electronic Patient Dossier (Elektronisches Patientendossier, EPD) uses a regulated exchange infrastructure. Integration work needs to distinguish the currently deployed community interfaces from proposed changes to the national architecture. Having worked on healthcare interoperability projects involving IHE profiles and FHIR — the two pillars of EPD integration — I want to share the practical technical knowledge you need to build EPD-connected systems. ## Understanding the EPD Architecture Unlike centralized national EHR systems (such as Estonia's or Denmark's), the Swiss EPD follows a **federated community model**. There is no single national health record. Instead, patients choose a reference community (Stammgemeinschaft) where their dossier is hosted, and healthcare providers join communities to participate. ``` 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) │ └─────────────────────────┘ ``` Key components: * **EPD Communities** — certified organizations that operate the infrastructure (e.g., CARA, AD Swiss, eHealth Aargau) * **Document Registry** — centralized metadata index within each community * **Document Repository** — storage for clinical documents * **Patient Identity Manager** — cross-references patient identities across systems * **Cross-Community Gateway** — enables queries across communities using XCA/XCPD ## Core IHE Profiles for EPD Integration The Swiss EPD is built on **IHE (Integrating the Healthcare Enterprise)** integration profiles. If you are coming from a FHIR-only background, this is where the learning curve hits. The EPD uses a specific set of IHE profiles defined in the Swiss national extensions (Annex 5 of the EPD ordinance). ### XDS.b — Cross-Enterprise Document Sharing XDS.b is the backbone of the EPD. It defines how clinical documents are registered, stored, and retrieved. **Key transactions you will implement:** | Transaction | IHE Code | Purpose | | --------------------------------- | -------- | ------------------------------------------- | | Register Document Set | ITI-42 | Register metadata for new documents | | Provide and Register Document Set | ITI-41 | Upload document + register metadata | | Registry Stored Query | ITI-18 | Search for documents by patient, date, type | | Retrieve Document Set | ITI-43 | Download a specific document | Documents in the EPD are stored with standardized metadata including: * **classCode** — document classification (e.g., discharge summary, lab report) * **typeCode** — specific document type * **formatCode** — technical format (CDA, PDF, FHIR document) * **confidentialityCode** — normal, restricted, or secret access level * **languageCode** — document language (critical in multilingual Switzerland) All metadata codes must use the official Swiss value sets published by eHealth Suisse. ### PIX V3 — Patient Identifier Cross-Referencing Since patients may be known by different IDs in different systems, PIX V3 manages cross-referencing: * **Patient Identity Feed (ITI-44)** — register or update patient identity * **PIX Query (ITI-45)** — look up a patient's EPD-MPI-ID using a local identifier The EPD uses a Master Patient Index (MPI) that assigns each patient a unique EPD-MPI-ID (OID-based). Your system needs to map local patient identifiers to this EPD-MPI-ID. ### PDQ V3 — Patient Demographics Query PDQ V3 allows searching for patients by demographic criteria: * **Patient Demographics Query (ITI-47)** — search by name, date of birth, gender, address This is used when you do not have the patient's local ID and need to find them in the EPD. ### XUA — Cross-Enterprise User Assertion Authentication and authorization in the EPD use SAML 2.0 assertions: * Healthcare professionals authenticate through their community's identity provider * A SAML assertion (XUA token) is attached to every EPD transaction * The assertion includes the user's role (healthcare professional, assistant, patient), GLN number, and purpose of use ``` 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 │ │◄─────────────────────────────────────│ ``` ## FHIR Interfaces — The New Path FHIR-based document exchange is an integration option to evaluate against the current Swiss specifications and the selected community’s supported interfaces. Availability of a published profile does not mean every community offers the same production endpoint. ### MHD — Mobile Health Documents MHD provides a RESTful FHIR API layer on top of the XDS.b infrastructure: | MHD Transaction | XDS.b Equivalent | FHIR Operation | | ------------------------ | ---------------- | ----------------------------------------- | | Find Document Lists | ITI-18 | GET /List with search params | | Find Document References | ITI-18 | GET /DocumentReference with search params | | Retrieve Document | ITI-43 | GET /Binary/{id} | | Provide Document Bundle | ITI-41 | POST /Bundle (transaction) | Evaluate MHD where the receiving community supports the required transactions and profile version. Confirm its operational availability before choosing it over an established SOAP interface. ### Swiss FHIR Profiles (CH Core) Switzerland maintains national FHIR profiles published by HL7 Switzerland (FHIR CH): * **CH Core** — base profiles for Swiss healthcare (CH Core Patient, CH Core Practitioner, etc.) * **CH EPR** — profiles specific to EPD integration * **CH EMED** — electronic medication profiles * **CH ORF** — order and referral forms * **CH VACD** — vaccination certificate profiles These profiles extend the base FHIR R4 resources with Swiss-specific extensions, such as: * **AHV/OASI number** (Swiss social security number) as a patient identifier * **GLN** (Global Location Number) for healthcare provider identification * **Swiss-specific value sets** for document metadata * **Multilingual support** (German, French, Italian, Romansh) ## Practical Integration Steps ### Step 1: Choose Your Community Agree the software onboarding and acceptance process with the selected community. Do not confuse vendor conformance checks with statutory certification of a community. Typical integration acceptance work includes: 1. Technical conformance testing against IHE profiles 2. Security and data protection assessment 3. Connectivity testing with the community's infrastructure 4. eHealth Suisse compliance validation ### Step 2: Implement the Integration Engine I recommend using **Mirth Connect** (or another integration engine) as middleware between your application and the EPD infrastructure. This handles: * SOAP/XML message construction for IHE transactions * SAML token management and renewal * Message logging and auditing (ATNA profile) * Error handling and retry logic For FHIR-based integrations (MHD), you can use standard HTTP clients, but I still recommend an integration layer for token management and audit logging. ### Step 3: Handle Document Formats The EPD supports multiple document formats: * **CDA R2** — HL7 Clinical Document Architecture (structured clinical documents) * **PDF/A** — for documents that cannot be structured * **FHIR Documents** — increasingly supported for structured data For maximum interoperability, generate CDA R2 documents using the Swiss exchange format specifications. If your system produces FHIR resources, convert them to the CH EPR FHIR document format. ### Step 4: Implement Consent and Access Control The EPD has a sophisticated consent model: * Patients control who can access their dossier * Access can be granted to specific healthcare professionals, groups, or roles * Confidentiality levels (normal, restricted, secret) control document visibility * Emergency access bypasses normal consent rules but is audited Your system must respect these access controls and properly handle cases where access is denied. ## Common Pitfalls 1. **Ignoring multilingual requirements** — Switzerland has four official languages. Document metadata, UI labels, and value set displays must support at least German, French, and Italian. 2. **Underestimating IHE complexity** — SOAP-based IHE transactions have steep implementation curves. Budget significantly more time than you would for REST APIs. 3. **Certificate management** — EPD integration requires mutual TLS with community-issued certificates. Certificate rotation and management is an operational concern that many teams overlook. 4. **Testing infrastructure** — the EPD test environments are not always available or stable. Plan for integration testing delays. ## The Legislative Reform Reform proposals and implementation programmes should not be treated as already operational interfaces or universal participation obligations. Check [eHealth Suisse’s current programme status](https://www.e-health-suisse.ch/koordination/elektronisches-patientendossier/aktueller-stand) and the applicable enacted law before committing to a delivery contract. Keep current production integration and future migration assumptions in separate documents, with an owner and a review date for each dependency. ## Conclusion Integrating with the Swiss EPD is technically demanding but increasingly essential. The combination of IHE profiles for the existing infrastructure and FHIR interfaces for new integrations gives developers flexibility. Revalidate the community contract and reform timetable at project kickoff. If you need help navigating EPD integration — from IHE profile implementation to FHIR-based document exchange — I would be glad to discuss your specific requirements.