Hinweise zum Antrag

Es gibt derzeit einige Besonderheiten, auf die der Empfänger eines Antrag hingewiesen werden muss. Zum Beispiel:

• Es besteht eine Signaturerfordernis, der Antragsteller kann jedoch keine Signatur oder einen Signaturersatz (z.B. eID) beibringen. Der Antrag wird daher hybrid eingereicht. D.h. es muss zusätzlich zur Übertragung ein unterschriebenes Dokument auf Papier kommen.
• Der Antrag konnte nicht plausibilisiert werden. In bestimmten Fällen kann die Prüfung der Daten des Antragstellers fehlschalgen, obwohl diese korrekt sind. Hier muss eine manuelle Nachprüfung bei der Zuständigen Stelle erfolgen.

Es lassen sich weitere ähnlich Hinweise finden, die einem Antrag mitgegeben werden sollten.

Vorschlag

Es wird in die "Application Metadata" unter additionalReferenceInfo ein Array notes mit aufgenommen. Die Notes bestehen aus

• einer verpflichtenden description vom Typ string,
• einer optionalen reference vom Typ string und
• einem optionalen identifier vom Typ Identifier.

Beispiel

  "additionalReferenceInfo": {
    "caseId": "JB/007",
    "subject": "Antrag auf neuen Dienstwagen",
    "notes": [
      {
        "description": "Antrag wird hybrid eingereicht. Der Antragsteller muss noch eine ausgedruckte und unterschiebene Kopie nachreichen.",
        "identifier": {
          "id": "hybrid",
          "schemeId": "urn:org.example:application-notes:v2",
          "schemeName": "Codes für Hinweise zu Anträgen",
          "schemeAgencyId": "uri:org.example",
          "schemeAgencyName": "Beispielorganisation"
        }
      },
      {
        "description": "Es bestehen Fehler in den Daten. Validieren Sie den Antrag manuell.",
        "reference": "antragsteller/adresse/hausnummer",
        "identifier": {
          "id": "invalid",
          "schemeId": "urn:org.example:application-notes:v2",
          "schemeName": "Codes für Hinweise zu Anträgen",
          "schemeAgencyId": "uri:org.example",
          "schemeAgencyName": "Beispielorganisation"
        }
      }
    ]
  }

added 1 deleted label

added 1 deleted label

added workflow::Peer Review label and removed 1 deleted label

Die Abbildung solcher Informationen als notes-Array halte ich für ungeeignet. Informationen zur Signaturerfordernis sollten vom Onlinedienst und Fachverfahren automatisch aus dem Kontext der Anfrage (z.B. anhand der Leika-ID) ermittelt werden.

Konkrete Anforderungen an zusätzlich zu übermittelnde Informationen sollten in konkret zu modellierenden, maschinenlesbaren Attributen abgebildet werden. Die Abbildung als "notes" mit entsprechenden Schema-URNs ohne Auflistung aller möglichen Schemata birgt die Gefahr hoher Koodinierungsaufwände bei der Implementierung von Fachverfahren, da nicht klar ist, welche Werte hier erwartet werden können/müssen.

Ich plädiere daher dafür, das notes-Array wieder vollständig zu streichen und die Bedarfe anders abzubilden.

Mögliche Anwendungsfälle:

• Nicht maschinenlesbare Hinweise (Texthinweise, die bei der Bearbeitung des Antrags im Fachverfahren angezeigt werden): a) vom Antragsteller und b) vom sendenden System (Online-Dienst).
• Maschinenlesbare Hinweise mit Schema-ID ("implementationSpecific"): Es sollte eine zentrale Liste (Git-Repository?) geben, in der alle eingesetzten Schemas zwingend hinterlegt werden müssen. Hintergrund: Fachverfahren sollten die Möglichkeit haben, sich über bestehende Erweiterungen des Standards zu informieren und diese ebenfalls zu unterstützen.

Hinweis von @Tobias_Schuh zur hybriden Einreichung: Infos zur hybride Einreichung sollten eher über ein fachspezifisches Datenmodell festgelegt werden (ggf. über ein FIM Datenfelder Baukastenelement) und nicht in der FIT-Connect-eigenen Datenstruktur für den Antragsdatenübermittlungsdienst verankert sein.

• Hybrid Einreichung könnte auch in Authentication strukturiert abgebildetet werden.
• Der andere Use-Case ist mir nicht so wirklich klar

Generell sollte man so Freitexthinweise vermeiden, da das unklare Prozesse nach sich zieht.

Ich würde das Issue erstmal aus Beta7 rausnehmen wollen. Teilaspekte kann man nochmal grundlegender betrachten.

Bei Einführung neuer Erweiterungen müssen Pull-Requests gegen die API-Spezifikation gestellt werden.

added 1 deleted label and removed workflow::Peer Review label

Änderung in der Spezifikation rückgängig gemacht.

removed milestone

removed 1 deleted label

@Alexander_Hoose @Marco_Holz @Andreas_Huber Was ist der Status hiervon? Steht nämlich noch im %v1 Milestone & eigentlich wurde alles dafür aus der API-Spec entfernt. Wenn das Relevant ist, sollte es eine entsprechende Proxy-Story in Jira geben.

Erstmal zurückstellen / aus der V1 entfernen.

In der aktuellen Version der Metadaten ist das Feld additionalReferenceInfo anpassbar, also selbst befüllbar. Ist es dennoch notwendig die notes, als explizit unterstütztes Feld hinzuzufügen?

/cc @Alexander_Hoose @Marco_Holz @Andreas_Huber