Stream: german (d-a-ch)

Topic: Breaking Change: Condition

Simone Heckmann (Apr 08 2021 at 08:39):

Achtung, wichtige Durchsage!

Wir sind in den letzten Wochen und Monaten immer wieder auf folgende Problematik gestoßen: Wie gehen wir mit postkoordinierten ICD-10-Diagnosen um, bei denen Primär- und Sekundärcode abweichende Diagnosesicherheiten bzw. Lokalisationen haben?

Diese Problematik spielt im stationären Kontext eine eher untergeordnete Rolle, kommt im niedergelassenen Umfeld jedoch regelmäßig vor. Kommunikationsformate wie §21-Datensätze sehen ebenfalls separate Felder für die Diagnosesicherheit von Primär- und Sekundärdiagnosen vor.
Unser Ziel ist es, in den Basisprofilen Empfehlungen zu geben, die sektorenübergreifend umsetzbar sind.

Wir - Das Technische Komitee für FHIR - haben in diverse Gespräche mit BfarM, KBV, MI-I und Gematik geführt und nun folgenden Vorschlag erarbeitet:
Abweichend zum bisherigen Vorgehen, in dem ein postkoordinierter ICD-10-Code in einer Condition-Ressource abgebildet wurde, werden wir künftig empfehlen, die Codes in zwei oder mehrere Conditions aufzusplitten und miteinander zu verlinken.

Statt bisher (in Pseudocode)

Condition:
    clinicalStatus = active | recurrence | relapse | inactive | remission | resolved
    verificationStatus = unconfirmed | provisional | differential | confirmed | refuted | entered-in-error
    code = J12.8 U07.1!
    bodySite = R| L| B

würden wir künftig die folgende Notation empfehlen:

Condition (primär):
    clinicalStatus = active | recurrence | relapse | inactive | remission | resolved
    verificationStatus = unconfirmed | provisional | differential | confirmed | refuted | entered-in-error
    code = J12.8
        extension:zusatz-kennzeichen = ! | * | + | none
    bodySite = R| L| B

Condition (sekundär):
    clinicalStatus = active | recurrence | relapse | inactive | remission | resolved
    verificationStatus = unconfirmed | provisional | differential | confirmed | refuted | entered-in-error
    code = U07.1
        extension:zusatz-kennzeichen = ! | * | + | none
    bodySite = R| L| B
    extension:condition-related = Reference (primär)

Über die Core-Extension condition-related werden die (Sekundär-/Ausrufezeichen-) Diagnosen mit den (Primär-/Kreuz-)Diagnosen verlinkt.
Die neue Extension zusatz-kennzeichen gibt Auskunft über die Art des Codes und damit auch über die Semantik der Verlinkung (Ätiologie/Manifestation/"in Verbindung mit"....)

Die bisherigen Extensions in den Basisprofilen zur Aufsplittung von postkoordinierten Codes

• icd-10-gm-primaercode
• icd-10gm-ausrufezeichen
• icd-10-gm-manifestationscode
  würden damit entfallen.

Programmtisch wäre das Vorgehen zur Abbildung eines beliebigen, postkoordinierten ICD-10-Codes folgendes:

1. Zerlegung des postkoordinierten Codes in Einzelcodes in einem Array (String split)
2. Abbildung jedes Codes des Arrays in einer separaten Condition
3. a) ggf. Abtrennen des Zusatzkennzeichens (+/*/!) in die Zusatz-Kennzeichen-Extension
4. Verlinkung aller Conditions mit Array-Index > 0 mit der Condition mit Array-Index 0 über die Condition-Related-Extension

Bevor wir diese Änderung in die Deutschen Basisprofile übernehmen, bitten wir die Community um Meinungsäußerungen:

• Ist das Vorgehen aus eurer Sicht sinnvoll?
• Ist das implementierbar?
• welche Vor-/Nachteile seht ihr?
• gibt es Konstellationen komplexer postkoordinierter Codes, in denen das Vorgehen nicht funktionieren würde?
• habt ihr Fragen?

Bitte gebt uns hier neben euren Kommentaren gerne auch nur ein einfaches "Daumen hoch/runter", damit wir ein Stimmungsbild erhalten...

@Maximilian Reith @Noemi Deppenwiese @Udo Siefker @Bettina Lieske @Patrick Wladowska @Willi Roos
@André Sander

Simone Heckmann (Apr 08 2021 at 09:05):

@Abel Stolz

Abel Stolz (Apr 12 2021 at 07:10):

Nach meinen bisherigen Erfahrungen ist das sicher implementierbar (in dem Kontext, dass aus anders vorliegenden Daten FHIR-Ressourcen erzeugt werden.)

Axel Biernat (Apr 16 2021 at 13:32):

Ein sehr guter Vorschlag. Inbesondere hervorzuheben, dass dies Ansatz schneller zu verstehen ist, da dies ähnlich der Erfassung von verbundenen Diagnosen funktioniert.

Alexander Kiel (Apr 21 2021 at 12:15):

Auf der einen Seite finde ich den Vorschlag sehr gut, weil ich bei einer Suche Patienten sowohl über den primären, als auch über die sekundären Codes finden kann, ohne dass ich custom Suchparameter brauche oder in CQL aufwendig in Extensions hineinschauen muss.

Auf der anderen Seite splitten wir hier eine logische Diagnose in mehrere. Gerade, wenn andere Ressourcen auf eine Condition Ressource verweisen wollen, ist die Frage auf welche, bzw. ob die primäre dann immer ausreichend ist.

Wichtig wären auch sicher noch Referenzen von der primären Diagnose auf die Sekundären. Immerhin nehmen wir ja aus der primären Informationen heraus, die dann ohne Referenz nicht mehr direkt zugreifbar sind.

Noch ein Punkt: Gibt es das Problem mit den postkoordinierten Codes auch in anderen Codesystemen und wenn ja, wie wird damit umgegangen?

Simone Heckmann (Apr 21 2021 at 12:29):

Alexander Kiel said:

Noch ein Punkt: Gibt es das Problem mit den postkoordinierten Codes auch in anderen Codesystemen und wenn ja, wie wird damit umgegangen?

Bei der Nutzung von ICD-10 in DE haben wir den Sonderfall, dass der postkoordinierte Code nicht als ein Konzept behandelt wird, das durch eine Kombination von Codes beschrieben wird - wie es bei Postkoordination üblich wäre - , sondern als nach wie vor unabhängige Konzepte, denen unabhängig voneinander Attribute zugeordnet werden können.

Ich glaube/hoffe, dass das nirgends sonst der Fall ist...

Christof Gessner (Apr 21 2021 at 18:03):

Sollten wir hier mal abgleichen mit der Umsetzungsstrategie bei der TNM-Klassifikation? @Frank Oemig

Frank Oemig (Apr 23 2021 at 11:33):

Dass wir vor Jahren eine abstrakten Diagnoseleitfaden geschrieben haben hatte schon einen Grund - und den kann man heute mit FHIR auch nicht invalidieren.

Axel Biernat (Apr 23 2021 at 13:10):

@Frank Oemig magst Du einen Link teilen?

Mareike Przysucha (Apr 23 2021 at 14:34):

@Frank Oemig Meinst Du diesen https://wiki.hl7.de/index.php?title=IG:Diagnoseleitfaden ?

Frank Oemig (Apr 23 2021 at 15:04):

Das ist die Wikiseite. Ich meinte http://download.hl7.de/documents/diagnosen/Diagnoseleitfaden-v1.1_20110622.pdf, aber anscheinend ist das dasselbe. Ich hatte das aber auch noch anders in Erinnerung - man wird alt...

Alexander Zautke (Apr 23 2021 at 15:10):

Die Einführung zur Diagnosesicherheit und Seitenlokalisation liest sich für mich jedoch, als würde davon ausgegangen werden, dass pro Code jeweils nur eine Diagnosesicherheit und Seitenlokalisation existiert. Wie oben beschrieben müsste man auch hier schauen wie man das pro Bestandteil eines postkoordinierten Codes hinbekommt.

Frank Oemig (Apr 23 2021 at 15:14):

Wenn wir "ich habe ein Problem mit meinem rechten Zeh, weil meine linke Niere kaputt ist" kodieren müssen, dann müssen wir das nochmal überdenken. Das bestätigt mich aber wieder, dass man erst die logischen Zusammenhänge dokumentiert, bevor man sich an irgendeine technische Abbildung macht.

Mareike Przysucha (Apr 23 2021 at 15:20):

Und was ist mit "Verdacht auf Retinopathie bei gesichertem Diabetes"?
Bzw. fällt jemandem aus der Gruppe ein anderes Beispiel ein, wir hatten da ja welche...

Simone Heckmann (May 04 2021 at 17:52):

"Verdacht auf Covid-19 bei gesicherter Pneumonie"

Simone Heckmann (May 04 2021 at 17:54):

Frank Oemig said:

Wenn wir "ich habe ein Problem mit meinem rechten Zeh, weil meine linke Niere kaputt ist" kodieren müssen, dann müssen wir das nochmal überdenken.

Genau dies ist unseren Recherchen zufolge der Fall.
Darum haben wir das überdacht und sind zu dem oben beschriebenen Breaking Change-Vorschlag gekommen.

Josef Schepers (May 13 2021 at 20:18):

Mir scheint der Vorschlag gut durchdacht.
Könnte die Abfragekonstrukte, die mit FHIR-Search gebaut worden sind, vereinfachen.
@ Alexander Kiel, Du hast mit den Leipziger und Jenenser Teams gesprochen?
Ich leite die Frage noch einmal nach Mannheim und München weiter.

Simone Heckmann (May 17 2021 at 08:06):

Kleines Addendum: Wir würden in den Basisprofilen dann auch einen zusätzlichen Suchprarameter auf "zusatzkennzeichen" und "condition-related" definieren, um entsprechende Abfragen (incl. chaining/reverse chaining) zu ermöglichen.

Wäre eine bidirektionale Verlinkung tatsächlich notwendig, wenn man die Primärdiagnose stets am Zusatzkennzeichen erkennen und die assoziierte Sekundärdiagnose über reverse chaining ermitteln könnte?

Mir widerstrebt die zirkuläre Verlinkung ein wenig...

Simone Heckmann (May 17 2021 at 08:14):

...oder anders gefragt (in Richtung der Terminologen): Besteht die Gefahr einer Fehlinterpretation, wenn man einen Primärcode ohne den zugehörigen Sekundärcode betrachtet? Nach meinem Dafürhalten, fügt ein Sekundärcode immer nur zusätzliche Informationen (über Ätiologie etc) hinzu. Der Primärcode bleibt als klinische Aussage aber stets bestehen und wäre - für sich allein betrachtet - stets gültig.
Oder kann ein Sekundärcode modifizierende/negierende Wirkung auf einen Primärcode haben?

Alexander Zautke (May 17 2021 at 08:39):

@Julian Sass Weißt du ob die Edge Cases die hier unter Doppelkodierung (nicht Kreuz-Stern-Klassifikation) darunter fallen würden?

Alexander Zautke (May 17 2021 at 08:39):

Hat jemand so was schonmal live in der Praxis gesehen? :sweat_smile:

Simone Heckmann (May 20 2021 at 10:25):

Ich bin gerade an der Erstellung des ValueSets für die Diagnosekennzeichen (*/+/!). Dabei sind folgende Fragen aufgetreten:

1. Wie benennen wir das? Die Bezeichnung "Zusatzkennzeichen" wird offenbar schon für Lateralität und Diagnosesicherheit verwendet.
2. Wie ist die korrekte Notation für das Kreuz? "+" oder " †"...?

Weiß das jemand auf die Schnelle?

Edit: laut der ClaML-Datei ist es offenbar " †".

Simone Heckmann (May 20 2021 at 10:27):

Vorschlag: "Mehrfachkodierungs-Kennzeichen" ?

Simone Heckmann (May 20 2021 at 10:34):

erster (Ent-)Wurf für das CodeSystem: https://simplifier.net/snippet/simone_heckmann/7
Bitte um kritische Würdigung...

Last updated: Apr 12 2022 at 19:14 UTC