Pagination issue

[Goldkugel]

Dear Projectathon team,

we are trying to run the docker containers implementing the decentralised version of VHF. However, we are facing an issue.

The result of the queries is returned by using pagination. Unfortunately, in this case, there is no total count in the query, but it seems, that the scripts expect such a count. Is this correct? For a better explanation, we added a screenshot.

Thank you for your help in advance.

Best regards

AIIM Team of TUM Munich

[knoppiks]

cc @astruebi

[astruebi]

Hallo Goldkugel,

in Anbetracht des Namens und des Benutzerbildes gehe ich einmal davon aus, dass wir die Unterhaltung auf deutsch führen können :)

Ich habe versucht, das Problem nachzustellen. Es ist mir nicht gelungen. Folgende Fragen:

1. Welcher FHIR-Server ist hier im Einsatz?
2. Gibt es eine mögliche Erklärung, warum (für den Zeitraum 01.01.2019 bis 31.12.2022) nur 241 Observations mit einem NTproBNP-Code gefunden werden? Das sind ziemlich kleine Zahlen im Vergleich zu anderen Häusern (15.000 - 25.000). Ist das ein Testserver oder haben die meisten NTproBNP-Obeservationen keine der üblichen loinc-Codes?
3. Haben Sie in der config.toml irgendetwas geändert außer den Zugangsdaten für den FHIR-Server und VERBOSE?
4. Das Script lädt alle NTproBNP Obeservationen mit bestimmten loinc-Codes im oben genannten Zeitraum herunter. Dabei werden die subject-Referenzen der Observations über include ebenfalls heruntergeladen. Für jede einmalige dieser subject-IDs wird dann die Patienten-Resource herunter geladen. Wenn die Daten bzw. Referenzen auf dem Server stimmen, dürften das niemals weniger sein, als verschiedene subject-IDs bei den Observationen gefunden wurden. D.h. mind. eine Referenz einer subject-ID einer Observation zeigt ins Leere oder aus nicht nachvollziehbaren Gründen kommt eine Patientenresource nicht zurück. Können Sie das prüfen? Wenn Sie VERBOSE weiter hoch setzen (z.B. 4) dann sehen Sie auch die Anfragen selbst, Die kann man auch im Postman abschicken. Mit dem DEBUG-Parameter können Sie festlegen, ob die vom Script geladenen Bundles gespeichert werden sollen. Sie liegen dann als xml-Dateien im outputLocal.

[Goldkugel]

Hallo astruebi,

sehr gerne können wir die Unterhaltung auf Deutsch weiterführen.

Um Ihre Fragen zu beantworten:

1. Wir haben einen BLAZE mit der Version 0.17, die mit der aktuellen Version des Feasibility Trinagle ausgelifert wird (siehe https://github.com/medizininformatik-initiative/feasibility-deploy).

2. Wir haben die FHIR-Query vom Antrag zusammengestellt und sind auch auf diese Zahl (241) gekommen.

3. Wir haben "registryUser", "registryPass", "fhirServerUser" und "fhirServerPass" als Parameter hinzugefügt. "registry" und "fhirServerEndpoint" abgeändert und "BUNDLE_RESOURCES_COUNT = 200" und "DEBUG = TRUE", "VERBOSE = 4" gesetzt.

4. Wir glauben, dieses Problem bereits im Script von VHF-MI-zentral gefunden zu haben und haben bereits ein Issue dazu in ihrem GitHub erstellt (https://github.com/juliangruendner/pj7-data-extraction/issues/3). Es sieht so aus, als würde das Script eine Referenz in den Observations erwarten, allerdings ist das nicht bei uns immer der Fall, da wir auch Identifier verwenden. Eine Lösung wäre, wenn das Script Observations, ohne eine Referenz, ignoriert. Wäre das implementierbar?

Liebe Grüße

Das AIIM Team der TUM München

[astruebi]

Hallo Goldkugel,

1. Die meisten anderen DIZ, mit denen ich zu tun hatte, nutzen HAPIs. Meine Testserver sind aber fast auch immer aktuelle Blazes. Sollte also passen.
2. Ist denn klar, warum das so wenige sind? Die Zahl sollte deutlich größer sein. Kann es sein, dass NTproBNP bei Ihnen mit irgendeinem anderen Code kodiert wurde, den wir nicht in der Liste haben. Vielleicht auch irgendein Code, der kein Loinc-Code ist? Ein anderes DIZ hatte auch größtenteils Hauscodes verwendet und konnte natürlich mit der Originalabfrage keine/kaum Ergebnisse liefern. Bei der dezentralen Analyse wird bei so wenigen Observationen, die sich auf noch weniger Patienten verteilen, in den Analysen für die Subkohorten (Geschlecht, Alter) kaum noch etwas herauskommen.
3. Die 200 beim BUNDLE_RESOURCES_COUNT halte ich für sportlich, aber das ist der Blaze ja auch. In Polar ist der Default auf 10 gestellt, und ich habe ihn in diesem Projekt hier erst kürzlich auch von 50 auf 10 gestellt, weil es bei einem HAPI Probleme mit der 50 gab und im Polar über alle Serverarten hinweg gute Erfahrungen mit dem 10er Wert gesammelt wurden. Bei meinen Tests hat es von der Geschwindigkeit her keinerlei Rolle gespielt, ob es auf 50 oder auf 10 steht. Höhere Werte hatte ich nicht ausprobiert.
4. Ich hatte ja oben beschrieben, wie das Retrieval-Script die Observations lädt und dass dabei der Patient per include mit der FHIR-Search-Anfrage aufgelöst wird. Die Frage ist: Wie sehen die Resourcen ohne Referenz aus? Ist dort das Feld subject in der Tabelle leer? Kann ich bitte für beide Fälle (mit (auflösbarer) Referenz und ohne Referenz) mal eine aussagekräftige Beispielzeile bekommen?

Meine E-Mail-Adresse lautet übrigens alexander.struebing@imise.uni-leipzig.de. Vielleicht können wir uns auf diesem Weg auch mal zu einem Telefonat oder ähnlichem verabreden.

Viele Grüße A. Strübing

[astruebi]

Ich habe gerade nochmal nachgesehen. Die Tabellen werden ja erst gespeichert, nachdem der oben genannte Fehler auftritt. Somit kann ich keine Beispielzeilen aus den Tabellen erhalten.

Ich baue jetzt mal für das VERBOSE-Level 4 einen Log-Schritt ein, so dass (nur) in die Konsole alle subject-IDs aller Observations geloggt werden und vielleicht noch weitere Informationen. Dann kann man vielleicht erkennen, wie sich die ungültigen Referenzen von den gültigen unterscheiden.

[astruebi]

Guten Morgen,

aktueller Stand: Observations, deren Patientenresource nicht aufgelöst und geladen werden kann, werden jetzt entfernt. Es wird geloggt (unabhängig vom VERBOSE in die Konsole und die ErrorMessage.txt), welche Referenzen nicht aufgelöst werden konnten. Zusätzlich dazu wird in die Konsole und die Retrieval.log geschrieben, wie viele Observations deswegen entfernt wurden.

Bitte diesen Stand einmal ausprobieren. Falls ein Fehler auftritt, bitte ausprobieren, ob derselbe Fehler immer wieder auftritt.

Ich konnte meine Testdaten jetzt so ändern, dass auch ich diesen Fehler mit den nicht auflösbaren Referenzen von den Observations auf die Patienten habe. Aber er hat bei mir nicht zu dem ursprünglichen Fehler dieses Issues von oben geführt.

[Goldkugel]

Hallo astruebi,

frohes neues Jahr und vielen lieben Dank für Eure Mühe.

Wir haben nochmal alles durchlaufen lassen, dieses Mal sieht es sehr viel besser aus. Es gibt nur eine Fehlermeldung (Inhalt der ErrorMessage.txt):

Errors in Retrieval from 2023-01-10 10:29:17: could not resolve Patient ID references from Observations: 1: NA

Dieser Fehler tritt bei jedem Ausführen aus.

217 Encounters wurden als Ergebnis zurückgeliefert, diese passen zu 184 Patienten. 24 Observations wurden entfernt, da sie ungültige Referenzen zu Patienten haben.

BUNDLE_RESOURCES_COUNT haben wir noch auf 200 gelassen.

Wir nehmen an, dass sich Deine Frage bzgl wie die Ressourcen ohne Referenz aussehen durch den erfolgreichen Durchlauf erübrigt hat.

PS: Wir haben noch ein Problem mit dem VHF-zentral (https://github.com/juliangruendner/pj7-data-extraction/issues/3), wir nehmen an, dass das wohl noch etwas länger braucht.

Vielen Dank nochmal für die Mühe und die Hilfe, unserer Meinung nach, kann das Issue geschlossen werden.

Liebe Grüße

Goldkugel

[astruebi]

Hallo Goldkugel,

ebenfalls ein frohes und gesundes neues Jahr und schön, dass es sich geklärt hat bzw. für meinen Bereich jetzt funktioniert!

(Mind.) 2 Fragen bleiben offen:

1. Woher kommen die fehlerhaften subject-Referenzen?
2. Die Frage, die oben bereits beide Male meine Frage 2 war, stellt sich immer noch: Warum sind insgesamt nur so wenige NT-proBNP-Observationen vorhanden und nicht mind. 10 oder 100 mal so viele? (siehe oben).

Viele Grüße

A. Strübing

[Goldkugel]

Hallo astruebi,

zu Deinen Fragen:

1. Wir haben keine Observations mit "fehlerhaften" Referenzen, sondern welche mit Referenzen, die sich nicht auflösen lassen (da sie auf einen Identifier zeigen, nicht auf einen auflösbaren URL, falls der entsprechende Patient noch nicht geladen wurde). Dieses Problem haben wir bereits bei einem anderen Projekt beschrieben. (https://github.com/juliangruendner/pj7-data-extraction/issues/3)

2. Wir vermuten, dass sich die geringe Anzahl der gefundenen Observations durch den geringen zeitlichen Overlap zwischen den P21 und den Lab Daten erklären lässt.

Beste Grüße

Goldkugel