Stream: german (d-a-ch)
Topic: Invarianten für Diagnosesicherheit
Simone Heckmann (Aug 07 2019 at 12:49):
Hinweis zum ICD10-Condition-Profil unter R4:
Bei Verwendung der Extension Diagnosesicherheit werden jetzt folgende Regeln geprüft, um die Äquivalenz der Angaben in der Extension zu clinicalStatus und verificationStatus sicherzustellen:
-
icd-4:Wenn die Diagnosesicherheit "A (Ausschluss)" verwendet wird, dann muss clinicalStatus leer bleiben und verificationStaus auf "refuted" gesetzt werden.
code!='A' or (%resource.verificationStatus.coding.where(code='refuted').exists() and %resource.clinicalStatus.empty()) -
icd-5:Wenn die Diagnosesicherheit "G (Gesichert)" verwendet wird, dann muss clinicalStatus auf "active" und verificationStatus auf "confirmed" gesetzt werden.
code!='G' or (%resource.clinicalStatus.coding.where(code='active').exists and %resource.verificationStatus.coding.where(code='confirmed').exists()) -
icd-6:Wenn die Diagnosesicherheit "V (Verdacht auf)" verwendet wird, dann muss clinicalStatus auf "active" und verificationStatus auf "provisional" gesetzt werden.
code!='V' or (%resource.clinicalStatus.coding.where(code='active').exists() and %resource.verificationStatus.coding.where(code='provisional').exists()) -
icd-7:Wenn die Diagnosesicherheit "Z (Zustand nach)" verwendet wird, dann muss clinicalStatus auf "resolved" und verificationStatus auf "confirmed" gesetzt werden.
code!='Z' or (%resource.clinicalStatus.coding.where(code='resolved').exists() and %resource.verificationStatus.coding.where(code='confirmed').exists())
Derzeit werden nur Warnung ausgegeben. Wäre zu diskutieren, ob das eventuell sogar ein harter Fehler sein soll...
Simone Heckmann (Aug 07 2019 at 12:52):
Hier ist ein Beispiel für eine Diagnose, die bei der Validierung durchfällt, weil die Sicherheit nur in der Extension, aber nicht in verificationStatus angegeben wurde: https://simplifier.net/basisprofil-de-r4/condition-invalid-2
Hier ein Beispiel für eine "gute" Condition: https://simplifier.net/basisprofil-de-r4/condition-zustand-nach
Simone Heckmann (Aug 07 2019 at 12:55):
Die geltenden Äquivalenzen sind im IG nochmal aufgeführt: https://simplifier.net/guide/basisprofil-de-r4/Diagnosesicherheit
Mareike Przysucha (Dec 11 2019 at 08:55):
Dazu gab es folgenden Einwand bei STU3:
m.E. muss hier alternativ auch "V" (Verdacht auf / zum Ausschluss von) => clinicalStatus = "active", verificationStatus="differential" aufgeführt werden. Außerdem fehlt eine Regel, welche clinicalStatus und verificationStatus bei Verwendung erzwingt.
Meine Frage an die Community, bevor ich mich daran setze, das einzuarbeiten: Ist das Konsens? Oder gibt es da noch Diskussionsbedarf?
Mareike Przysucha (Dec 13 2019 at 09:41):
Scheinbar nicht, daher setze ich mich jetzt mal daran.
Simone Heckmann (Dec 13 2019 at 09:44):
Grundsätzlich d'accord, allerdings vermute ich, dass die meisten Szenarien auf FHIR und weniger von FHIR mappen werden. Daher sollten wir wenigsten eine Präferenz oder ein default Mapping für "V" vorgeben.
Da bin ich jetzt allerdings überfragt, welches da geeigneter wäre...
Simone Heckmann (Dec 13 2019 at 09:46):
Ich sehe momentan die einzige Möglichkeit darin, auch beide möglichen Varianten hinzuweisen und in Prosa die Problematik zu beschrieben, dass das "richtige" Mapping allein aus dem Code "V" nicht eindeutig hervorgeht...
Mareike Przysucha (Dec 13 2019 at 09:47):
So etwas ähnliches war ich auch gerade am schreiben: Im Profil beides erlauben, und im IG auf die Problematik hinweisen.
Noemi Deppenwiese (Jun 24 2020 at 12:55):
Ich wärme diesen Thread mal wieder auf: Wir laufen jetzt mit §21 daten genau in diese Problematik. Wir haben nur das V und wissen dementsprechend nicht, was der "richtige" Code ist (provisional | differential). Meine Idee war, das einfach auf "unconfirmed" zu mappen... Aber das lassen die Invarianten ja nicht zu. Gab es hierzu schon weitere Diskussionen?
Und: §21 sieht bei postkoordinierten Codes vor, die Diagnosesicherheit für beide Teile einzeln anzugeben :see_no_evil: Mit dem aktuellen Basis-DE-Extensions kann man ja nur eine Diagnosesicherheit für den kompletten Code setzen. Unser aktuellen Workaround ist, bei verschiedenen Sicherheiten einfach keine zu setzen, was gerade bei "Auschlussdiagnosen" zu Problemen führen könnte.... Kam das beim Profilieren auf bzw. hat hier jemand eine bessere Lösung parat?
Simone Heckmann (Jun 24 2020 at 16:05):
Ich wäre grundsätzlich nicht abgeneigt, die Invariante dahingehend zu erweitern, dass sie das Mapping der Diagnosesicherheit V auf unconfirmed zulässt.
Die Angabe separater Diagnosesicherheiten für die einzelnen Anteile eines postkoordinierten Codes steht meiner Auffassung nach im Widerspruch zu den Definitionen des DIMDIs, dass es sich bei postkoordinierten Diagnosen um eine Diagnose mit Angabe der Ätiologie handelt und nicht um zwei eigenständige Diagnosen.
Wenn ich "Glaukom bedingt durch Diabetes Melitus" postkoordiniert codiere, dann mache ich sowohl in Lateralität als auch in Diagnosesicherheit nur Aussagen zum Primärcode Glaukom.
Wenn ich Details zum Diabetes angeben möchte, dann mache ich das in einem separaten Code, in dem nur der Diabetes steht.
Oder anders gesagt: Ich würde bei einem Patienten mit diabetischem Glaukom immer auch die Existenz eines "reinen" Diabetes-Codes erwarten. Dessen Kodierung erfolgt nicht "implizit" durch das postkoordinierte Glaukom.
Aber: Das ist laienhafte Spekulation meinerseits.
Erbitte Unterstützung, @Heike Dewenter @Christine Haas @Sylvia Thun @Elisabeth Pantazoglou
Elisabeth Pantazoglou (Jun 25 2020 at 06:34):
@Simone Heckmann
Könnt ihr bitte die Problematik genauer erläutern. Wahrscheinlich bin ich im falschen Film, soweit ich weiß, dürfen Zusatzkennzeichen im stat. Bereich nicht verwendet werden. Die Extension Diagnosessicherheit bezieht sich demnach auf amb. Versorgung.
"In der ambulanten Versorgung (§ 295 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit obligatorisch. In der stationären Versorgung (§ 301 SGB V) sind die Zusatzkennzeichen für die Diagnosensicherheit verboten, d.h. sie dürfen nicht verwendet werden. In der stationären Versorgung sind stattdessen die hierfür vorgesehenen Schlüsselnummern im Kap. XXI zu verwenden. Außerdem sei auf die Kodierrichtlinien DKR und DKR-Psych verwiesen."
M.M.n. wäre dein Bsp. auch genau andersrum anzuwenden. Das Glaukom wird Stern- und der D.M. Kreuz kodiert. "Zuerst wird die Ätiologie (d. h. der Primärkode mit Kreuz †), dann die Manifestation (= Sekundärkode mit Stern *) kodiert."
Sven Helfer (Jun 25 2020 at 07:11):
In unseren Daten finden sich auch im stationären Bereich Diagnosesicherheiten. Intern kann ja jeder verschlüsseln, wie man will.§21 gibt ja auch die Spalten für Diagnosesicherheit vor. Wenn ich das richtig verstehe, geht es ja nicht nur um das Mapping von Abrechnungsdaten...
Noemi Deppenwiese (Jun 25 2020 at 11:41):
Anmerkung-2020-06-25-133456.png
Der §21 hat aber tatsächlich zwei Spalten mit Primär- und Sekundärcode und nachfolgend jeweils eine extra Spalte "Diagnosesicherheit". Konnte ich erst auch nicht richtig glauben... Die sind aber wohl nur bei Fällen aus der psychatrischen Ambulanz §118 SGB V erlaubt... OK, d.h. bei den allermeisten Fällen hat man gar keine Diagnosensicherheit im §21, und sonst zwei? :confused:
Weiß jemand, was es mit den "hierfür vorgesehenen Schlüsselnummern im Kap. XXI " auf sich hat? Gibt es die im §21 überhaupt?
Simone Heckmann (Jun 25 2020 at 12:38):
Ungeachtet dessen ist aber auch die doppelte Angabe der Lokalisation an dieser Stelle m. M. n. Murks...?
Sven Helfer (Jun 26 2020 at 05:54):
Lokalisation der PD und SD, kann schon mal unterschiedlich sein bzw. ist ein Diabetes ja keiner Seite zuzuordnen.
Sven Helfer (Jun 26 2020 at 05:56):
Noemi Deppenwiese said:
Weiß jemand, was es mit den "hierfür vorgesehenen Schlüsselnummern im Kap. XXI " auf sich hat? Gibt es die im §21 überhaupt?
In welchem Zusammenhang ist das? Es geht ja um:
Kapitel XXI
Faktoren, die den Gesundheitszustand beeinflussen und zur Inanspruchnahme des Gesundheitswesens führen
(Z00-Z99)
Sven Helfer (Jun 26 2020 at 05:58):
Sven Helfer said:
Noemi Deppenwiese said:
Weiß jemand, was es mit den "hierfür vorgesehenen Schlüsselnummern im Kap. XXI " auf sich hat? Gibt es die im §21 überhaupt?
In welchem Zusammenhang ist das? Es geht ja um:
Kapitel XXI Faktoren, die den Gesundheitszustand beeinflussen und zur Inanspruchnahme des Gesundheitswesens führen (Z00-Z99)
Habs gefunden: Kap. XXI enthält Vorsorge und "Abklärungs-Diagnosen" (Untersuchung von Organsystem ..., Beurteilung des Entwicklungsstandes...) Das was man eben macht, wenn man einen Verdacht hat bzw. etwas ausschließt ;)
Noemi Deppenwiese (Jun 26 2020 at 09:20):
Danke! Auf dieses Kapitel XXI bin ich gar nicht gekommen. OK; dh idR ist die Sicherheit schön durch die Codierung an sich ausgedrückt.
Noemi Deppenwiese (Aug 13 2020 at 14:22):
Ich muss hier noch einmal nachhaken. Zwar ist das im stationären Kontext kein Problem, da es dort wie beschrieben keine Diagnosesicherheiten in der ICD-Codierung gibt. Im ambulanten Sektor aber schon, und zwar tatsächlich für die einzelnen Code-Teile (zB Kreuz- und Sterncode, Im §21 Primär und Sekundärcode genannt.). Leider finde ich dazu kein Beispiel beim DIMDI, in der §21 Spezifikation ist das aber nachzulesen (und an echten §21 daten auch so zu beobachten...) Diese tauchen im §21 für die PIA-Fälle (ambulant, aber aus Gründen Teil des §21) auf. Hier gibt es also tatsächlich zwei Diagnosesicherheiten.
-
Könnte man die Diagnosesicherheit-Extension so abändern, dass sie an den Extensions mit den Code-Teilen (Kreuz, Stern bzw Ausrufezeichencode) sitzt? Vermutlich müsste man dazu eine komplexe Extension als "zusammenhalter" bauen, aber sonst könnte man die einzelnen Teile nicht verlustfrei aufsplitten.
-
Es wäre super, wenn es eine Guideline beim Coding-Profil gäbe, die empfiehlt, ob man die Sicherheit mit in das "code" Feld schreiben soll oder eben nicht. Ich tendiere zu nicht, da hier https://www.dimdi.de/dynamic/de/klassifikationen/icd/icd-10-gm/kodierfragen/ folgendes steht
Generell gilt aus klassifikatorischer Sicht, dass Zusatzkennzeichen nicht Bestandteil eines ICD- oder OPS-Kodes sind und somit auch nicht als eine zusätzliche Stelle eines Kodes bezeichnet werden können. D.h., ein vierstelliger Kode wird durch die Angabe eines Zusatzkennzeichens nicht zu einem fünfstelligen Kode.
Gerade dann wäre es aber wichtig, diese Info mit einer Extension an die Codeteile hängen zu können.
- Man müsste zusätzlich noch Regeln festlegen, wie man die möglichen Diagnosesicherheit-Kombinationen auf die Condition.verificationStatus abbildet. zB Sobald ein "A" dabei ist immer refuted. Da dies eigene Probleme mit sich bringt, könnte man auch über eine "Aufteilung" auf zwei Conditions nachdenken. zB aus B56.0† G G02.8* V eine "confirmed" B56.0 und eine "unconfirmed" B56.0† G02.8*. Das klappt natürlich nicht bei allen Kombis, weil es ja auch Kreuzcodes gibt, die nicht alleine stehen dürfen. Von * und ! Codes, für die das ja immer gilt, mal ganz abgesehen...
Man könnte den verificationStatus bei solchen Geschichten auch verbieten, aber das bringt auch Probleme. Eine einfache Lösung sehe ich leider nicht.
Noemi Deppenwiese (Aug 20 2020 at 09:24):
Ich adde mal @Azadeh Nassirian und @Sven Helfer , die sich schon über alternative Modellierungen Gedanken gemacht haben.
Azadeh Nassirian (Aug 20 2020 at 09:25):
Danke Noemi
Sven Helfer (Aug 20 2020 at 12:38):
Hab erst zu einfach gedacht, aber jetzt sehe ich das genauso wie @Noemi Deppenwiese ...
Sven Helfer (Aug 20 2020 at 12:40):
(deleted)
Frank Oemig (Aug 20 2020 at 17:04):
Hattet ihr dazu mal den Diagnoseleitfaden gesichtet, der zwar auf v2/V3 ausgerichtet ist, aber genau darüber nachgedacht hat?
Noemi Deppenwiese (Aug 21 2020 at 11:56):
Den kenne ich leider nicht. Ist das ein HL7 oder DIMDI Dokument?
Noemi Deppenwiese (Aug 21 2020 at 12:09):
Ich habe das hier https://wiki.hl7.de/index.php?title=cdaab2:ICD-Diagnose_Entry_(Template)#Diagnosesicherheit_2 gefunden.
In v3 werden die einzelnen Codeteile also tatsächlich getrennt und als unterschiedliche Observations betrachtet, die eine mit einem Attribut versehene Relation haben. In FHIR würde ich mich allerdings dagegen aussprechen, zwei Condition-Ressourcen zu verwenden, da die ganzen anderen Daten (onset, asserter...) der Condition ja für beide Codeteile gleich sein werden.
Noemi Deppenwiese (Aug 21 2020 at 12:21):
Aber vielleicht kann man die Struktur für die Extensions übernehmen? Quasi die v3 referenzierten Observations zu je einer komplexen extension machen.
Das, was in v3 über den "typeCode" ausgedrückt wird, könnte man A) entweder als Attribut einer neuen "CodePart"-Extension verwenden oder B) über die Extension an sich (so wie aktuell, wo es ja eine Kreuzcode, Sterncode und Ausrufezeichencode Extension gibt) ausdrücken.
In jedem Fall hätte man komplexe Extensions, die "unter-Extensions" mit dem eigentlichen Codeteil und der Sicheheit enthalten würden.
Und: In jeden Fall hätte man das Problem, wie man mit dem verficationStatus umgeht.
Stefan Lang (Aug 21 2020 at 13:52):
Ich denke, Frank meint diesen hier:
https://wiki.hl7.de/index.php?title=IG:Diagnoseleitfaden
aus dem der oben verlinkte Diagnose-Entry dann später ausgelagert wurde.
Leider ist das sehr CDA-zentrisch, d.h. es gibt genau genommen kein technologieneutrales detailliertes Modell (zumindest nicht dazu, wie nun z.B. Diagnosesicherheit in Beziehung zur Hauptdiagnose steht).
CDA verwendet dafür Qualifier, die es in FHIR nicht gibt. Die Idee war, dies mit Extensions nachzubilden, um den spezifischen Wünschen nach 1:1-Abbildung der Einzelcodes nachzukommen.
Gleichzeitig aber auch,um konform zu FHIR zu sein, clinicalStatus und verificationStatus entsprechend zu setzen. Und das ist der Ist-Stand.
Frank Oemig (Aug 21 2020 at 13:56):
Ich habe da noch ein anderes Dokument im Sinn, was wir vor Jahren mal zu der Problematik geschrieben und als PDF veröffentlicht haben. Ich muss da nochmal auf die Suche gehen...
Stefan Lang (Aug 21 2020 at 15:17):
Wurde das nicht damals auf Wiki restrukturiert?
Frank Oemig (Aug 22 2020 at 10:47):
Wir hatten da was mit den Templates genacht?! Aber das PDF...?
Alexander Zautke (Aug 26 2020 at 08:33):
@Noemi Deppenwiese @Sven Helfer @Azadeh Nassirian Habt ihr euch Gedanken gemacht bezüglich des Clinical Status im stationären Kontext? Kann man davon ausgehen, dass für der clinicalStatus für die Aufnahmediagnose "active" ist mit verfificationStatus confirmed oder unconfirmed? Für die Diagnose welche mit dem MII Abrechnungsfall verbunden ist würde dann clinicalStatus = active, verificationStatus = confirmed gelten, oder?
Alexander Zautke (Aug 26 2020 at 08:34):
CC: @Danny Ammon @Josef Schepers @Andrea Essenwanger
Azadeh Nassirian (Aug 28 2020 at 07:46):
@Alexander Zautke Vielen Dank für guten Hinweiß. Weil unsere Sourcedatei sind noch P21 Daten. (Die Daten, die wir in FHIR haben, kommen aus ETL Strecke "p21 to FHIR "), haben wir noch nicht daran gedacht. Clinicalstatus sowie Verificationstatus sind Optional, das heißt Condition Resosurcen dürfen keine haben. Ich werde aber in unserem Team darüber diskutieren.
Azadeh Nassirian (Aug 28 2020 at 07:52):
(deleted)
Noemi Deppenwiese (Sep 07 2020 at 08:16):
Alexander Zautke said:
Noemi Deppenwiese Sven Helfer Azadeh Nassirian Habt ihr euch Gedanken gemacht bezüglich des Clinical Status im stationären Kontext? Kann man davon ausgehen, dass für der clinicalStatus für die Aufnahmediagnose "active" ist mit verfificationStatus confirmed oder unconfirmed? Für die Diagnose welche mit dem MII Abrechnungsfall verbunden ist würde dann clinicalStatus = active, verificationStatus = confirmed gelten, oder?
Dem verificationStatus würde ich spontan zustimmen :+1:
Ob es im MII-Kontext sinnvoll ist, den ClinicalStatus zu pflegen? Idealerweise ist die Aufnahmediagnode bei Entlassung ja "resolved".
Sven Helfer (Sep 07 2020 at 10:12):
Noemi Deppenwiese said:
Dem verificationStatus würde ich spontan zustimmen :+1:
Ob es im MII-Kontext sinnvoll ist, den ClinicalStatus zu pflegen? Idealerweise ist die Aufnahmediagnode bei Entlassung ja "resolved".
So ist das leider nicht, ich würde sogar sagen, dass die meisten Diagnosen bei Entlassung noch nicht "resolved" sind, maximal "gebessert"...
Was genau meinst du mit "pflegen"? Ich denke, wir haben (Stand aktuell) keine belastbaren Daten dazu in den Quellsystemen (mal von NLP-Zeug und regelbasierten Einzelfalllösungen abgesehen). Eine wichtige Information ist es trotzdem und könnte z.B. durch hinzunahme eines EDC-Systems irgendwann integriert werden ;)
Noemi Deppenwiese (Sep 07 2020 at 10:21):
Mit "pflegen" meinte ich den zu setzen und idealerweise upzudaten. Man könnte natürlich "active" setzen, weil zum Zeitpunkt der Aufnahme war der bestimmt "active", aber ob wir da ohne ein Updat bei Änderung des Zustandes, das aus den von Dir genannten Gründen ja wahrscheinlich nicht erfolgt, da einen Nutzen haben? Evtl. führt das eher zu Verwirrung, wenn da ein Haufen "active" Conditions rumfliegen, die aber schon veraltet sind.
Sven Helfer (Sep 07 2020 at 10:43):
Dann würde ich sagen Stand aktuell: Nicht pflegen. Über die Pflege des ClinicalStatus kann man wahrscheinlich sowieso ganze Abhandlungen schreiben - oder sie sind schon geschrieben und ich habe sie noch nicht gelesen... :D
Sven Helfer (Sep 07 2020 at 10:46):
Und über den verificationStatus der Aufnahmediagnose, muss man wahrscheinlich auch nachdenken. Das ist ja nur die (Verdachts-)Diagnose, die zur Aufnahme geführt hat...
Noemi Deppenwiese (Sep 07 2020 at 10:50):
Aber im stationären Kontext ist es ja immer sicher? da kann man ja keinen Verdacht codieren?
Sven Helfer (Sep 07 2020 at 10:52):
Da kodiert man im Zweifel falsch ;)
Noemi Deppenwiese (Sep 07 2020 at 15:56):
Im MII-IG zu Fall steht
Encounter.diagnosis Die (bestätigte!) Aufnahemdiagnose. Keine Abbildung von reinen Symptomen.
Da kann man also nicht mehr von einem verdacht ausgehen.
Aller anderen Fälle .... :upside_down:
Noemi Deppenwiese (Sep 16 2020 at 09:49):
Noemi Deppenwiese said:
Aber vielleicht kann man die Struktur für die Extensions übernehmen? Quasi die v3 referenzierten Observations zu je einer komplexen extension machen.
Das, was in v3 über den "typeCode" ausgedrückt wird, könnte man A) entweder als Attribut einer neuen "CodePart"-Extension verwenden oder B) über die Extension an sich (so wie aktuell, wo es ja eine Kreuzcode, Sterncode und Ausrufezeichencode Extension gibt) ausdrücken.
In jedem Fall hätte man komplexe Extensions, die "unter-Extensions" mit dem eigentlichen Codeteil und der Sicherheit enthalten würden.
Und: In jeden Fall hätte man das Problem, wie man mit dem verficationStatus umgeht.
Gibt es dazu eigentlich Neuigkeiten? Das Problem "Mit dem aktuellen Stand kann man Diagnosesichrheiten nach ICD-10-GM nicht richtig abbilden" besteht ja noch.
Last updated: Apr 12 2022 at 19:14 UTC
