Leitfaden Basis Onkologie DE (R4), Profil „UICC TNM Klassifikation“ #29
Comments
|
Kommentar einleuchtend, Änderung durch TC Terminologie empfohlen. |
|
Hallo, Folgende Punkte sind uns aufgefallen
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
Vorschlag zur Diskussion |
|
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: 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.
|
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.
The text was updated successfully, but these errors were encountered: