FAQs

Fragen, die bereits besonders häufig über die Hotline gestellt wurden, werden hier erklärt. Aktuell finden Sie hier Antworten zu den Themen:

Ist dann die Schnittstelle DEMIS-Survnet nicht mehr möglich? Also kommen Laborergebnisse ausschließlich durch DEMIS-SORMAS rein?

Die Meldungen kommen sowohl in der SurvNet-, als auch in der SORMAS-Instanz an. Die Meldungsbearbeitung sollte allerdings ausschließlich über SORMAS erfolgen.

Was ist mit dem DEMIS Import? Müssen wir da was machen?

Nein, der Anschluss erfolgt über den DEMIS Adapter, der von Nezlink an die jeweilige Sormas Instanz angeschlossen wird. Der DEMIS-Adapter ist wichtig für das Absetzen von Meldungen, der Empfang dieser wird vom DEMIS-Importer unterstützt

Ist es geplant, dass auch Abstrichzentren oder mobile Abstrichteams über SORMAS organisiert werden können?

Die Organisation in SORMAS für Abstrichzentren und mobile Abstrichteams steht auf der internen SORMAS-Wunschliste

Kann man denn nicht automatisiert nur veränderte/neue Datensätze senden lassen?

Seit der Version 1.59 ist es möglich im Fallverzeichnis nach nicht übertragenen oder nach in der letzten Übertragung geänderten Fällen zu filtern. Diese Fälle können dann markiert werden und im Massenbearbeitungsmodus an SurvNet übertragen werden.

Ist eine Falldefinitionskategorie für Schnelltests vorgesehen?

Von Seiten des RKI gilt ein Schnelltest als labordiagnostischer Nachweis, weshalb der Fall in die Kategorie C-E, abhängig von den Symptomen, eingeordnet werden kann. Eine andere Möglichkeit der Handhabung wäre die Fälle solange als Fallkategorie 0 zu führen, bis das angeordnete PCR – Ergebnis vorliegt. Die Übermittlung von Fällen mit positivem Antigennachweis ist gemäß Falldefinition jedoch vorgesehen.

Wie kann man sehen, welche Fälle heute neu angelegt wurden oder verändert wurden?

Sormas bietet die Möglichkeit, die angezeigten Daten im Fallverzeichnis nach verschiedenen Kriterien zu filtern. Unter anderem kann so auch nach neu angelegten Fällen über den Filter Meldedatum gesucht werden.

Erfolgt nach der Freischaltung der Schnittstellen generell die Arbeit über SORMAS oder betrifft dies nur COVID-19 Fälle?

SORMAS unterstützt das Fall- und Kontaktpersonenmanagement während der COVID-19-Pandemie, somit erfolgt für COVID-19 eine Bearbeitung ausschließlich über SORMAS und die angeschlossenen Schnittstellen. Für alle anderen meldepflichtigen Infektionskrankheiten wird weiterhin direkt SurvNet oder eine der anderen IfSG-Fachanwendungen zur Bearbeitung verwendet.

Welche Personendaten werden von SORMAS nach SurvNet übermittelt und sind diese verschlüsselt?

Es werden alle IfSG-relevanten Daten übermittelt, dabei werden personenbezogene Daten pseudonymisiert. Die Übertragung selbst erfolgt verschlüsselt.

Wird der Daten-Export aus SurvNet nicht vom Gesundheitsamt allein bewältigt?

Nein, wenn aber alle Daten inkl. der GUID übereinstimmen, sollte der Import sehr schnell durchlaufen. Die GUID wird automatisch in SurvNet vergeben und kann nicht manuell bearbeitet werden.

Was passiert, wenn nach der Migration doch noch Fälle in SurvNet angelegt wurden?

Der Datensatz muss in SurvNet dann gelöscht und in SORMAS neu angelegt werden.

Welche Einschänkungen im Arbeitsablauf treten während der Aktivierung der Schnittstellen und der Migration der Daten von Survnet nach SORMAS ein?

Die Bearbeitung von COVID-Daten in SurvNet wird während und nach der Migration verhindert. Alle anderen Infektionskrankheiten können jedoch nach wie vor weiter bearbeitet und gemeldet werden. Die Arbeit in SORMAS soll während dieser Zeit unterbrochen und erst nach erfolgter Migration wieder aufgenommen werden.

Welche Datensätze werden bei der Umstellung auf SORMAS X mit gleichzeitiger Aktivierung der Schnittstellen von Survnet nach SORMAS migriert? Nur die Meldepflichtigen?

Die Migration berücksichtigt die Gesamtzahl der vorhandenen Datensätze, nicht nur die meldepflichtigen Datensätze.

Was passiert mit den Daten, die nach der Datensicherung und vor der Beendigung des Kopierens erfasst werden?

Die Arbeit in SORMAS soll während der Migration unterbrochen und erst nach erfolgter Migration wieder aufgenommen werden. Zudem ist die Arbeit in SORMAS in dieser Zeit vollständig gesperrt.

Was hat sich geändert beim Löschen von Fällen und Ereignissen?

in SurvNet) sowie beim Löschen von Ereignissen Löschanfragen für SurvNet generiert, die aber erst beim nächsten Senden eines beliebigen Falls oder Ereignisses an SurvNet mitgesendet wurden. Bis dahin war der Fall bzw. das Ereignis noch in SurvNet zu sehen.
Nun wird die Löschanfrage in beiden Fällen und Ereignissen unverzüglich an SurvNet gesendet. Der entsprechende Datensatz ist damit in SurvNet nach dem nächsten Einlesen der Daten über die SurvNet-Transportverwaltung nicht mehr sichtbar, d.h. in Survnet auf verworfen gesetzt.

Wird die Falldefinitionskategorie von SORMAS an SurvNet übertragen?

Generell gilt, dass die Falldefinitionskategorie aus SORMAS nicht an SurvNet übertragen wird, außer, es wird die Falldefinitionskategorie „X.kein Fall“ gesetzt.
Die Auswahl der Falldefinitionskategorie „X.kein Fall“ führt in SurvNet immer zu „Verdacht nicht bestätigt“ im Bereich „Klinische Informationen“ / „Verdachtsfall“.
Das Setzen des Häkchens bei „Negatives Testergebnis zur Krankheit“ ist dazu nicht nötig und bietet den GÄ die Möglichkeit, diese zusätzliche Information in SORMAS zu erfassen. (Das Setzen hat keinerlei Auswirkungen auf SurvNet.)

Was muss man in SORMAS eingeben, damit in SurvNet der Haken bei „Gesamtgenomsequenzierung“ gesetzt wird?

Im Falle einer Gesamtgenomsequenzierung wählen Sie dazu in der Probe für den Erregertest im Feld „Art des Tests“ den Wert „Gesamtgenomsequenzierung“ aus und geben die Typisierungs-ID sowie die getestete Krankheitsvariante an.

Dann wird in SurvNet das Häkchen gesetzt und die Referenzdefinition in SurvNet ist erfüllt.

Wie werden Symptome (SORMAS) auf – Klinische Informationen (SurvNet) gemapped? Wann wird „Ja, aber ohne Symptomatik, die für die gemeldete Krankheit bedeutsam“ gesetzt?

Wenn in SORMAS alle Symptome weder auf Ja, Nein oder Unbekannt gesetzt sind, wird in SurvNet das Feld Klinische Informationen der Wert „nicht erhoben“ gesetzt.
Wenn in SORMAS alle Symptome auf Nein gesetzt werden, dann wird in SurvNet das Feld Klinische Informationen auf „Ja, aber ohne Symptomatik, die für die gemeldete Krankheit bedeutsam“ ist gesetzt.

Welche Personen-Daten werden an SurvNet gesendet? Müssen Fälle bei Änderungen immer an SurvNet gesendet werden?

Personenbezogene Daten sind nicht IfSG-relevant und werden nicht von SORMAS an SurvNet gesendet.
Daher müssen Fälle nicht von SORMAS an SurvNet gesendet werden, wenn nur solche Angaben geändert werden.

  • Nicht an SurvNet übermittelt werden: Vorname, Nachname, Geburts-Tag, Adressen, Kontaktinformationen, Reisepassnummer, Krankenversicherungsnummer.
  • Folgende Daten werden an SurvNet übermittelt: Geburtsjahr, Geburtsmonat, Geschlecht.

(Personenbezogene Daten sind gemäß DSGVO alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen.)

Beim Rollout wurden einige Fälle nicht i.R.d. Initialen Imports von SurvNet nach SORMAS importiert. Wir haben ein Liste mit solchen übersprungenen Fällen erhalten. Was ist zu tun?

Sie müssen die ExterneID in SORMAS mit der GUID des Falls in SurvNet befüllen. Dazu müssen Sie ggf. einen Export der entsprechenden Datensätze aus SurvNet und anschließend einen Import per csv-Datei in SORMAS vornehmen
Option 1:
Wenn Sie alle Daten eines Falles in SORMAS (nach)gepflegt haben und nur noch die ExterneID/GUID fehlt, dann nehmen Sie die SORMAS-Importdatei für den Import von Fällen, füllen Sie die Pflichtfelder aus und setzen Sie die GUID von SurvNet ein (inkl. der geschweiften Klammern!).
Anschließend führen Sie den Import durch.
Damit haben Sie nun 2 Fälle in SORMAS, die Sie über die Duplikatszusammenführung zu einem Fall zusammenführen. (Der obsolet gewordene Fall wird dabei automatisch gelöscht.)
Danach senden Sie den führenden Fall an SurvNet.
Option 2:
Sie exportieren zunächst die übersprungenen Fälle aus SurvNet.W
Die Daten tragen Sie in die SORMAS-Importdatei für den Import von Fällen ein und setzen die GUID von SurvNet ein (inkl. der geschweiften Klammern!).
Anschließend führen Sie den Import durch.
Damit haben Sie nun 2 Fälle in SORMAS, die Sie über die Duplikatszusammenführung zu einem Fall zusammenführen. (Der obsolet gewordene Fall wird dabei automatisch gelöscht.)
Ggf. pflegen Sie die Vorherigen Krankenhausaufenthalte (s.u.) manuell nach.
Danach senden Sie den führenden Fall an SurvNet.
Zu beachten:
Vorherige Krankenhausaufenthalte können nicht per csv-Datei in SORMAS importiert werden. Sie müssen ggf. manuell in SORMAS nachgeflegt werden.

Eine Herdkennung wird von anderem Gesundheitsamt (GA) gemeldet: Was passiert dann?

Wenn ein Ausbruch / Herdkennung gesundheitsamtübergreifend ist, dann verhält es sich so:

  • Es gilt grundsätzlich: GA 1 und GA 2 fügen jeweils ihre eigenen Fälle zu ihren eigenen Clustern hinzu, wobei beide Cluster dieselbe Herdkennung haben. Und GA 1 und GA 2 senden ihre eigenen Fälle und eigenen Cluster an SurvNet.
  • Die Landesstelle fügt anhand der Herdkennung XCZ die Cluster des GA 1 und GA2 mit den darin enthaltenen Fällen zusammen und meldet dies weiter.

Der Ablauf ist i.a. wie folgt:

  • GA 1 erstellt ein Ereignis mit Ereignisstatus Cluster in SORMAS, führt eigene Fälle zu, und sendet an SurvNet.GA 1 erkennt, dass auch ein Fall aus GA 2 an dem Ausbruch beteiligt ist und informiert
  • GA 2, dass dieser Fall, für den GA 2 der Zuständige LK/SK ist, am Ausbruch mit der Herdkennung XYZ beteiligt ist.
  • GA 2 erhält diese Information und legt ein eigenes Ereignis mit Ereignisstatus Cluster in seiner SORMAS-Instanz an, wobei es dieselbe Herdkennung XYZ und unterschiedlichem Aktenzeichen (das kann variieren) vergibt. GA 2 fügt den eigenen Fall bzw. die eigenen Fälle hinzu, und sendet den Fall und das Cluster an SurvNet.

Bei der Zusammenführung von 2 Fällen (einer mit und einer ohne Aktenzeichen) kommt eine Fehlermeldung mit Aktenzeichen doppelt vergeben.

Ist ein bekanntes Problem, dass eine Fehlermeldung erscheint, wenn man den Fall mit Aktenzeichen mit dem ohne zusammenführt (Fall A mit B zusammenführen):

https://github.com/hzi-braunschweig/SORMAS-Project/issues/5382

Als Lösung führt man die Fälle auf Basis des Falles OHNE Aktenzeichen zusammen (Fall B mit A zusammenführen).

Es werden uns leider manchmal Fälle aus anderen Landkreisen zugewiesen. Wie soll man damit jetzt umgehen, da die Bearbeitung gesperrt ist? Zuvor werden diese Fälle immer auf verworfen gesetzt.

Hierfür führen Sie einen CSV-Export dieser Fälle aus SurvNet durch und tragen danach in die Importvorlage für Fälle von SORMAS fiktive Fälle zusammen mit den jeweiligen externen IDs und Aktenzeichen der zu löschenden Fälle ein. Im Anschluss führen Sie einen Fall-Import durch und löschen diese neuangelegten Fälle, wodurch der Löschauftrag an SurvNet übermittelt wird. Die betroffenden Fälle werden hierdurch dann aus Ihrer SurvNet-Instanz gelöscht.

Ein Fall mit Reinfektion aus SurvNet führte beim initialen Import zu 2 Fällen in SORMAS. Wie soll damit weiter verfahren werden?

Einen Fall archivieren, den anderen Fall behalten und die Reinfektion dort vermerken. Im Anschluss wird dann dieser Fall zur Person verknüpft.

Trotz Fall-Zusammenführung in SORMAS, verbleibt trotzdem ein Fall mehr in SurvNet

Hierfür führen Sie einen CSV-Export dieses Falls aus SurvNet durch und tragen danach die externe ID und das Aktenzeichen des Falls in die Importvorlage für Fälle von SORMAS in einen Dummyfall ein. Im Anschluss führen Sie einen Fall-Import durch und löschen diesen neuangelegten Fall, wodurch der Löschauftrag an SurvNet übermittelt wird. Der betroffende Fall wird hierdurch dann aus Ihrer SurvNet-Instanz gelöscht.

DEMIS Meldungen bleiben auch nach Bearbeitung in SORMAS sichtbar und präsent.

Nur DEMIS Meldungen für Covid-19 werden via SORMAS verarbeitet, alle anderen nicht. Da es keine Rückkopplung an SurvNet gibt, verbleiben diese Meldungen im Eingang.

Die Übertragung SORMAS zu SurvNet beim Infektionsumfeld ergibt in SurvNet, dass Informationen noch fehlen. So wird dort z.B. nur „Ja“ und nicht „Ja, mit Symptomen“ hinterlegt.

Nur die vom RKI definierten Symptome für COVID-19 werden auch übertragen mit „Ja, mit Symptomen“.

Der Filter „Nur Fälle, die noch nicht an die Meldesoftware gesendet wurden“ zeigt nach der Migration alle beim Initialen Datenimport von SurvNet nach SORMAS übertragenen Fälle an, da diese noch nicht von SORMAS aus an SurvNet gemeldet wurden. Wie kann man jetzt diese Fälle von den neuen ebenfalls noch nicht gesendeten Fällen per Filter separieren?

Mit dem kommenden Update 1.61 werden die initial importierten Altfälle auf den Status „Bereits an Meldesoftware gesendet“ gesetzt. Hierdurch werden beim Setzen des Filters „Nur Fälle, die noch nicht an die Meldesoftware gesendet wurden“ auch nur noch die neuen Fälle angezeigt, die noch nicht an SurvNet gesendet wurden.

Nutzer sehen eine unterschiedliche Anzahl aller Aufgaben im Aufgabenverzeichnis

  • Nutzer mit identischen Rechten (z.B. Kontakt- und Überwachungsleitung, Ärztin) und identischem Zuständigkeitsbereich sehen nur Aufgaben für einen Fall/Kontakt/Ereignis,
    • welche sie selbst erstellt haben
    • welche ihnen zugewiesen wurden
  • Aufgaben anderer Nutzer sind nur sichtbar, wenn die Nutzer die identischen Rechte haben und die Aufgabe einen Kontext im zuständigen Landkreis (LK) hat
  • Wichtig: jeder Nutzer sieht alle ihm zugewiesenen bzw. selbst erstellen Aufgaben

Ein Nutzer dessen Rollenkombination die Rolle „Nationaler Benutzer“ enthält, sieht alle Aufgaben, die innerhalb der SORMAS-Instanz erstellt wurden. Das schließt ein:

  • alle Aufgaben mit vom Typ „Allgemein“
  • Aufgaben die sich auf Fälle/Kontakte/Ereignisse beziehen, die außerhalb der regulären Zuständigkeit des Amtes verortet sind (LK/SK oder sogar BL weichen von dem der SORMAS-Instanz ab)

Ein Nutzer mit der Rollenkombination (Arzt/Ärztin, Überwachungsleitung, Kontaktleitung):

  • sieht alle Aufgaben, die ihm zugewiesen wurden und die er erstellt hat
  • alle Aufgaben vom Typ Fall/Kontakt/Ereignis auf seiner Zuständigkeitsebene (identisches BL)

Ein Nutzer mit der Rolle „Beauftragter“

  • sieht alle Aufgaben, die ihm zugewiesen wurden
  • sieht Aufgaben nicht, wenn sie von ihm erstellt wurden, aber einem Nutzer mit mehr Rechten zugewiesen hat (z.B. einer Leitung)

Nur der „Verlauf der Erkrankung des Falls“ „Verstorben“ wurde beim initialen Import aus SurvNet übertragen, alle anderen Status wurden als „Unbekannt“ an SORMAS übertragen.

Das Mapping für das Feld „verstorben“ in SurvNet bezieht sich auf das Feld „Aktueller Zustand der Person“ in SORMAS. Der „Verlauf der Erkrankung des Falls“ wird zwar auf „Verstorben“ gesetzt, allerdings bedeutet nicht verstorben nicht automatisch, dass die Person auch genesen ist und daher, wird der Rest von SORMAS automatisch auf „Unbekannt“ gesetzt.

Was bedeutet der Untersuchungsstatus in SORMAS und wie wird dieser in SurvNet abgebildet?

Der Untersuchungsstatus bezieht sich auf eine durchgeführte Diagnostik vom Arzt oder eine durchgeführte Untersuchung im Labor. Das Untersuchungsdatum daneben gibt an, was zuerst stattgefunden hat: Diagnostik ODER Untersuchung. Eine Übermittlung vom Untersuchungsstatus inklusive Untersuchungsdatum nach SurvNet findet nicht statt, die Übermittlung der dafür zugrundeliegenden Diagnostik oder Untersuchung im Labor allerdings schon. Abgebildet wird die durchgeführte Diagnostik vom Arzt, die in SORMAS unter den „Meldungen“ im Reiter „Fall“ hinterlegt wird, und die Untersuchung im Labor, also die Informationen aus einer Probe der Art Antigennachweis, Eregerisolierung oder Nukleinsäure-Nachweis, in SurvNet unter den im Abschnitt „Zuordnung“ im Punkt „Meldungen“ angezeigten Informationen wie „Art des Meldenden“, „Datum der Meldung“ und „Datum der Diagnose“. Dabei entsprechen das „Datum der Meldung“ und das „Datum und Uhrzeit des Ergebnisses“ im Erregertest der Probe dem „Datum der Meldung“ und „Datum der Diagnose“ in SurvNet.

Wie funktioniert die Duplikatserkennung in SORMAS?

Die Dublettenerkennung basiert immer auf der Zuständigkeit des Benutzers, der Personen, Fälle, Kontakte oder Veranstaltungsteilnehmer anlegt oder in das System importiert. Daten, auf die der Benutzer keinen Zugriff hat, werden nicht berücksichtigt, so dass theoretisch auch bei konsequenter Nutzung der Dublettenerkennung durch jeden Benutzer die Entstehung von Dubletten möglich ist. Um dies zu beheben, haben Benutzer mit den entsprechenden Rechten Zugang zu speziellen Ansichten „Duplikate zusammenführen“ für Fälle und Kontakte, die über die Verzeichnisse zugänglich sind, wo sie das System durch Zusammenführen doppelter Daten bereinigen können.

Bitte beachten Sie, dass es derzeit keine Dublettenerkennung gibt, wenn Daten über die ReST-Schnittstelle an SORMAS übertragen werden! (Stand 1.61.2)

Wann wird eine bereits in SORMAS angelegte Person, Fall, Kontakt, Ereignisteilnehmer vom Programm erkannt? (Duplikatserkennung)

Personen

Immer wenn ein Benutzer versucht, Daten anzulegen, die Personen – Fälle, Kontakte oder Veranstaltungsteilnehmer – betreffen, wird das System auf ähnliche Personen geprüft, bevor eine anschließende Dublettenerkennung des eigentlichen Falls, Kontakts oder Veranstaltungsteilnehmers durchgeführt wird. Eine Person wird als potenzielles Duplikat eingestuft, wenn sie die folgenden Anforderungen erfüllt. Jede Variable, die für die erstellte Person nicht angegeben ist, wird bei dieser Berechnung ignoriert. Die Person muss mit mindestens einem Fall, Kontakt oder Veranstaltungsteilnehmer verknüpft sein. Wenn die Server-Eigenschaft duplicatechecks.excludepersonsonlylinkedtoarchivedentries aktiviert ist, muss der zugehörige Fall oder Kontakt bzw. das Ereignis, zu dem der Ereignisteilnehmer gehört, zusätzlich aktiv sein, d.h. nicht gelöscht und nicht archiviert. Standardmäßig ist diese Eigenschaft deaktiviert.

  • Die Person muss einen ähnlichen Namen haben.
  • Um ähnliche Namen zu erkennen, verwenden wir das pg_trgm-Modul von PostgreSQL, das Trigramme verwendet, um die Ähnlichkeit zwischen zwei Zeichenketten zu berechnen, in diesem Fall die Namen zweier Personen. Die Standardschwelle für die Ähnlichkeit ist 0,65. Dieser Schwellenwert kann durch Ändern des Werts der Servereigenschaft namesimilaritythreshold angepasst werden. Je höher der Wert, desto ähnlicher müssen die Namen sein, damit sie erkannt werden.
  • Beide Personen müssen das gleiche oder kein Geschlecht haben (falls bei der erstellten Person angegeben).
  • Das Geschlecht „Unbekannt“ passt zu jedem anderen Geschlecht, so dass das System eine Person mit dem Geschlecht „Unbekannt“ als potenzielles Duplikat einer Person mit dem Geschlecht „Männlich“, „Weiblich“ oder „Andere“ erkennen würde, solange alle anderen Anforderungen erfüllt sind.
  • Beide Personen dürfen kein unterschiedliches Geburtsjahr, -monat oder -tag haben.
  • Personen werden auch als potenzielle Duplikate erkannt, wenn ihr Geburtsjahr, -monat oder -tag leer ist. Sie werden nur dann ausgeschlossen, wenn es einen tatsächlich unterschiedlichen Wert gibt.
  • Beide Personen dürfen keine abweichende nationale Gesundheitskennung haben.

Wichtig: Alle oben genannten Anforderungen werden ignoriert (mit Ausnahme der Anforderung der Assoziation), wenn beide Personen dieselbe Reisepassnummer haben.

Fälle

Wenn ein Benutzer versucht, einen Fall anzulegen und eine potenziell doppelte Person identifiziert und ausgewählt wurde, wird das System zusätzlich auf ähnliche Fälle der ausgewählten Person geprüft. Ein Fall wird als potenzielles Duplikat eingestuft, wenn er die folgenden Anforderungen erfüllt. Jede Variable, die für den angelegten Fall nicht angegeben ist, wird bei dieser Berechnung ignoriert. Es werden nur Fälle berücksichtigt, die nicht als gelöscht markiert wurden, einschließlich archivierter Fälle.

  • Beide Fälle müssen die gleiche Krankheit haben.
  • Beide Fälle müssen dieselbe Aufenthaltsregion haben oder, wenn die Aufenthaltsregion leer ist, dieselbe zuständige Region.
  • Die Meldedaten beider Fälle müssen innerhalb von 30 Tagen nacheinander liegen.

Kontakte

Wenn ein Benutzer versucht, einen Kontakt zu erstellen und eine potenziell doppelte Person identifiziert und ausgewählt wurde, wird das System zusätzlich auf ähnliche Kontakte der ausgewählten Person geprüft. Ein Kontakt wird als potenzielles Duplikat eingestuft, wenn er die folgenden Anforderungen erfüllt. Jede Variable, die für den erstellten Kontakt nicht angegeben ist, wird bei dieser Berechnung ignoriert. Es werden nur Kontakte berücksichtigt, die nicht als gelöscht markiert wurden, einschließlich Kontakte von archivierten Fällen.

  • Wenn kein Ausgangsfall ausgewählt wurde, müssen beide Kontakte die gleiche Krankheit haben.
  • Wenn ein Ausgangsfall ausgewählt wurde, müssen beide Kontakte denselben Ausgangsfall haben.
  • Die Meldedaten beider Kontakte müssen innerhalb von 30 Tagen nacheinander erfolgen.
  • Die Daten des letzten Kontakts beider Kontakte müssen innerhalb von 30 Tagen liegen (falls für den erstellten Kontakt angegeben).

Teilnehmer an Ereignissen

Wenn ein Benutzer versucht, einen Veranstaltungsteilnehmer anzulegen und eine potenziell doppelte Person identifiziert und ausgewählt wurde, prüft das System zusätzlich, ob es für die ausgewählte Person bereits einen Veranstaltungsteilnehmer in der zugehörigen Veranstaltung gibt. In diesem Fall wird dem Benutzer eine Fehlermeldung angezeigt, die ihn über diesen Umstand informiert und ihn daran hindert, einen doppelten Veranstaltungsteilnehmer anzulegen.

Warum wurde die REST-API abgeschaltet?

In Anbetracht der Schlüsselrolle, die SORMAS sowie das gesamte Elektronische Melde- und Informationssystem für den Infektionsschutz insbesondere in der aktuellen Pandemielage einnehmen, müssen durchgehend hohe Qualitätsstandards in Bezug auf die Informationssicherheit gelten. Um zu vermeiden, dass über Drittanwendungen die Sicherheit des Meldesystems kompromittiert wird, wurde die REST-API in SORMAS seit dem 28. Mai 2021 vorerst deaktiviert.

Diese Deaktivierung erfolgte in Rücksprache mit dem Bundesministerium für Gesundheit und den Hinweisen des Bundesamts für Sicherheit in der Informationstechnik auf die gesamtgesellschaftliche IT-Sicherheitslage im Allgemeinen und die IT-Sicherheitsrisiken durch unsichere Drittanwendungen im Speziellen.

Bei Bedarf einer Aktivierung der Rest-API regen wir Sie an, in Kontakt mit den Herstellern der Drittanwendungen zu treten, um die Sicherheit dieser Anwendungen zu erhöhen und Wege für einen sicheren Datenaustausch mit dem SORMAS-System zu identifizieren.

Falls Sie Fragen haben, die hier nicht oder nicht ausreichend erklärt wurden, kontaktieren Sie uns gerne!