Wir haben die SORMAS Schnittstelle genauer angeschaut und ausprobiert – mit Erfolg! Wir präsentieren die ersten curl-Requests, die helfen die Kontaktdaten schnell an SORMAS zu übermitteln. Für nicht-Tekkies bitte die Einleitung und das Fazit lesen. Ein Beitrag von Jan Kus und Andreas Finke.
Der nicht technische Teil
Wir sind weiterhin im Lockdown, das Corona-Virus verbreitet sich rasend schnell und es heißt weiterhin “durchhalten, durchhalten, durchhalten”. Zugegeben, was mir in meinem Social Media Feeds: Twitter, Facebook und LinkedIn begegnet, löst auch in mir Nervosität aus, sich eine lautstarke Reaktion zu verkneifen fällt oft schwer.
Positiver Nebeneffekt: mein Team und ich kommen ins Gespräch, mit Politik, mit Verwaltung, mit Städten, mit dem Land. Und wir haben weiterhin Lust, mit Elan und Speed unsere Unterstützung zur Bekämpfung dieser Pandemie weiterhin anzubieten. Nachdem wir seit März mit dem Veedelsretter fast 650.000 Euro dem Einzelhandel zugute kommen haben lassen, im Mai recoverapp.de und später recover health und recover care ins leben gerufen haben, stehen wir vor der nächsten Herausforderung: die Anbindung von recover an SORMAS und andere Systeme, die von Gesundheitsämtern zur Kontaktnachverfolgung genutzt werden Bspw. DiKoMa in Köln.
Die Intention des Ganzen liegt darin, mit den ersten Zeilen Code den Wettbewerb und Mitwirkung anzuregen, wir versuchen mit den Erkenntnissen nicht für uns einen Vorteil herauszuholen. Nur gemeinsam werden wir erfolgreich. Wer den technischen Teil skippen möchte, kann sich am Ende noch mal das Fazit anschauen. Wir unterstützen alle Gesundheitsämter gerne dabei eine technisch saubere Lösung und Dokumentation bereitzustellen, um schnell eine möglichst breite Masse an Kontaktdatenerfassungssystemen andocken zu lassen.
Der technische Teil
Zugegeben, fühlt sich die SORMAS API nicht direkt smooth an und es bedarf Nachfragen beim Entwicklerteam, um die entsprechenden Endpunkte zu finden. Nun sind wir fündig geworden. Wir haben die ersten Calls natürlich nicht ‘live’ gemacht, sondern die Testinstanz von SORMAS genutzt
Wir sind open source – alle Details findet ihr auch auf Github in diesem Link Ticket.
Voraussetzungen
Um die Kontaktdaten aus recover zu übermitteln, müssen wir ein paar Dinge vorbereiten: wir brauchen im SORMAS-Backend erstmal einen Fall zu dem alles weitere zugeordnet wird. Wir gehen davon aus, dass dieser im Live-Betrieb vom Gesundheitsamt angelegt wird und bei der Nachfrage nach den Kontaktdaten eine entsprechende Fallnummer kommuniziert wird.
Einen Fall anlegen
Zu Testzwecken haben wir einen Fall mit dem Account eines “Surveillance Officers” im SORMAS Webinterface angelegt. Ein Fall braucht mindestens ein Meldedatum, einen Vornamen, Nachnamen, Geschlecht und eine Einrichtung. Das Anlegen eines Falls resultiert in einer Fall-Id, die wir später brauchen werden.
Das Datenmodel von SORMAS
Für die Datenübermittlung, muss das Datenmodell von SORMAS kurz erläutert werden:
- FALL: Ein bestätigter Fall von Coronavirus, der über ein positives Testergebnis an das Gesundheitsamt weitergeleitet wurde.
- KONTAKT: Ein Kontakt einer anderen Person mit der Person aus dem FALL.
- PERSON: Eine Person die zum KONTAKT gehört.
Dabei ist die Relation folgende: FALL 1 → n KONTAKT 1 → 1 PERSON.
Ein Beispiel zur Veranschaulichung:
- Die Person aus einem Fall war in Gastronomie A am Tag X zwischen Y und Z.
- In diesem Fall muss Recover folgende Daten erstellen:
- n = Anzahl der Checkins in Gastronomie A (oder Bereich) am Tag X zwischen Y und Z
- n * PERSON
- n * KONTAKT
- Jedem KONTAKT ist dabei eine PERSON zugewiesen.
Die Datenübermittlung durch recover
Die SORMAS Schnittstelle ist nicht 100% REST-konform. Daher brauchen wir mehrere UUIDs, die wir generieren müssen, um die Daten entsprechend zu übertragen. Zu Testzwecken benutzen wir https://www.uuidgenerator.net/. In “echt” würde man sich diese natürlich on the fly programmatisch generieren.
Für die Autorisierung benutzen wir die selben Zugangsdaten wie für das SORMAS Webinterface (“Surveillance Officer”). Diese müssen in der API als Base64 encodiert im Authorization header gesetzt werden.
Schritt 1: eine Person anlegen
Um die Daten erfolgreich zu übertragen brauchen wir erstmal eine Person (s. Datenmodell weiter oben) und dafür auch eine “frische” UUID:
curl --location --request POST 'https://demoversion.sormas-oegd.de/sormas-rest/persons/push'
--header 'Authorization: Basic U3Vydk9mZjpTdXJ2T2Zm' . # Zugangsdaten vom Surveilance Officer
--header 'Content-Type: application/json'
--data-raw '[
{
"uuid": "<DEINE frische UUID>", # Das ist die eindeutige ID der PERSON. Diese kann über https://www.uuidgenerator.net/ generiert werden. Setzt man sie nicht oder benutzt man die selbe ID noch einmal, bekommt man einen 500er Server Fehler
"firstName": "Kontakt",
"lastName": "von Recover",
"sex": "OTHER"
}
]'Im nächsten Schritt brauchen wir einen Kontakt und dafür werden wiederum zwei UUIDs vergeben:
curl --location --request POST 'https://demoversion.sormas-oegd.de/sormas-rest/contacts/push'
--header 'Authorization: Basic U3Vydk9mZjpTdXJ2T2Zm'
--header 'Content-Type: application/json'
--data-raw '[
{
"uuid": "<DEINE erste frische UUID>", # Das ist die eindeutige ID des KONTAKTes. Diese kann über https://www.uuidgenerator.net/ generiert werden. Setzt man sie nicht oder benutzt man die selbe ID noch einmal, bekommt man einen 500er Server Fehler
"caze": {
"uuid": "<Die Fall UUID vom Anfang>" # Das ist die eindeutige ID des Falles die wir vorher im Webinterface kopiert haben. Später können wie diese ID über Recover ermitteln, indem der GA Mitarbeiter die ersten 6 Stellen mitteilt.
},
"disease": "CORONAVIRUS",
"reportDateTime": 1611232518,
"reportingUser": {
"uuid": "TN2E4T-2OUTRL-FUFFX2-BMACKCDU". # Siehe unter "Fazit und Ausblick", die UUID sollte sich eigentlich aus den User credentials ableiten.
},
"contactClassification": "UNCONFIRMED",
"person": {
"uuid": "<Die Person UUID aus Schritt 1)>" # Das ist die eindeutige ID der Person die wir vorher angelegt haben.
},
"healthConditions": {
"creationDate": 1611232518,
"uuid": "<DEINE zweite frische UUID>" # Muss generiert werden über https://www.uuidgenerator.net/ . Sollte man die nicht setzen, bekommt man einen 500er Fehler.
},
"contactProximity": "SAME_ROOM",
"contactProximityDetails": "Besuch der selben Einrichtung am 20.01. zwischen 14:00 und 16:00",
"contactCategory": "LOW_RISK",
"followUpStatus": "FOLLOW_UP",
"followUpComment": "Telefon Nummer aus Recover App 03012312312213"
}
]'“Boom – that’s it. It works like magic”. Man kann jetzt den Kontakt im SORMAS Webinterface sehen.
Postman-Collection
Wie gesagt, eigentlich kein Rocket-Science und doch hat es ein wenig Zeit gekostet dahinter zu kommen, wie das Datenmodell funktioniert und die API zu verstehen. Wir haben uns dazu paar Sample-Antworten via Postman angeschaut und die entsprechenden Mindest-Anforderungen an Attributen, die Notwendig sind, um erfolgreich die Daten zu übermitteln reverse-engineered. Die Collection findet ihr in unserem Repository.
Fazit und Ausblick
Wir haben die entsprechende Calls abgesetzt und stellen folgendes fest:
Positiv:
- Es gibt eine REST Schnittstelle für die Integration von Recover App
Daten. Ein Testlauf mit Testdaten und Test Credentials hat funktioniert. - Das Entwickler-Team von SORMAS hat uns effizient und gut geholfen und hat schnell auf Fragen geantwortet.
Optimierungsbedarf:
- Die IDs von neuen KONTAKT und PERSON muss auf Client Seite erzeugt werden. Das ist nicht 100% RESTful.
- Das Feedback im Fehlerfall ist unzureichend. In den meisten Fällen bekommt man einen 500er Server Error zurück ohne weitere Erklärung des Fehlers.
- Beim jedem API call muss die UUID des aktuellen Benutzers (Beispiel: SurvOff) mit angegeben werden. Das erhöht den Aufwand beim Client.
Offene organisatorische Fragen
Momentan herrscht noch Unsicherheit wie wir die Kontaktdatenerfassungssysteme, an die entsprechenden Endpoints der Gesundheitsämter kommen und entsprechende Nutzer mit Berechtigungen erhalten, die dann berechtigt sind diese API-Calls auszuführen. Und es wird sehr mühsam sein alle 400 Gesundheitsämter dazu zu kontaktieren. Wir möchten auch nicht mehr Arbeit produzieren, sondern Arbeit abnehmen und hoffen, dass Initiativen wie Innovation mit Öffentlicher Gesundheit uns dabei unterstützen können. Weiterhin gibt es Bundesländer wie Rheinland-Pfalz die auf andere Systeme wie Mikado setzen und es nicht abzusehen ist, dass diese abgelöst werden. Ob eine einheitliche Bundesweite Lösung zeitnah existieren wird, bleibt also ungewiss. Wir unterstützen wo wir können und bieten allen Gesundheitsämtern an, gerne mit uns ins Gespräch zu kommen, um das Thema SORMAS und Kontaktdatenerfassungssyteme auszulagern. Wir helfen bei einer Bundesweiten technischen Dokumentation. Open Source, Transparent und für alle Systeme nutzbar.
Wir für die Digitalisierung – eine gemeinsame Initiative der Kontaktdatenerfassungssysteme
Zum Schluss noch ein wenig Eigenwerbung: ab dem 01.02. starten wir unsere Aktion wirfuerdigitalisierung.de – ein Aktionsmonat, der auf das Thema Digitalisierung und speziell Kontaktdatenerfassung, SORMAS, Corona-Warn-App aufmerksam machen möchte. Unser Anliegen: Kontakterfassung digitalisieren und bestehende Lösungen nutzen und fördern, um Gesundheitsbehörden zu entlasten.
Wir planen Meetups, Talks und Diskussionsrunden zu verschieden Themen, das erste Meetup startet am 04.02. um 14:00 bei Zoom. Entsprechende Links werden über unsere Social Media Kanäle kommuniziert.
Wir für Digitalisierung ist ein Gemeinschaftsprojekt von:
recover, darfichrein.de, inög, Hygiene-Ranger, Snapweb24, Corona Presence, kontakterfassung, Digital Waiter, 2fdz, SmartMeeting, e-guest, scopevisio und gastident.
Photo by Alexander Sinn on Unsplash
