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.

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

Die Grafik kann hier auch als PDF heruntergeladen werden.

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 es die lokale Patienten–ID, zusammen mit den demographischen Daten aus der Personendatenbank UPI der Zentralen Ausgleichsstelle 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 der 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 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 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 lokalen Patienten-ID die EPR-SPID und MPI-PID mittels PIXV3 Query abfragen.

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 bei ihrem 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 (Authenticate User), die Erneuerung einer abgelaufenen aber erneuerbaren Identity Provider User Session (IdP Renew) sowie das Logout (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 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 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 Provide and Register Document Set registriert und speichert das Primärsystem Dokumente in der eigenen Gemeinschaft. Dabei übergibt 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 zentralen 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 Registry Stored Query aus und zeigt dem Benutzer eine Liste der Ergebnisse.

Im zweiten Schritt fragt das Primärsystem via 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.

Letzte Änderung 11.03.2021