Datum: 04.04.2023

Autoren: [email protected] & [email protected]

Dieses Project führtdas MIRACUM ("WE-STORM") Projekt vom 6. Projectathons aus. Hier ist eine dezentrale Analyse (distributed On-Site and Federated Learning)vorgesehen. Dieses Repository beinhaltet Skripte für das zweistufige Verfahren:

• Skript-1 (Step 1 - Abfrage) erzeugt mehreren Tabellen mit (anonymen, grob)aggregierten Daten, die für die Planung der statistischen Analysen (Step 2) benötigt werden. Diese Tabellen wurden zentral evaluiert und somit an die datenauswertendende Stelle (MIRACUM, Mannheim) übergeben.
• Skript-2 (Step 2 Analysen) neues Update vom 13-01-2023, im Folder step2 des master Branches, führt die basierend der Step 1 erstellten statistische Modelle und Maschinelle Lernalgorithmen aus. Die Modelle werden ausschließlich lokal (im jeweiligen DIZ) trainiert und nur die Modellobjekte werden i.R. des Federated Learning Verfahrens zusammengeführt.

Das Readme beschreibt zunächst die technischen Details der Verwendung. Darunter sind die verwendeten CodeSysteme/Ressourcen/Profile und der konzeptionelle Ablauf der Abfrage beschrieben.

• Finaler Abschluss der Testphase 31.03.2023 der Step2 Skripte für HAPI und BLAZE FHIR Servers inkl.

  • A) dockerhub Image, B) docker compose oder C) lokale base R mit Shell-Skript.
  • Die finale Ergebnisse im step2/results Folder werden als .zip Datei mit standortspezifischen Namen generiert. Diese soll über DSF oder CarusCloud an die Datentransferstelle (entsprechend der Step1 credentials) übertragen werden.

• Abschluss der Testphase 20.02.2023 der Step2 Skripte.

• Freigabe 13.01.2023 der Step2 Skripte für die statistischen Analysen mittels Federated Learning.

• In der MII Weekly Projectathon Webkonferenz am 29.04.2022 haben wir die Scripts für die Select-Abfrage (Step 1) freigegeben. Details zur Ausführung der Scripte finden Sie im Changelog.

Den Quick-Fix für die häufigste Error Meldung HTTP code 500 (bisher nur HAPI) aufgrund der Timeout der Abfrage (für Observations Modul) finden sie hier und für Condition Resources hier.

• 2023-0. UPDATE - Step2 Analysen
• 2023-1. Verwendung (Step 2)
  • 1.1. Ausführung in R Step2
• 2023-2 Ablauf und Logik der Analyse Pipeline
• 2023-3. Ausführung im Docker Container (Step 2)
  • 3.2. Docker Compose
• 2023-4. Changelog (Step 2)
  • March 31, 2023 - Finaler Abschluss der Testphase
• 2022-0. Step 1
• 1. Verwendung (Step 1)
  • 1.1. Ausführung in R
  • 1.1.1. Vor der ersten Nutzung
  • 1.1.1.1. Batch-Datei/Shell-Skript
  • 1.1.1.2. R/RStudio
• 2. Ausführung im Docker Container (Step 1)
  • 2.1. DockerHub
  • 2.2. Docker Compose
  • 2.3. Ohne Docker Compose
  • 2.4. DockerHub Direkt Download
• 3. Output (Step 1)
  • 3.1. Summary
• 4. Verwendete Codesysteme (Step 1)
• 5. Verwendete Profile/Datenelemente (Step 1)
• 6. Konzeptioneller Ablauf der Abfrage (Step 1)
• 7. Datentransfer (Step 1)
• 8. Changelog (Step 1)
  • Apr 29, 2022 - Freigabe der Scripte für die STEP 1-Select Abfrage
  • May 05, 2022 - Frequent Errors & Quick fixes - HTTP 500 Observation Module
  • May 06, 2022 - Frequent Errors & Quick fixes - HTTP 500 Condition Resources

Es gibt zwei Möglichkeiten die R-Skripte für die "Step 2 - Analysen" auszuführen:

• Direkt in R oder in einem Docker Container. Beide werden im folgenden beschrieben.

Wichtig: nach dem Cloning des Repos bitte ins step2 Folder navigieren und als working/reference director einstellen.

1. Um die Analysen auszuführen (Analog zu den Step1-Skripten), muss der Inhalt des Git-Repository auf einen Rechner (PC, Server) gezogen werden, von dem aus der REST-Endpunkt des gewünschten FHIR-Servers (z.B. FHIR-Server der Clinical Domain im DIZ) erreichbar ist.

2. Auf diesem Rechner muss R (aber nicht notwendigerweise RStudio) als genutzte Laufzeitumgebung installiert sein.

3. Im master branch des Repos soll im Folder step2 befindliche Datei ./config_default.yml muss nach ./config.yml kopiert werden und lokal angepasst werden (serverbase, ggf. Authentifizierung - Username and password, proxy configs); Erklärungen dazu finden sich direkt in dieser Datei. Eine Authentifizierung mit Basic Authentication. Dafür müssen in config.yml die Variable authentication und die zugehörigen Zugangsdaten (password/username) angepasst werden.

4. Wenn die App über runMiracum_select.bat (unter Windows) gestartet wird, sollte in dieser der Pfad zur Datei Rscript.exe geprüft und ggf. angepasst werden (z.B. C:\Program Files\R\R-4.0.4\bin\Rscript.exe).

Beim ersten Start des Skripts wird überprüft, ob die zur Ausführung notwendigen R-Pakete vorhanden sind. Ist dies nicht der Fall, werden diese Pakete nachinstalliert – dieser Prozess kann einige Zeit in Anspruch nehmen.

Unter Windows: Mit der Batch-Datei runMIRACUM_select_step2.bat. Beim ersten Ausführen sollte diese ggf. als Administrator gestartet werden (über Eingabeaufforderung oder Rechtsklick), wenn die ggf. notwendigen Berechtigungen zum Nachinstallieren der R-Pakete sonst nicht vorhanden sind. Nach der ersten Installation reicht dann ein Doppelklick zum Starten.

Unter Linux: Mit dem Shell-Skript runMIRACUM_select_step2.sh. Das Shell-Skript muss ausführbar sein und ggf. beim ersten Ausführen mittels sudo gestartet werden, wenn ein Nachinstallieren der R-Pakete außerhalb des User-Kontexts erforderlich ist.

Beide Skripte (runMIRACUM_select_step2.bat und runMIRACUM_select_step2.sh) führen die Datei execution.R aus.

Diese Skript (execution.R) führt sequenziell 6 weitere R Skripte aus, wie folgt:

• 1_install_r_packages.R, Load & Install notwendige R Packete
• 2_data_selection.R, Selektion der Daten vom FHIR Server zum Wetterdaten-Matching
• 3_feature_extraction.R, Extraktion der Wetterparameter entsprechend der WStationen.
• 4_modeling1_fixedwindow_false.R, Modeling 1: Kreuzvalidierung (fixedWindow = F)
• 5_modeling2_fixedwindow_true.R, Modeling 2: Kreuzvalidierung (fixedWindow = T)
• 6_modeling3_gamboost.R, Modeling 3: genestete-Kreuzvalidierung

Hinweis: Alle notwendige präprozessierte Wetterdaten sind im Folder data vorhanden. Im Rahmen der Ausführung der Skripte werden keine Daten von externen Quellen herunterladen, keine Ports geöffnet.

Link to DockerHub or by using docker pull nandhinis08/projectathon6-miracum1-step2

1. Git-Respository klonen: git clone https://github.com/medizininformatik-initiative/Projectathon6-miracum1.git
2. Verzeichniswechsel in das lokale Repository und in den neuen Folder step2: cd Projectathon6-miracum1/step2
3. Konfiguration lokal anpassen: ./config_default.yml nach ./config.yml kopieren und anpassen
4. Image downloaden und Container starten:

docker run --name projectathon6-miracum1-step2 \
       -v "$(pwd)/errors:/errors" \
       -v "$(pwd)/data:/data" \
       -v "$(pwd)/results:/results" \
       -v "$(pwd)/conf:/conf" \
       -v "$(pwd)/config.yml:/config.yml" \
       nandhinis08/projectathon6-miracum1-step2

1. Git-Respository klonen: git clone https://github.com/medizininformatik-initiative/Projectathon6-miracum1.git
2. Verzeichniswechsel in das lokale Repository und in den neuen Folder step2: cd Projectathon6-miracum1/step2
3. Konfiguration lokal anpassen: ./config_default.yml nach ./config.yml kopieren und anpassen
4. Image bauen und Container starten: docker compose up -d

Zum Stoppen des Containers docker compose stop. Um ihn erneut zu starten, docker compose start.

Die gleiche Schritte wie oben Ausführung in R beschrieben:

1. Der Inhalt dieses Repository auf einen Rechner (PC, Server) geladen werden, von dem aus der REST-Endpunkt des gewünschten FHIR-Servers (z.B. FHIR-Server der Clinical Domain im DIZ) erreichbar ist.
2. Auf diesem Rechner muss base R (aber nicht notwendigerweise RStudio) installiert sein.
3. Im master branch des Repos soll im Folder step2 befindliche Datei ./config_default.yml muss nach ./config.yml kopiert werden und lokal angepasst werden (serverbase, ggf. Authentifizierung - Username and password, proxy configs); Erklärungen dazu finden sich direkt in dieser Datei. Eine Authentifizierung mit Basic Authentication. Dafür müssen in config.yml die Variable authentication und die zugehörigen Zugangsdaten (password/username) angepasst werden.
4. Wenn die App über runMiracum_select.bat (unter Windows) gestartet wird, sollte in dieser der Pfad zur Datei Rscript.exe geprüft und ggf. angepasst werden (z.B. C:\Program Files\R\R-4.0.4\bin\Rscript.exe).

Im step2/results folder sollen insgesamt 101 Dateiensein:

• 2 excel files with multiple sheets
• 3 PDF files with plots/images of model performance
• Multiple .RData/.Rda Dateien mit den jeweiligen ML-Modelobjekt was die Modelinskripte (4_modeling1, 5_modeling2, 6_modeling3) erstellen.

Keine diese Datenbeinhalten persönliche indetifiers. Die Modelle fitten die count (Anzahl der Fälle).

In der neuesten Version der Skripte March 7, 2023 werden die obige Dateien als .zip Datei komprimiert und mit einem standortspezifischen Namen versehen.

paste('westorm-step2-results-', conf$site, "-", Sys.Date(), "-coverage-", min(year), "-", max(year), "-totalcases-", sum(daily$total_count),  sep = "")

Diese <name>.zip Datei sollte an die Datenmanagement Stelle (Dresden) über DSF oder CarusCloud versandt werden.

Novel issue, kindly raised by @FloSeidl, which is caused by not properly working R.utils::zip() function in the last (6_modeling3_gamboost.R) script (lines 260-264, which occured at Charité Berlin on a Windows Server during a local run in RStudio (v4.2.2).

The issue could be fixed by installing the zip library and using the zip::zipr() function.

A simple alternative solution would be the manual zip compression of the 101 output files in the results folder.

All 15 participating sites has succesfully tested certain versions of the script. Thank you for Your efforts!

We provide 3 versions (as mentioned in the readme text above):

• A) Pull image from Docker Hub
• B) Docker compose
• C) Local run using base R and batch script (.sh)

All scripts are available for both HAPI (master branch) and BLAZE FHIR (blaze_update branch) servers.

The current version of the sricpts creates a step2/results containing a .zip file of all model outputs.

Various issues were fixed and requested features (bundle & count) were added based on feedbacks from lokal testings from 9/15 sites. Thank you all for your contributions!

As of today, two issues are still outstanding. One regarding the blaze branch (probably, due to a memory issue or docker version) and one regarding script-6 and gamboost models (matrix factorization problem probably due to the matrix structure).

MII Projektathon Weekly-Sprechstunde: WE-STORM Step2 Update Darstellung.

The branch blaze_update has also been updated with step2 scripts.

Currently, UKH and UKJ successfully ran the scripts in their current forms.

Link to DockerHub

Minor: the number of model objects in the results folder is coming soon.

GitHub Issue #11 regarding missing support vectors in SVM fit is fixed.

TL;DR Explanation This issue originated from the hardcoded import time range of 2015-01-01 to 2021-12-31, which might not neccessarily be available at all sites, resulting in (potentially years of) 0 values in the target vector (count). Hence, no decision boundary could be found. Additionally, try() | tryCatch() wrappers have been added to assure that the script runs even if certain model fits would fail. Thanks for raising and helping to solve the issue @pdi-uk.

GitHub Issue #10 regarding package dependency is now fixed.

GitHub Issue #9 regarding predict.glm(..., type = "response") is now fixed. Thanks for raising the issue @KutSaleh.

Major Update: Analyses Skripts for Step 2 including statistical (baseline) and machine learning models.

Uploaded the fix for the issue (Fehler bei der Ausführung (step2) #9). Updated Poisson-glm object with type = "response"

Uploaded the fix for the issue (Error for SVM model #11). Added try catch blocks, Changed dataframe timerange based on local min and max

Custom Random Forest function to tune mtry and ntree parameter. Made the max_bundles as configurable parameter in config.yml

SVM linear kernal models added and source path error fixed by changing source(file.path(getwd(), "customRF.R")) to source(file.path(getwd(), "customRF.R") , local = TRUE) (cannot open file '//customRF.R': No such file or directory #16)

Added count parameter to config and updated fhir query to drop warnings related to new updates in FHIRCRACKr. Fix for issue #18

Searching for single ICD code in every requests. Fix for issue #19

Zipping all results to a single file - caraous cloud upload

Es gibt zwei Möglichkeiten diese R-Skripte auszuführen: Direkt in R oder in einem Docker Container. Beide werden im folgenden beschrieben.

1. Um die Selectanfrage durchzuführen, muss der Inhalt des Git-Repository auf einen Rechner (PC, Server) gezogen werden, von dem aus der REST-Endpunkt des gewünschten FHIR-Servers (z.B. FHIR-Server der Clinical Domain im DIZ) erreichbar ist.

2. Auf diesem Rechner muss R (aber nicht notwendigerweise RStudio) als genutzte Laufzeitumgebung installiert sein.

3. Die mitgelieferte Datei ./config_default.yml muss nach ./config.yml kopiert werden und lokal angepasst werden (serverbase, ggf. Authentifizierung - Username and password, proxy configs); Erklärungen dazu finden sich direkt in dieser Datei. Eine Authentifizierung mit Basic Authentication. Dafür müssen in config.yml die Variable authentication und die zugehörigen Zugangsdaten (password/username) angepasst werden.

4. Wenn die App über runMiracum_select.bat (unter Windows) gestartet soll, muss in dieser der Pfad zur Datei Rscript.exe geprüft und ggf. angepasst werden (z.B. C:\Program Files\R\R-4.0.4\bin\Rscript.exe).

Beim ersten Start des Skripts wird überprüft, ob die zur Ausführung notwendigen R-Pakete ("rprojroot","fhircrackr","config","dplyr","zoo","stringr","tidyr") vorhanden sind. Ist dies nicht der Fall, werden diese Pakete nachinstalliert – dieser Prozess kann einige Zeit in Anspruch nehmen.

Unter Windows: Mit der Batch-Datei runMIRACUM_select.bat. Beim ersten Ausführen sollte diese ggf. als Administrator gestartet werden (über Eingabeaufforderung oder Rechtsklick), wenn die ggf. notwendigen Berechtigungen zum Nachinstallieren der R-Pakete sonst nicht vorhanden sind. Nach der ersten Installation reicht dann ein Doppelklick zum Starten.

Unter Linux: Mit dem Shell-Skript runMIRACUM_select.sh. Das Shell-Skript muss ausführbar sein und ggf. beim ersten Ausführen mittels sudo gestartet werden, wenn ein Nachinstallieren der R-Pakete außerhalb des User-Kontexts erforderlich ist.

Debugging/Error: Im Falle eines Berechtigungsfehlers soll der folgende Befehl vor dem ausführen des o.b. Shell-Skripts noch zusätzlich ausgeführt werden: chmod -R 777 ./

Durch Öffnen des R-Projektes (Projectathon6-miracum1.Rproj) mit anschließendem Ausführen der Datei miracum_select.R innerhalb von R/RStudio. Auch hier werden beim ersten Ausführen ggf. notwendige R-Pakete nachinstalliert.

Um die Abfrage in einem Docker Container laufen zu lassen gibt es zwei Möglichkeiten:

1. Git-Repository klonen: git clone https://github.com/medizininformatik-initiative/Projectathon6-miracum1.git Projectathon6-miracum1
2. Verzeichniswechsel in das lokale Repository: cd Projectathon6-miracum1
3. Konfiguration lokal anpassen: ./config_default.yml nach ./config.yml kopieren und anpassen
4. Image downloaden und Container starten:

docker run --name projectathon6-miracum1 \
       -v "$(pwd)/errors:/errors" \
       -v "$(pwd)/Bundles:/Bundles" \
       -v "$(pwd)/Summary:/Summary" \
       -v "$(pwd)/Ergebnisse:/Ergebnisse" \
       -v "$(pwd)/config.yml:/config.yml" \
       nandhinis08/projectathon6-miracum1

1. Git-Respository klonen: git clone https://github.com/medizininformatik-initiative/Projectathon6-miracum1.git
2. Verzeichniswechsel in das lokale Repository: cd Projectathon6-miracum1
3. Konfiguration lokal anpassen: ./config_default.yml nach ./config.yml kopieren und anpassen
4. Image bauen und Container starten: docker compose up -d

Zum Stoppen des Containers docker compose stop. Um ihn erneut zu starten, docker compose start.

1. Git-Respository klonen: git clone https://github.com/medizininformatik-initiative/Projectathon6-miracum1.git
2. Verzeichniswechsel in das lokale Repository: cd Projectathon6-miracum1
3. Image bauen: docker build -t projectathon6-miracum1 .
4. Konfiguration lokal anpassen: ./config_default.yml nach ./config.yml kopieren und anpassen
5. Container starten: docker run --name projectathon6-miracum1 -v "$(pwd)/errors:/errors" -v "$(pwd)/Bundles:/Bundles" -v "$(pwd)/Ergebnisse:/Ergebnisse" -v "$(pwd)/config.yml:/config.yml" projectathon6-miracum1

Erklärung:

• -v "$(pwd)/config.yml:/config.yml"" bindet die lokal veränderte Variante des config-Files ein. Wenn dieses geändert wird, reicht es, den Container neu zu stoppen und starten (docker stop Projectathon6-miracum1, config.yml ändern, dann docker start Projectathon6-miracum1), ein erneutes docker build ist nicht nötig.

Falls ein Error beim lokalen Builden des Containers auftreten soll (e.g. RUN install2.r --error --deps TRUE fhircrackr ---> Running in 34cdad0afa40), bitte entsprechend des Changelogs Feb 17 und Feb 18 den neusten pre-built container vom dockerhub herunterladen. Der DockerHub Link wurde angepasst, bitte entsprechend des Changelogs die letzte Version Apr 12 nutzen.

Das Skript erzeugt mehrere Ordner im Projekt-Directory. Um für den Projectathon eine möglichst einfache übersichtliche Lösung zu bekommen, werden alle files, die darin erzeugt werden bei mehrmaligem Ausführen ggf. einfach überschrieben.

Wenn die Abfrage erfolgreich durchgeführt wurde, wird die folgende Zusammenfassung in Excel erstellt

• Cohort_Feature_availability Dieses Blatt zeigt den Prozentsatz der verfügbaren Merkmale für jeden Monat in der Kohorte. Diese Tabelle enthält die wichtigsten Merkmale, die für das Modell benötigt werden
• MultiplePatientVisit: Hier wird die Zuordnung zwischen der Anzahl der Patienten und ihrer Besuche dargestellt
• PLZ Hier wird die Anzahl der Begegnungen in jeder PLZ angegeben (gefiltert größer oder gleich 5). Dies hilft uns bei der Identifizierung der wichtigsten PLZ in der Kohorte für den Abgleich mit den Wetterstationen.
• Stroke_ICD_Summary Dies gibt die Anzahl der Begegnungen mit einem entsprechenden ICD an und auch den Prozentsatz, den dieser in der Gesamtkohorte ausmacht, der ebenfalls mit etwas Rauschen addiert wird.
• Different Procedures Für die identifizierte Kohorte werden hier die verschiedenen Verfahren, die für die verschiedenen Begegnungen durchgeführt wurden, und ihr prozentualer Anteil an der Gesamtkohorte angegeben.
• Previous comorbidities Anzahl der Fälle gruppierte entsprechend der verfügbaren Stroke diagnosen ICDFür die identifizierte Kohorte werden hier die früheren Komorbiditäten für die verschiedenen Begegnungen und ihr prozentualer Anteil an der Gesamtkohorte angegeben.
• LabValues Für die identifizierte Kohorte werden hier die Labormethoden angegeben, die bei verschiedenen Untersuchungen gemessen wurden (basierend auf LOINC-Code), sowie deren prozentualer Anteil an der Gesamtkohorte.
• Medication Für die identifizierte Kohorte werden hier die bei verschiedenen Untersuchungen verabreichten Medikamente und ihr prozentualer Anteil an der Gesamtkohorte angegeben. Diese sind benötigt um die Different Procedures größte und feature-reicshte homogene Kohrote über alle Standorten hinweg für die statistische Auswertung selektieren zu können.

Dieses System wird für den Download per FHIR Search verwendet

• http://fhir.de/CodeSystem/dimdi/icd-10-gm für Condition.code.coding.system
• http://fhir.de/CodeSystem/dimdi/ops für Procedure.code.coding.system
• http://loinc.org für Observation.code.coding.system
• http://fhir.de/CodeSystem/dimdi/atc für Medication.code.coding.system

Die Abfragen werden auf der Grundlage der MII-Profile für die entsprechenden Ressourcen geschrieben. Die Skripte sind mit der neuesten Version der verfügbaren Hauptversionen kompatibel. Im Folgenden wird für jeden verwendeten Ressourcentyp beschrieben, welche Elemente für die FHIR-Suchanfrage an den Server verwendet werden (diese Elemente müssen vorhanden sein, damit kein Fehler ausgelöst wird) und welche Elemente im Skript extrahiert und in die Ergebnistabellen geschrieben werden.

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-person/StructureDefinition/Patient

Version: 2.0.0-alpha3 bzw. 1.0.14

Für Servabfrage verwendete Elemente: Extrahierte Elemente:

• Patient.id
• Patient.gender
• Patient.birthDate
• Patient.address.postalCode

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-fall/StructureDefinition/KontaktGesundheitseinrichtung

Version: 1.0.1

Extrahierte Elemente:

• Encounter.id
• Encounter.subject.reference
• Encounter.period.start
• Encounter.diagnosis.condition.reference
• Encounter.diagnosis.rank
• Encounter.hospitalization.dischargeDisposition.coding.code

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-diagnose/StructureDefinition/Diagnose

Version: 2.0.0-alpha3 bzw. 1.0.4

Für Servabfrage verwendete Elemente:

• Condition.subject.reference

Extrahierte Elemente:

• Condition.id
• Condition.recordedDate
• Condition.code.coding.code
• Condition.code.coding.system
• Condition.encounter.reference
• Condition.subject.reference

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-prozedur/StructureDefinition/Procedure

Version: 2.0.0-alpha3 bzw. 1.0.4

Für Servabfrage verwendete Elemente:

• Procedure.subject.reference

Extrahierte Elemente:

• Procedure.id
• Procedure.performedDateTime
• Procedure.code.coding.code
• Procedure.code.coding.system
• Procedure.encounter.reference
• Procedure.subject.reference

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-labor/StructureDefinition/ObservationLab

Version: 1.0.6

Extrahierte Elemente:

• Observation.id
• Observation.effectiveDateTime
• Observation.code.coding.code
• Observation.code.coding.system
• Observation.subject.reference
• Observation.valueQuantity.value
• Observation.valueQuantity.unit
• Observation.subject.reference
• Observation.encounter.reference

Profil: https://www.medizininformatik-initiative.de/fhir/core/modul-medikation/StructureDefinition/MedicationStatement

Version: 1.0.6

Extrahierte Elemente:

• MedicationStatement.medication
• Medication.code.coding.code
• Medication.code.coding.system

Im Prinzip läuft das Drehbuch wie folgt ab:

1. Es verbindet sich mit dem FHIR-Server, um alle Encounter-Ressourcen herunterzuladen, die die unten genannten Schlaganfalldiagnosen aus dem Zeitraum vom 2015-01-01 bis zum aktuellen Datum haben.

   ICD10: I60.0,I60.1,I60.2,I60.3,I60.4,I60.5,I60.6,I60.7,I60.8,I60.9,I61.0,I61.1,I61.2,I61.3,I61.4,I61.5,I61.6,I61.8,I61.9,I63.0,I63.1,I63.2,I63.3,I63.4,I63.5,I63.6,I63.8,I63.9,I67.80!
   

2. Es lädt auch alle referenzierten Patienten-, Condition- Ressourcen durch die erhaltenen Encounter-Ressourcen herunter bei bei denen in Schritt 1. Encounters erhaltenen worden sind.

   Request: [base]/Encounter?date=ge2015-01-01&_has:diagnosis.code&_include=Encounter:patient&_include=Encounter:diagnosis
   

3. Nachdem diese Ressourcen heruntergeladen wurden, wird die notwendige Verarbeitung mit dem FHIRCrackR Paket durchgeführt und in einen Datenframe mit relevanten Merkmalen für die Encounter mit der entsprechenden Diagnose umgewandelt.

4. Die Liste der Encounter- und Patienten-IDs wird aus den extrahierten Ressourcen extrahiert und wird für das Herunterladen weiterer Ressourcen wie Observation und Medikation verwendet.

5. Die Observation- Ressources werden für die Liste der Patient-IDS und LOINC-Codes heruntergeladen. Zusätzlich werden die Observation- Ressources basierend auf das Aufnahme- und Entlassdatum miteinander gematcht.

   Request: [base]Observation?subject=xx&code=777-3,6301-6,3173-2,2160-0,2089-1,2085-9,7799-0,4548-4,2345-7,2093-3,74201-5
   *Note: xx indicates a placeholder for list of patient ids*
   

6. Ähnlich werden die Procedure- Ressources für die Liste der Patient-IDS heruntergeladen und basierend auf das Aufnahme- und Entlassdatum zusätzlich gematcht.

    Request: [base]Procedure?subject=xx
    *Note: xx indicates a placeholder for list of patient ids*  
   

7. Das medicationStatement wird für die Liste der Encounters heruntergeladen, aus der die relevante Medikamenten-ID gewonnen wird, die dann zur Extraktion der eigentlichen **Medikamenten-**Ressourcen verwendet wird:

   Request: [Base]/Medication?id=xx
   *Note: xx indicates a placeholder for list of encounter ids*
   

8. Um die früheren Komorbiditäten im Zusammenhang mit dem kardiovaskulären Risiko und den metabolischen Risiken zu erhalten, wird die Condition-Ressource für die Liste der Patienten extrahiert und die relevanten Merkmale werden auf der Grundlage der ICD10-Codes erstellt.

    Request: [Base]/Condition?subject=xx        
    *Note: xx indicates a placeholder for list of patient ids*
   

9. Wann alle diese Ressourcen heruntergeladen worden sind, werden in R verschiedene Data-Frames für die gesamten aggregierten Daten und auch verschiedene Summaries erstellt, und als .csv gespeichert werden. Die Einzelheiten dazu sind im obigen Abschnitt über die Ausgabe aufgeführt.

Datentransfer: Für den zentralen Datentransfer der Ergebnisse der SELECT-Abfrage (Summary/Summary_Step1_MIRACUM_WESTORM.xlsx) soll der Prozess-Skript für den Dateityp (".xlsx") angepasst werden. Der Hintergrund dafür ist, dass der Projectathon Prozess prüft den tatsächlichen MimeType der Base64 codierten Datei gegen den deklarierten MimeType. Daher muss der deklarierte MimeType in den DocumentReferenceundBinary Ressourcendazu passen bzw. identisch sein. Für eine.xlsxDatei wie folgt:`.

Die Repository für das MII Projectathon Data Transfer process befindet sich unter MII DSF Processes.

Als Beispiel, @wetret (Reto Wettstein) hat bereits einen erfolgreichen Test mit dem folgenden Skript (DicFhirStore_WE-STORM.xml; lines 23 & 38) durchgeführt.

Vielen Dank an @wetret (Reto Wettstein) und @hhund (Hauke Hund) sowie Christian Gierschner für den Support.

Siehe das Issue was auch ein HTTP code 500 error geliefert hat. Das Problem scheint hier mit der HAPI Server Version (5.3.0) gebunden zu sein. Die länge der Condition Resources und Anzahl der gebundelten Fälle (zuvor max_bundles = 100) kann ggf. zu lang werden.

Der simple Fix in line 131 mit der Reduktion auf , max_bundles = 40 hat das Problem in Halle gelöst. Vielen Dank @Diana Pietzner.

Die häufigste Fehlermeldung beim Ausführen des Scripts (miracum_select.R) war bisher das folgende Your request generated a server error, HTTP code 500. siehe auch das Issue - vielen Dank @pdi-uk und @Abel Stolz (MII Slack). Der Fehler trat bisher nur beim HAPI FHIR Servers auf.

Das Problem wird von der langen Query im Rahmen der Abfrage vom Labor Modul ausgelöst. Die kombinierte Länge der multiplen LOINC Codes von multiplen Patienten überschreiten die erlaubte URL Charakter Länge. Diese wird in Zeile 352 definiert. In Erlangen, Jena, Mannheim lief das Script mit 1800 durch. In Leipzig kam der HTTP 500 Error.

• Zuvor nchar_for_ids <- 1800 - (nchar(conf$serverbase)+nchar_loincs)
• Lösung nchar_for_ids <- 900 - (nchar(conf$serverbase)+nchar_loincs)
  • Dadurch wird die Anzahl der Patienten pro Anfrage reduziert, für die LOINC-kodierte Beobachtungen heruntergeladen werden (z.B. in Leipzig hat es das Problem gelöst).

Wir haben den master Branch dem entsprechend (Observation_length_update) aktualisiert.

In der heutigen MII Weekly Projectathon Webkonferenz haben wir die Step 1, Select-Abfrage des WE-STORM Projektes freigegeben. Die Skripte wurden erfolgreich an den folgenden Standorten getestet (e.g. Erlangen, Jena, Mannheim, TU-München, Tübingen).

Vielen Dank für die gute Zusammenarbeit, Eure Zeit und Unterstützung sowie die Anregungen und Verbesserungs Vorschläge, insbesondere an:

• Julia Palm, UK Jena (HAPI)
• Jonathan Mang, UK Erlangen (HAPI)
• [Thomas Ganslandt], UK Erlangen (HAPI)
• [Noemi Deppenwiese], UK Erlangen (HAPI)
• Raffael Bild, TUM (IBM HAPI & BLAZE)
• [Stephanie Biergans], UK Tübingen (IBM HAPI & Blaze)
• Alexander Kiel, Uni Leipzig (blaze v0.17.0 update with chaining)

1. Für die HAPI erstellte Scripte können vom master Branch ge-pullt werden.
2. Für blaze angepasste Scripte können vom blaze_update Branch ge-pullt werden.
   • Diese wurden für v0.16.x(noch ohne chained search parameters) angepasst.

Die dockerhub Images sind für jeweils:

• HAPI-type und
• blaze FHIR Server über die Links verfügbar. Diese können je nach Server/Proxy Settings eine einfachere Lösung bieten (siehe Changelogs Apr 12 & Feb 18).

Der geschwindigkeitslimitierende Faktor ist der Download der Observations (Labor Module. Für Standorte mit vielen Labordaten erhöht sich die Zeit (vor allem auf HAPI FHIR).

• Time ranges (HAPI): 4h-16h (cohort sizes: ~2-9k)
• Time range (blaze): 46 mins (cohort sizes: ~6-9k)

Für blaze Servers wird der Download von Resourcen angepasst, um die Verkettung (chaining) aus dem Filtering-Process der HAPI Scripte zu entfernen (siehe Issue hier).

Wir haben die Scripts updated um stationäre und ambulante Fälle, je nach vorliegende FHIR-Elemente (.class, .rank, .use) bzw. Kondierung des jeweiligen DIZ besser unterscheiden zu können. Aktuell basieren diese Scripts auf lokale (Mannheimer DIZ-Daten) somit müssen diese noch vor dem finalen Einsatz (Step 1, SELECT-Abfrage), extern getestet werden. Diese Tests sind noch aussstehend, daher bitte den Script noch nicht nutzen.

Änderung: Zusätzlich zu den Ergebnis-Tabellen wird nun ein Textfile "Summary/miracum_select.log" erzeugt, welches die Anzahl der extrahierten Fälle, Patienten und die Laufzeit des R-Skriptes dokumentiert. Das log-file muss nicht geteilt werden, es dient den DIZen nur als Hilfestellung für die Einschätzung von Laufzeiten und Ergebnismengen.

Updated LOINC Codes: Die LOINC Codes für die Laborparameter mussten aufgrund der unterschiedlichen Kodierung der Laborparameter zwischen den Standorten erweitert werden. Hierfür haben wir die Referenztabelle mit Top 300 LOINC Codes entsprechend der Liste im KDS Basismodule, 03 Modul Laborbefunde 2021-08-08_MII_TOP_300_LOINC.xlsx verwendet.

Updated DockerHub Link: Ein neues dockerhub Image wurde mit den neuen Updates vom 12.04.2022 erstellt. Wenn dieses Image lokal nachgebaut wird soll dies mit --deps TRUE Flag passieren, somit alle R Pakete bereits miteingebaut werden.

Proxy-Konfigurationsoptionen in config_default.yml hinzugefügt und in miracum_select.R eingefügt, um es in R-Session zu verwenden

Maxbundles-Argument aus dem Encounter-Bundle-Downlaod entfernt, das am 25. Januar versehentlich hinzugefügt wurde (Überbleibsel aus einer Debug-Session)

Rückmeldung von Leipzing: Fehlermeldung bei R package install Warning: unable to access index for repository https://packagemanager.rstudio.com/cran/__linux__/focal/latest/src/contrib: cannot open URL ...

Bei WE-STORM werden zur Run time des Containers durch das R-Skript (install2.r) weitere R-Pakete (fhircrackr, config, dplyr, zoo, didyr, data.table, openxlsx) nachinstalliert, deise benötigen weitere Pakete als Abhängigkeiten, welche standardgemäß von CRAN geladen werden.

Zwischenlösung: @joundso docker image auf dockerhub nachgebaut mit --deps TRUE flag somit alle R Pakete bereits miteingebaut sind.

Falls der Skript ausführende Server keine Internetverbindung hat siehe Feb 17 kann der o.g. updated container vom dockerhub docker pull joundso/projectathon6-miracum1:latest benutzt werden.

Rückmeldung von Leipzig: Fehler am ehesten aufgrund von Firewall beim Download vom R-Packete & Dependencies (Abel Stolz; RUN install2.r --error --deps TRUE fhircrackr ---> Running in 34cdad0afa40), weil wir aktuell den Docker-Container lokal selbst bauen.

Anmerkung: Das Docker-Image sollte für Sites verfügbar sein, die nicht in der Lage sind, selbst zu bauen. Siehe auch Issue.

Zwischenlösung: @joundso (Jonathan Mang) hat netterweise das Image unter seinem dockerhub-Konto hochgeladen. Es wird noch ein Konto des Maintainers ([@nandhiniS08] | [@mematt]) erstellt.

Änderung: Fälle mit fehlenden Aufnahme- und Aufzeichnungsdaten wurden entfernt.

Änderung: Logik beim herunterladen von Conditions geändert. Es werden jetzt alle Conditions zu den untersuchten Patienten gezogen und anschließend so gefiltert, dass nur Conditions übrig bleiben, die zu den gewünschten Encountern gehören.

Erklärung: Damit ist es jetzt irrelevant, ob der Encounter auf die Condition verlinkt oder die Condition auf den Encounter verlinkt. Das Skript funktioniert, solange mindestens eine der Richtungen gegeben ist. Diese Änderung wurde implementiert, weil es sich herausgestellt hat, dass die Linkrichtung in den verschiedenen DIZen heterogen und unterschiedlich gelöst ist.

Änderung: Problem, wenn multiple Medikamenten-IDs gefiltert werden, wird die URL-Länge der FHIR Query zu lang. Dieses Problem hat Erlangen gemeldet. Die Medikamenten-IDs werden aufgeteilt und die Ressourcen werden in Teilen heruntergeladen.

Erklärung: Es wurde versäumt, die Logik der Aufteilung von IDs anzupassen (die für andere Ressourcen-Downloads implementiert ist). Der Fehler trat auf der lokalen Seite nicht auf, da die Medikationsdaten sehr gering sind.

Änderung: Anpassung des Formats und des Inhalts der Excel-Zusammenfassung gemäß einem Vorschlag der UAC.

Änderung: Anpassung der FHIR-Suchparameter für den Diagnosecode

Änderung: Extraction based on subject_id and admission and discharge date

Änderung: Adapted SSL option in config and adapted the readme

Änderung: minor changes on readme and removed saving bundles