Relevante Schnittstellen

Gesundheitseinrichtungen schliessen sich einer Gemeinschaft an. Bei einer tiefen Integration des EPD in ein Primärsystem muss dieses sich nicht nur an die Gemeinschaft, sondern für die Authentifizierung der Benutzer auch an den Identity Provider der Gemeinschaft anbinden. Sämtliche Kommunikation mit anderen Gemeinschaften oder mit Bundesdiensten führt die Gemeinschaft im Hintergrund aus.

Diese Ebene richtet sich an Technikverantwortliche, die wissen wollen, welche Schnittstellen und Sicherheitsanforderungen implementiert werden müssen, damit sie später ihr Primärsystem an die EPD-Plattform ihrer Gemeinschaft anschliessen können.

Die Schnittstellenbezeichnungen sind mit Nachrichtenbeispielen und weiteren Detailinformationen für die Schnittstellenentwicklerinnen und -entwickler verlinkt. Dieses Angebot auf GitHub wird laufend ergänzt und weiter ausgebaut.

Externer Link: GitHub

Übersicht der relevanten Komponenten und Schnittstellen

Die untenstehende Grafik zeigt die erforderlichen Anwendungsfälle (Pfeile zwischen dem Primärsystem und der Gemeinschaft resp. dem Primärsystem und dem Identity Provider) zusammen mit den relevanten technischen EPD-Komponenten.

Externer Link: Die Grafik kann hier auch als PDF heruntergeladen werden. (418 KB, 30.10.23)

Die Anwendungsfälle und Schnittstellen im Detail

Nachfolgend werden die Anwendungsfälle und die relevanten Schnittstellen beschrieben.

1. Patienten verwalten

Damit eine Gesundheitsfachperson oder ihre Hilfsperson auf ein EPD zugreifen kann, muss das Primärsystem die Patientin oder den Patienten bei der Gemeinschaft registrieren.

Dazu schickt das Primärsystem seine lokale Patienten–ID zusammen mit den zuvor abgefragten demographischen Daten aus der Personendatenbank UPI des Bundes an den Master Patient Index (MPI) der Gemeinschaft.

Um zu erfahren, wie Sie die demographischen Daten der UPI-Datenbank erhalten, kontaktieren Sie bitte Ihre Gemeinschaft.

Hat das Primärsystem die Patientin oder den Patienten erfolgreich bei der Gemeinschaft registriert, kann es für den Zugriff auf das EPD anhand seiner lokalen Patienten-ID die Identifikatoren abfragen, die für den Zugriff auf Daten im EPD erforderlich sind.

1.1 Patient suchen

Ist die Patientin oder der Patient bereits im MPI der Gemeinschaft registriert, kann ein Primärsystem auch mittels demographischer Angaben (z.B. Name, Vorname oder Geburtsdatum) im MPI mit der Externer Link: Patient Demographics Query  nach der Patientin oder dem Patienten suchen, um zum Beispiel danach die lokale ID zu registrieren.

1.2 Patient registrieren

Für die Registrierung einer Patientin oder eines Patienten im MPI der Gemeinschaft schickt das Primärsystem beim Externer Link: Patient Identity Feed  die Personenangaben aus der UPI sowie die lokale Patienten-ID.

1.3 Patientenidentitäten abfragen

Nachdem die Patientin oder der Patient im MPI der Gemeinschaft registriert worden ist, kann das Primärsystem anhand der registrierten lokalen Patienten-ID die Patienten-IDs für den Zugriff auf das EPD (EPR-SPID und MPI-PID) mittels Externer Link: PIXV3 Query  abfragen.

Hinweis: Die EPR-SPID darf aus rechtlichen Gründen nicht dauerhaft im Primärsystem gespeichert werden und muss deshalb erneut abgefragt werden.

2. EPD-Benutzer authentisieren

Die Gesundheitsfachperson oder die Hilfsperson authentisiert sich über das Primärsystem mittels elektronischer Identität (E-ID) beim Identity Provider. Dieser bestätigt der Gemeinschaft, dass es sich um die behauptete Person handelt und baut eine Identity Provider User Session auf.

Dazu sind die drei Schnittstellen erforderlich: Die Authentisierung des Benutzers (Externer Link: Authenticate User ), die Erneuerung einer abgelaufenen aber erneuerbaren Identity Provider User Session (Externer Link: IdP Renew ) sowie das Logout (Externer Link: SSO Logout ).

Im EPD-Kontext ist die Nutzung des SAML 2 Artifact Bindings über HTTP mit einem XML SOAP Webservice Backchannel vorgeschrieben. Dabei erfolgt die Authentisierung in zwei Schritten, wobei im ersten Schritt nur abstrakte Token via HTTP übertragen werden und die Angaben zum Benutzer (Claims) erst im zweiten Schritt über einen abgesicherten Webservice-Aufruf abgefragt werden.

3. EPD-Benutzer autorisieren

Ist die Gesundheitsfachperson oder die Hilfsperson beim Identity Provider authentifiziert, gibt sie den Kontext des EPD-Zugriffs an, beispielsweise ihre Benutzerrolle oder die Vertraulichkeitsstufe für die Dokumentenabfrage. Diese Angaben schickt sie mittels Externer Link: Get X-User Assertion  an den X-Assertion Provider. Als Antwort erhält sie eine SAML 2.0 User Assertion, welche die gemachten Angaben bestätigt.

Bei sämtlichen Schnittstellen, welche zusätzlich über die Zugriffsrechtesteuerung abgesichert sind (dies betrifft primär das Dokumentenmanagement), muss neben der fachlichen Nachricht zusätzlich diese SAML 2.0 Assertion via Externer Link: Provide X-User Assertion  mitgeschickt werden.

4. Dokumente im EPD verwalten

Nachfolgend werden die Anwendungsfälle zur Bereitstellung, der Suche und dem Abruf sowie der Aktualisierung von Dokumenten und Dokumentenmetadaten im EPD erläutert.

4.1 Dokumente bereitstellen

Mittels Externer Link: Provide and Register Document Set  registriert und speichert das Primärsystem Dokumente in der eigenen Gemeinschaft. Dabei übermittelt es ein oder mehrere Dokumente mit den zugehörigen Metadaten (Autor, Fachrichtung des Autors, Dokumentenklasse, u.a.). Das Document Repository nimmt die Anfrage entgegen, registriert die Dokumenten-ID und die Metadaten in der Document Registry und legt das Dokument selbst bei sich ab.

4.2 Dokumente suchen und abrufen

Die Abfrage von Dokumenten wird normalerweise in zwei Schritten durchgeführt:

Im ersten Schritt fragt das Primärsystem die Dokumentmetadaten aller Dokumente eines Patienten – gegebenenfalls gefiltert nach gewissen Metadaten – ab. Dazu führt das Primärsystem eine Externer Link: Registry Stored Query  aus und zeigt dem Benutzer eine Liste der Ergebnisse.

Im zweiten Schritt fragt das Primärsystem via Externer Link: Retrieve Document Set  ein oder mehrere ausgewählte Dokumente ab und zeigt die Inhalte in den Benutzeroberflächen an oder speichert sie im Primärsystem.

5. Sichere Kommunikation und Protokollierung

Für die sichere Kommunikation verwendet das Primärsystem TLS. Es authentisiert sich mittels seines Client Zertifikats (mutual authentication).

Bei jeder Kommunikation schreibt das Primärsystem ein Audit Log und übermittelt dieses mittels Record Audit Event an die Gemeinschaft. Als Format ist ein spezielles XML Schema definiert. Die Details zu den Audit Nachrichten sind bei den Schnittstellen auf GitHub angegeben.

 Externer Link: Go to Github

In Kürze: