Laufzeitgruppen & Richtlinien
Da Application-Polling sowohl die Performance der e-card Infrastruktur beim Vertragspartner als auch die des e‑card Systems beeinträchtigt, ist Application-Polling generell untersagt, sofern sich aus der Richtlinie kein anderes Vorgehen ergibt.
Application-Polling (s. Pkt. 1 der Definition) ist ausschließlich für die angeführten Funktionen innerhalb der folgenden Grenzwerte erlaubt:
| Grenzwert Intervall/[Einheit] | BASE Service SS12-Request |
| 1x/Dialog | getVertraege() |
| ≥120sec/VPNR | pollMessages() |
Überschreitungen der o.a. Grenzwerte sowie sämtliche andere Arten von Application-Polling (Pkt. 2 und 3 der Definition) sind nicht gestattet, zumal für Abfragen ohne Behandlungskontext bzw. fachlichen Kontext auch keine Rechtsgrundlage besteht.
Beispiele für nicht gestattete Programmabläufe sind:
- Aufbau und sofortige Schließen eines Dialogs
- Aufbau eines Dialogs, um einen Aufruf zu tätigen, gefolgt von sofortigem Schließen trotz Bedarf der Weiterverwendung
(Anm.: Hier können sehr hohe Dialoganzahlen zustandekommen.) - Unverändertes zyklisches Aufrufen von Methoden, die in gleichbleibenden Fehlern resultieren
Beispiele für nicht gestattete Aufrufe sind:
| Service | SS12-Request mit Beispielfall |
| ABS | Mehrmaliger Aufruf von abfragenLangzeitbewilligung() (z.B. mit identen Abfrageparametern und nicht im Rahmen der Replayfunktionalität) |
| BASE | hasUnreadMessages() im Sekundenabstand |
| BKF | checkBkfToken() ohne Behandlungskontext |
| KSE | Unberechtigtes Durchführen von doKonsultation() ohne Behandlungskontext doKonsultation() und unmittelbares Storno (außer im Falle einer Korrekturkonsultation) oder doKonsultation() und unmittelbarer Download der Konsultationsdaten |
| PROP | Mehrmaliger Aufruf von createBefund() ohne fachlichen Kontext |
| SAS | adressdatenAbfragen() ohne Behandlungskontext |
| VDAS | Mehrmaliger Aufruf von retrieveVersichertendatenPerStichtag() oder retrieveVersichertendaten() bzw. Aufruf ohne Behandlungskontext |
Für den Fall, dass ein Softwareprodukt gegen diese Richtlinie verstößt, wird der Softwarehersteller einmalig darüber informiert mit dem Ersuchen, sein Programm innerhalb einer festgesetzten Frist (nicht unter 14 Tage) entsprechend der Richtlinie zu ändern. Sollte die Änderung bis zu dem festgesetzten Zeitpunkt nicht vorgenommen worden sein, behalten wir uns vor, das Softwareprodukt an der SS12 zu sperren.
Für den Fall, dass mit dem Application-Polling eine akute Gefährdung für das e‑card-System verbunden ist („Gefahr im Verzug“), wird das Softwareprodukt umgehend, d.h. ohne Vorwarnung des Softwareherstellers, an der SS12 gesperrt.
Replayfunktionalität
Die Replayfunktionalität schützt das e‑card System und ELGA vor mehrmaligem Einbringen identer Datensätze. Bei schreibendem Zugriff von e‑card oder ELGA Funktionen soll die Response des Systems für kurze Zeit erneut abgefragt werden können. Dies gilt insbesondere dann, wenn:
ein Request aus der VP Software das Rechenzentrum erreicht hat und die fachliche Transaktion durchgeführt wurde, die Antwort aber nicht vom System des VP empfangen wurde.
- der Funktionsaufruf die Erzeugung eines Dokuments triggert (z.B. PDF), welches zusammen mit der Antwort vom e‑card System zurückgeliefert werden soll.
Grundsätzlich soll allen Funktionsaufrufen eine eindeutige Transaktions-ID im Request mitgegeben werden. Es soll jedoch nur bei relevanten Funktionen (bei denen IDs oder Dokumente zur weiteren Verarbeitung erzeugt werden, s.o.) im Bedarfsfall – wenn vom System keine Antwort empfangen wird – ein einmaliger Replay-Request (Wiederholung) mit der gleichen Transaktions-ID geschickt werden.
(Bei reinen Abfrage- oder Suchfunktionen kann der Request immer erneut ohne Replay ausgeführt werden.)
Weitere Informationen zur Replayfunktionalität finden sich in der aktuellen e-card Schnittstellenbeschreibung (JavaDoc).