Für die Kommunikation mit den Meldeportalen der Landeskrebsregister wurde eine API entwickelt. Die Spezifikation dafür wird hier veröffentlicht und kann als ZIP-Datei (Anhang) heruntergeladen werden. Die API wird von allen Krebsregistern ab dem 01.01.2025 unterstützt werden.

Zielgruppe

Die Zielgruppe der Meldeportal-API sind Meldestellen mit einem geringen Meldungsaufkommen und/oder mit Dokumentationssystemen, in denen nur eine geringe Anzahl von Merkmalen des onkologischen Basisdatensatzes bisher strukturiert erfasst werden. Für diese Fälle ist die Implementierung der XML-Schnittstelle in das lokale Dokumentationssystem häufig unwirtschaftlich und die Meldepflicht wird durch manuelle Übertragung von Daten in die Eingabemasken der Meldeportale erfüllt.

Da dies arbeitsintensiv und fehlerträchtig ist, schließt die Meldeportal-API diese Lücke, indem sie erlaubt, einige der strukturiert vorliegenden Stammdaten aus dem lokalen System automatisiert in die webbasierten Eingabemasken der Meldeportale zu übernehmen. Die Dokumentation der restlichen oBDS-Felder erfolgt weiterhin manuell über die Eingabemasken.

Datensicherheit im Deeplink

Die Krebsregister haben hohe Anforderungen an den Datenschutz der erfassten Daten. Dabei ist in einigen Fällen eine Datentrennung vorgesehen. Dabei dürfen personenbezogene Daten (Patientenstammdaten) und medizinische Angaben (medizinische Dokumentation) nicht gemeinsam auf einem Server verarbeitet werden. Dies wird in den betroffenen Krebsregistern durch die beiden Einheiten 'Vertrauensstelle' und 'Registerstelle' gewährleistet. Die 'Vertrauensstelle' verwaltet dabei die Patientenstammdaten, hat aber keine Information über die Erkrankungen des Patienten. Die 'Registerstelle' verwaltet die Angaben zur Erkrankung (Diagnose), Therapien und Verlaufsuntersuchungen sowie weiterer medizinische Angaben.

Ein Rückschluss auf eine konkrete Person ist in der 'Registerstelle' aber nicht möglich.

Diese Trennung der Datenverarbeitung wird durch die eingesetzten Meldeportale umgesetzt. Für die Anwender stellt es von außen betrachtet ein einheitliches System zur Verfügung. Intern ist die Meldeportal Anwendung entsprechend gestaltet um dieser Datentrennung zu entsprechen.

Die Deeplinks werden so konzipiert, bzw. verarbeitet, dass die gegebene Trennung der Daten ebenfalls im Browser des Anwenders stattfinden muss.

Dennoch können auch die Deeplinks personenbezogene Daten bzw. medizinische Angaben enthalten, die es gesondert zu sichern gilt. Deeplinks entsprechen dabei einer URL auf das Meldeportal, die auf Serverseite die Deeplink Funktionalität abruft.

Die Daten, die der Deeplink mit sich führt, werden in der URL nach dem Raute-/Hashzeichen (#) angegeben. Dies stellt sicher, dass alle angegebenen Daten nur im lokalen Browser des Benutzers zur Verfügung stehen. Die Spezifikation des Transport-Protokolls (http/https) definiert, dass diese Angaben der URL nicht in die Anfrage (Request) an den Server zu übermitteln sind. Insofern hat das lokale System des Benutzers die Datenhoheit über diese Daten.

Aktuelle Browser speichern aufgerufene Webseiten im Browserverlauf, teilweise über Wochen und Monate. Hierbei wird sowohl die Adresse des Servers als auch der Inhalt nach dem Raute-/Hashzeichen (#) gespeichert. Damit ist es relativ einfach, die Inhalte von aufgerufenen Deeplinks auszulesen. Dies kann insbesondere zu einer potentiellen Gefahr

Da das Ausspähen dieser Daten auf dem lokalen Arbeitsplatz nicht verhindert werden kann, müssen die Daten vor Zugriffen Dritter entsprechend gesondert geschützt werden.

Kryptographische Verfahren

Für den Schutz der Daten werden kryptographische Funktionen eingesetzt, um deren Inhalte zu schützen. Als Verschlüsselungsverfahren werden hierbei AES für die symmetrische Verschlüsselung und RSA für die asymmetrische Verschlüsselung eingesetzt.

Zusätzlich können Daten auch hybrid verschlüsselt werden. Dabei wird ein zufälliger AES-Schlüssel gewählt, um die Daten symmetrisch mit dem AES-Verfahren zu verschlüsseln. Der zufällige Schlüssel wird dann asymmetrisch mit dem RSA-Verfahren mit dem öffentlichen Schlüssel der empfangenden Stelle verschlüsselt. Für die hybride Verschlüsselung werden also zwei Datenpakete erstellt. Ein asymmetrisch verschlüsselter Zufallsschlüssel und ein symmetrisch damit verschlüsselter Datenblock.

Im Fall der Schnittstelle nach außen (Deeplinks und RESTful-Services) in Verbindung mit einem Arzt-Informationssystem genügt es, wenn dieses die entsprechenden Geheiminsse (s.u.) kennt. So kann die Verschlüsselung der Daten mit Hilfe des symmetrischen AES-Verfahrens umgesetzt werden. Eine asymmetrische oder hybride Verschlüsselung ist in der ersten definierten Umsetzungsphase dann nicht notwendig.

Datenarten

Im Folgenden werden die Datenarten des Deeplinks definiert und welche Verschlüsselungsverfahren anzuwenden sind:

Da die Inhalte des Deeplinks lokal im Browser des Anwenders verarbeitet werden, muss bei der Implementierung der Logik des Deeplinks die Trennung der Daten vorgenommen und die Vorgaben zur kryptographischen Verschlüsselung der Daten umgesetzt werden.

Struktureller Aufbau

Deeplinks sind so aufgebaut, dass diese in der URL nach dem Hash-/ Rautezeichen (#) folgen. Die URL vor dem Hash-/ Rautezeichen (#) dient zum Aufruf der Deeplinkfunktionalität des Meldeportals vom Server. Die Logik darin verarbeitet dann den eigentlichen Deeplink, der nach dem Hash-/ Rautezeichen (#) folgt.

Der Deeplink selbst besteht wie eine URL aus verschiedenen (Pfad-) Elementen die mit dem Slash (/) getrennt sind. Allem voran sind die Authentifizierungsinformationen mitzugeben. Diese bestehen dabei aus den Credentials, welche der API-Key, die Melder-ID und ein Einmalpasswort (One-Time-Password) sind. Mit diesen kann eine gültige Sitzung am Zielsystem erzeugt werden. Danach folgen die Parameter für den eigentlichen Aufruf der verschiedenen Funktionen auf dem Zielsystem.

Alle Bestandteile des Deeplinks bis auf die Credentials sind wie in Abschnitt Datenarten beschrieben mit dem AES-Verfahren symmetrisch verschlüsselt und als Base64-kodiertes Chiffrat angehängt. Die Credentials selbst sind durch eine Base64-Kodierung lediglich verschleiert. Entsprechend gibt es den aufrufenden Deeplink, welcher verschlüsselt und verschleiert ist und den entschlüsselten Deeplink für die interne Verarbeitung.

Wie die Ver- und Entschlüsselung im Detail funktioniert, wird im folgenden Kapitel Prozess / Ablauf erläutert.

Im Folgenden wird der Aufbau der Deeplinks immer im entschlüsselten Zustand beschrieben. Beispiele demonstrieren wie der verschlüsselte Deeplink aussieht.

Im Quellsystem hinterlegte Stammdaten

Zur Verwendung der Deeplink API (und später REST API) werden im Quellsystem verschiedene Parameter hinterlegt. Diese dienen zur Authentifizierung und Ausführung der Anfragen. Die einzelnen Parameter sind wie folgt definiert:

Authentifizierungsinformationen

Ein Aufruf enthält im ersten (Pfad-) Element das Credentials-Objekt bestehend aus dem API-Key, der Melder-ID und dem optionalen Authentifizierungs-Token. Mit dem API-Key wird der Benutzer identifiziert, mit der Melder-ID der Leistungserbringer / Melder und das optionale Authentifizierungs-Token welches die Authentifizierung vollständig macht.

Mit diesen Informationen wird bei der durchzuführenden Authentifizierung der korrekte Melder zum Benutzer gesetzt und mittels dem Authentifizierungs-Token autorisiert. Die Struktur des Credentials-Objekts entspricht einem JSON Objekt.

Authentifizierung

Zur Authentifizierung benötigt das Zielsystem die folgenden Informationen:

• API-Key: Identifizierung des Benutzers

• Melder-ID: Identifizierung des Leistungserbringers

• Auth-Token: Authentifizierungs-Token, welches zur Authentifizierung benötigt wird

Das Auth-Token wird mit Hilfe des Time-Based One-Time Password Algorithm (TOTP, RFC 6238, HMAC-SHA-1, 30 Sekunden Timeslot, gekürzt auf 6 Zeichen) aus dem Authentifizierungsschlüssel ermittelt. Wird das Auth-Token nicht angegeben, so muss vor der Ausführung des Deeplinks dieses beim Benutzer manuell durch die Applikationslogik des Deeplinks abgefragt werden.

Beispiel

Darstellung ohne Verschlüsselung und ohne Base64-Kodierung.

#/{"apiKey": <API-Key>, "melderId": <MelderID>, "authToken": <AuthToken>}
#/{"apiKey": "8277e0910d750195b448797616e091ad", "melderId": "200221", "authToken": "123456"}

Darstellung der verschleierten Authentifizierungsinformationen mit Base64-Kodierung

#/<Base64_Credentials>

#/ViDCXy0n+1vM3f...eY1f

Funktionen

Hinter den Authentifizierungsinformationen folgen die (Pfad-) Elemente für den Funktionsaufruf des Deeplinks. Dabei besteht eine Funktion immer aus maximal zwei (Pfad-) Elementen. Das erste Element beschreibt die auszuführende Funktion, das zweite Element enthält den Funktionsinhalt, welcher wie das Credentials-Objekt ein JSON Objekt ist. Die Funktionen mit den jeweiligen Deeplinks sind im folgenden Kapitel technisch definiert.

Der Funktionsaufruf und sämtliche Funktionsparameter werden zusammen mit dem Credentials-Objekt symmetrisch mit dem Portalschlüssel mit dem AES-Verfahren verschlüsselt und bilden ein Chiffrat. Das verschlüsselte Chiffrat wird mit einem Slash (/) getrennt von den Authentifizierungsinformationen (Credentials-Objekt) als Base64-Darstellung in dem Deeplink angegeben.

Beispiel

Darstellung ohne Verschlüsselung und ohne Base64-Kodierung. Das Crendentials-Objekt ist aus Gründen der Leserlichkeit gekürzt dargestellt:

#/{ [...] }/<Funktion>/<FunktionObjekt>

#/{ [...] }/patient/{"patientId":"test-123","vorname":"Max", [...] }

Darstellung mit Verschlüsselung und Base64-Kodierung. Das Credentials-Objekt ist ebenfalls wieder gekürzt dargestellt:

#/<Base64_Credentials>/<Base64_Funktion_Chiffrat>

#/ViDCXy0n+1vM3f...eY1f/8mfkBFQ1Eez32bM...P+7M=

Formale Beschreibung

Erläuterung

Im Folgenden ist der Aufbau der Deeplinks formal beschrieben. Dabei entsprechen <XY> benannte Platzhalter (Name XY). Platzhalter sind mit einem Gleichheitszeichen (=) definiert. Angaben in eckigen Klammern ([...]) sind optionale Angaben. Angaben, die mit einer Pipe (|) getrennt sind, bedeuten, dass entweder das eine oder andere gilt.

Die Angabe ENCRYPTED(...) definiert, dass der Inhalt entsprechend der kryptographischen Vorgabe verschlüsselt wird. Die Angabe BASE64(...) definiert, dass der Inhalt mit Base64 kodiert werden muss. Alle anderen Angaben stellen Literale dar und sind somit direkt zu übernehmen.

Definition

Allgemeine Definition des Deeplink

Deeplink = /BASE64(<Credentials>) [ /BASE64(ENCRYPTED(<Funktion>)) ]

Definition der Funktionen

Funktion = /<FunktionName> [ /<FunktionObjekt> ]

Definition der Nutzdaten einer Funktion

FunktionObjekt = {<FunktionParameter>}

FunktionParameter = <Parameter> : <Wert> [ , <FunktionParameter> ] Parameter = <Literal>

Wert = <Literal> | <FunktionObjekt>

Definition der Authentifizierung

Credentials = { "apiKey": <API-Key>, "melderId": <MelderID> [, "authToken": <AuthToken>] })

Definition der Elemente

• ENCRYPTED(*) entspricht der Verschlüsselung der Daten (*) mit dem Portalschlüssel

• BASE64(*) stellt die Base64-Darstellung der Daten (*) dar

• API-Key ist der API-Key des Benutzers

• MelderID ist die zu verwendende Melder-ID des Benutzers

• AuthToken ist das Geheimnis, welches zur erweiterten Authentifizierung genutzt wird und aus dem Authentifizierungsschlüssel ermittelt wird

• FunktionName ist eine Funktion, die ausgeführt werden soll. Diese werden im Folgenden genauer definiert.

Prozess / Ablauf

Für die symmetrische Verschlüsselung innerhalb des Deeplinks wird ein Schlüssel benötigt, welcher dem Quellsystem als Portalschlüssel vorliegt. Dieser sollte pro Benutzer des Zielsystems individuell sein.

Die Authentifizierungsinformationen des Credential-Objekts werden zur Verschleierung Base64 kodiert. Die Deeplink-Funktion wird mit dem Portalschlüssel verschlüsselt und Base64 kodiert. Aus diesen beiden resultierenden Base64-Chiffraten wird damit die Deeplink URL vollständig aufgebaut.

Der Deeplink wird dann im Browser aufgerufen und es wird vom Zielsystem eine Applikationslogik (JavaScript) zur Verfügung gestellt, welche die Abarbeitung des Deeplinks ausführen soll. Wenn von der Logik oder Applikationslogik die Rede ist, dann sind dies Funktionen die die HTTP Ressource des Deeplink ausliefert um diesen abzuarbeiten. Dies ist nur zur Veranschaulichung der API Spezifikation aufgeführt, aber nicht Bestandteil dieser. Die Implementierung der Logik ist in den einzelnen Meldeportal Projekten definiert.

Diese Logik wird im Folgenden die Verarbeitung des Deeplinks durchführen. In jedem Abarbeitungsschritt ist durch die Logik sicherzustellen, dass die Anfrage syntaktisch und soweit möglich auch inhaltlich vollständig und korrekt entsprechend der Spezifikation ist. Wird davon abgewichen, wird der Deeplink nicht ausgeführt und der Fehler dem Benutzer zurückgemeldet.

Die Logik wird zuerst das Base64-kodierte Credentials-Objekt auslesen. Wenn hier die Angabe des optionalen Authentifizierungs-Token fehlt, kann dies durch die Deeplink-Logik auf Meldeportal-Seite beim Benutzer angefragt werden. Das vollständige Credentials Objekt wird dann an das Zielsystem zur Authentifizierung gegeben.

Eine fehlerhafte Authentifizierung führt dazu, dass die Deeplink-Funktion abgebrochen wird. Durch eine erfolgreiche Authentifizierung darf der zum API-Key gehörende Portalschlüssel an die Deeplink-Funktion zurückgeliefert werden.

Mit dem erhaltenen Schlüssel wird dann der Inhalt des Deeplink entschlüsselt. Zuerst wird die Base64-Kodierung zurückgenommen und das Chiffrat mit dem erhaltenen Schlüssel entschlüsselt. Sollte dies nicht möglich sein, da der verwendete Schlüssel nicht mehr gültig ist, so kann der Deeplink nicht mehr verwendet werden. Der Anwender wird darüber informiert und die Verarbeitung endet an dieser Stelle.

Das entschlüsselte Chiffrat besteht aus einzelnen (Pfad-) Elementen. Sind Funktionen definiert werden diese vor der Verarbeitung, wie oben beschrieben, auf Syntax und Inhalt validiert und gegebenenfalls endet die Abarbeitung an dieser Stelle mit einem Fehler.

Jeder Deeplink enthält immer die Authentifizierungsinformationen. Bei der Authentifizierung kann es zu einer Sitzung im Browserkontext kommen. Um diesen Sitzungskontext explizit zu beenden wird eine Logout-Funktion definiert. Prinzipiell kann analog zur REST Schnittstelle ein Deeplink als eine in sich abgeschlossene Aktion angesehen werden. Nach Schließen des zugehörigen Browser Fensters oder Tab ist die Verarbeitung des Deeplinks vollständig beendet und ein Weiterführen der Sitzung nicht notwendig.

Konnte die Authentifizierung und die angegebene Funktion erfolgreich ausgeführt werden, so gilt die Verarbeitung des Deeplink als erfolgreich.

Zusammenfassung

Die verschiedenen Schritte im Ablauf müssen teilweise im aufrufenden System (Quellsystem) geschehen, andere Schritte müssen von der Logik der Implementierung des Deeplink passieren (Zielsystem). Diese werden wahlweise lokal oder remote ausgeführt.

1. Credentials-Objekt erzeugen (Quellsystem)

   1. API-Key und Melder-ID aufnehmen

   2. optional Auth-Token aus dem Authentifizierungsschlüssel mit Hilfe des TOTP Verfahren ermitteln (Quellsystem)

2. Funktion und deren Payload bestimmen und erzeugen ()

3. Deeplink URL mit Credentials-Objekt und Funktion zusammenstellen (Quellsystem)

   1. Das Credentials-Objekt wird Base64 kodiert in die URL gesetzt

   2. Die Funktion wird mit dem Portalschlüssel verschlüsselt und als Base64 Chiffrat eingesetzt

4. Aufruf der Deeplink URL (Quellsystem)

5. Authentifizierung mit dem Credentials-Objekt am Zielsystem (Meldeportal:remote)

   1. im Fehlerfall: Abbruch

   2. im Erfolgsfall: Portalschlüssel zurückgeben

6. Entschlüsselung des Base64 Chiffrats des Deeplink mit dem Portalschlüssel (Meldeportal:lokal)

7. Funktion entsprechend ausführen (Meldeportal:lokal)

Erläuterungen zur API

+Server+

Unter dem Abschnitt Servers sind mögliche Endpunkte für die Deeplinks benannt. Dies stellt nur ein exemplarisches Beispiel dar. Aus Gründen der formalen Beschreibungssprache kann in der Spezifikation kein Rautezeichen (#) direkt verwendet werden. Dies wird durch das Wort HASHTAG ersetzt.

+Pfade+ Die Pfade stellen die eigentlichen Deeplinks dar. Dies sind die Informationen die nach dem Rautezeichen (#) in exakt dieser Form zu folgen haben. In der Realität sind die Informationen verschlüsselt. Der verschlüsselte Deeplink sieht in allen Fällen wie folgt aus:

/{apiKey}/{chiffrat}

Es ist immer der API-Key im Klartext, gefolgt von einem Base64 Inhalt, der ein AES Chiffrat des eigentlichen Deeplinks darstellt.

+Authentifizierung+

Die Authentifizierungsinformationen werden in jedem Deeplink mitgegeben und sind damit immer ein Bestandteil des Deeplinks. Für alle Deeplinks gilt daher:

Die Authentifizierung ist im Kapitel Prozess / Ablauf näher erläutert. Ist das optionale Feld authToken nicht angegeben worden, muss zuerst der Benutzer in einem Dialog diese Information manuell nachliefern. Anschließend kann eine Authentifizierung durchgeführt werden. Tritt ein Fehler beim Authentifizieren auf, wird die Verarbeitung des Deeplinks beendet und der Benutzer durch einen entsprechenden Fehlerhinweis darauf hingewiesen!

Für die Folgende Spezifikation sind die Deeplinks alle unverschlüsselt dargestellt. In den einzelnen Deeplinks sind Beispiele und Formatierungshinweise vorhanden, wie diese zu betrachten sind.

Login

credentialsLoginGet

Authentifiziert den Benutzer und ruft das Meldeportal auf.

Nach erfolgreicher Authentifizierung wird die Startseite des Meldeportals aufgerufen und der Benutzer ist angemeldet. Im Fehlerfall wird dies dem Anwender in geeigneter Form zurückgemeldet.

+Beispiel des Deeplinks+

/<Credentials>/login - (Spezifikation)

/{"apiKey":"8277e0910d750195b448797616e091ad","melderId":"200221","authToken":"123456"}/login - (Unverschlüsselt)

/ViDCXy0n+1vM3f...eY1f/ZHNmZHNmc2Zk[...]c2Zhc2RmZA== - (Base64 und Verschlüsselt mit dem Portalschlüssel

GET

Usage and SDK Samples

Curl

Parameters

Path parameters

Responses

Status: default - Wurde der Benutzer korrekt angemeldet und authentifiziert wird die Startseite des Meldeportals angezeigt.

Logout

credentialsLogoutGet

Meldet den Benutzer mit dem API-Key ab.

Gehört die aktive Sitzung dem Benutzer mit dem angegebenen API-Key, wird diese Sitzung mit einem Logout beendet. Ist die aktive Sitzung nicht dem Benutzer zugehörig oder es gibt keine aktive Sitzung, wird dies mit einem Fehler quittiert.

+Beispiel des Deeplinks+

/<Credentials>/logout - (Spezifikation)

/{"apiKey":"8277e0910d750195b448797616e091ad","melderId":"200221","authToken":"123456"}/logout - (Unverschlüsselt)

/ViDCXy0n+1vM3f...eY1f/ZHNmZHNmc2Zk[...]c2Zhc2RmZA== - (Base64 und Verschlüsselt mit dem Portalschlüssel)

GET

Usage and SDK Samples

Curl

Parameters

Path parameters

Responses

Status: default - Die aktive Sitzung des Benutzers wurde beendet .

Meldung

credentialsMeldungMeldungGet

Es wird die übergebene Meldung im Anzeige- / Bearbeitenmodus geöffnet.

Mit dieser Funktion kann eine Meldung direkt aufgerufen werden.

+Beispiel des Deeplinks+

/<Credentials>/meldung/{MeldungRef} - (Spezifikation)

/{"apiKey":"8277e0910d750195b448797616e091ad","melderId":"200221","authToken":"123456"}/meldung/{"patientId":"ITC-2023-05-01","meldungId":"200221E0000123"} - (Unverschlüsselt)

/ViDCXy0n+1vM3f...eY1f/XaaAcDZmscZnNm[...]c4ZhcBamCd== - (Base64 und Verschlüsselt mit dem Portalschlüssel)

GET

Usage and SDK Samples

Curl

Parameters

Path parameters

Responses

Status: default - Es wird versucht die Meldung über die Referenzen `patientId` und `meldungId` zu finden. Im Erfolgsfall wird die Meldung geöffnet und im Anzeige-/Bearbeitenmodus angezeigt. Im Fehlerfall wird dies dem Anwender entsprechend dargestellt.

Patient

credentialsPatientPatientGet

Anlage, Bearbeiten oder Öffnen der Patientenakte eines Patienten.

Das Ziel dieser Anfrage ist es, die Akte zu dem gewünschten Patienten anzuzeigen. Dabei soll das Zielsystem den gesuchten Patienten über die Patientenreferenz patientId eindeutig identifizieren, ggf. anzulegen oder zu aktualisieren.

+Beispielhafter Ablauf+: Kann das System den gewünschten Patienten nicht eindeutig identifizieren, kann ggf. der Benutzer diesen aus einer Liste möglicher Patienten auswählen.

Es wird anschließend geprüft, ob sich Änderungen an den Stammdaten des Patienten ergeben haben. Dies kann durch Zeitstempel, Hashwerte, o.ä. geprüft werden. Bei einer Änderungen wird die entsprechende Aktion ausgeführt, bevor die Patientenakte geladen werden kann.

Ist noch kein Patient unter der Patientenreferenz vorhanden, so wird die Anlage des Patienten ausgeführt und danach die Patientenakte geladen. Das Primärsystem sollte hierfür, zusätzlich zu den technischen Pflichtfeldern der API, möglichst viele Informationen zum Patienten, insbesondere die Versichertendaten, im Deeplink übermitteln. Andernfalls müssen die Angaben durch die/den Nutzer*in vervollständigt werden, bevor die Anlage des Patienten abgeschlossen werden kann.

+Beispiel des Deeplinks+

In diesem Beispiel des vollständigen Deeplinks, ist das Patienten-Objekt gekürzt.

/<Credentials>/patient/<Patient> - (Spezifikation)

/{"apiKey":"8277e0910d750195b448797616e091ad","melderId":"200221","authToken":"123456"}/patient/ {"patientId":"ITC-2023-05-01","nachname":"Mustermann","vornamen":"Maximilian","geschlecht":"M","geburtsdatum":"1983-02-15E" - (Unverschlüsselt)

/ViDCXy0n+1vM3f...eY1f/rZAcDZmRzZnNm[...]c2ZhcBamZA== - (Base64 und Verschlüsselt mit dem Portalschlüssel)

GET

Usage and SDK Samples

Curl

Parameters

Path parameters

Responses

Status: default - Anzeige der Patientenakte im Erfolgsfall

Anhang

Open

 

Inhalt:

Meldeportal Deeplink API (PDF-Beschreibung dieser Seite und YAML)

Meldeportal REST API (PDF-Beschreibung und YAML)

Glossar (PDF)