Skip to content

Destination API Nutzung klarer ausformulieren

Dokumentationsseiten (Pflichtfeld)

User Story

Wir (FIT-Connect) möchten Anbindungsprojekte dazu ermuntern, ihre Fachverfahren möglichst nutzerfreundlich zu gestalten, indem sie die Verwaltung von Zustellpunkten durch die Implementierung der Destination API direkt in das Fachverfahren integrieren.

Warum

Die Implementierung des Empfangs von Anträgen über FIT-Connect in einem Fachverfahren (Verwaltungssystem) beinhaltet, dass das Fachverfahren die Leistung(en) (=LeiKaIds), und die Fachdatenschemata (Schema-URIs) genau kennt, zu denen es Anträge verarbeiten kann. Gleiches gilt für die Metadatenversion(en), die es verarbeiten kann, und die Rückkanäle, die es es bedienten kann. Wozu soll also jemand diese Informationen manuell im SSP einpflegen, wenn das das Fachverfahren per Destination API viel besser erledigen kann?

Erkenntnis → Was muss dokumentiert werden? (Pflichtfeld)

In der Dokumentation sollte (am besten ganz oben) ein Abschnitt ergänzt werden, der beschreibt, wie durch Implementierung der Destination-API in einem Verwaltungssystem dessen Nutzern/Kunden die Pflege von Zustellpunkten wesentlich erleichtert wird.

  • Das Verwaltungssystem (Fachverfahren) sollte so gestaltet sein, dass die Nutzer dort lediglich die Daten eingeben, die das Verwaltungssystem selbst nicht liefern kann:
    • ClientID & ClientSecret, die der Nutzer im FIT-Connect-SSP anlegt (Subscriber-Client aka Verwaltungssystem) -> Das sind die Zugangsdaten, die das Fachverfahren benötigt, um "seinen" Zustellpunkt anlegen und pflegen zu können.
    • Kontaktdaten des technischen Ansprechpartners (Organisation,... E-Mail, Telefonnummer)
    • VPKI-Zertifikat (im Original, nicht die generierten öffentlichen JWKs)
    • den oder die ARS für den die betreffende Behörde zuständig ist.
  • Anhand seiner eigenen Spezifikation (LeiKaIds zu denen Anträge verarbeitet werden können, Fachdatenschemata und Metadatenschema-Versionen, die unterstützt werden, Rückkanäle, die bedient werden können) legt das Fachverfahren mithilfe der Client-Daten "seinen" Zustellpunkt an.
  • Das Verwaltungssystem generiert dafür aus dem Zertifikat die JWKs. Die öffentlichen JWKs hinterlegt es im Zustellpunkt, die privaten benötigt es selbst, um Anträge zu entschlüsseln bzw. Events zu signieren.
  • Wird das Fachverfahren aktualisiert, aktualisiert es auch den von ihm verwalteten Zustellpunkt. Bsp.: Für eine Leistung gibt es z.B. aufgrund einer Gesetzesänderung ein neues Fachdatenschema (neue XÖV-Version, neues FIM-Schema). Das hat das Fachverfahren implementiert, weswegen eine neue Version des Fachverfahrens ausgerollt wird. Dann aktualisiert das Fachverfahren im Zuge seines eigenen Updates das im Zustellpunkt konfigurierte Fachdatenschema.

Links, Hinweise, Bemerkungen

Ansprechperson (Pflichtfeld)

  • Zuständige PO: Laura Elges
  • Technische Ansprechperson: Andreas Aschauer

Akzeptanzkriterien (Pflichtfeld)

  1. Die Dokumentation beschreibt klar, wie Fachverfahren Zustellpunkte über die Destination API automatisiert anlegen, aktualisieren und verwalten können.
  2. Ein vollständiges Beispiel (Request / Response) für die automatisierte Anlage eines Zustellpunkts ist enthalten.
  3. Es wird erläutert, welche Felder vom Nutzer manuell befüllt werden müssen (ClientID, Zertifikat, ARS, Ansprechpartner).
  4. Das Zusammenspiel zwischen Destination API und SSP (Teamfunktion, Rollenverwaltung, Berechtigungen) ist beschrieben.
  5. Verantwortlichkeiten (z. B. Hersteller / Behörde / IT-Dienstleister) sind nachvollziehbar dargestellt.
  6. Ein Beispielprozess zur automatisierten Aktualisierung (z. B. bei Schemawechsel oder Gesetzesänderung) ist dokumentiert.
  7. Sicherheitsanforderungen und Zertifikatsmanagement (VPKI, JWKs) sind erklärt und verlinkt.

Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)

  • Bereitstellung einer Video Schritt-für-Schritt-Anleitung in der Mediathek.
  • Definition of Done wurde überprüft.
Edited by Laura Elges