medizininformatik-initiative / INTERPOLAR

CDS Tool Chain Repository
https://medizininformatik-initiative.github.io/INTERPOLAR/
4 stars 0 forks source link

Error beim Ausführen des Befehls: docker compose run --rm --no-deps r-env Rscript R-db2frontend/StartDB2Frontend.R #334

Open vicho001 opened 1 month ago

vicho001 commented 1 month ago

Hallo, wir sind vom Standort Essen und haben in den letzten Schritten noch Probleme.

docker compose run --rm --no-deps r-env Rscript R-db2frontend/StartDB2Frontend.R

Try to connect with: 
   dbname=cds_hub_db
   host=cds_hub
   port=5432
   user=db2frontend_user
   password=db2frontend
   schema=db2frontend_out
importRecords will change how it validates data in version 3.0.0.
We recommend preparing your data for import using castForImport .
Error in copyDB2Redcap() : 1 assertions failed:
 * The variable(s) patient_fe_id, pat_gebdat, pat_aktuell_alter,
 * pat_geschlecht are not found in the project and/or cannot be
 * imported.
Calls: copyDB2Redcap ... <Anonymous> -> importRecords.redcapApiConnection -> <Anonymous>
Execution halted

Hinzu kommt bei dem Schritt davor Warnings, die eventuell zum oberen Error führen könnte:

No Encounter found for PID Patient/12345...
No Encounter found for PID Patient/55555..
No Encounter found for PID Patient/67890...
...
The following tables are found in database: fall_fe, medikationsanalyse_fe, mrpdokumentation_validierung_fe, patient_fe, risikofaktor_fe, trigger_fe
astruebi commented 1 month ago

Die Warnings aus dem Modul 'dataprocessor' deuten darauf hin, dass die Fälle der Patienten mit den oben genannten IDs nicht zum "aktuellen" Datum passen.

Sind die Daten der Patienten im ersten Modul 'cds2db' mit einem in der Vergangenheit liegenden 'DEBUG_PERIOD_START' und DEBUG_PERIOD_END eingespielt worden? Falls es so ist, muss in der Konfigurations-TOML-Datei des Moduls 'dataprocessor' auch ein passendes Datum eingestellt werden. Was passend heißt, steht im Kommentar über der Variable. Im Echtbetrieb sollten alle Variablen mit dem Präfix 'DEBUG_' aber deaktiviert sein.

Sehr wahrscheinlich wurden einfach überhaupt keine Fälle zu irgendeinem Patienten gefunden, was den Fehler verursacht. Die Fehlermeldung hier muss von uns verbessert werden,

medicreitzner commented 1 month ago

Hallo zusammen, wir haben das gleiche Problem. "DEBUG_" ist bei uns aber deaktiviert.

vicho001 commented 1 month ago

Wir haben auch keinen "DEBUG_" gesetzt. Einige Encounter haben bei uns auch keinen "period", liegt das Problem eventuell daran? Eine Option zum Printen der FHIR Search Query könnte enorm bei der Fehlersuche helfen.

astruebi commented 1 month ago

Allgemein gilt: Wenn in Tabellen geschaut werden soll, dann ist immer das DB-Schema 'db_log' gemeint, das den Kern der Datenbank anzeigt. Da die Cron-Jobs zum Überspielen der Daten in den Kern immer 1 mal pro Minute laufen, muss man ca. 1 Minute warten nachdem ein Modul gelaufen ist.

Um das Ganze prinzipiell erst einmal zu Laufen zu bekommen, empfiehlt es sich, mit einer leeren Datenbank zu starten. (docker compose down -> docker volume rm <%name-des-volumes-cds_hub_db%> -> docker compose up)

Dann Modul 'cds2db' starten:

Fragen: 1.) Wie werden die Patienten IDs ermittelt? Über die source-pid.txt Datei oder über die Filter für die Encounter? 2.) Stehen ca. 1 Minute nach dem Durchlauf des Moduls 'cds2db' im Schema 'db_log' Daten in der Tabelle 'pids_per_ward'? 3.) Stehen auch Daten in den Tabellen 'patient' und 'encounter'?

In allen 3 Tabellen sollten Daten stehen.

Dann das Modul 'dataprocessor' starten. Das Modul schreibt die Tabellen 'patient_fe' und 'fall_fe'. Dort sollte am Ende irgendwas drinstehen. Das sind die Tabellen, die das Frontend anzeigt.

Fragen: 4.) Kommt bei allen Patienten-IDs, dass kein Encounter gefunden wurde oder nur bei einigen? (Es werden nur Encounter gefunden, wenn für die jeweilige Patienten-ID mind. ein Encounter ein Startdattum < aktuelles Datum hat und ein leeres Enddatum oder ein Enddatum nach dem aktuellen Datum und dieser Encounter keine partOf-Beziehung hat.)

cDataPusher commented 1 month ago

Hallo; selber Fehler bei mir. Bei mir ist die fall_fe leer. Beim Data Processor wird in Funktion createEncounterFrontendTable SELECT * FROM v_encounter_all WHERE enc_patient_id IN ('') ..

enc_patient_id sind jedoch mit dem Prefix Patient/ versehen, so dass

  SELECT COUNT(*) FROM db2dataprocessor_out.v_encounter_all e join db_log.pids_per_ward p on 'Patient/'||p.patient_id = e.enc_patient_id

ein Ergebnis liefert, während die im Code verwendete pids_per_ward$patient_id lediglich integer beinhaltet ( SELECT COUNT(*) FROM db2dataprocessor_out.v_encounter_all e join db_log.pids_per_ward p on p.patient_id = e.enc_patient_id)

Dadurch werden keine Encounter gefunden.

Das Hinzufügen von 'Patient/' für den join bringt jedoch Probleme mit sich, das wir später im Code wieder den gleichen Vergleich, diesmal in R, durchführen. Meine Übergangslösung aktuell ist folgende: das enc_patient_id in CAST(SPLIT_PART(enc_patient_id, '/', 2) AS INTEGER) abändern

sowie anschließend den Vergleich anpassen:

pid_encounters <- encounters[sub("Patient/", "", encounters$enc_patient_id) == as.character(pid), ]

Das sollte zumindest das Encounter-Problem lösen, wobei bei mir auch einige wenige Encounter keine Patienten finden.

@vicho001 wie sieht bei euch db_log.patient_fe aus? Klingt ja laut Fehlermeldung so, als würden Spalten fehlen.

Grüße aus Dresden

cDataPusher commented 1 month ago

Guten Morgen, ein paar Beobachtungen, da ich nun eine ähnliche Fehlermeldung bekomme: es gibt leichte Differenzen zwischen den Attributbezeichnern in Redcap und in der Datenbank. Trotz Anpassung der Feldbezeichner kam es jedoch zu diversen Fehlermeldungen. Ich vermute, dass die von mir importierte Redcap-Projektdefinition inzwischen geändert wurde und die cdsdb und Skripte nicht mit der bisherigen Version kompatibel sind.

Nach verwenden des letzten Releases des Redcap-Projektes besteht das Problem jedoch weiterhin. Ein direkter Import mittels httr

patient_json <- jsonlite::toJSON(PatientFromDB, dataframe = "rows")
response <- httr::POST(
    url = REDCAP_URL,
    body = list(
      token = REDCAP_TOKEN,
      content = 'record',
      format = 'json',
      type = 'flat',
      data = patient_json,
      returnFormat = 'json'
    ),
    encode = "form"
  )

funktioniert.

Verwende ich jedoch die Funktion redcapAPI::importRecords, welche für data ein DataFrame erwartet, erhalte ich folgenden Fehler:

importRecords will change how it validates data in version 3.0.0.
We recommend preparing your data for import using castForImport .
Error in copyDB2Redcap() : 1 assertions failed:
 * The variable(s) record_id, patient_fe_id, pat_id, pat_name,
 * pat_vorname, pat_gebdat, pat_aktuell_alter, pat_geschlecht,
 * patient_complete are not found in the project and/or cannot be
 * imported.
Calls: copyDB2Redcap ... <Anonymous> -> importRecords.redcapApiConnection -> <Anonymous>
Execution halted

Beispiel-Dataframe:

  PatientFromDB <- data.frame(
    record_id = c("123", "125", "126", "124"),
    patient_fe_id = c(123, 125, 126, 124),
    pat_id = c("51251", "12345", "54321", "12543"),
    pat_name = c(NA, NA, NA, NA),
    pat_vorname = c(NA, NA, NA, NA),
    pat_gebdat = as.Date(c("1997-01-01", "1987-01-01", "1977-01-01", "1976-01-01")),
    pat_aktuell_alter = c(NA, NA, NA, NA),
    pat_geschlecht = c("female", "male", "male", "female"),
    patient_complete = c(2, 2, 2, 2)
  )

Auch das Platzieren von der vorgeschlagenen Funktion redcapAPI::castForImport vor das importRecords hat zu einem Fehler geführt:

  Error in copyDB2Redcap() : 1 assertions failed:
 * Variable 'fields': Must be a subset of
 * {'record_id;;record_id','patient_fe_id;;patient_fe_id','pat_id;;pat_id','pat_name;;pat_name','pat_vorname;;pat_vorname','pat_gebdat;;pat_gebdat','pat_aktuell_alter;;pat_aktuell_alter','pat_geschlecht;;pat_geschlecht','patient_complete;;patient_complete','patient_id_fk;;patient_id_fk','fall_typ_id;;fall_typ_id','fall_fe_id;;fall_fe_id','fall_pat_id;;fall_pat_id','fall_id;;fall_id','fall_studienphase;;fall_studienphase','fall_station;;fall_station','fall_aufn_dat;;fall_aufn_dat','fall_aufn_diag;;fall_aufn_diag','fall_gewicht_aktuell;;fall_gewicht_aktuell','fall_gewicht_aktl_einheit;;fall_gewicht_aktl_einheit','fall_groesse;;fall_groesse','fall_groesse_einheit;;fall_groesse_einheit','fall_bmi;;fall_bmi','fall_nieren_insuf_chron;;fall_nieren_insuf_chron','fall_nieren_insuf_ausmass;;fall_nieren_insuf_ausmass','fall_nieren_insuf_dialysev;;fall_nieren_insuf_dialysev','fall_leber_insuf;;fall_leber_insuf','fall_leber_ins

, was das data dictionary in Redcap darstellt.

Die Spaltenbezeichner im Dataframe gleichen der in Redcap, aber der check der Attribute, (hier beschrieben)[https://www.rdocumentation.org/packages/redcapAPI/versions/2.9.1/topics/importRecords] schlägt fehl. print(redcapAPI::exportFieldNames(redcapcon)) gibt das data dictionary zurück.

mayadogh commented 1 month ago

@cDataPusher: es scheint wirklich so zu sein, dass das REDCap Projekt ein älteres ist. Vom Release 0.2.x ist auf Sharepoint -> INTERPOLAR -> Referenzarkitektur -> eDataCapture -> Release 0.2.x das neueste zu finden.

cDataPusher commented 1 month ago

Liebe @mayadogh, ich habe das neuste Release vom Redcap-Projekt INTERPOLARDev_2024-06-12_1131.REDCap.zip verwendet, was ich etwas missverständlich ausgedrückt habe. Alles aus dem zweiten Kommentar ist auf diesem Release. Verwunderlich ist unabhängig vom Redcap-Projekt, dass die record_id auch nicht gefunden wird, obwohl diese Standard in Redcap-Projekten ist.

mayadogh commented 1 month ago

Liebe(r) @cDataPusher, hmm, wenn nicht mal record_id geht, ist wahrscheinlich das Problem irgendwo anderes. Nur folgendes fällt mir ein als erstes zu überprüfen (vielleicht auch schon gemacht?):

  1. Ist das API Token im Projekt eingeschaltet?
  2. Sind Token & URL im R-toml richtig?
  3. Funktioniert ein Export? (Das wäre manuell in R nur dieses Teil des Codes laufen zu lassen, nicht mal in die DB lesen lassen, einfach in der Konsole.)
  4. Wenn der Export geht, welche Felde sind zu sehen?

VG

astruebi commented 1 month ago

Hallo; selber Fehler bei mir. Bei mir ist die fall_fe leer. Beim Data Processor wird in Funktion createEncounterFrontendTable SELECT * FROM v_encounter_all WHERE enc_patient_id IN ('') ..

enc_patient_id sind jedoch mit dem Prefix Patient/ versehen, so dass

SELECT COUNT(*) FROM db2dataprocessor_out.v_encounter_all e join db_log.pids_per_ward p on 'Patient/'||p.patient_id = e.enc_patient_id

ein Ergebnis liefert, während die im Code verwendete pids_per_ward$patient_id lediglich integer beinhaltet ( SELECT COUNT(*) FROM db2dataprocessor_out.v_encounter_all e join db_log.pids_per_ward p on p.patient_id = e.enc_patient_id)

Dadurch werden keine Encounter gefunden.

Das Hinzufügen von 'Patient/' für den join bringt jedoch Probleme mit sich, das wir später im Code wieder den gleichen Vergleich, diesmal in R, durchführen. Meine Übergangslösung aktuell ist folgende: das enc_patient_id in CAST(SPLIT_PART(enc_patient_id, '/', 2) AS INTEGER) abändern

sowie anschließend den Vergleich anpassen:

pid_encounters <- encounters[sub("Patient/", "", encounters$enc_patient_id) == as.character(pid), ]

Das sollte zumindest das Encounter-Problem lösen, wobei bei mir auch einige wenige Encounter keine Patienten finden.

@vicho001 wie sieht bei euch db_log.patient_fe aus? Klingt ja laut Fehlermeldung so, als würden Spalten fehlen.

Grüße aus Dresden

Dieses Problem sollte jetzt behoben sein (commit 359e3561e9cfef7cf00156fb0026e1d4c1bedbd7). Im aktuellen "release"-Branch ist es gefixt.

Das Problem trat nur auf, wenn die relevanten Patienten über die Textdatei "source_PIDs.txt" übergeben wurden. Wenn dort keine vollständigen Referenzen wie z.B. "Patient/UKB-001" angegeben wurden, sondern nur IDs wie "UKB-0001", dann kam es zu dem Fehler. Wir haben es so geändert, dass man beides angeben kann, also das "Patient/" später im Code ergänzt wird, wenn es fehlt. Siehe auch den neuen Kommentar in der Beispieldatei "source_PIDs.txt".

Das Problem mit den angeblich fehlenden Redcap-Spalten bleibt aber bestehen.

mayadogh commented 1 month ago

@cDataPusher : wollen wir mal per Vidko dieses Problem anschauen? Ich hätte heute 14:30 Zeit oder morgen um 11:00, mir bitte anschreiben.

JustAzes commented 1 month ago

Da wir auch gemeinsam keine Lösung gefunden haben, werde ich den oben beschriebenen REST-request verwenden. @medicreitzner und @vicho001 könnten Sie bitte schauen, ob dies für Sie auch eine Option darstellt?