FHIR Chat · GECCO-Datensatz · german (d-a-ch)

Stream: german (d-a-ch)

Topic: GECCO-Datensatz

Julian Sass (Jun 08 2020 at 14:16):

Sammelthread zum GECCO-Datensatz:
Datensatz: https://art-decor.org/art-decor/decor-datasets--covid19f
FHIR-Projekt: https://simplifier.net/forschungsnetzcovid-19

Julian Sass (Jun 08 2020 at 14:17):

@Sven Helfer

Sven Helfer (Jun 11 2020 at 05:51):

Danke schön. Ich sammle erst noch mal ein paar konkrete Dinge. Vielleicht schon mal vorab: An vielen Stellen passen in art-decor die Fragen nicht zu den Valuesets ("Ist der Patient transplantiert?" -> Liste von Organen) die LOINC-Valuesets sind z.T. klinisch nicht korrekt (ALAT im Fruchtwasser wird mit ALAT im Serum gleichgesetzt).
Das sind jetzt beides keine FHIR-Probleme, da muss ich mir die Profile noch mal genauer anschauen, was mir da aufgefallen war...

Sylvia Thun (Jun 14 2020 at 07:15):

Viele Fragen und Antworten stammen aus dem ISARIC der WHO und anderen int. Assessments und sollten nicht abgeändert werden. Über Kommentare zu der Kodierung und der FHIR-Umsetzung freuen wir uns trotzdem.

Sven Helfer (Jun 16 2020 at 15:14):

Ich bin nur etwas verwirrt, weil die Antwort "Leber" nicht besonders passend auf die Frage "Ist der Patient transplantiert." ist. Zumal die Antwortmöglichkeit "Nein" fehlt. Ähnlich die Frage "Leidet der/die Patient*in unter mind. einer aktiven Tumor-/Krebserkrankung? " mit den Antworten "Active" und "Remission". Auch hier kein "Nein" - ich habe mir jetzt mal die FHIR-Profile kurz angeschaut. Da sind das ja Conditions. Wie definiere ich denn da zum beispiel "Nein"? Wenn mehrere Transplantationen (oder anschaulicher vielleicht Komplikationen) vorliegen. Ist das dann jedes mal eine neue Instanz?
Wie Sie sehen, bin ich etwas verwirrt ;)

Sven Helfer (Sep 10 2020 at 06:55):

Ich versuche aktuell die Daten einiger unserer Patienten "Gecco-Konform" aufzubereiten. Dabei habe ich seit längerem mal wieder in Art-Decor geschaut. Hier finde ich jetzt einen GECCO-Datensatz und einen GECCO-Plus-Datensatz. Mir ist, als hätte ich "Gecco-Plus" schon ein-zwei mal gehört, aber ich finde gerade keine genaue Dokumentation dazu. Könnte mich hier noch mal jemand auf den aktuellen Stand bringen was die Unterschiede sind?

Andrea Essenwanger (Sep 10 2020 at 07:25):

@Alexander Bartschke

Noemi Deppenwiese (Sep 10 2020 at 08:01):

Apropos: Ich würde mir im GECCO Core IG (https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/GECCOCore) auch eine "Terminologie" Seite mit allen im IG definierten CS/VS wünschen, wie auch in den MII-IGs. Die CodeSysteme sind sonst schwierig zu finden...

Alexander Bartschke (Sep 10 2020 at 11:55):

GECCO Plus soll eine Erweiterung des GECCOs werden. Momentan werden die Inhalte noch erarbeitet bzw. sind noch nicht abgestimmt.

Sven Helfer (Sep 10 2020 at 13:22):

Ah, danke! Wird das dann die modulare Struktur des original Gecco ablösen?

Alexander Bartschke (Sep 10 2020 at 18:09):

Ich freue mich, dass ich helfen kann. Eine Ablösung der modularen Struktur ist meines Wissens nach nicht geplant.

Marcus Wurlitzer (Sep 29 2020 at 12:11):

Hallo zusammen, bei der Sichtung der GECCO-FHIR-Profile haben sich bei uns einige Fragen ergeben. Warum z. B. werden pro Condition 3 Profile nach dem Schema Condition X present/absent/unknown definiert (Profile in simplifier vom 30.7.)? Und welche Rolle spielen die Condition-Profile ohne den Zusatz vom 12.8.? Danke und Grüße aus Hamburg.

Julian Sass (Sep 30 2020 at 13:33):

Die Condition ohne den Zusatz ist jeweils die Basisdefinition. Davon abgeleitet gibt es dann present/absent/unknown, um das Vorhandensein bestätigen oder ausschließen zu können, wie in Studien gefordert.

Marcus Wurlitzer (Oct 09 2020 at 10:49):

Danke!

Nils Dittberner (UKE) (Oct 12 2020 at 10:19):

Hallo zusammen, wir würden gerne ein paar Fragen zum GECCO Datensatz besprechen. Nach Rücksprache mit Herrn Saß versuchen wir das mal hier im Zulip Channel.

Nils Dittberner (UKE) (Oct 12 2020 at 10:20):

bzgl. der Condition Profile haben wir uns gefragt, ob es Alternativen zu den dreigeteilten Profilen present/absent/unknown gibt.

Nils Dittberner (UKE) (Oct 12 2020 at 10:21):

Dann sind einige Items (Respiratorisches Outcome, Ergebnis Folgeabstrich, ..) für uns nicht eindeutig. Welcher Folgeabstrich ist gemeint? Ist mit Respiratorischem Outcome die Frage nach einer Entlassung im beatmeten Zustand gemeint?

Nils Dittberner (UKE) (Oct 12 2020 at 10:23):

Einige der Fragen betreffen auch deren Ausprägung im eCRF. Zum Beispiel wie die Beatmungstherapie zu dokumentieren ist oder die Vitalparameter. In der Version vom 06.10. sind hier immer nur einfache Einträge möglich. D.h. man kann nur eine Beatmungstherapie angeben und nur einmal die Vitalparameter

Nils Dittberner (UKE) (Oct 12 2020 at 10:24):

Gibt es zu diesen und weiteren Themen vllt. schon irgendwo eine Diskussion?

Julian Sass (Oct 12 2020 at 10:49):

Nils Dittberner (UKE) said:

bzgl. der Condition Profile haben wir uns gefragt, ob es Alternativen zu den dreigeteilten Profilen present/absent/unknown gibt.

Das ändere ich gerade auf jeweils nur ein Profil. Present/absent dann über verificationStatus und nur noch für Unknown eine Extension.

Julian Sass (Oct 12 2020 at 10:51):

Nils Dittberner (UKE) said:

Gibt es zu diesen und weiteren Themen vllt. schon irgendwo eine Diskussion?

Bisher nur hier :)
Ich habe die anderen Fragen an die Redaktionsgruppe weitergeleitet.

Christof Gessner (Oct 12 2020 at 16:34):

@Julian Sass finde ich irgendwo dokumentierte Diskussion zu dieser Nutzung von verificationStatus? Wir haben ähnlichen Entscheidungsbedarf bei #IPS im Kontext US core/C-CDA.

Julian Sass (Oct 12 2020 at 17:24):

@Christof Gessner ja wir haben die SNOMED on FHIR working group mappings als Anlass genommen, Confirmed present | Definitely NOT present über verificationStatus abzubilden, statt wie bisher nach dem logica Vorbild über Extensions. Bloß 'unknown' lässt sich in verificationStatus nicht richtig unterbringen. https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=82873012

Christof Gessner (Oct 12 2020 at 19:22):

Thanks! Erörterung geht weiter... Unsere IPS-Annahme war, solche Aussage gleich als Code festzustellen, also "no known allergies" an der gleichen Stelle, wo sonst die "known allergies" dokumentiert würden.

Christof Gessner (Oct 12 2020 at 19:23):

@Giorgio Cangioli sorry, we are discussing this in German.

Nils Dittberner (UKE) (Oct 13 2020 at 06:00):

@Julian Sass könnte man nicht _unknown_ auf die Abwesenheit von _present_ und _absent_ mappen?

Julian Sass (Oct 13 2020 at 08:09):

Nils Dittberner (UKE) said:

Julian Sass könnte man nicht _unknown_ auf die Abwesenheit von _present_ und _absent_ mappen?

Ja ist die Frage, ob das Fehlen von clinicalStatus und verificationStatus 'unknown' bedeutet, oder ob man das als Flag nicht irgendwo setzen sollte, um Fehlinterpretation zu vermeiden.

Nils Dittberner (UKE) (Oct 13 2020 at 08:19):

und wenn man keine Ressource mit der entsprechenden Condition sendet und das dann auf unknown mappt?

Mareike Przysucha (Oct 13 2020 at 08:38):

Hier gilt das gleiche wie bei der Pflegestufe im anderen Thread: Das ich etwas nicht schicke, heißt nicht, dass ich etwas nicht weiß. Wenn man etwas nicht weiß, sollte man das auch so kommunizieren.

Andrea Essenwanger (Oct 13 2020 at 08:38):

Man kann nicht annehmen, dass die Information "unknown" ist, nur weil sie nicht vorhanden ist. Falls diese nicht angegeben wurde, weil vllt ein Feld bei der Eingabe übersehen wurde, dann wäre es nicht richtig diese auf "unknown" zu setzen.

Marcus Wurlitzer (Oct 13 2020 at 08:54):

Danke für die Antwort - durchaus plausibel und in der Theorie sicher korrekt. Auf der anderen Seite: man könnte für jeden Patienten eine beliebige Zahl von Condition-Ressourcen mit sämtlichen denkbaren Diagnosen erzeugen und deren Status auf "unknown" setzen. Das wäre technisch und medizinisch korrekt, sofern über diese Condition nichts bekannt ist. Die Frage wäre: bieten diese unknown-Ressourcen bei der Datenauswertung tatsächlich einen Mehrwert? Oder würde man in der Auswertepraxis fehlende Ressourcen und explizite unknown-Ressourcen nicht ohnehin gleich behandeln?

Andrea Essenwanger (Oct 13 2020 at 08:59):

Naja, nicht unbedingt oder? Wenn man eine Qualitätsanalyse der Daten machen möchte, würde es schon einen Unterschied machen ob diese als "unknown" eingetragen wurden oder z.B. eher vergessen wurden. Unknown hieße, dass der Zustand nicht bekannt ist, aber die Frage unbeantwortet zu lassen hieße dann eher, dass z.B. noch iwas an der eigentlichen Eingabe der Daten falsch läuft. (entweder auf menschlicher oder auf der Maschinen-Seite)

Andrea Essenwanger (Oct 13 2020 at 09:01):

Sollte ich dann meinetwegen eine Software entwickelt haben, die die Eingabemaske bereitstellt, dann würde ich doch wissen wollen, ob die Beantwortung der Fragen intuitiv genug ist oder ob vllt das Personal zu dem Thema noch weiter geschult werden sollte. Somit würde ich doch untersuchen wollen ob die Daten überhaupt ordentlich eingetragen werden. (nur so als Beispiel)

Sven Helfer (Oct 13 2020 at 09:11):

Ich denke, da könnte ein gewisser Gap zwischen Anspruch und Realität entstehen. Diese Ressourcen sollen in Rekordzeit gefüllt und bereitgestellt werden. Da ist das mit der Datenqualität so oder so eine Sache...ob da diese Unterscheidung wirklich hilft...
Es ist ja so, dass die/viele Standorte schon gut damit beschäftigt sind, Daten im MI-I-KDS-Format bereit zu stellen (also die, die es tatsächlich in den Quellsystemen gibt). Damit wären alle nicht gefüllten Diagnosen erst mal sowieso im "Ziel" also "zentral" "unknown". (Dokumentare gibt es ja in dem Bereich nicht)
Jetzt noch Dummies zu erstellen, nur um das noch mal explizit zu bestätigen ist halt schon noch mal Aufwand und sollte vielleicht diskutiert werden...
N.B.: Wir sprechen auch noch über einen wenig definierten Mix aus automatisch aus den Quellsystem ermittelten Daten und Daten aus einem EDC-System...

Julian Sass (Oct 13 2020 at 09:20):

Christof Gessner said:

Thanks! Erörterung geht weiter... Unsere IPS-Annahme war, solche Aussage gleich als Code festzustellen, also "no known allergies" an der gleichen Stelle, wo sonst die "known allergies" dokumentiert würden.

Stimme ich zu. Haben wir aus der IPS auch übernommen und deckt sich mit: http://hl7.org/fhir/condition.html#9.2.3.4
Darüber hinaus soll aber erfasst werden, dass Problem A vorliegt, Problem B ausgeschlossen ist und Problem C ungewiss ist. Dann passt die Definition von "no-known-problems" aus der IPS aber nicht.

Christof Gessner (Oct 13 2020 at 09:43):

@Julian Sass Ich glaube, die Diskussion bei https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=82873012 übersieht, dass bei http://build.fhir.org/codesystem-condition-ver-status.html provisional und differential Spezialisierungen von unconfirmed sind?

Christof Gessner (Oct 13 2020 at 09:47):

@Julian Sass Ich denke, dass verificationStatus=unconfirmed das sinnvollste Mapping für "unknown" ist. present/absent wird zu confirmed/refuted, vermute ich?

Julian Sass (Oct 13 2020 at 10:04):

Christof Gessner said:

Julian Sass Ich glaube, die Diskussion bei https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=82873012 übersieht, dass bei http://build.fhir.org/codesystem-condition-ver-status.html provisional und differential Spezialisierungen von unconfirmed sind?

Gut möglich, dass sie das nicht beachtet haben.

Julian Sass (Oct 13 2020 at 10:11):

Christof Gessner said:

Julian Sass Ich denke, dass verificationStatus=unconfirmed das sinnvollste Mapping für "unknown" ist. present/absent wird zu confirmed/refuted, vermute ich?

Present/absent zu confirmed/refuted passt. Die Definition von 'unconfirmed' legt aber nahe, dass zumindest mal ein Verdacht bestanden hat. Bei 'unknown' gibt es in der Regel wahrscheinlich keinen Verdacht. Deswegen haben wir 'unknown' bislang nicht auf 'unconfirmed' gemappt.

Noemi Deppenwiese (Oct 13 2020 at 10:13):

MVn ist die "unknown" Extension auch vA für die EDC Systeme gedacht? Im DIZ-Setting ist das ja fast nicht zu beantworten.

Christof Gessner (Oct 13 2020 at 10:31):

@Julian Sass Aus Sicht des Dokumentierenden würde ich sagen: "unconfirmed" (There is not sufficient diagnostic and/or clinical evidence to treat this as a confirmed condition.) ist genau der richtige Wert, und impliziert noch keinen Verdacht, aber auch keinen definitiven Ausschluss. I will discuss this with @Giorgio Cangioli and the IPS team tomorrow.

Christof Gessner (Oct 13 2020 at 10:37):

@Julian Sass Bei einer Query ist es IMHO aber falsch, in der Response einen Status "unconfirmed" zu liefern, falls es im Quellsystem keine Information gibt. Das wäre dann vielleicht Euer "unknown"-Fall?

Christof Gessner (Oct 13 2020 at 10:46):

Vermutlich braucht man beides: unconfirmed - Aktive Dokumentation des Nicht-Wissens, unknown - Das System enthält keine Dokumentation.

Christof Gessner (Oct 13 2020 at 10:49):

Dann wären unconfirmed/confirmed/refuted drei mögliche zu dokumentierende Aussagen. unknown bedeutet dann "keine Aussage wurde im System erfasst". Und so passt es auch ganz gut zu der SNOMED-Konzepthierarchie.

Marcus Wurlitzer (Oct 13 2020 at 10:53):

Andrea Essenwanger said:

Naja, nicht unbedingt oder? Wenn man eine Qualitätsanalyse der Daten machen möchte, würde es schon einen Unterschied machen ob diese als "unknown" eingetragen wurden oder z.B. eher vergessen wurden. Unknown hieße, dass der Zustand nicht bekannt ist, aber die Frage unbeantwortet zu lassen hieße dann eher, dass z.B. noch iwas an der eigentlichen Eingabe der Daten falsch läuft. (entweder auf menschlicher oder auf der Maschinen-Seite)

Ja, das stimmt schon, ein Unterschied ist gegeben und kann je nach Kontext relevant sein. "Keine Information zu Condition X vorhanden" vs. "Ein Dateneintragender hat am dd.mm.yy angegeben, dass keine Information zu Condition X vorhanden ist". Meine Frage zielt genau darauf ab: ist diese Unterscheidung in unserem Kontext notwendig und sinnvoll? Oder ließe sich die Vollständigkeit der Datensätze auch lokal prüfen, und per Konvention wird bei "unbekannt" keine Ressource angelegt? Ich kann diese Frage nicht mit Gewissheit beanworten, daher die Anregung zur Diskussion. :)

Christof Gessner (Oct 13 2020 at 10:56):

Auf der Seite der Dokumentation plädiere ich dafür, die Dinge einfach zu halten. Dort bräuchte man die unknown-Extension also gar nicht zu verwenden. Auf der Seite der Auswertung kann je nach use case entweder dokumentiertes "unconfirmed" mit "unknown" gleichgesetzt werden, oder eben nicht.

Marcus Wurlitzer (Oct 13 2020 at 10:58):

Sven Helfer said:

Es ist ja so, dass die/viele Standorte schon gut damit beschäftigt sind, Daten im MI-I-KDS-Format bereit zu stellen (also die, die es tatsächlich in den Quellsystemen gibt). Damit wären alle nicht gefüllten Diagnosen erst mal sowieso im "Ziel" also "zentral" "unknown". (Dokumentare gibt es ja in dem Bereich nicht)

Ja – aus dieser DIZ-Sicht heraus entstand auch meine Überlegung. Aber vielleicht ist die Lage im EDC-Kontext auch anders, da bin ich unsicher.

Julian Sass (Oct 19 2020 at 11:41):

Marcus Wurlitzer said:

Ja – aus dieser DIZ-Sicht heraus entstand auch meine Überlegung. Aber vielleicht ist die Lage im EDC-Kontext auch anders, da bin ich unsicher.

@Alexander Bartschke

Sven Helfer (Oct 19 2020 at 12:00):

Das spielt am Ende auch dahinein, ob "Ein GECCO-Datensatz" ein Datensatz mit im Grunde leicht abgeänderten KDS-Ressourcen ist, oder ein FHIR-Export der Infromation "Es bestand eine chronische Lungenerkrankung." aus einem EDC. Das ist von der Implementation etwas komplett anderes...und ich glaube, wir brauchen hier relativ schnell verlässliche und pragmatische und umsetzbare Antworten/Entscheidungen... :grimacing:

Nils Dittberner (UKE) (Oct 19 2020 at 12:53):

Gibt es denn schon Antworten aus der Redaktionsgruppe?

Nils Dittberner (UKE) (Oct 19 2020 at 12:55):

@Julian Sass wurde schon über die Fragestellung zu Zeitreihen bei Vitaldaten, Medikation und co entschieden?

Julian Sass (Oct 19 2020 at 13:00):

Nils Dittberner (UKE) said:

Julian Sass wurde schon über die Fragestellung zu Zeitreihen bei Vitaldaten, Medikation und co entschieden?

Nein habe ich noch keine Info zu.

Stefanie Schild (Oct 30 2020 at 15:45):

Hallo zusammen
werden die Aktualisierungen des Datensatzes nur noch in Simplifier geschehen oder ist auch ein Update der ArtDecor Spezifikation geplant?

Andrea Essenwanger (Oct 30 2020 at 15:48):

PING! @Julian Sass @Alexander Bartschke

Julian Sass (Oct 30 2020 at 16:52):

Stefanie Schild said:

Hallo zusammen
werden die Aktualisierungen des Datensatzes nur noch in Simplifier geschehen oder ist auch ein Update der ArtDecor Spezifikation geplant?

Auf ArtDecor sind die Datensatzkonzepte und Beschreibungen fix und lassen sich nicht mehr ändern. Änderungen nur noch auf Simplifier. Aber gerne alle Verbesserungsvorschläge auch bzgl. ArtDecor einreichen.

Cornelius Erbelding (Nov 02 2020 at 12:23):

Sollen Änderungshinweise (fehlende Codierungen, vertauschte Werte, ...) bezüglich der Datensätze in Simplifier als Issue in GitHub eingestellt werden?

Andrea Essenwanger (Nov 02 2020 at 13:17):

Hallo! Ob solche Sachen als Issue über Simplifier oder GitHub gemeldet werden, würde für uns keinen großen Unterschied machen (auf GitHub ist es mit der Nachverfolgung natürlich schneller, weil wir die Issues direkt beim Commit als "gelöst" markieren können). Für diejenigen, die weder auf GitHub noch auf Simplifier unterwegs sind, kann man uns natürlich auch über gecco@charite.de anschreiben.

Detlef Kraska (Nov 02 2020 at 13:21):

Werden die über EMail gecco@charite.de gemeldeten Issues auch im GitHub eingetragen oder wo kann man deren Bearbeitungsstatus einsehen?

Alexander Bartschke (Nov 02 2020 at 13:33):

Nein, diese werden nicht auf GitHub eingetragen. Es sollen alle Issues (Zulip, GitHub, Gecco@charite.de, etc.) auf dem Confluence von Adesso gesammelt werden. Die Idee diese auch auf GitHub abzulegen finde ich gut. Ich werde den Vorschlag weitergeben.

Holger Stenzhorn (Nov 06 2020 at 08:30):

@Julian Sass @Alexander Bartschke Kann man in Art-Decor eigentlich die konkreten Unterschiede zwischen einzelnen Entwürfen/Versionen wie in dem Beispiel sehen?

Julian Sass (Nov 06 2020 at 08:37):

Holger Stenzhorn said:

Julian Sass Alexander Bartschke Kann man in Art-Decor eigentlich die konkreten Unterschiede zwischen einzelnen Entwürfen/Versionen wie in dem Beispiel sehen?

Ich denke nicht. Mir ist jedenfalls nicht bekannt, wie das geht.

Holger Stenzhorn (Nov 06 2020 at 08:50):

Julian Sass said:

Holger Stenzhorn said:

Julian Sass Alexander Bartschke Kann man in Art-Decor eigentlich die konkreten Unterschiede zwischen einzelnen Entwürfen/Versionen wie in dem Beispiel sehen?

Ich denke nicht. Mir ist jedenfalls nicht bekannt, wie das geht.

Mmmmh, ok. ...und es gibt keine Verbindung zu GitHub o.Ä. (analog zu Simplifier), wo man dort die Änderungen nachverfolgen kann - oder vielleicht doch? Habt ihr vielleicht ein entsprechendes Log aller Änderungen irgendwo abgelegt, welches man sich anschauen kann?

Julian Sass (Nov 06 2020 at 10:05):

Holger Stenzhorn said:

Mmmmh, ok. ...und es gibt keine Verbindung zu GitHub o.Ä. (analog zu Simplifier), wo man dort die Änderungen nachverfolgen kann - oder vielleicht doch? Habt ihr vielleicht ein entsprechendes Log aller Änderungen irgendwo abgelegt, welches man sich anschauen kann?

Nochmal gecheckt, aber ist tatsächlich leider nicht möglich.

Holger Stenzhorn (Nov 06 2020 at 10:07):

Julian Sass said:

Holger Stenzhorn said:

Mmmmh, ok. ...und es gibt keine Verbindung zu GitHub o.Ä. (analog zu Simplifier), wo man dort die Änderungen nachverfolgen kann - oder vielleicht doch? Habt ihr vielleicht ein entsprechendes Log aller Änderungen irgendwo abgelegt, welches man sich anschauen kann?

Nochmal gecheckt, aber ist tatsächlich leider nicht möglich.

...aber eines manuelles Log eurer Änderungen in den einzelnen Entwürfen/Versionen habt ihr und ist irgendwo zugänglich, richtig?

Julian Sass (Nov 06 2020 at 10:30):

Nein nicht für ArtDecor. Die Versionen in dem Screenshot vergibt das Tool schon, wenn man nur einen Typo fixt. Das ist ohne enormen Aufwand nicht möglich manuell zu tracken.

Holger Stenzhorn (Nov 06 2020 at 11:09):

Julian Sass said:

Nein nicht für ArtDecor. Die Versionen in dem Screenshot vergibt das Tool schon, wenn man nur einen Typo fixt. Das ist ohne enormen Aufwand nicht möglich manuell zu tracken.

Ok, also auch für die "richtigen" größeren Änderungen gibt es auch kein solches Log?

Julian Sass (Nov 06 2020 at 11:57):

Holger Stenzhorn said:

Julian Sass said:

Nein nicht für ArtDecor. Die Versionen in dem Screenshot vergibt das Tool schon, wenn man nur einen Typo fixt. Das ist ohne enormen Aufwand nicht möglich manuell zu tracken.

Ok, also auch für die "richtigen" größeren Änderungen gibt es auch kein solches Log?

Den DIFF mit dem zugrundeliegenden Dokument können wir machen. Das ist überschaubar.

Johannes Oehm (Dec 21 2020 at 13:05):

Hallo zusammen,

Ich bin gerade dabei, Vorarbeiten für das Mapping von unserem ORBIS-Formular, welches wir basierend auf dem Art-Decor und dem RedCap-Formular entwickelt haben, auf die FHIR-Profile aus dem Implementation Guide durchzuführen. Mir sind dabei noch ein paar Sachen unklar, aber vielleicht kann mir hier jemand helfen:

• Bei Anamnese/Risikofaktoren gibt es für jede Oberkategorie von Krankheiten wie "Chronische Lungenerkrankungen", "Herz-Kreislauferkrankungen" ein Feld "Andere". Wie wird dies in FHIR modelliert?
• Bei "Ist der/die Patient*in organtransplantiert?" gibt es im RedCap-Formular den Punkt "Darm", das zugehörige ValueSet OrgansForTransplant unterscheidet jedoch Dickdarm und Dünndarm. Sollen wir den Wert in Formular in Dickdarm und Dünndarm aufteilen?
• Bei den Impfungen: Ich kann über die Slice "absentOrUnknownImmunization" beim vaccineCode markieren, dass gar keine Impfung vorliegt oder ich nichts über den Impfzustand weiß. Wie markiere ich, dass eine der vordefinierten Impfungen "Influenza", "Pneumokokken", "BCG", "Covid19" nicht vorliegt oder ich nicht weiß, dass eine vorliegt? Soll ich in beiden Fällen einfach die Ressource weglassen? Theoretisch könnte man über Immunization.status = "not-done" markieren, dass eine Impfung nicht gemacht wurde, und bei "Unknown" die Ressource komplett weglassen. Macht das Sinn?
• Bei "Imaging procedures"/"Radiological findings": Wie stelle ich in den FHIR-Profilen den Zusammenhang zwischen durchgeführtem bildgebendem Verfahren und dem Befund her? Also wenn ich z.B. ein unauffälligen Ultraschall aber einen Covid-typischen CT-Befund habe, wie bilde ich das ab?
• Bei der Antikoagulations-Medikation: Im Simplifier gibt es eine lange Liste von ATC-Codes, im RedCap finde ich unfraktioniertes Heparin, Niedermolekulares Heparin, Plättchenaggregationshemmer und DOAK. Ich bin medizinischer Laie, kann mir jemand helfen, hier die dazugehörigen ATC-Codes zu finden?
• Bei den Symptomen: Im RedCap gibt es den Punkt "Geruchs- bzw. Geschmacksstörungen", sollten wir den Punkt aufteilen in zwei Punkte "Geruchsverlust" und "Geschmacksverlust" in Übereinstimmung mit dem ValueSet "SARSCoV2Symptoms"?

Das sind soweit die Punkte, die bei mir noch unklar sind. Ich würde mich freuen, wenn mir jemand hierbei helfen kann.

Viele Grüße

Johannes

Johannes Oehm (Jan 04 2021 at 09:28):

@Alexander Bartschke @Andrea Essenwanger @Julian Sass Habt ihr hierzu Ideen/Kommentare?

Julian Sass (Jan 04 2021 at 10:37):

Hallo @Johannes Oehm

Johannes Oehm said:

• Bei Anamnese/Risikofaktoren gibt es für jede Oberkategorie von Krankheiten wie "Chronische Lungenerkrankungen", "Herz-Kreislauferkrankungen" ein Feld "Andere". Wie wird dies in FHIR modelliert?

Die ValueSets der verschiedenen Kategorien enthalten intensionale Definitionen, worüber man "Andere"-Erkrankungen erfassen kann. Bsp. https://simplifier.net/forschungsnetzcovid-19/chronic-lung-diseases beinhaltet neben den explizit gelisteten Antwortmöglichkeiten noch alle SNOMED Codes, die descendants or self of 106048009 |Respiratory finding (finding)| sind. Wenn man die Expansion anfordert, bekommt also auch "Andere".

• Bei "Ist der/die Patient*in organtransplantiert?" gibt es im RedCap-Formular den Punkt "Darm", das zugehörige ValueSet OrgansForTransplant unterscheidet jedoch Dickdarm und Dünndarm. Sollen wir den Wert in Formular in Dickdarm und Dünndarm aufteilen?

Kann ich nicht sicher sagen, aber ich denke die Aufteilung in RedCap macht Sinn.

• Bei den Impfungen: Ich kann über die Slice "absentOrUnknownImmunization" beim vaccineCode markieren, dass gar keine Impfung vorliegt oder ich nichts über den Impfzustand weiß. Wie markiere ich, dass eine der vordefinierten Impfungen "Influenza", "Pneumokokken", "BCG", "Covid19" nicht vorliegt oder ich nicht weiß, dass eine vorliegt? Soll ich in beiden Fällen einfach die Ressource weglassen? Theoretisch könnte man über Immunization.status = "not-done" markieren, dass eine Impfung nicht gemacht wurde, und bei "Unknown" die Ressource komplett weglassen. Macht das Sinn?

In den Vorgaben zum Datensatz wird nur nach den erfolgten Impfungen gefragt. Ich würde daher nur angeben, was tatsächlich geimpft wurde. Für "Unbekannt" würde ich den absentOrUnknownImmunization Slice nutzen.

• Bei "Imaging procedures"/"Radiological findings": Wie stelle ich in den FHIR-Profilen den Zusammenhang zwischen durchgeführtem bildgebendem Verfahren und dem Befund her? Also wenn ich z.B. ein unauffälligen Ultraschall aber einen Covid-typischen CT-Befund habe, wie bilde ich das ab?

Die Procedure referenziert auf den DiagnosticReport. So lassen sich auch meherere Prozeduren einem Report zuordnen. Bsp. https://simplifier.net/forschungsnetzcovid-19/procedure-example-chest-x-ray

• Bei der Antikoagulations-Medikation: Im Simplifier gibt es eine lange Liste von ATC-Codes, im RedCap finde ich unfraktioniertes Heparin, Niedermolekulares Heparin, Plättchenaggregationshemmer und DOAK. Ich bin medizinischer Laie, kann mir jemand helfen, hier die dazugehörigen ATC-Codes zu finden?

Hab ich auch nicht auf Anhieb für jeden der ATCs parat. Ich sehe mal zu, dass wir eine Übersicht erstellen und im IG veröffentlichen. Auf Art-Decor gibt es eine Zuordnung: https://art-decor.org/art-decor/decor-datasets--covid19f-?id=2.16.840.1.113883.3.1937.777.53.1.1&effectiveDate=2020-04-08T13%3A04%3A13&conceptId=2.16.840.1.113883.3.1937.777.53.2.1.2080&conceptEffectiveDate=2020-04-08T00%3A00%3A00&language=de-DE

• Bei den Symptomen: Im RedCap gibt es den Punkt "Geruchs- bzw. Geschmacksstörungen", sollten wir den Punkt aufteilen in zwei Punkte "Geruchsverlust" und "Geschmacksverlust" in Übereinstimmung mit dem ValueSet "SARSCoV2Symptoms"?

Im RedCap aufteilen oder so lassen und zwei Condition-Ressourcen draus machen mit dem jeweiligen SNOMED Code.

Johannes Oehm (Jan 04 2021 at 13:12):

Vielen Dank für die Antwort. Ich lasse dann "Geruchs- und Geschmacksverlust" sowie "Darm" im ORBIS-Formular aufteilen. Für die Impfungen werde ich die Ressource nur erzeugen, welche auch tatsächlich durchgeführt wurden. Wurde keine Impfung durchgeführt. Sollten keine Impfungen angeklickt worden sein, oder alles auf unbekannt, setzte ich "no-known-immunization".

Das mit der Zuordnung bei den Antikoagulations-Medikamenten klingt gut. Ich sehe jetzt auch gerade, dass das RedCap-Formular scheinbar um eine Möglichkeit, das genaue Medikament zu erfassen, erweitert wurde. Ich werde veranlassen, dass diese Listen dann ebenfalls in unser ORBIS-Formular übernommen werden.

Das mit "Andere" bei der Ananmese habe ich lediglich noch nicht verstanden. Das Prinzip von der Expansion eines ValueSets ist mir jedoch grundsätzlich klar. Verstehe ich das also richtig, dass wir dann manuell versuchen sollen, den String, der bei "Bitte spezifizieren" eingetragen wurde, mit SNOMED zu kodieren und dann das Ergebnis zu übermitteln? Wenn "Andere" auf "Nein" oder "Unbekannt" gesetzt wird, was machen soll ich dann? Einfach weglassen? Weil wenn ich z.B. eine Ressource mit 106048009 | Respiratory finding (finding) | auf verificationStaus=refuted setze, würde ich ja damit ausdrücken, dass die anderen Erkrankungen aus der "fixen Liste" ebenfalls nicht vorliegt. Soll ich dann für jede einzelne Erkrankung aus dem ValueSet ebenfalls eine Condition-Ressource erstellen?

Julian Sass (Jan 05 2021 at 09:23):

Johannes Oehm said:

Verstehe ich das also richtig, dass wir dann manuell versuchen sollen, den String, der bei "Bitte spezifizieren" eingetragen wurde, mit SNOMED zu kodieren und dann das Ergebnis zu übermitteln?

Ich denke es wird durch das ValueSet an der Stelle lediglich vorgeschlagen, welche Codes für "Andere" in Frage kommen. Es kann aus meiner Sicht nicht erwartet werden, dass jeder String, der dort eingetragen wird, auf den richtigen SNOMED Code gematcht wird. Das zugrundeliegende MII KDS Diagnose-Profil setzt voraus, dass in Condition.code auch immer ein coding enthalten ist. Es reicht daher leider nicht, bei "Andere" den String mit Condition.code.text zu übermitteln.

Wenn "Andere" auf "Nein" oder "Unbekannt" gesetzt wird, was machen soll ich dann? Einfach weglassen? Weil wenn ich z.B. eine Ressource mit 106048009 | Respiratory finding (finding) | auf verificationStaus=refuted setze, würde ich ja damit ausdrücken, dass die anderen Erkrankungen aus der "fixen Liste" ebenfalls nicht vorliegt. Soll ich dann für jede einzelne Erkrankung aus dem ValueSet ebenfalls eine Condition-Ressource erstellen?

Wenn keine anderen existieren, würde ich auch keine Ressourcen erzeugen.

Johannes Oehm (Jan 07 2021 at 12:39):

alles klar, vielen Dank!

Cornelius Erbelding (Jan 22 2021 at 10:44):

Julian Sass said:

Johannes Oehm said:

Verstehe ich das also richtig, dass wir dann manuell versuchen sollen, den String, der bei "Bitte spezifizieren" eingetragen wurde, mit SNOMED zu kodieren und dann das Ergebnis zu übermitteln?

Ich denke es wird durch das ValueSet an der Stelle lediglich vorgeschlagen, welche Codes für "Andere" in Frage kommen. Es kann aus meiner Sicht nicht erwartet werden, dass jeder String, der dort eingetragen wird, auf den richtigen SNOMED Code gematcht wird. Das zugrundeliegende MII KDS Diagnose-Profil setzt voraus, dass in Condition.code auch immer ein coding enthalten ist. Es reicht daher leider nicht, bei "Andere" den String mit Condition.code.text zu übermitteln.

Für den ODM2FHIR-Mapper (CDISC-ODM aus REDCap & DIS -> FHIR Resourcen) haben wir für "andere" aktuell den SNOMED-Code 385432009 (Not applicable) mit dem Textfeld-Inhalt als Code.Text (nicht Display)
Dieser Code ist zwar im ValueSet nicht vorhanden, ist aus unserer Sicht jedoch aktuell die einzige Möglichkeit die Information nicht zu überspringen. (Hier müsste man die ValueSets ggf. noch erweitern ODER diese als extensible Binding deklarieren)

Julian Sass (Jan 22 2021 at 10:58):

Cornelius Erbelding said:

Für den ODM2FHIR-Mapper (CDISC-ODM aus REDCap & DIS -> FHIR Resourcen) haben wir für "andere" aktuell den SNOMED-Code 385432009 (Not applicable) mit dem Textfeld-Inhalt als Code.Text (nicht Display)
Dieser Code ist zwar im ValueSet nicht vorhanden, ist aus unserer Sicht jedoch aktuell die einzige Möglichkeit die Information nicht zu überspringen. (Hier müsste man die ValueSets ggf. noch erweitern ODER diese als extensible Binding deklarieren)

Ja macht Sinn, nur auf extensible Binding wechseln geht nicht, weil die MII Diagnose, von der abgeleitet wird, an der Stelle schon ein required ValueSet hat. Und es müssen alle Codes subtypes der Codes aus dem MII ValueSet sein. Dort sind Codes aus SNOMED Clinical finding, situation und event erlaubt. Der Validator wird wahrscheinlich meckern, dass 385432009 |Not applicable (qualifier value)| nicht in dem MII ValueSet ist.

Cornelius Erbelding (Jan 25 2021 at 08:09):

Julian Sass said:

Ja macht Sinn, nur auf extensible Binding wechseln geht nicht, weil die MII Diagnose, von der abgeleitet wird, an der Stelle schon ein required ValueSet hat. Und es müssen alle Codes subtypes der Codes aus dem MII ValueSet sein. Dort sind Codes aus SNOMED Clinical finding, situation und event erlaubt. Der Validator wird wahrscheinlich meckern, dass 385432009 |Not applicable (qualifier value)| nicht in dem MII ValueSet ist.

Welcher Code ist ihrer Meinung nach dann hier zu Nutzen? In manchen Profilen werden Sammel-Codes (z.B. <106048009 bei Chron. Lung Dieseases) angegeben. Diese sind jedoch ebenfalls nicht vom Validator aktzeptiert. (Alle Codes mit Concept, is-a, 106048009 sind zu speziell, während 106048009 nicht akzeptiert wird)

Julian Sass (Jan 25 2021 at 16:11):

is-a 106048009 beinhaltet 106048009 und validiert.

Julian Sass (Jan 25 2021 at 16:14):

Würde dann immer auf die unspezifischen Sammelcodes gehen.

Cornelius Erbelding (Jan 26 2021 at 06:23):

Wenn ich den HAPI-FHIR Validator nutze, wird die Resource als invalid gekennzeichnet und der Validator liefert die folgende Meldung:
ERROR: Die angegebene Codierung ist nicht im ValueSet https://www.netzwerk-universitaetsmedizin.de/fhir/ValueSet/xxxx enthalten, und es wird ein Code aus diesem ValueSet benötigt. (error message = Validation failed)

Funktionieren die einzelnen FHIR-Validatoren hier unterschiedlich?

Julian Sass (Jan 26 2021 at 08:18):

HAPI weiß ich nicht. Beispielressource mit 106048009mit Java Validator gegen den IG valididert.

Angela Merzweiler (Jan 26 2021 at 11:09):

Recihen bei den Medikationsdaten die SNOMED Codes oder muss man auch ATC Codes liefern? Wäre ja extrem aufwändig.

Cornelius Erbelding (Jan 26 2021 at 12:32):

Julian Sass said:

HAPI weiß ich nicht. Beispielressource mit 106048009mit Java Validator gegen den IG valididert.

Dürfte ich diese Beispielressource mal sehen? Ich kann die in Simplifier angegebenen Ressourcen nämlich nicht erfolgreich validieren!.

Julian Sass (Jan 26 2021 at 12:33):

Angela Merzweiler said:

Recihen bei den Medikationsdaten die SNOMED Codes oder muss man auch ATC Codes liefern? Wäre ja extrem aufwändig.

SNOMED reicht aus.

Julian Sass (Jan 26 2021 at 12:35):

Cornelius Erbelding said:

Dürfte ich diese Beispielressource mal sehen? Ich kann die in Simplifier angegebenen Ressourcen nämlich nicht erfolgreich validieren!.

Ja klar

{
    "resourceType": "Condition",
    "id": "4f7ba670-119e-4964-9cd5-c191f1c00ce1",
    "meta": {
        "profile":  [
            "https://www.netzwerk-universitaetsmedizin.de/fhir/StructureDefinition/chronic-lung-diseases"
        ]
    },
    "clinicalStatus": {
        "coding":  [
            {
                "system": "http://terminology.hl7.org/CodeSystem/condition-clinical",
                "code": "active",
                "display": "Active"
            }
        ]
    },
    "verificationStatus": {
        "coding":  [
            {
                "system": "http://terminology.hl7.org/CodeSystem/condition-ver-status",
                "code": "confirmed",
                "display": "Confirmed"
            },
            {
                "system": "http://snomed.info/sct",
                "code": "410605003",
                "display": "Confirmed present (qualifier value)"
            }
        ]
    },
    "category":  [
        {
            "coding":  [
                {
                    "system": "http://snomed.info/sct",
                    "code": "418112009",
                    "display": "Pulmonary medicine"
                }
            ]
        }
    ],
    "code": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "106048009",
                "display": "Respiratory finding (finding)"
            }
        ],
        "text": "Eine Lungenerkrankung"
    },
    "subject": {
        "reference": "Patient/c786ac3c-0579-4aa2-adda-db784b214ad6"
    },
    "recordedDate": "2020-10-06"
}

Cornelius Erbelding (Jan 26 2021 at 12:37):

Julian Sass said:

is-a 106048009 beinhaltet 106048009 und validiert.

Das kann ich nicht ganz nachvollziehen.
Laut SNOMED-Browser trifft auf 106048009 nur concept isA 118234003 |Finding by site (finding) zu. (siehe "Details")
Die SNOMED Codes auf die dieser Filter zutrifft sind unter "References" zu finden.

Cornelius Erbelding (Jan 26 2021 at 12:41):

Julian Sass said:

Cornelius Erbelding said:

Dürfte ich diese Beispielressource mal sehen? Ich kann die in Simplifier angegebenen Ressourcen nämlich nicht erfolgreich validieren!.

Ja klar
[CODE]

Auch für diese Ressource lautet die Validator-Meldung
ERROR: Die angegebene Codierung ist nicht im ValueSet https://www.netzwerk-universitaetsmedizin.de/fhir/ValueSet/chronic-lung-diseases enthalten, und es wird ein Code aus diesem ValueSet benötigt. (error message = Validation failed)
Offenbar scheinen sich die Validatoren zu unterscheiden.

Noemi Deppenwiese (Jan 26 2021 at 12:43):

(Oder die GECCO-Version unterscheidet sich bei euch?)

Cornelius Erbelding (Jan 26 2021 at 12:54):

Noemi Deppenwiese said:

(Oder die GECCO-Version unterscheidet sich bei euch?)

Aber auch die von @Julian Sass hier gepostete Beispiel-Ressource lässt sich mit den aktuellen Profilen nicht validieren. Hier wurde von uns nichts bearbeitet.

Julian Sass (Jan 26 2021 at 12:56):

Cornelius Erbelding said:

Das kann ich nicht ganz nachvollziehen.
Laut SNOMED-Browser trifft auf 106048009 nur concept isA 118234003 |Finding by site (finding) zu. (siehe "Details")
Die SNOMED Codes auf die dieser Filter zutrifft sind unter "References" zu finden.

Ah ok verstehe was du meinst. Ja in SNOMED bezieht sich das is-a auf das Parent-Concept. In dem ValueSet hier ist aber der FilterOperator gemeint: http://hl7.org/fhir/codesystem-filter-operator.html#filter-operator-is-a

Cornelius Erbelding (Jan 26 2021 at 13:00):

Julian Sass said:

Ah ok verstehe was du meinst. Ja in SNOMED bezieht sich das is-a auf das Parent-Concept. In dem ValueSet hier ist aber der FilterOperator gemeint: http://hl7.org/fhir/codesystem-filter-operator.html#filter-operator-is-a

Alles klar, das erklärt das die Verwirrung.

Julian Sass (Jan 26 2021 at 13:01):

Also wenn man sich die Expansion auf das ValueSet geben lässt, ist der 106048009 selbst mit enthalten.

Cornelius Erbelding (Jan 26 2021 at 13:01):

Nutzt ihr diesen FHIR-Validator: https://wiki.hl7.org/Using_the_FHIR_Validator? Wenn ja mit welchem Link für den IG?

Julian Sass (Jan 26 2021 at 13:05):

Cornelius Erbelding said:

Nutzt ihr diesen FHIR-Validator: https://wiki.hl7.org/Using_the_FHIR_Validator? Wenn ja mit welchem Link für den IG?

Ja mit dem package lokal bspw. kann man das Bsp. validieren mit java -jar validator_cli.jar example.json -output validation-example.xml -ig de.gecco-1.0.2.tgz

Cornelius Erbelding (Jan 28 2021 at 07:21):

Hallo zusammen, wie soll denn eine Impfung mit "Unknown" in FHIR codiert werden? Die Beispiele in Smplifier beschreiben nur die durchgeführten Impfungen bzw. keine durchgeführte Impfung. Ist hier vorgesehen Unknown-Impfungen nicht in FHIR zu überführen?

Holger Stenzhorn (Jan 28 2021 at 08:08):

Cornelius Erbelding said:

Hallo zusammen, wie soll denn eine Impfung mit "Unknown" in FHIR codiert werden? Die Beispiele in Smplifier beschreiben nur die durchgeführten Impfungen bzw. keine durchgeführte Impfung. Ist hier vorgesehen Unknown-Impfungen nicht in FHIR zu überführen?

Wenn ich mir https://www.hl7.org/fhir/immunization.html anschaue, so steht dort...

The Immunization resource is intended to cover the recording of current and historical administration of vaccines to patients across all healthcare disciplines in all care settings and all regions.

Im GECCO-IG wird ja auch darauf verwiesen, dass das GECCO-Immunization-Profil sich eng an das entsprechende Profil des MIO-Impfpasses der KBV anlehnt, welcher halt die Historie der durchgeführten Impfungen enthält (also analog zum regulären papierbasierten Impfpass).

Für mein Verständnis würde dies bedeuten, dass in dem Fall, wenn im EDC-System bei einer Impfung für den Parameter "durchgeführt" der Wert "unbekannt" angegeben wird, einfach keine Immunization-FHIR-Ressource erzeugt wird.

(Dies würde dann natürlich analog auf andere Parameter/Ressourcen zutreffen, z.B. wenn "unbekannt" ist, ob ein bestimmtes bildgebendes Verfahren "durchgeführt" wurde oder ob eine bestimmte Komplikation aufgetreten ist.)

@Julian Sass Wie ist denn deine Meinung hierzu?

Noemi Deppenwiese (Jan 28 2021 at 13:05):

Da es in der immunization keinen expliziten "Unknown" Status gibt, würde ich auch für ein nicht Erzeugen der Ressource plädieren.

Julian Sass (Jan 28 2021 at 14:27):

Genau, ich würde da nur das erzeugen, was auch vorliegt. Es gab keine Vorgabe, dass man nicht erfolgte Impfungen explizit nennen muss.

Jan Prill (Feb 23 2021 at 14:57):

Hallo @Julian Sass , uns hat aus dem AP6 Jour fixe folgende Frage erreicht:

Das Eintragen des Geburtsdatums in RedCap ist bei uns nicht möglich, da es sich um eindeutig identifizierende Daten handelt. Dieser Umstand scheint jetzt auch bei anderen Standorten wichtig zu sein (siehe Kommentar von JG vom 18.02.2021 30 EDC System REDCap). Ist es daher möglich anstatt des Geburtsdatums das Alter zu verwenden? (Frage an alle Standorte und das Gecco Redaktionsteam).

Könntest Du einerseits sagen, ob folgende Antwort soweit richtig ist:

Das Element birthDate ist in https://simplifier.net/ForschungsnetzCovid-19/Patient/~details mit der Kardinalität 0..1, aber auch mit "Must Support" true modelliert. Must Support bedeutet, im Sinne der RFC-Definitionen ein "SHALL" (was natürlich bei dem Wortlaut etwas seltsam anmutet, aber hier nachzulesen ist: http://hl7.org/fhir/r4/conformance-rules.html#mustSupport).

Grds. ist laut Frau Thun ja für größtmögliche Flexibilität der Standorte gesorgt worden, indem die Angabe von Elementen ganz überwiegend optional ist. Das Geburtsdatum sollte also definiert werden. Soweit die Modellierung nach meinem Verständnis. Spätestens beim nächsten Teilprojektleitermeeting, an dem Fr. Thun regelm. teilnimmt, gibt es die Möglichkeit die Frage an Fr. Thun zu stellen. Wollen Sie die Frage evtl. auch direkt noch einmal im https://chat.fhir.org und dort dem Kanal german (d-a-ch) an Julian Sass aus dem Team von Fr. Thun stellen?

Wenn falsch: Gerne korrigieren. Außerdem: Was können wir dem Fragesteller (Hr. Hennings) für einen Tipp geben? Kann das Alter bereits jetzt, ohne genaues Geburtsdatum im Datensatz untergebracht werden?

Julian Sass (Feb 23 2021 at 16:18):

Patient.birthDate ist optional 0..1, damit die Standorte, wo die Information nicht vorliegt oder nicht erfasst werden kann, diese auch nicht angeben müssen. Wenn ich aber bspw. client-seitig in meinem EDC System etc. ein Geburtsdatum erfasse, dann sollte ich in der Lage sein, dieses in dem birthDate-Element unterzubringen. Daher das must-support. Plus: auf der Empfängerseite sollte ich in der Lage sein, wenn der Client das Geburtsdatum liefert, dieses auch verarbeiten zu können.
Für das Alter gibt es die Age-Extension auf Patient, in der man das Alter zu einem bestimmten Zeitpunkt erfassen kann.

Jan Prill (Feb 23 2021 at 17:18):

Danke sehr!

Christof Gessner (Feb 23 2021 at 18:26):

Observation mit LOINC https://loinc.org/30525-0/ oder https://loinc.org/63900-5/ ?

Julian Sass (Feb 23 2021 at 20:21):

Christof Gessner said:

Observation mit LOINC https://loinc.org/30525-0/ oder https://loinc.org/63900-5/ ?

Die Variante über Observation und 30525-0 wäre auch gut gewesen, das stimmt.

Frank Oemig (Feb 24 2021 at 07:13):

Ein mustSupport bedeutet, dass diese Information grundsätzlich behandelt werden können muss, ansonsten ist man nicht konform.
0..1 heißt, dass diese Information aber nicht immer verfügbar sein muss. Wer anstelle von Geburtsdatum nur das Alter kann, verletzt also diese Anforderung.
Als Lösung wäre hier ein unscharfes Alter anzugeben. Wenn ich weiß, dass jemand 30 Jahre alt ist, dann müsste er/sie ungefähr 1990-1991 geboren worden sein. Das kann man mit einer uncertainty extension dann umsetzen.
Wenn ich tatsächlich nur das Alter angeben will, dann wäre das eine Beobachtung zu einem bestimmten Zeitpunkt.

Simone Heckmann (Feb 24 2021 at 15:23):

Es wäre absolut legitim, ein partielles Datum anzugeben:
<birthDate value="1991"/>
Damit wäre das Feld gefüllt, die Angabe von partiellen Daten ist in FHIR erlaubt, wäre also valide und es ist in etwa genau so "unscharf" wie die Angabe des Alters...

Frank Oemig (Feb 24 2021 at 17:29):

Richtig, wenn das Alter aber 29 ist, dann ist das Geburtsdatum wohl gegen Mitte des Jahres. Daher value=1991-06 mit Genauigkeit halbes Jahr - oder so ähnlich....

Diana Pietzner (Feb 25 2021 at 13:26):

Frage zu ICD 10 Codes: auf https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Chroniclungdiseases-duplicate-2 beim ValueSet 'ChronicLungDiseasesICD' fehlt die Zuordnung der ICD10-Codes zu SNOMED bzw. zum GECCO-Fragebogen. z.B. Farmerlunge ist im RedCap nicht implementiert. Sind die ICD10-Codes trotzdem verbindlich umzusetzten, also z.B. bei Asthma nur J45.9, oder auch J45.8, J45.1, J45.0?
Gibt es für die Symptome https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Symptom auch eine Zuordnung zu den ICD10-Codes?

Julian Sass (Feb 25 2021 at 19:55):

Diana Pietzner said:

Frage zu ICD 10 Codes: auf https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Chroniclungdiseases-duplicate-2 beim ValueSet 'ChronicLungDiseasesICD' fehlt die Zuordnung der ICD10-Codes zu SNOMED bzw. zum GECCO-Fragebogen. z.B. Farmerlunge ist im RedCap nicht implementiert. Sind die ICD10-Codes trotzdem verbindlich umzusetzten, also z.B. bei Asthma nur J45.9, oder auch J45.8, J45.1, J45.0?
Gibt es für die Symptome https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Symptom auch eine Zuordnung zu den ICD10-Codes?

Link zu Art-Decor hier gibt's die Zuordnung ICD<->SNOMED. Bei ICD stehen auch Codes drin, die unter die Antwortmöglichkeit 'andere' fallen, deswegen 'Farmerlunge' etc. Ich würde nur kodieren, was tatsächlich vorliegt. Wenn lediglich nach 'Asthma' gefragt wird, ist deswegen der generische SNOMED Code für Asthma zugeordnet und der ICD J45.9 n.n.b. Für die anderen ICDs müsste ich ja die spezifische Asthmaform erfragen. Die weiteren Codes sind aber möglich, wenn die genaue Form bekannt ist oder man den Datensatz aus Routinedaten aus dem DIZ füllt, wo man oft die genaueren ICDs hat.
Die Symptome haben wir bislang anscheinend nur mit SNOMED gemacht.

Diana Pietzner (Feb 26 2021 at 10:34):

Julian Sass said:

Wenn lediglich nach 'Asthma' gefragt wird, ist deswegen der generische SNOMED Code für Asthma zugeordnet und der ICD J45.9 n.n.b. Für die anderen ICDs müsste ich ja die spezifische Asthmaform erfragen. Die weiteren Codes sind aber möglich, wenn die genaue Form bekannt ist oder man den Datensatz aus Routinedaten aus dem DIZ füllt, wo man oft die genaueren ICDs hat.
Die Symptome haben wir bislang anscheinend nur mit SNOMED gemacht.

D.h. wir verwenden die gesamte J45.-(allergisches und nichtallergisches Asthma), aber nicht die J46 (Akutes schweres Asthma bronchiale)?
Es wäre gut, da eine verbindliche Liste der ICD-Codes zu haben, insbesondere auch welche Risikofaktoren/Symptome als "andere" zu erfassen sind, damit sich nicht jeder Standort eigene Zuordnungen überlegt.

Noch eine Frage zur Position "Zustand nach Herzinfarkt": sind hier nur alte Herzinfarkte nach ICD gemeint (>29 Tage, I25.2-), oder auch wenige Tage alte, also I21.-? Die SNOMED-Definition beinhaltet meiner Meinung nach beides.

Julian Sass (Mar 01 2021 at 09:47):

Diana Pietzner said:

D.h. wir verwenden die gesamte J45.-(allergisches und nichtallergisches Asthma), aber nicht die J46 (Akutes schweres Asthma bronchiale)?

J46 macht wahrscheinlich auch Sinn.

Es wäre gut, da eine verbindliche Liste der ICD-Codes zu haben, insbesondere auch welche Risikofaktoren/Symptome als "andere" zu erfassen sind, damit sich nicht jeder Standort eigene Zuordnungen überlegt.

Es gibt dazu keine Vorgabe durch die Redaktionsgruppe, das verbindlich vorzugeben.

Noch eine Frage zur Position "Zustand nach Herzinfarkt": sind hier nur alte Herzinfarkte nach ICD gemeint (>29 Tage, I25.2-), oder auch wenige Tage alte, also I21.-? Die SNOMED-Definition beinhaltet meiner Meinung nach beides.

Ich schätze beides. "Zustand nach Herzinfarkt" ist schon die ganze Information aus der Vorgabe ohne nähere Erläuterung.

Stefanie Schild (Mar 03 2021 at 15:10):

Hallo zusammen,
wir haben uns die Daten unserer Covid-Patienten auf der Intensivstation angeschaut und haben festgestellt, dass wir z.B. für Blutdruck, Atemfrequenz und Körpertemperatur neben allgemeineren LOINCS auch spezifischere LOINCs angeben könnten, als die für Gecco geforderten, z.B.
76213-8 (Invasive Diastolic blood pressure) - gefordert 8462-4 (Diastolic blood pressure)
19840-8 (Breath rate spontaneous and mechanical --on ventilator) - gefordert 9279-1 (Respiratory rate)
8334-5 (Body temperature - Urinary bladder) - gefordert 8310-5 (Body temperature)

Wie soll damit umgegangen werden?
Aus unserer Sicht wäre möglich:

• Nur die Messwerte für den geforderten LOINC ausliefern (eventuell wird bei einem Patienten aber nur IBP gemessen)
• Die spezifischeren LOINCs für den Export auch auf den allgemeineren LOINC mappen (es kommt aber auch vor, dass ein Patient beide Messwerte gleichzeitig liefert, z.B. IBP über eine Sonde und NIBP über eine Blutdruckmanschette, die voneinander abweichen können)

Julian Sass (Mar 05 2021 at 13:36):

Stefanie Schild said:

Hallo zusammen,
wir haben uns die Daten unserer Covid-Patienten auf der Intensivstation angeschaut und haben festgestellt, dass wir z.B. für Blutdruck, Atemfrequenz und Körpertemperatur neben allgemeineren LOINCS auch spezifischere LOINCs angeben könnten, als die für Gecco geforderten, z.B.
76213-8 (Invasive Diastolic blood pressure) - gefordert 8462-4 (Diastolic blood pressure)
19840-8 (Breath rate spontaneous and mechanical --on ventilator) - gefordert 9279-1 (Respiratory rate)
8334-5 (Body temperature - Urinary bladder) - gefordert 8310-5 (Body temperature)

Wie soll damit umgegangen werden?
Aus unserer Sicht wäre möglich:

• Nur die Messwerte für den geforderten LOINC ausliefern (eventuell wird bei einem Patienten aber nur IBP gemessen)
• Die spezifischeren LOINCs für den Export auch auf den allgemeineren LOINC mappen (es kommt aber auch vor, dass ein Patient beide Messwerte gleichzeitig liefert, z.B. IBP über eine Sonde und NIBP über eine Blutdruckmanschette, die voneinander abweichen können)

Haben die Frage an die Redaktionsgruppe des Datensatzes weitergegeben, weil ich das so nicht beantworten kann, inwiefern das inhaltlich für die Auswertung geplant war. Die Meinung der Mediziner*innen hier war, die drei Parameter auch mit dem unspezifischen LOINC abbilden zu können. FHIR-seitig könntet ihr eure spezifischen LOINCs zusätzlich zu den geforderten in der Observation erfassen.

Stefanie Schild (Mar 10 2021 at 08:56):

Ok, vielen Dank für die Rückmeldung!

Patrick Werner (Mar 13 2021 at 11:56):

FHIR bietet hier die schöne Möglichkeit der mehrfachen codierung. Also der Erfassung eines required codes wie "85354-9" + alternativer, feiner granularer Konzepte (wie oben bspw: 76213-8)

Patrick Werner (Mar 13 2021 at 11:57):

Hierzu sollten aber die SCT und LOINC Slices auf 1..* bzw. 0..* gesetzt werden. Die aktuelle Profilierung verbietet mutliple codings im selben System.

Julian Sass (Apr 14 2021 at 14:20):

Stefanie Schild said:

Hallo zusammen,
wir haben uns die Daten unserer Covid-Patienten auf der Intensivstation angeschaut und haben festgestellt, dass wir z.B. für Blutdruck, Atemfrequenz und Körpertemperatur neben allgemeineren LOINCS auch spezifischere LOINCs angeben könnten, als die für Gecco geforderten, z.B.
76213-8 (Invasive Diastolic blood pressure) - gefordert 8462-4 (Diastolic blood pressure)
19840-8 (Breath rate spontaneous and mechanical --on ventilator) - gefordert 9279-1 (Respiratory rate)
8334-5 (Body temperature - Urinary bladder) - gefordert 8310-5 (Body temperature)

Wie soll damit umgegangen werden?
Aus unserer Sicht wäre möglich:

• Nur die Messwerte für den geforderten LOINC ausliefern (eventuell wird bei einem Patienten aber nur IBP gemessen)
• Die spezifischeren LOINCs für den Export auch auf den allgemeineren LOINC mappen (es kommt aber auch vor, dass ein Patient beide Messwerte gleichzeitig liefert, z.B. IBP über eine Sonde und NIBP über eine Blutdruckmanschette, die voneinander abweichen können)

Hallo @Stefanie Schild also ihr könnt/sollt die spezifischen Messungen mitnehmen. Ich hab im IG eure Beispiele aufgenommen, wie ihr das mit mehreren Codings machen könnt. Bei den meisten Vitalzeichen ging das schon, jetzt auch bei den Blutdruck components. Danke für den Hinweis @Patrick Werner

Stefanie Schild (Apr 15 2021 at 06:22):

ok, vielen Dank für die Rückmeldung!

Johannes Oehm (May 04 2021 at 12:03):

Hallo zusammen,

Weiß jemand, ob es zufällig irgendwo schon eine FHIR-Questionnaire mit den GECCO-Datenelementen gibt?

Alexander Zautke (May 04 2021 at 16:24):

Es gibt erste Entwicklungen im Bereich der Generierung von Questionnaires auf Basis der Profile, aber leider noch nichts das öffentlich ist.

Morten Ernebjerg (May 05 2021 at 07:21):

Der FHIR-Questionnaire, der die fragen in der CovApp Corona Guidance App beschreibt, ist zwar nicht nach GECCO modelliert (weil er definiert wurde, bevor es GECCO gab), benutzt aber Teilweise sehr aehnliche Datenelement (z.B. fuer Symptome). Der IG dazu ist hier, der Questionnaires auf dieser Unterseite, die Symptom VS ist hier.

Julian Sass (May 06 2021 at 12:00):

Johannes Oehm said:

Hallo zusammen,

Weiß jemand, ob es zufällig irgendwo schon eine FHIR-Questionnaire mit den GECCO-Datenelementen gibt?

@Alexander Bartschke

Morten Ernebjerg (May 12 2021 at 14:24):

Mir ist gerade aufgefallen, dass fast alle Dependencies im neustem GECCO-Package (1.0.3) Package-Versionen sind, die im FHIR Package Registry als "unlisted" gefuehrt werden. Genauer genommen gilt es fuer die DE-Basisprofile und alle Packages aus dem Medizininformatikinitiative. Die sind zwar noch alle ueber Simplifier verfuegbar, aber koennte es trotztdem zu Tooling-Probleme fuehren? Konkret habe ich gerade Probleme, das GECCO-Paket in HAPI zu laden, siehe diesen thread im HAPI-Stream.

Julian Sass (May 12 2021 at 19:11):

Morten Ernebjerg said:

Mir ist gerade aufgefallen, dass fast alle Dependencies im neustem GECCO-Package (1.0.3) Package-Versionen sind, die im FHIR Package Registry als "unlisted" gefuehrt werden. Genauer genommen gilt es fuer die DE-Basisprofile und alle Packages aus dem Medizininformatikinitiative. Die sind zwar noch alle ueber Simplifier verfuegbar, aber koennte es trotztdem zu Tooling-Probleme fuehren? Konkret habe ich gerade Probleme, das GECCO-Paket in HAPI zu laden, siehe diesen thread im HAPI-Stream.

Der Fehler ist mir auch neu und ich hatte das package vor einiger Zeit schon mal in den JPA starter server geladen. Beim Java Tooling war mir bislang nur ein Fehler durch die KBV.Basis Dependency in MII Diagnose bekannt. Deswegen kann ich gerade nicht sagen, woran es liegt. Im current build sind die MII dependencies schon aktualisiert und dann in Kürze in 1.0.4 drin.

Morten Ernebjerg (May 13 2021 at 19:08):

Alles klar, danke @Julian Sass !

Julian Sass (May 26 2021 at 08:12):

@Morten Ernebjerg magst du einmal https://simplifier.net/packages/de.gecco/1.0.4-rc.1 testen?

Morten Ernebjerg (May 26 2021 at 09:31):

@Julian Sass Gerne :smile: Mit dem neusten HAPI JPA server starter sehe ich folgendes beim Laden (beim Hochfahren)

• Jede menge "Failed to pre-expand ValueSet"-Fehler, die aber scheinbar ignoriert werden (Beispiel2021-05-26 11:18:26.993 [hapi-fhir-jpa-scheduler-clustered-1] ERROR c.u.f.jpa.term.BaseTermReadSvcImpl [BaseTermReadSvcImpl.java:1772] Failed to pre-expand ValueSet: Unknown CodeSystem URI "http://fhir.de/CodeSystem/dimdi/ops" referenced from ValueSet)
• Das Hochfahren scheitert immer noch, weil der Server bei der Snapshot-Generierung versucht, auf Resources aus den Dependencies zuzugreifen und scheitert ([...] Caused by: ca.uhn.fhir.rest.server.exceptions.PreconditionFailedException: Unknown base definition: https://www.medizininformatik-initiative.de/fhir/core/modul-medikation/StructureDefinition/MedicationStatement)

Ich denke, dass ist wohl eher ein HAPI-Problem mit dem Depdendency-Resolution, vgl. HAPI-Thread dazu. Ich schreibe da einen Update.

Julian Sass (May 26 2021 at 09:39):

@Morten Ernebjerg Ich hab die MII Packages aus den Dependencies nochmal separat in der application.yaml vom JPA server, damit er die Snapshots generiert.

Morten Ernebjerg (May 26 2021 at 09:50):

@Julian Sass Ah, ist das mit Absicht so gemacht oder ist es einfach ein bekannter Fehler? Ich denke, das geht auch bei mir, aber habe gedacht, HAPI wuerde das Depedency-Management auch von alleine schaffen.

Julian Sass (May 26 2021 at 09:59):

Ne ich war auch davon ausgegangen, das Depedency-Management würde durch Package und Server gehändelt. Bis ich dann auch Unknown base definition bekommen und etwas rumprobiert habe. Deswegen ganz interessant, was zu deinem Post im Hapi Stream rauskommt.

Julian Sass (Jun 03 2021 at 08:58):

https://simplifier.net/packages/de.gecco/1.0.4

Release notes sind unter dem Link auf Simplifier. Bei Problemen gerne weiter Rückmeldung geben.

Julian Sass (Jun 03 2021 at 09:00):

Es laufen noch Anträge bei SNOMED/LOINC, um in den kommenden Versionen die custom-definierten Codes auszutauschen. Für den SOFA-Score gibt es voraussichtlich mit dem nächsten Release dann auch einen LOINC.

Yannick Börner (Jun 14 2021 at 07:30):

Spricht etwas dagegen, im Profil für Heart Rate auf observation.valueQuantity.unit ein pattern mit 'beats/minute' zu setzen? Der code hat schon das pattern '/min'.

Julian Sass (Jun 14 2021 at 09:07):

Yannick Börner said:

Spricht etwas dagegen, im Profil für Heart Rate auf observation.valueQuantity.unit ein pattern mit 'beats/minute' zu setzen? Der code hat schon das pattern '/min'.

Ich würde Quantity.unit ungern vorschreiben und es der jeweiligen Implementierung überlassen, welcher Display Term für die UCUM Einheit gewählt wird.

Julian Sass (Aug 05 2021 at 08:49):

Betrifft die Implementierung in CODEX: Wir brauchen für das Data Sharing Framework eine Möglichkeit alle Ressourcen in den lokalen FHIR Stores der Standorte zu identifizieren für die der Consent vorliegt und die im Rahmen des Projektes an die zentrale Plattform übermittelt werden dürfen. Momentan sucht und pullt die Process Engine Ressourcen mit Canonical https://www.netzwerk-universitaetsmedizin.de/… Das wird aber nur bedingt funktionieren, weil die Profile Resource.meta.profile nicht vorschreiben.

1. Alternative: Mit Consent.provision.data.reference auf alle vom Consent abgedeckten Ressourcen referenzieren.
2. Alternative: Ressourcen unter Encounter zusammenfassen, wie jetzt schon in der RedCap Implementierung

Weitere Ideen? @Noemi Deppenwiese @Holger Stenzhorn @Cornelius Erbelding @Florian Seidel und wen ich von CODEX noch vergessen habe :smile:

Noemi Deppenwiese (Aug 05 2021 at 08:52):

@Julian Gruendner @Marvin Kampf

Marvin Kampf (Aug 05 2021 at 09:51):

Vielleicht etwas naiv gedacht, aber kann man die Ressourcen nicht via subject-Reference finden?

Marvin Kampf (Aug 05 2021 at 09:52):

Also patienten-zentriert

Julian Sass (Aug 05 2021 at 11:22):

Das wäre wie $everything Operation auf Patient. Nur dann überträgt man alle Daten von einem Patienten und hat aber ggf. nur Erlaubnis für das GECCO Subset. Deswegen die Überlegung, wie man am besten filtert. Und die NUM Canonical ist imo kein gutes Kriterium.

Marvin Kampf (Aug 05 2021 at 11:42):

Ich bin bisher davon ausgegangen, dass im GECCO-FHIR-Server auch nur GECCO-Ressourcen liegen.

Julian Sass (Aug 05 2021 at 11:51):

Das ist eine Frage seitens DSF, ob tatsächlich in dem Server immer nur Ressourcen liegen mit Consent.

Marvin Kampf (Aug 05 2021 at 11:52):

Mein Stand (aber keine offizielle Aussage) ist: GECCO-FHIR-Server enthält nur GECCO-Ressourcen, allerdings sind nicht alle Ressourcen, die enthalten sind, für die Weitergabe an zentral konsentiert. Es können auch GECCO-Ressourcen enthalten sein, für die es keinen Consent gibt, die aber für Feasibility-Anfragen genutzt werden können.

Marvin Kampf (Aug 05 2021 at 11:52):

@Julian Gruendner

Julian Sass (Aug 05 2021 at 12:07):

In dem Fall darf das DSF nur genau die Ressourcen rauspicken, die für die Weitergabe an zentral konsentiert sind.

Marvin Kampf (Aug 05 2021 at 12:25):

Das heißt, es gibt zu einem einzelnen Patienten Ressourcen, die konsentiert und Ressourcen, die nicht konsentiert sind?

Julian Sass (Aug 05 2021 at 12:33):

Davon ist auszugehen, ja.

Alexander Kiel (Aug 05 2021 at 19:50):

Julian ist noch zwei weitere Wochen im Urlaub. Ich habe in CODEX an AP2 Feasibility mitgearbeitet. Ich kann euch aber leider nicht viel zum zentralen Upload und Consent sagen. @Hauke Hund kannst Du hier weiterhelfen?

Sven Helfer (Aug 09 2021 at 06:26):

Julian Sass said:

Davon ist auszugehen, ja.

Ist insgesamt schwierig. Ich glaube, der Scope der Aufklärung (des z-Moduls) ist "der COVID-Fall" (also nach unserer Interpretation der letzte/aktuelle). Wie will man denn überhaupt überprüfen, ob der letzte Fall jetzt noch der aktuelle ist, oder ob es z.B. die spätere Diagnose einer Komplikation ist? Ich glaube, das Problem ist hier gar nicht nur ein technisches...

Gustav Vella (Aug 11 2021 at 09:47):

Es ist leider nicht so dass der "COVID-Fall" immer der letzte aktuelle Fall des Patienten/GECCO-Probanden ist. Die richtigen Observations oder sonstige Ressourcen aus dem lokalen FHIR Server rauszufischen ist bei Kunden, die sie nicht klar im ServiceRequest gekennzeichnet haben echt ein Problem. Ich kann diese nicht deterministisch assoziieren. Wie gehen andere hiermit um? Habt ihr die im KIS oder Labor eindeutig annotiert? Was macht ihr wenn das nicht der Fall ist? Annotiert ihr sie nachträglich im KIS und aktualisiert die Ressourcen? Gibt es ein klares Kriterium oder eine klare Ableitungsregel?

Sven Helfer (Aug 11 2021 at 14:07):

Also wir fragen im DWH nur COVID-Fälle ab - die Problematik mit dem Scope der Aufklärung ignorieren wir aktuell noch, da keine aufgeklärten Patienten (lange Geschichte... :unamused: )

Sven Helfer (Aug 11 2021 at 14:09):

(...und es eben ein Randfall ist. Wer hat wohl 2x Covid und willigt beim ersten ein und beim zweiten - absichtlich - nicht)

Lorenz Rosenau (Sep 15 2021 at 06:52):

Gibt es einen Hintergrund dafür, dass im logical model für das alter keine <f:extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-allowedUnits"> für das Alter:

            <f:path value="forschungsdatensatz_gecco.gecco.demographie.alter"/>
            <f:code>
                <f:system value="http://loinc.org"/>
                <f:code value="30525-0"/>
                <f:display value="Age"/>
            </f:code>
            <f:code>
                <f:system value="http://snomed.info/sct"/>
                <f:code value="424144002"/>
                <f:display value="Current chronological age (observable entity)"/>
            </f:code>
            <f:short value="Age">
                <f:extension url="http://hl7.org/fhir/StructureDefinition/translation">
                    <f:extension url="lang">
                        <f:valueCode value="de-DE"/>
                    </f:extension>
                    <f:extension url="content">
                        <f:valueMarkdown value="Alter"/>
                    </f:extension>
                </f:extension>
            </f:short>
            <f:definition value="Age at study enrollment (in years or months)">
                <f:extension url="http://hl7.org/fhir/StructureDefinition/translation">
                    <f:extension url="lang">
                        <f:valueCode value="de-DE"/>
                    </f:extension>
                    <f:extension url="content">
                        <f:valueMarkdown value="Alter bei Studieneinschluss in Jahren oder Monaten"/>
                    </f:extension>
                </f:extension>
            </f:definition>
            <f:min value="0"/>
            <f:max value="*"/>
            <f:base>
                <f:path value="forschungsdatensatz_gecco.gecco.demographie.alter"/>
                <f:min value="0"/>
                <f:max value="*"/>
            </f:base>
            <f:type>
                <f:code value="Quantity"/>
            </f:type>
        </f:element>

Vorhanden ist? Im Rahmen von CODEX rendern wir die Einheiten basierend auf dem Logical Model. Von daher wäre es wünschenswert, wenn auch das Alter eine Einheit hätte.

Julian Sass (Sep 20 2021 at 09:33):

Hallo @Lorenz Rosenau die Einheiten sind jetzt auch im LogicalModel hinzugefügt.

Lorenz Rosenau (Sep 21 2021 at 12:38):

Vielen Dank.

Mário Macedo (Nov 23 2021 at 13:32):

Hello, first time here and I was hoping to get some help regarding the GECCO dataset (Sorry, my German is not so good)

Regarding the Anamnesis record, in the Chronic Lung diseases question:
In the implementation guide, one can see that the response options is a list of diseases but suddenly we also have the No, other and unknown. My question is whether
a) the structure should actually be like in the Symptoms, so that for each disease one must answer either with yes, no or unknown. Therefore we would always generate a fhir for each disease with its corresponding answer.
b) everything should be in one general file, where no or unknown would apply to everything, and in the case of yes, then the list of diseases the patient suffers from would be provided. In this case the fhir would have several codes corresponding to the different diseases (however, currently such a file is not validated successfully, since it only accepts one code)

Additionally, how should "other" be represented? Haven't found any example for this one.

Finally, would the same logic apply to the Cardiovascular/Liver/Rheumatological diseases? As well as the organ transplant one?

Thank you for the help!

Julian Sass (Nov 23 2021 at 15:14):

Hi @Mário Macedo you're welcome,
a) yes, the structure for lung/cardiovascular etc. is like in symptoms. So for each disease they ask you to state whether it's present/absent/unknown.
b) you generate one Condition resource per disease, that's why code is max 1. The concept of a list is a different resource type in FHIR, but you're not required to use it here.
other) if you want to capture 'other', inside each ValueSet there are these include statements Include codes from... that cover a range of appropriate codes for each category.

Mário Macedo (Nov 23 2021 at 15:30):

@Julian Sass Thank you for the answer :)

Lorenz Rosenau (Dec 07 2021 at 12:35):

Hi @Julian Sass ,
für SarsCoV2AbSerPlIAaCnc, SarsCoV2IgASerPlIAaCnc, SarsCoV2IgGSerPlIAaCnc und SarsCoV2IgMSerPlIAaCnc
verwenden für das disablen der Verwendung von valueCodeableConcept:

      {
        "id": "Observation.value[x]:valueCodeableConcept",
        "path": "Observation.value[x]",
        "sliceName": "valueCodeableConcept",
        "max": "0"
      }

Überall sonst, erfolgt die Modellierung rein quanitativer Observations über:

      {
        "id": "Observation.value[x]",
        "path": "Observation.value[x]",
        "slicing": {
          "discriminator": [
            {
              "type": "type",
              "path": "$this"
            }
          ],
          "ordered": false,
          "rules": "open"
        },
        "type": [
          {
            "code": "Quantity"
          }
        ],
        "mustSupport": true
      },

Könnte man das für zukünftige Versionen bitte anpassen.

Hao Qian (Dec 20 2021 at 09:39):

Hallo zusammen!
ich habe eine Frage zum GECCO Consent. Bei uns müssen die CODEX Patienten zwei Einwilligungen unterschreiben, ein Board Consent und ein CODEX Consent. Meine Frage ist, können wir die beiden Consents in zwei FHIR Resource schreiben? Das wäre einfacher für uns. Im Beispiel (https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Consent) werden die Policies aus MII Board Consent und Z-Modul in einem FHIR Resource geschrieben.

Julian Sass (Dec 20 2021 at 10:11):

Lorenz Rosenau said:

Hi Julian Sass ,
für SarsCoV2AbSerPlIAaCnc, SarsCoV2IgASerPlIAaCnc, SarsCoV2IgGSerPlIAaCnc und SarsCoV2IgMSerPlIAaCnc
verwenden für das disablen der Verwendung von valueCodeableConcept:

      {
        "id": "Observation.value[x]:valueCodeableConcept",
        "path": "Observation.value[x]",
        "sliceName": "valueCodeableConcept",
        "max": "0"
      }

Überall sonst, erfolgt die Modellierung rein quanitativer Observations über:

      {
        "id": "Observation.value[x]",
        "path": "Observation.value[x]",
        "slicing": {
          "discriminator": [
            {
              "type": "type",
              "path": "$this"
            }
          ],
          "ordered": false,
          "rules": "open"
        },
        "type": [
          {
            "code": "Quantity"
          }
        ],
        "mustSupport": true
      },

Könnte man das für zukünftige Versionen bitte anpassen.

Das lässt sich nicht so ohne Weiteres anpassen. Die erste Variante wird immer genutzt, wenn das Profil auf der Labor Observation der MI-I aufbaut. Bei der MI-I sind in value[x] schon zwei Slices für Quantity und CodeableConcept vordefiniert, wovon eins dann jeweils deaktiviert wird.

Mário Macedo (Jan 12 2022 at 15:39):

Hello everyone!
I have a question, in the History of travel, in case the patient went to more than one destination, do we need to generate one fhir file for each destination?
Or is there any structure for several destinations simultaneously?
Thanks in advance

Julian Sass (Jan 12 2022 at 16:34):

Mário Macedo said:

Hello everyone!
I have a question, in the History of travel, in case the patient went to more than one destination, do we need to generate one fhir file for each destination?
Or is there any structure for several destinations simultaneously?
Thanks in advance

Hi @Mário Macedo, you would generate a separate Observation instance for each destination.

Julian Sass (Jan 12 2022 at 16:40):

Hao Qian said:

Hallo zusammen!
ich habe eine Frage zum GECCO Consent. Bei uns müssen die CODEX Patienten zwei Einwilligungen unterschreiben, ein Board Consent und ein CODEX Consent. Meine Frage ist, können wir die beiden Consents in zwei FHIR Resource schreiben? Das wäre einfacher für uns. Im Beispiel (https://simplifier.net/guide/GermanCoronaConsensusDataSet-ImplementationGuide/Consent) werden die Policies aus MII Board Consent und Z-Modul in einem FHIR Resource geschrieben.

Hallo @Hao Qian, es ist noch nicht abschließend geklärt, wie der Consent von der Infrastruktur überprüft wird. Also momentan geht es, Broad- und CODEX-Consent in zwei Consent Ressourcen zu erfassen.

Last updated: Apr 12 2022 at 19:14 UTC