Leitfaden Basis Onkologie DE (R4), Profil „UICC TNM Klassifikation“

Observation.code.coding:snomed

{ "system": "http://snomed.info/sct", "code": "258235000" }

trifft nicht zu.

Stattdessen sollten die beiden SCT-Codes { "system": "http://snomed.info/sct", "code": "399537006" } und { "system": "http://snomed.info/sct", "code": „399588009" }

verwendet werden, da es ein klinisches und ein pathologisches Staging gibt (Im UICC / TNM Atlas 8.Auflage, so nicht explizit ausgewiesen, jedoch sowohl in LOINC als auch in SNOMED-CT durch entsprechende Konzepte hinterlegt.

Kommentar einleuchtend, Änderung durch TC Terminologie empfohlen.

Hallo, für uns wäre es derzeit nicht möglich als Konsument der Resource zu fungieren (wir könnten Sie aber so bereitstellen). Da wir diese Resource nicht eindeutig unterschiedlichen Entitäten und Versionen in unserer Applikation zuordnen können.

Folgende Punkte sind uns aufgefallen

Die Modellierung erlaubt Inkonsistenzen innerhalb der Observation. Es ist möglich, dass sich p und c Prefix bei den Components von den vorgeschlagenen LOINC Codes unterscheiden.
Um welches TNM handelt es sich? Die Observation verliert zu viel inherent notwendige Information wenn nicht die Version und Entität des TNMs beschrieben werden.
Es erscheint uns inkonsistent das Stadium als Value zu definieren wenn der Rest der recht generischen Resource in components abgelegt sind.

Der Weg über die Condition an die Entität zu kommen halte ich für problematisch, da es mehr als eine Condition pro Patient geben kann und es auch Patienten gibt, die Stagings für unterschiedliche Entitäten bekommen (sogar innerhalb eines Encounters möglich...).

Use Cases die nicht direkt funktionieren

Register: Lunge in Version 7 ist nicht mit Lunge in Version 8 vergleichbar (siehe Grafik)
Tumorboard Lösungen: Ohne direkten Kontext über die Entität kann man bestimmte Vorauswahlen nicht treffen.
Systeme die Reasoning anbieten können das Stadium nicht anhand von TNM bestimmen und somit auch keine Leitfaden Empfehlung ableiten

Vorschlag zur Diskussion Leider gibt es keine fertigen LOINC Codes die wir direkt verwenden können. Ich würde daher bei "code" etwas generisches wie UICC staging vorschlagen. Und bei "value" ein neues Value-Set (oder neue LOINC Codes?) mit der jeweiligen Entität incl Version aufführen. Dann hätten wir auf Observation Resourcen Ebene die notwendigen Meta Informationen und alle Klinischen Informationen stecken in den Components. Die Staging Component sollte eine 1..1 Beziehung haben.

Da es sich um ein Basisprofil handelt, scheint mir der generische Ansatz, also auch der Verzicht auf die Profilierung organtumorspezischer Lösungen, gerechtfertigt.

Die gewünschte Berücksichtigung von Tumorentitäten sollte dennoch realisiert werden, indem das Profil "Tumor Histologie und Morphologie" (ein Misnomer, müsste heißen "Histologischer Tumortyp und Tumorlokalisation ICD-O-3") in den Implementation Guide aufgenommen wird.

Die Problematik der cp-Präfixe wurde im Issue #31 angesprochen.

Das Problem der TNM-Ausgabe, das berechtigt angesprochen wurde, ließe sich über ausgabenspezifische Value sets jeweils für die T-, N- und M-Kategorie lösen. Nach Vorgabe der Deutschen FHIR Basisprofile sollte jedoch beachtet werden: "... dass bei Bindung eines FHIR-Datenelements (coding) an ein solches ValueSet (für das Versionen vorliegen (GH)) die alleinige Angabe von system und code nicht ausreicht, um eine eindeutige Aussage zu ergeben. In solchen coding-Elementen muss ausdrücklich auch die Version angegeben werden."

LOINC-codes sind für tumorentitätenspezifsche T-, N- und M-Kategorie Values nicht geeignet, SNOMED-CT codes aber schon, siehe 385417002 |Breast TNM finding (finding)|

Vielen Dank für die ausführliche Antwort! Hier ein paar Gedanken dazu:

Ich verstehe, dass es hier eine generische Implementierung geben soll. Aber hier wird lediglich der Use Case Krebsregister abgedeckt. Ist dann die Idee, dass ein weiteres TNM modelliert werden soll wo diese Generalisierung nicht gemacht wird? Ich versuche mal ein Beispiel zu geben warum ich denke, dass wir schon jetzt eine Lösung brauchen: Wenn wir ein Tumorboard System entwickeln wollen welches lediglich TNM irgendwo zur Anzeige bringt ist der generische Ansatz in Ordnung. Wenn die Tumorboardlösung aber auch schon vorausgewählt die S3 Leitlinien und mögliche Therapiewege auflisten soll geht das mit der generischen Lösung einfach nicht. D.h. auf Herstellerseite müssen zwei unterschiedliche TNMs implementiert werden?

Ich denke man sollte es vermeiden und auch in der Spezifikation fordern, dass die unterschiedlichen TNM Kategorien in der selben Version vorliegen müssen. TNM ist, auch wenn es in unterschiedlichen Systemen und Abteilungen zusammengesammelt werden muss, eine Gesamtbetrachtung. Was sagen hier die Ärzte und Tumordokumentare dazu? Werden die einzelnen Kategorien in unterschiedlichen Versionen von TNM für einen Patienten reportet?

Generell finde ich den Ansatz wie M-Code TNM löst einfacher (Pro Kategorie eine Resource, Code ist gelöst wie hier, bei Value leider nur LOINC generisch hinterlegt...) in der Umsetzung ohne Information zu verlieren. Die hohe Kohäsion der Resource hier im Vorschlag ist verständlich im Kontext der Krebsregister aber in anderen Anwendungsfällen ist die Kohäsion nicht von Nöten (beispielsweise das Ergebnis aus der Pathologie wird immer nur pT oder pN oder pM sein, welches System sammelt diese Informationen dann zusammen auf welche Art und Weise muss hier in der Spezifikation beschrieben sein).

Das mit LOINC habe ich nicht ganz verstanden. Mir ist klar, dass SNOMED post koordiniert ist und ich somit Kombinationen besser abbilden kann. Aber die Anzahl der Entitäten ist bei TNM durch die jeweilige Ausgabe klar definiert. Die Verwendung auf Herstellerseite bei der Auflösung von SNOMED Codes kann gerade bei der Auflistung von mehreren Codes aufwendig werden. Generische Implementierungen dafür gestalten sich als schwer und erfordert hohes Expertenwissen.

Sehr spannende Diskussion :-)

Vielen Dank für die interessanten Gedanken und Fragen. Um es vorauszuschicken: Ich will mich nicht mit fremden Federn schmücken, ich bin kein Mitautor des Leitfadens sonder als Pathologe einer der potentiellen Nutzer eines generischen TNM Profils, welches eben auch, aber nicht nur für eine Krebsregistermeldung verwendet werden kann. Es ist aber eben nur ein Baustein für komplexere Lösungen!

völlig daneben wäre die Profilierung verschiedener TNM-Profile für verschiedene Use cases. Das soll ja gerade durch Basisprofile vermieden werden. Anwendersysteme müssen derartige Module intelligent miteinander verknüpfen, z.B. durch Verwendung des hier diskutierten Basisprofils mit weiteren Profilen wie spezifischen DiagnosticReports für Tumorboards. Hier könnte man sich auch an m-Code orientieren. Vielleicht schauen Sie sich einmal den Implementierungsleitfaden für den Kerndatensatz Pathologiebefund der MII an, der ab 20.7.22 zur Abstimmung veröffentlicht wird. Dort kann das Basismodul UICC TNM ganz einfach verwendet werden.
unterschiedliche Versionen der TNM-Kategorien machen überhaupt keinen Sinn, das ist wohl unstrittig. Problematischer auf Anwenderseite ist eher die übliche Situation bei Pathologen, nur eine cM-Information vom Kliniker zu haben. Welches UICC-Stadium liegt dann vor? Klinisch oder pathologisch? Eine Mischform ist in der vorgeschlagenen Kodierung nicht möglich und die gibt es wohl auch nicht.
bezüglich der Entitäten ist das Basisprofil allein nicht die Lösung, dazu braucht man zusätzliche Profile, die zwar vorhanden, aber leider nicht in den Leitfaden aufgenommen wurde, der hier zur Diskussion steht. Aber das könnte man leicht nachholen.
in Deutschland würde ich gegenwärtig, auch im Hinblick auf den allseits verwendeten ADT/Gekid -BDS nicht auf präkoordinierte SNOMED-CT Konzepte für organbezogene TNM-Kategorien setzen, da deren Pflege undurchsichtig ist. Abhilfe kommt möglicherweise durch die ICCR. Ihren Hinweus auf LOINC habe ich aber leider nicht kapiert.
es bleibt spannend:)

Von meinem iPhone gesendet

Am 18.07.2022 um 12:35 schrieb johannes-kast-mint @.***>:

Vielen Dank für die ausführliche Antwort! Hier ein paar Gedanken dazu:

Ich verstehe, dass es hier eine generische Implementierung geben soll. Aber hier wird lediglich der Use Case Krebsregister abgedeckt. Ist dann die Idee, dass ein weiteres TNM modelliert werden soll wo diese Generalisierung nicht gemacht wird? Ich versuche mal ein Beispiel zu geben warum ich denke, dass wir schon jetzt eine Lösung brauchen: Wenn wir ein Tumorboard System entwickeln wollen welches lediglich TNM irgendwo zur Anzeige bringt ist der generische Ansatz in Ordnung. Wenn die Tumorboardlösung aber auch schon vorausgewählt die S3 Leitlinien und mögliche Therapiewege auflisten soll geht das mit der generischen Lösung einfach nicht. D.h. auf Herstellerseite müssen zwei unterschiedliche TNMs implementiert werden?

Ich denke man sollte es vermeiden und auch in der Spezifikation fordern, dass die unterschiedlichen TNM Kategorien in der selben Version vorliegen müssen. TNM ist, auch wenn es in unterschiedlichen Systemen und Abteilungen zusammengesammelt werden muss, eine Gesamtbetrachtung. Was sagen hier die Ärzte und Tumordokumentare dazu? Werden die einzelnen Kategorien in unterschiedlichen Versionen von TNM für einen Patienten reportet?

Generell finde ich den Ansatz wie M-Code TNM löst einfacher (Pro Kategorie eine Resource, Code ist gelöst wie hier, bei Value leider nur LOINC generisch hinterlegt...) in der Umsetzung ohne Information zu verlieren. Die hohe Kohäsion der Resource hier im Vorschlag ist verständlich im Kontext der Krebsregister aber in anderen Anwendungsfällen ist die Kohäsion nicht von Nöten (beispielsweise das Ergebnis aus der Pathologie wird immer nur pT oder pN oder pM sein, welches System sammelt diese Informationen dann zusammen auf welche Art und Weise muss hier in der Spezifikation beschrieben sein).

Das mit LOINC habe ich nicht ganz verstanden. Mir ist klar, dass SNOMED post koordiniert ist und ich somit Kombinationen besser abbilden kann. Aber die Anzahl der Entitäten ist bei TNM durch die jeweilige Ausgabe klar definiert. Die Verwendung auf Herstellerseite bei der Auflösung von SNOMED Codes kann gerade bei der Auflistung von mehreren Codes aufwendig werden. Generische Implementierungen dafür gestalten sich als schwer und erfordert hohes Expertenwissen.

Sehr spannende Diskussion :-)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

hl7germany / basisprofil-onkologie-R4

Leitfaden Basis Onkologie DE (R4), Profil „UICC TNM Klassifikation“ #29