Stream: german/mi-initiative
Topic: Mappathon: §21-Module: Condition
Simone Heckmann (Nov 29 2018 at 11:15):
Hier mein first draft einer aus ICD.csv gemappten Condition (ist aber noch nicht vollständig...)
<Condition xmlns="http://hl7.org/fhir"> <clinicalStatus value="active" /> <verificationStatus value="unknown" /> <code> <coding> <system value="http://fhir.de/CodeSystem/dimdi/icd-10" /> <version value="2017" /> <code value="M16.7" /> </coding> </code> <bodySite> <coding> <system value="http://fhir.de/CodeSystem/kbv/s-icd-seitenlokalisation" /> <code value="L" /> </coding> </bodySite> </Condition>
context und subject muss ich füllen, indem ich anhand der Identifier die URL von Patient und Encounter ermittle.
Sekundärdiagnosen habe ich bislang noch ignoriert...
mein Mapping für clinicalStatus und verificationStatus ist folgendes:
Simone Heckmann (Nov 29 2018 at 11:15):
(deleted)
Simone Heckmann (Nov 29 2018 at 11:16):
A(Ausschluss)-> active/refuted
G(Gesichert)->active/confirmed
V(Verdacht)->active/provisional
Z(Zustand nach...)->inactive/confirmed
k.A.->active/unknown
Simone Heckmann (Nov 29 2018 at 11:30):
Der Sekundär-Code wäre hier in der Tat eine weitere Condition, oder? Das hat nix mit +/*-Notation zu tun...?
Andrea Essenwanger (Nov 29 2018 at 11:47):
@Josef Schepers korrigiere mich falls ich jetzt was falsches sage. Ich meine das soll eine weitere Condition sein.
Simone Heckmann (Nov 29 2018 at 11:49):
Ich hoffe es ganz fest, weil wenn das +/*-Diagnosen sind, dann wäre das in FHIR eine Condition mit einem postkoordinierten Code und ich hätte keine Ahnung, wie wir mit den potentiell abweichenden Lokalisationen und Diagnosesicherheiten umgehen sollten...
Andrea Essenwanger (Nov 29 2018 at 11:49):
bzw. @Moritz Lehne ?
Moritz Lehne (Nov 29 2018 at 12:46):
Hallo, hier meine erste Nachricht im Chat - und dann gleich eine schlechte: Soweit ich weiß, sind die Sekundär-Kodes genau für diese +/*-Diagnosen gedacht. Das ist allerdings relativ selten, deswegen ist der Sekundär-Kode meist leer. Dass sich die Lokalisation2 dann auch noch von der ersten Lokalisation unterscheidet, ist, denke ich, extrem unwahrscheinlich (die Lokalisationsfelder sind sowieso meist leer).
Simone Heckmann (Nov 29 2018 at 13:27):
Worst Case Szenario wäre dann ungefähr der Verdacht auf Nierenmetastase links bei gesichertem Mammakarzinom rechts
Simone Heckmann (Nov 29 2018 at 13:28):
@Stefan Lang : Ich weiß wir hatten die Diskussion gefühlt schon 100 mal ...aber ich hab gerade nur noch weißes Rauschen, was den Verbleib angeht...
...Hilfe...?
Stefan Lang (Nov 29 2018 at 13:35):
Und hier die gute Nachricht: Metastasen sind in ICD-10-GM keine Stern-Codes. Somit eigene Conditions.
Stefan Lang (Nov 29 2018 at 13:37):
Der komplette Abschnitt zu Tumoren (C00-D48) enthält keine Kreuz-/Stern-Systematik und nur einige Ausrufezeichencodes (C94.8, C95.8, C97)
Simone Heckmann (Nov 29 2018 at 13:37):
Wären !-Codes in §21 auch als Sekundär-Kodes enthalten...?
Stefan Lang (Nov 29 2018 at 13:43):
In der Datensatzbeschreibung sind sowohl Primär- als auch Sekundärcodes als "alphanumerisch, max. 9 Stellen" beschrieben.
Plus. "Diagnoseschlüssel sind in der gültigen ICD-10GM-Version analog zur § 301-Vereinbarung zu übermitteln: d.h. mit Sonderzeichen".
Also schon incl. Punkt, d.h. ein einzelner Code hat meist schon 5 Zeichen ("C50.3").
Somit bleibt für Ausrufezeichen-Codes nur der Sekundärcode.
Simone Heckmann (Nov 29 2018 at 13:44):
Das würde in der Konsequenz bedeuten: Wenn wir die Primär/Sekundärcodes in FHIR zu postkoordinierten Codes zusammenpappen wollten, wüssten wir im Zweifel nicht, ob mit +/* oder ! (..es sei denn wir hätten einen unheimlich schlauen Terminologieserver...)
Stefan Lang (Nov 29 2018 at 13:45):
Naja, "mit Sonderzeichen" würde für mich auch "mit '+' bzw. '*' implizieren
Stefan Lang (Nov 29 2018 at 13:45):
Aber das sollte jemand sagen, der sich damit auskennt ;)
Simone Heckmann (Nov 29 2018 at 13:46):
Ah so! Also könnten wir in der Tat einfach konkatenieren!?
Stefan Lang (Nov 29 2018 at 13:47):
Wenn ich das richtig interpretiere, ja (mit Leerzeichen getrennt).
Fehlt nur ein offizieller Beispieldatensatz mit Kreuz-Stern, um es zu verifizieren.
Andrea Essenwanger (Nov 29 2018 at 13:48):
@Julian Sass ???
Simone Heckmann (Nov 29 2018 at 13:51):
Also für meinen UseCase hätte ich kein Problem damit, eventuell abweichende Lokalisationen bzw. Diagnosesicherheiten bei Sekundärcodes einfach zu ignorieren. Weiß nicht, wie man das in der MI-Initiative sieht...?
Ich gehe mal davon aus, dass eine negierende Diagnosesicherheit hier nicht auftreten kann. (um beim vorherigen Beispiel zu bleiben:
Ausschluss einer Nierenmetastase links bei gesichertem Mammakarzinom rechts als +/* zu notieren wäre doch ein grobes Foul gegen die Kodierrichtlinien, ...oder????
Stefan Lang (Nov 29 2018 at 13:53):
Das ist ja auch keine Kreuz-Stern-Kombination ;)
Aber da +/* dafür da ist, mit zwei Codes einen Sachverhalt auszudrücken, dürfen ganz allgemein solche Fälle (gesichert+ ausgeschlossen*) nicht vorkommen.
Simone Heckmann (Nov 29 2018 at 13:57):
...dann könnte ich mit der Regelung "Sekundär-Kode - falls vorhanden - an Primär-Kode konkatenieren (leerzeichengetrennt), Lokalisation und Diagnosesicherheit zu Sekundär-Kode ignorieren" gut leben...
Würde vll. einen Bericht generieren, um festzustellen, wie oft abweichende Lokalisationen/Sicherheiten überhaupt vorkommen...
Moritz Lehne (Nov 29 2018 at 14:48):
Ich habe hier nochmal die Experten der Charité gefragt: Ein wirkliches Beispiel für abweichende Lokalisationen/Diagnosesicherheiten bei Primär- und Sekundärkodes scheint hier niemandem einzufallen. Ist wahrscheinlich nur eine theoretische Möglichkeit...
Julian Sass (Nov 29 2018 at 20:28):
Die Strings der Primär- und Sekundär-Kodes leerzeichengetrennt konkatenieren war das Vorgehen, wie wir es mit Vocab hier http://build.fhir.org/icd.html festgehalten haben. Dann bekommen wir bei mehreren Kodes ggf. Probleme, weil sich die Seitenlokalisation nicht eindeutig einer Diagnose zuordnen lässt, ebenso bei der Diagnosesicherheit. Oder übersehe ich hier etwas? Im stationären Bereich sind die Zusatzkennzeichen für Diagnosesicherheit verboten btw. (außer bei psychiatrischer Institutsambulanz). Sollten wir aber für ambulante Fälle auf jeden Fall berücksichtigen. Ich favorisiere momentan die Lösung eine Condition enthält eine Diagnose. Über die Referenz auf den Patient/Fall können die Conditions dann wieder in Relation gesetzt werden. Mir scheint die Lösung auch für Analytics praktikabler, als später die konkatenierten Strings erst wieder parsen zu müssen bevor ich auf einen bestimmten ICD-Kode abfragen kann. Oder was meint ihr?
Stefan Lang (Nov 29 2018 at 20:47):
Ich denke, dass nur Kreuz-Stern und Ausrufezeichen-Kombinationen in eine Condition gepackt werden sollten. Das schon aus dem Grund, dass
a) ein Stern- bzw. Ausufezeichencode nie allein stehen darf und
b) die Semantik sich durch die Kombination ändern kann
Wenn aber jemand im P21-Datensatz Brustkrebs als Primärdiagnose und die zugehörige Lebermetastase als Sekundärdiagnose setzt, sind das definitiv zwei getrennte Conditions. Kein Kreuz/Stern, kein Ausrufezeichen, zwei separate Aussagen.
Um in dem Beispiel zu bleiben: es kommt z.B. durchaus vor, dass eine Metastase entdeckt wird, aber kein Primärtumor zu finden ist. Die Metastase ist also auch fachlich eine eigenständige Aussage.
Bei einer Kreuz-Stern-Kombination ist das nicht der Fall, die gehören fachlich und logisch zusammen.
Julian Sass (Nov 30 2018 at 09:05):
Ich denke, dass nur Kreuz-Stern und Ausrufezeichen-Kombinationen in eine Condition gepackt werden sollten. Das schon aus dem Grund, dass
a) ein Stern- bzw. Ausufezeichencode nie allein stehen darf und
b) die Semantik sich durch die Kombination ändern kann
stimme zu. das ist ein Argument, es in einer Condition zu machen
Simone Heckmann (Dec 07 2018 at 13:29):
Im MI-Kerndatensatz gibt es eine Diagnose-kodiert mit einer Lokalisation und einer Diagnosesicherheit.
Aber separat auch einen "Auslöser", der sich wohl auf einen Teil eines postkoordinierten ICD-Codes bezieht: https://art-decor.org/art-decor/decor-datasets--mide-?id=2.16.840.1.113883.3.1937.777.24.1.1&effectiveDate=2018-06-05T12%3A44%3A12&conceptId=2.16.840.1.113883.3.1937.777.24.2.49&conceptEffectiveDate=2018-06-05T22%3A41%3A16&language=de-DE
Eine separate Lokalisation/Sicherheit für den Auslöser gibt es auch hier nicht, also sind wir da zumindest auf Linie.
Last updated: Apr 12 2022 at 19:14 UTC
