Kontakt

Die Schnittstelle wird gepflegt und angepasst vom Schnittstellen-Team der RpDoc Solutions GmbH.

Bei Fragen oder Anmerkungen können Sie das Team über fhir@rpdoc.de erreichen.

Einleitung

Die RpDoc.SOA-Schnittstelle dient dem Abruf und Setzen von Teilnahme-Einwilligungen von Versicherten zu einem Krankenkassen-Projekt.

Mit Hilfe dieser Schnittstelle wird einer Anwendung ermöglicht:

  • abzufragen, ob ein Versicherter Teilnehmer an einem festgelegten Projekt ist,
  • abzufragen, welche Versicherte registrierte Teilnehmer für einen Leistungserbringer sind,
  • einen Versicherter-Teilnahmestatus für ein festgelegtes Projekt durch Leistungserbringer zu erfassen.

Der Aufruf erfolgt im Auftrag eines Leistungserbringers und wird im Kontext eines Projekts oder Vertrags stattfinden. Der Kontext muss vorab zwischen den Beteiligten abgestimmt werden und wird bei der Anfrage über das Feld "Aufrufkontext" im Request-Bundle angegeben.

Die Schnittstelle besteht aus zwei Funktionen. Bei GetEinwilligung wird beim Aufruf ein GETEINWILLIGUNG_REQUEST_BUNDLE übergeben und ein GETEINWILLIGUNG_RESPONSE_BUNDLE als Antwort erwartet. Bei SetEinwilligung wird beim Aufruf ein SETEINWILLIGUNG_REQUEST_BUNDLE übergeben und (nur im Fehlerfall) ein OperationOutcome als Antwort erwartet. Eine Verlinkung auf externe FHIR-Ressourcen ist nicht zulässig. Alle zum Request verfügbaren Daten sollen im Response enthalten sein. Im Rahmen dieser Schnittstelle ist kein Zugriff auf einzelne Elemente (zum Beispiel über GET mit Parametern) vorgesehen.

Als Grundregeln für die Arbeit mit Teilnahmeeinwilligungen gilt:

  • Der Service der Krankenkasse ist die einzige gültige Quelle bezüglich des Einwilligungsstatus. Das heißt, ein ggf. in der Endanwendung gespeicherter Einwilligungsstatus darf lediglich Dokumentationszwecken dienen, aber nicht für die Freigabe von Daten verwendet werden.
  • Vor dem Zugriff auf die Daten eines Versicherten, ist mindestens einmal pro Tag die Prüfung des Einwilligungsstatus obligatorisch.
  • Vor jeder Datenschutz-kritischen Aktion (zum Beispiel Bereitstellung von Daten an Dritte zur Konsultation oder für Evaluationszwecke) ist eine erneute Prüfung des aktuellen Einwilligungsstatus obligatorisch.
  • Nach dem Versuch, einen neuen Einwilligungsstatus zu Speichern ist ein erneutes Abfragen des aktuellen Einwilligungsstatus obligatorisch. Es darf nicht optimistisch davon ausgegangen werden, dass der gewünschte Status tatsächlich vom System der Krankenkasse übernommen wurde. Unabhängig davon, ob beim Speichern eine Fehlermeldung erzeugt wurde oder die Aktion (scheinbar) erfolgreich war.

Noch offene Punkte

Verschlüsselung

Neben der obligatorischen Sicherheitsmaßnahmen (TLS, Client-Zertifikat, IP-Pinning) soll eine zusätzliche Inhaltsverschlüsselung angewendet werden. Die Details werden derzeit noch ausgehandelt. (Stand 04/2024)

Anfragen-Limit

Die Struktur der Schnittstelle unterstützt grundsätzlich die Bündelung beliebig vieler Datenanfragen in einer Abfrage. Um die Performance des Service sicherzustellen, muss die Anzahl der Anfragen pro Bundle begrenzt werden. Dies ist allerdings von der Implementierung des Service abhängig und muss individuell abgestimmt werden. Bei Überschreitung der maximal zulässigen Bundle-Größe ist ein entsprechender technischer Fehler zurückzugeben. Erste Absprachen und Empfehlungen stehen derzeit noch aus. (Stand 04/2024)