FHIR Chat · ICD-Diagnosen · german (d-a-ch)

Stream: german (d-a-ch)

Topic: ICD-Diagnosen

Simone Heckmann (Mar 17 2017 at 06:47):

.

Simone Heckmann (Mar 17 2017 at 06:47):

Diagnosenleitfaden.xml

Simone Heckmann (Mar 17 2017 at 06:49):

TODO:

• !-Diagnosen ("Diagnosen, die nicht alleine stehen können")

Simone Heckmann (Mar 17 2017 at 06:52):

Was mir noch eingefallen ist: Wir können ja nicht nur die Resource "Condition" erweitern, sondern auch den Datentyp "Coding". Wenn wir also die postkoordinierte Form des Codes zusätzlich übermitteln wollen, könnten wir das in einer Extension des Codings tun! (Hätte den Vorteil, das man das an jeder Stelle wiederverwenden kann, wo ICD-10 vorkommt, nicht nur in Condition...

Simone Heckmann (Mar 17 2017 at 06:53):

z.B.:

<!-- Verdachtsdiagnose C50.7 L-->
<Condition xmlns="http://hl7.org/fhir">
    <verificationStatus value="refuted"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="C50.7"/>
            <extension url="http://hl7.org/fhir/StructureDefinition/code-postcoordinated">
                <valueString value = "C50.7 L A"/>
            </extension>
        </coding>
    </code>
    <bodySite>
        <coding>
            <system value ="http://fhir.de/CodeSystem/kbv/lateralitaet"/>
            <code value="L"/>
        </coding>
    </bodySite>
</Condition>

Simone Heckmann (Mar 17 2017 at 07:01):

So könnten Systeme, die mit der Semantik von ICD-10 überfordert sind, wenigstens die postkoordinierte Form austauschen, was ja in manchen UseCases durchaus ausreichend wäre.
Dass sich verificationSatus und Code nicht widersprechen, könnten wir mittels Invarianten prüfen, z.B. "Wenn code-postcoordinated " A" enthält, dann muss der verificationStatus = A sein"

Simone Heckmann (Mar 17 2017 at 07:12):

Ich habe eben hier nochmal nachgelesen: https://www.dimdi.de/static/en/klassi/icd-10-who/systematik/kategorie.htm:

Dagger codes: Primary codes
Dagger codes classify the aetiology. They are primary codes; this means that they can be but do not have to be combined with an asterisk code. Frequently, the dagger code is supplemented with the optional asterisk code. Apart from codes marked as dagger codes, each random primary code can be used as an aetiology code and combined with an asterisk code. In this case, the aetiology code is marked with a dagger by the encoder.
Asterisk codes: Additional codes
Asterisk codes designate the manifestation of a disease. As additional codes, they must never be used on their own but only as part of a dual encoding in the "dagger and asterisk" system, i.e. always in conjunction with a dagger code or another primary code. Very often, the corresponding dagger code is given for an asterisk code.

Demnach gibt es doch tatsächlich nur eine einzige Relation zwischen Kreuz und Stern. Die Unterscheidung ist doch nur die Blickrichtung!
+ --> * = Manifestation

• --> + = Ätiologie

Wir bräuchten also nur dann zwei verschiedene Relations-Typen wenn wir in beide Richtungen verlinken wollten (UseCase!?!)
Wenn wir festlegen, dass wir die Relation immer als Link von Stern auf Kreuz abbilden, dann ist das mMn IMMER ein dueTo.

Stefan Lang (Mar 17 2017 at 08:09):

Für's Protokoll: dueTo ist die einzige Extension, die wir für +/* brauchen

Stefan Lang (Mar 17 2017 at 08:12):

Die post-coordinated Extension ist quasi ein Schweizer Taschenmesser. Das würde ich gern als STandard-Extension sehen

Stefan Lang (Mar 17 2017 at 08:27):

Ausrufezeichen, Beispiel aus ICD-10-GM 2016:

"Die Schlüsselnummer S41.87! "Weichteilschaden I. Grades bei offener Fraktur oder Luxation des
Oberarmes" ist mit einem Ausrufezeichen gekennzeichnet. Sie dürfen diese Schlüsselnummer nicht
allein benutzen; Sie können sie jedoch zusätzlich zu einem Primärkode (Kode ohne Ausrufezeichen
oder Stern) verwenden, um eine Diagnose zu spezifizieren. Sie können z.B. bei
"Humerusschaftfraktur" durch die zusätzliche Angabe "Weichteilschaden I. Grades bei offener Fraktur
oder Luxation des Oberarmes" die Frakturverletzung näher spezifizieren: S42.3 S41.87!"

Stefan Lang (Mar 17 2017 at 08:30):

http://www.dimdi.de/dynamic/de/klassi/downloadcenter/icd-10-gm/version2016/systematik/x1gbp2016.zip

Simone Heckmann (Mar 17 2017 at 09:10):

Wäre "postcoordinated" eine sinnvolle Bezeichnung für die Extension?
Ist das R/L und A/V/Z-Lametta auch Postkoordination oder ist das was anderes?

Simone Heckmann (Mar 17 2017 at 09:12):

Beispiel: S42.3 S41.87!
Primärdiagnose postcoordinated wäre nur S42.3, da macht es keinen Sinn, den kompletten String zu verwenden, da es ja mehrere Sekundärdiagnosen dazu geben kann.
Bei der Sekundärdiagnose S41.87 wäre dann aber die postkoordinierte Notation S42.3 S41.87!
...oder nur S41.87!
?

Simone Heckmann (Mar 17 2017 at 09:44):

Für's Protokoll:
Die !-Notation ist German Modification, daher wäre die Abbildung als National Extension ok.
In CDA ist die Relation "supported by", zeigt jedoch von Primär- auf Sekundärdiagnose.
In FHIR wäre die Referenz umgekehrt und müsste daher "supports" o.ä. heißen.

Simone Heckmann (Mar 17 2017 at 09:48):

<!--Beispiel für !-Notation : S42.3 S41.87!-->
<Condition xmlns="http://hl7.org/fhir">
    <id value="20390"/>
    <verificationStatus value="unknown"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="S42.3"/>
        </coding>
    </code>
</Condition>

<Condition xmlns="http://hl7.org/fhir">
    <id value="20391"/>
    <verificationStatus value="unknown"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="S41.87"/>
        </coding>
    </code>
    <extension url="http://fhir.de/StructureDefinition/condition-supports"/>
        <valueReference>
            <reference value="/Condition/20390"/> 
        </valueReference> 
    </extension> 
</Condition>

Peter Scholz (Mar 17 2017 at 10:11):

Ich denke für könnten dafür die partOf Extension nehmen, die existiert bereits und wir benötigen sie nicht mehr im +* Umfeld.
Die Defintion passt eigentlich auch: The procedure, condition, or observation this condition was created as part of (such as elevated blood pressure is part of diabetes).

Hier ein Beispiel aus DKR 2016:

 Beispiel 1
Spontane vaginale Geburt eines gesunden Neugeborenen in der 39. Schwangerschaftswoche, Damm intakt.
Hauptdiagnose: 
O80- Spontangeburt eines Einlings
Nebendiagnose(n):
Z37.0!  - Lebendgeborener Einling 
O09.6! - Schwangerschaftsdauer 37. Woche bis 41 vollendete Wochen 

Wäre dann

<!--Beispiel für !-Notation : 1506f Spontane vaginale Entbindung eines Einlings-->
<Condition xmlns="http://hl7.org/fhir">
    <id value="20400"/>
    <verificationStatus value="unknown"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="O80"/>
        </coding>
    </code>
</Condition>

<Condition xmlns="http://hl7.org/fhir">
    <id value="20401"/>
    <verificationStatus value="unknown"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="O09.6"/>
        </coding>
    </code>
    <extension url="http://fhir.de/StructureDefinition/condition-partOf"/>
        <valueReference>
            <reference value="/Condition/20400"/> 
        </valueReference> 
    </extension> 
</Condition>
<Condition xmlns="http://hl7.org/fhir">
    <id value="20402"/>
    <verificationStatus value="unknown"/>
    <code>
        <coding>
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="Z37.0"/>
        </coding>
    </code>
    <extension url="http://fhir.de/StructureDefinition/condition-partOf"/>
        <valueReference>
            <reference value="/Condition/20400"/> 
        </valueReference> 
    </extension> 
</Condition>

Stefan Lang (Mar 17 2017 at 10:14):

+1 für partOf

Simone Heckmann (Mar 17 2017 at 12:18):

Hallo Welt!

Stefan Lang (Mar 17 2017 at 12:18):

^^^ Off Topic

Simone Heckmann (Mar 20 2017 at 10:34):

Um das hier zu einem vorläufigen Abschluss zu bringen: Wir wollen zwar mit der Profilierung bis STU3 warten (seit 0:00h EST ist das QA abgeschlossen!!!) aber die Beispiele könnten wir eigentlich schon finalisieren, kommentieren und auf Simplifier hochladen.
Um alle Szenarien abzudecken bräuchten wir

• eine Ausschlussdiagnose
• eine (Verdachts-)Diagnose mit Angabe der Lateralität
• eine (gesicherte) +-Primärdiagnose
• eine *-Sekundärdiagnose, die auf die Primärdiagnose verweist
• eine !-Sekundärdiagnose, die auf eine Primärdiagnose verweist

...gibt es noch weitere Beispiele, die wir erstellen sollten...?

Stefan Lang (Mar 20 2017 at 15:42):

Der "Zustand nach" fehlt noch.
Wollen wir die "postcoordinated"-Extension auf fhir.de legen oder bringst Du das international ein?

Stefan Lang (Mar 20 2017 at 15:43):

Im Zweifel sollten wir die dann auch (als Draft unter fhir.de) hochstellen.

Stefan Lang (Mar 20 2017 at 15:44):

Und das KBV-Seitenlokalisation-ValueSet auch auf Simplifier, würde ich sagen

Stefan Lang (Mar 20 2017 at 15:50):

@Simone Heckmann Lädtst Du das auf Simplifier hoch und wir schauen nochmal drüber, oder wollen wir das erst hier nochmal durchdeklinieren?

Stefan Lang (Mar 20 2017 at 15:50):

(Simplifier ist wahrscheinlich einfacher)

Simone Heckmann (Mar 21 2017 at 09:17):

Ich schieße alles auf einen öff. Server, dann kann jeder kucken, editieren und vor allem: Wir können die Beispiele validieren ;-)

Simone Heckmann (Mar 21 2017 at 09:18):

Ich komme allerdings frühestens heute Abend dazu.

Simone Heckmann (Mar 21 2017 at 14:18):

Frage zum Beispiel der Auschlussdiagnose "H28.0 A":
Wir mappen A -> verificationStatus="refutet", allerdings ist der clinicalStatus ein Pflichtfeld mit der Auswahl "active | recurrence | inactive | remission | resolved".
(Falls sich jemand wundert: clinicalStatus ist 0..1, aber es gibt eine Invariante:
con-3: Condition.clinicalStatus SHALL be present if verificationStatus is not entered-in-error (expression : verificationStatus='entered-in-error' or clinicalStatus.exists())

The devil lies in the detail ;-)
Grahame's Server hat mich höflich darauf aufmerksam gemacht, als ich ihm das Beispiel zur Validierung geschickt habe.

Simone Heckmann (Mar 21 2017 at 16:48):

Da wir im Prinzip nur aus dem Zusatz "Z" -> inactive eine Aussage über den clinicalStatus ableiten können, müssten wir bei allen anderen Diagnosen einen Defaultwert setzen ("active").

Simone Heckmann (Mar 21 2017 at 16:59):

Wo wir schon dabei sind: wollen wir das Fass der Diagnosenkategorieren auch gleich mit aufmachen? Oder anders gefragt: Welche gibt es überhaupt. Mit meinem oblatendünnen Kodierrichtlinen-Dreiviertelwissen erinnere ich mich vage an "Hauptdiagnose, Nebendiagnose, Fachabteilungshauptdiagnose, Einweisungsdiagnose, Entlassdiagnose...?"

Simone Heckmann (Mar 21 2017 at 17:02):

Wobei: das Thema ist ja eigentlich nur "ICD-10" und nicht "Kodierung nach DRG"

Simone Heckmann (Mar 21 2017 at 17:18):

Das Profil, das wir für Condition erstellen würde dann wohl so ungefähr "http://fhir.de/StructureDefinition/icd-diagnose" heißen.
Ein weiteres, davon abgeleitetes Profil "http://fhir.de/StructureDefinition/drg-diagnose" würde dann die zusätzlichen Angaben und Pflichtfelder für eine ICD10-Diagnose im Rahmen der DRG-Abrechnung festlegen (Also die Kategorie, verpflichtende Angabe eines Datums etc.) D'Accord?

Simone Heckmann (Mar 21 2017 at 17:20):

Im ganzen Satz wäre damit das erste unserer Beispiele die Ausschlussdiagnose I21.9 A:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Ausschlussdiagnose I21.9 A-->
<Condition xmlns="http://hl7.org/fhir">
<meta>
    <profile value="http://fhir.de/StructureDefinition/icd-diagnose"/>
</meta>
  <text> 
    <status value="generated"/> 
    <div xmlns="http://www.w3.org/1999/xhtml">Ausschluss von: Akuter Myokardinfarkt, nicht näher bezeichnet (I21.9)</div> 
  </text> 
  <!-- ICD-10 Diagnosen sind immer als "active" zu kennzeichnen, es sei denn, sie haben den Zusatz "Z"-->
    <clinicalStatus value="active"/>
    <!-- ICD-10 Diagnosen mit Zusatz "A" sind als "refuted" zu kennzeichnen-->
    <verificationStatus value="refuted"/>
    <code>
        <coding>
            <!-- Als Codesystem gilt immer die URL http://fhir.de/CodeSystem/icd-10-gm/ gefolgt von der Jahreszahl des gültigen Kataloges-->
            <system value ="http://fhir.de/CodeSystem/icd-10-gm/2016"/>
            <code value="I21.9"/>
        </coding>
    </code>
    <!-- Link zum Patienten-->
    <subject> 
        <reference value="Patient/example"/> 
    </subject> 
</Condition>

Simone Heckmann (Mar 21 2017 at 17:23):

Online-Version:
http://fhirtest.uhn.ca/baseDstu3/Condition/41527 (JSON)
http://fhirtest.uhn.ca/baseDstu3/Condition/41527?&_format=xml (XML)

Ich habe mich für HAPI entschieden, da Grahame's Server die XML-Kommentare nicht speichert.

Simone Heckmann (Mar 21 2017 at 17:39):

Zweites Beispiel: "Verdachtsdiagnose mit Seitenangabe":
Online-Version:
http://fhirtest.uhn.ca/baseDstu3/Condition/41529 (JSON)
http://fhirtest.uhn.ca/baseDstu3/Condition/41529?&_format=xml (XML)

Simone Heckmann (Mar 21 2017 at 17:54):

Nebenbei: ich habe das Thema "Postkoordinierte Form" mal in den Implementer's Stream geworfen:
https://chat.fhir.org/#narrow/stream/implementers/topic/saving.20postcoordinated.20code.20in.20Coding.20datatype

Stefan Lang (Mar 21 2017 at 17:57):

Puh, schreib nie mehr an einem Stück, als man auf einer Bildschirmseite lesen kann, wenn es noch jemand verarbeiten soll :D

Stefan Lang (Mar 21 2017 at 17:58):

refuted in Kombination mit active ist IMHO korrekt, da der Status des Ausschlusses ja nach wie vor gilt.

Stefan Lang (Mar 21 2017 at 17:59):

Das Thema ist _eigentlich_ Abbildung von Diagnosen ;-)
Ich schau gleich mal, ob sich zu Haupt/Neben/XY-Diagnose was im CDA-Leitfaden bzw. in ART-DECOR befindet.

Stefan Lang (Mar 21 2017 at 18:00):

Insofern würde ich das Profil tendenziell auch nicht mit "icd" im Namen haben wollen

Simone Heckmann (Mar 21 2017 at 18:01):

Streng genommen gehört die L/R/B und die A/Z/V/G-Thematik ja auch nicht ins ICD-Profil, sondern schon ins DRG-Profil

Stefan Lang (Mar 21 2017 at 18:02):

Nach meinem Verständnis haben wir die generische Diagnose, repräsentiert _zum Beispiel_ durch ICD-10-Codes und optional mit Diagnoseart Haupt/Neben/....
Die Spezialisierung wäre dann die DRG-Diagnose, mit Diagnoseart 1..1

Stefan Lang (Mar 21 2017 at 18:03):

Streng genommen finden die Qualifikatoren auch im medizinisch-fachlichen Bereich Anwendung, nicht nur in DRG ;-)

Simone Heckmann (Mar 21 2017 at 18:04):

ok, überzeugt :)

Simone Heckmann (Mar 21 2017 at 18:19):

Nachgedanke zum verificationStatus:
wir hatten überlegt, das zum Pflichtfeld zu machen, mit der Option, es auf "unknown" zu setzen, falls der ICD-Code keine Angabe zur Diagnosensicherheit (A/G/V) enthält.
Allerdings würde "unknown" ja implizieren, dass es auch eine "refuted" Diagnose sein könnte, man weiß es halt nicht...
Ein ICD-10 Code ohne Zusatz tendiert semantisch doch aber stark in Richtung "gesichert", oder?
Wäre es da nicht besser, die Angabe des verificationStatus wegzulassen um die Diagnose nicht unsicherer darzustellen, als sie eigentlich ist?

Stefan Lang (Mar 21 2017 at 18:22):

Da "refuted" eigentlich senkrecht zum Sicherungsgrad steht: d'accord.

Stefan Lang (Mar 21 2017 at 18:26):

Die Idee hinter dem HAPI ist jetzt, dass einfach alle so lange die Beispiele updaten, bis sie passen, ja?

Simone Heckmann (Mar 21 2017 at 18:32):

Im Prinzip... Ich kann sie aber auch simpli-fhirn, und wenn jemand eine Anmerkung hat, dann diskutieren wir das hier und dann muss eben einer von uns beiden die Änderung machen.

Stefan Lang (Mar 21 2017 at 18:35):

Och, probieren wir das mal so aus. Nur sollte man sie sichern. Ist immerhin ein öffentlicher(!) Test(!)server ;-)

Simone Heckmann (Mar 21 2017 at 18:35):

Grahame's Server wäre nett gewesen. Der hat eine edit-Box im Browser. Aber da uns dort sie Kommentare flöten gehen...
(außerdem wirft die Edit-Box eine Exception :D)

Simone Heckmann (Mar 21 2017 at 18:36):

Per REST-Client auf HAPI zu editieren ist dagegen schon etwas nerdig.

Stefan Lang (Mar 21 2017 at 18:37):

HAPI hätte das auch, aber im Moment wohl nur für DSTU2

Stefan Lang (Mar 21 2017 at 18:38):

Naja, ob ich jetzt 3 Änderungen im XML im Editor oder direkt im Browser mache ;-)

Stefan Lang (Mar 21 2017 at 18:38):

Hab die beiden Beispiel oben mal upgedated

Stefan Lang (Mar 21 2017 at 18:39):

Also: Profilname geändert, Wording für den Text an ICD-10-Wortlaut angepasst und das CodeSystem für die Seitenlokalisation umbenannt

Simone Heckmann (Mar 21 2017 at 18:42):

Äh. Simplifier hat sich erledigt. Die Beispiele kollidieren mit DSTU2, daher verweigert Simplifier die Annahme :P

Stefan Lang (Mar 21 2017 at 18:44):

Das wird ne harte Zeit bis Mai :D

Simone Heckmann (Mar 21 2017 at 18:49):

Ich weiß nicht, ob wir ein Profil so allgemein benennen sollten wie "diagnose". Das würde ja bedeuten, dass wir perspektivisch auch andere in Deutschland verwendete Codesysteme (SNOMED -haha!) in diesem Profil definieren würden.

Das halte ich für keine gute Idee. Es wird ja immer Systeme geben, die entweder nur ICD-10 oder nur SNOMED können. Daher sollten diese die Möglichkeit haben, in deren jeweiligem CapabilityStatement zu sagen "ich kann http://fhir.de/StructureDefinition/icd-10".
Oder: "ich kann http://fhir.de/StructureDefinition/icd-10 und http://fhir.de/StructureDefinition/snomed".

Aber wie soll ein System, das nur ICD-10 kann sagen "ich kann http://fhir.de/StructureDefinition/diagnose", aber nur so halb...

Gleichsam sollte jedes System an den eingehenden Conditions durch auswerten von meta.profile erkennen können, ob es mit dem Inhalt etwas anfangen kann, oder nicht.

Simone Heckmann (Mar 21 2017 at 18:52):

So lange die beiden Profile icd-10 und snomed kompatibel sind (durch offenes slicing), könnte sich eine Condition, die sowohl einen ICD-10 als auch einen SNOMED-Code enthält (beide konform zum jeweiligen Profil) ja durchaus mit beiden Profilen in meta-profile schmücken.
Validatoren würden dann auch nach Konformität zu beiden Profilen prüfen.

Stefan Lang (Mar 21 2017 at 18:57):

Hm, ich würde das lieber so betrachten, dass wir ein "diagnose"-Basisprofil haben, in das wir alles reinwerfen, aber optional.
Und davon abgeleitet zunächst mal ein "diagnose-icd10"-Basisprofil. Aber da wir in der Praxis im Moment sowieso nur von ICD-10 sprechen, wäre vielleicht "diagnose-icd10" dann doch angemessener. Zumal womöglich in "anderen" Codiersystemen die Lateralität ganz anders abgebildet wird.

Stefan Lang (Mar 21 2017 at 18:58):

Sollte der Bedarf bestehen, können wir ja auch später noch "rückwärts" ein generisches "diagnose"-Profil ableiten

Stefan Lang (Mar 21 2017 at 19:00):

Und wieder geändert :D

Simone Heckmann (Mar 21 2017 at 19:02):

Kreuz...
http://fhirtest.uhn.ca/baseDstu3/Condition/41530 (JSON)
http://fhirtest.uhn.ca/baseDstu3/Condition/41530?&_format=xml (XML)
...und Stern...
http://fhirtest.uhn.ca/baseDstu3/Condition/41531 (JSON)
http://fhirtest.uhn.ca/baseDstu3/Condition/41531?&_format=xml (XML)
..wobei ich bei letztere den dueTo link nicht angepasst habe um auf die Kreuzdiagnose zu zeigen.

Stefan Lang (Mar 21 2017 at 19:04):

Als "Struktur-Nazi" ändere ich den Profilnamen dort auch gerade mal auf "diagnose-icd10".
(Das allgemeinere nach vorne, und "icd" könnte auch ICD-9 bedeuten, daher "icd10")

Simone Heckmann (Mar 21 2017 at 19:05):

diagnose-icd10-gm?

Stefan Lang (Mar 21 2017 at 19:07):

Was ist die Steigerung von "Struktur-Nazi"? :D
D'accord ;-)

Stefan Lang (Mar 21 2017 at 19:22):

Für Haupt-/Nebendiagnose usw. gibt es im deutschen v2 im wesentlichen die Tabellen 0052 und 0359, beschrieben für DG1-6 bzw. DG1-15:
http://wiki.hl7.de/index.php?title=Segment_DG1#DG1-6_Diagnosetyp

Stefan Lang (Mar 21 2017 at 19:23):

Die weichen aber stark vom Basis-v2-Standard ab:
http://build.fhir.org/v2/0052/index.html
http://build.fhir.org/v2/0359/index.html

Simone Heckmann (Mar 21 2017 at 19:28):

Da das ja keine medizinische Bewandnis hat und rein der DRG-Abrechnung dient, hätte ich jetzt kein Problem damit, wenn die Interoperabilität an der Landesgrenze aufhört :D
Wir können ja dort, wo es möglich ist, ein Mapping auf die Standardwerte angeben.

Stefan Lang (Mar 21 2017 at 19:30):

Joah. Schade halt nur, dass wir nicht einfach mal die fertigen internationalen v2-ValueSets nehmen können ;-)

Simone Heckmann (Mar 21 2017 at 21:28):

Also. Der Grahame hat gesprochen: Unser Zauberknopf für Postkoordination heißt CodeSystem.compositional :)

Simone Heckmann (Mar 21 2017 at 21:37):

...allerdings heißt das auch, dass wir die Systematik nochmal überdenken sollten.

Stefan Lang (Mar 21 2017 at 21:37):

Wenn ich das parsen soll, muss ich zumindest die Regeln kennen, siehe meinen Kommentar im Thread.

Stefan Lang (Mar 21 2017 at 21:38):

Die Regeln sind für ICD-10-GM meines Wissens nirgends klar definiert, zumindest nicht im Original-Dokument. In freier Wildbahn habe ich schon alles gesehen.

Stefan Lang (Mar 21 2017 at 22:10):

Gefällt mir ehrlich gesagt überhaupt nicht, dass man letzten Endes bei postkoordinierten Codes diese quasi als Strings parsen muss, um an die Detailinformationen zu kommen. Und faktisch wäre jeder ICD-10-Code ein potentiell postkoordinierter.
Noch dazu ohne fest definierte Regeln. Das war/ist in v2 schon einigermaßen chaotisch.

Simone Heckmann (Mar 22 2017 at 07:44):

Ich glaube wir müssen hier nochmal nachlesen: http://build.fhir.org/icd.html
(ich kannte diese Seite bisher nicht. Muss ich übersehen haben oder es gab sie noch nicht, als ich zuletzt geschaut habe)
Da ich in der Vocab-Gruppe nicht aktiv bin, habe ich deren Aktivitäten nicht auf dem Schirm.

Simone Heckmann (Mar 22 2017 at 07:45):

Der Knackpunkt ist dieser:

Note that for dual coding (see volume 2 ICD-10 Manual ), section 3.1.3 Two codes for certain conditions), simply use the two ICD-10 codes separated by a space, e.g. "J21.8 B95.6"

Stefan Lang (Mar 22 2017 at 08:19):

Na, "separated by a space" ist ja schon mal eine wohldefinierte Syntax, wie ich sie gesucht habe. Wenn das auch für die Qualifikatoren gilt, wäre zwar nicht 100% glücklich, aber zufrieden.

Stefan Lang (Mar 22 2017 at 08:20):

Ungeklärt dabei: wie bilden wir den Unterschied zwischen "+/*" und "!" ab?

Simone Heckmann (Mar 22 2017 at 08:42):

Der Leitfaden ist da nicht ganz eindeutig. Mir ist nicht klar, ob die +/* im Code beibehalten werden, oder ob sich das dann aus der Reihenfolge ergeben soll. Das (einzige) Beispiel ist ausgerechnet eine !-Diagnose, die ja in der internationalen Schreibweise kein Zusatzsymbol hat :P

Simone Heckmann (Mar 22 2017 at 08:43):

Nebenbei sind in diesem Leitfaden die jährlichen Ausgaben von ICD tatsächlich als Versionen modelliert und nicht als separate CodeSysteme mit jeweils eigener URL.

Stefan Lang (Mar 22 2017 at 08:45):

Das ist aber falsch, und das gibt es auch nicht zu diskutieren ;-)

Stefan Lang (Mar 22 2017 at 08:45):

Es sind definitiv keine Versionen eines einzigen CodeSystems

Simone Heckmann (Mar 22 2017 at 09:04):

Selbst das DIMDI spricht von "Versionen":

Die Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme, 10. Revision, German Modification (ICD-10-GM) ist die amtliche Klassifikation zur Verschlüsselung von Diagnosen in der ambulanten und stationären Versorgung in Deutschland. Seit dem 1. Januar 2017 ist die ICD-10-GM in der Version 2017 anzuwenden.

Simone Heckmann (Mar 22 2017 at 09:07):

http://www.dimdi.de/static/de/klassi/icd-10-gm/historie/gueltigkeit/index.htm

Simone Heckmann (Mar 22 2017 at 09:08):

Versionsverlauf (sic!)

Patrick Werner (Mar 22 2017 at 09:25):

ja das DIMDI denkt hier in Versionen, es ändern sich zwar die semantischen Bedeutungen von Codes, aber Versionen ;.)

Stefan Lang (Mar 22 2017 at 09:34):

Seufz. Was DIMDI schreibt, entspricht halt nur nicht dem Begriff der Version für Codesysteme.
Sobald sich die Semantik auch nur eines Codes ändert, hast Du keine neue Version mehr, sondern ein neues Codesystem.
Und das ist regelmäßig z.B. für die XXX.9-Codes der Fall.

Stefan Lang (Mar 22 2017 at 09:47):

Siehe auch: http://wiki.hl7.de/index.php?title=H%C3%A4ufig_gestellte_Fragen,_Tipps_und_Tricks_zum_Thema_OIDs#Frage_13..09Wann_muss_f.C3.BCr_ein_Kodiersystem_eine_neue_ISO_OID_vergeben_werden.3F

Stefan Lang (Mar 22 2017 at 09:47):

und OID <===> URI

Stefan Lang (Mar 22 2017 at 10:30):

@Simone Heckmann Um Deine "Denkhaube" zu befüttern, hier mal meine Gedanken zu den Zusammenhängen:
- Unser Basisprofil-Leitfaden referenziert auf das ValueSet ".../icd-10-gm" in seiner jeweils aktuellen Version
- Jede Jahres-"Version" von ICD-10-GM ist ein Codeystem(".../icd-10-gm/2016", ".../icd-10-gm/2017", ".../icd-10-gm/2018" usw., äquivalent zu den jährlich neuen Codesystem-OIDs), immer mit CodeSystem.version=1, sofern das DIMDI nicht im Jahresverlauf Korrekturen veröffentlicht.
- Das ValueSet ".../icd-10-gm" bekommt jährlich das neue ICD-10-GM-Codesystem included, dadurch ändert sich die Version des ValueSets

Stefan Lang (Mar 22 2017 at 10:32):

Um mehr geht's doch eigentlich nicht, oder?

Simone Heckmann (Mar 22 2017 at 10:33):

Das hier ist interessant:
http://build.fhir.org/codesystem-definitions.html#CodeSystem.version

There may be different code system instances that have the same identifier but different versions. The version can be appended to the url in a reference to allow a refrence to a particular business version of the code system with the format [url]|[version].

Stefan Lang (Mar 22 2017 at 10:35):

Ja, bloß haben die ICD-10-GM-Version unterschiedliche Identifier, nämlich die jeweiligen OIDs

Simone Heckmann (Mar 22 2017 at 10:36):

Jetzt meine Gegenvorschlag:
- Unser Basisprofil-Leitfaden referenziert auf das ValueSet ".../icd-10-gm" Punkt
- Jede Jahres-"Version" von ICD-10-GM ist ein Codeystem mit dem immer gleichen identifier /icd-10-gm, aber unterschiedlichen Versionen (CodeSystem.version="2017"...)
-Das ValueSet ".../icd-10-gm" muss niemals aktualisiert werden
- In der Instanz wird ein Code mit code.system=".../icd-10-gm|2017" übermittelt.

Simone Heckmann (Mar 22 2017 at 10:36):

In so fern haben wir auch immer eine eindeutige Semantik für den Code

Stefan Lang (Mar 22 2017 at 10:37):

Nach meinem Verständnis muss ich unterschiedliche URLs haben, wenn ich unterschiedliche OIDs habe.

Stefan Lang (Mar 22 2017 at 10:38):

Weil:

Stefan Lang (Mar 22 2017 at 10:40):

"urn:oid:1.2.276.0.76.5.409" === ".../icd-10-gm"
UND "urn:oid:1.2.276.0.76.5.463" === ".../icd-10-gm"
Daraus folgt: "urn:oid:1.2.276.0.76.5.409" === "urn:oid:1.2.276.0.76.5.463", und das ist offensichtlich unzutreffend

Simone Heckmann (Mar 22 2017 at 10:43):

ICD-2016:
CodeSystem.url=.../icd-10-gm
CodeSystem.version=2016
CodeSystem.identifier = urn:oid:1.2.276.0.76.5.409

ICD-2017:
CodeSystem.url=.../icd-10-gm
CodeSystem.version=2017
CodeSystem.identifier = urn:oid:1.2.276.0.76.5.463

Simone Heckmann (Mar 22 2017 at 10:43):

So wie ich die Definition von url und version lese, ist das erlaubt.

Simone Heckmann (Mar 22 2017 at 10:45):

Das geniale daran ist, dass unser ValueSet binding an /icd-10-gm für alle Zeiten stabil wäre :P

Stefan Lang (Mar 22 2017 at 10:45):

CodeSystem.url: the canonical URL that never changes for this code system - it is the same in every copy. Ideally, the URL should also be the location of the master version of the code system, though this is not always possible
CodeSystem.identifier: A system/value pair that is used to identify the code system in other contexts (such as an OID in an HL7 v3 specification)

Stefan Lang (Mar 22 2017 at 10:46):

In beiden Fällen ist von "the code system" die Rede, also sollte auch dasselbe gemeint sein

Stefan Lang (Mar 22 2017 at 10:46):

Und nicht identifier === url|version

Stefan Lang (Mar 22 2017 at 10:49):

Plus: version sollte man wirklich vorhalten für den Fall, dass das DIMDI tatsächlich mal Korrektur-Releases macht. Ist schon vorgekommen.

Simone Heckmann (Mar 22 2017 at 11:01):

Der CodeSystem.identifier hat nach meiner Auffassung in FHIR eine eher untergeordnete Rolle. Mehr so ein "auch bekannt als..."
Dass dieser Identifier zur richtigen Instanz des CodeSystems führt ist also eher für diese "other contexts" relevant und wäre für V3 ja auch gegeben. Die versionsspezifische OID identifiziert die versionsspezifische Instanz des CodeSystems. Die Notwendigkeit, dass gleiche URLS auch gleiche OIDs haben, leite ich daraus nicht ab.

Simone Heckmann (Mar 22 2017 at 11:01):

könnten Korrektur-Releases dann nicht einfach 2016-a heißen? Wie "heißen" diese Versionen denn im DIMDI?

Stefan Lang (Mar 22 2017 at 11:04):

Um nochmal von der anderen Seite ranzugehen:
- Die CodeSystem-Ressource soll ein Codesystem (sic!) repräsentieren.
- Jede Jahresfassung von ICD-10-GM ist per Definitionem (und vom DIMDI vergebener Codesystem-OID) ein eigenes Codesystem.
- Die Zusammenfassung mehrerer Codesysteme ist eine mögliche Art ein ValueSet (sic!2) zu definieren.
- Die Zusammenfassung mehrerer Codesysteme ist nichts, was man in einer CodeSystem-Ressource abbildet
Irgendwelche Fehler bei diesen Gedanken?

Simone Heckmann (Mar 22 2017 at 11:10):

Bei meinem Vorschlag hätten wir ja auch zwei CodeSystem-Instanzen, bloß dass beide sich die gleiche "Logical"url teilen und damit anstatt über die url nur über url|version eindeutig referenziert werden können

Stefan Lang (Mar 22 2017 at 11:11):

Es sind nicht zwei Instanzen. Es sind zwei Versionen einer Instanz. Das ist ein Unterschied.

Stefan Lang (Mar 22 2017 at 11:12):

Die Instanz definiert sich ausschließlich über die globally unique URL

Simone Heckmann (Mar 22 2017 at 12:14):

Ok, vielleicht ist das ein Terminologieproblem: Es sind zwei Instanzen einer Resource, mit jeweil eigener physischer URL (z.B.: /CodeSystem/123 und /CodeSystem/345)
Beide haben die gleiche "Logische URL", die für den Verweis aus dem ValueSet heraus verwendet wird.
Mit der Angabe der logischen url (z.B. Binding im Profil) sage ich nur "alle Codesysteme mit dieser logischen url".
Wenn ich genau spezifizieren möchte, welches ich eine, muss ich immer die Version dazu nennen.

Über das Flag CodeSystem.needsVersion, kann ich Kennzeichnen, dass die Angabe der Version verpflichtend ist.

Stefan Lang (Mar 22 2017 at 12:37):

Das ist ein Meta-Terminologieproblem ;-)
Ich bin da jetzt mal starrköpfig: Ein Codesystem ist ein Codesystem ist keine Version eines Codesystems, und so sollte man das IMHO auch in FHIR abbilden.

Stefan Lang (Mar 22 2017 at 12:39):

Unbenommen, dass wir auf der Ebene der String-Verarbeitung gerade diskutieren, ob wir irgendwo ein "/", ein "|" oder vielleicht ein "-" setzen ;-)

Simone Heckmann (Mar 22 2017 at 12:42):

Die Frage ist eher, ob es uns das Beharren auf "/" statt "|" wert ist, aus dem internationalen Standard auszubrechen :P

Stefan Lang (Mar 22 2017 at 12:43):

Wo brechen wir denn aus dem Standard aus?

Simone Heckmann (Mar 22 2017 at 12:44):

z.B. indem wir die hier definierte URL für icd-gm nicht verwenden: http://build.fhir.org/icd.html

Stefan Lang (Mar 22 2017 at 12:45):

Das ist eine Unvollständigkeit bzw. Unkorrektheit im Standard, daher das GForge-Item.

Simone Heckmann (Mar 22 2017 at 12:47):

Zumal nach wie vor der Nachteil besteht, dass wir jährlich unser ValueSet updaten müssten mit der Klausel "...und außerdem include alle codes aus /icd-10-gm/2017 .../2018 ...2019 usw. Während wir bei der Standard-Vorgehensweise ein stabiles ValueSet hätten.
Allerdings würde ich das auch nochmal zusammenschreiben und mit von den Experten absegnen lassen. Nur weil ich *glaube* dass es so ist, muss es ja noch lange nicht so sein.

Stefan Lang (Mar 22 2017 at 12:57):

Der Nachteil des jährlichen ToDos ist klar, wobei ich die 5 zusätzlichen Minuten, um das ValueSet zu erweitern, nicht unbedingt als kritisch ansehe.
Ich fände es halt extrem unschön, wenn wir deswegen die Bedeutung des Begriffs "Codesystem" bzw. der Ressource "CodeSystem" so verwischen.
Wahrscheinlich sollten wir tatsächlich nochmal damit an die Experten gehen, wobei: meinen wir damit jetzt Terminologie- oder FHIR-Experten? :D

Stefan Lang (Mar 22 2017 at 12:59):

Dass es da durchaus unterschiedliche Auffassungen gibt, hat Grahame ja im implementers-Thread geschrieben.
Allerdings ist dort auch inzwischen geklärt, dass es breaking Changes zwischen den Jahresfassungen gibt.

Simone Heckmann (Mar 22 2017 at 13:02):

Ich hab immer noch nicht verstanden warum das schlimm ist, wenn doch jeder code IMMER aus System+Version+Code besteht.
Der Terminologieserver weiß ja dann bei der Validierung, in welches CodeSystem er kucken muss und wo er ggf. den korrekten DisplayText herbekommt.
Die Aussage von Grahame wiederum, dass das ValueSet die Semantik redefiniert, habe ich gar nicht verstanden. Das liegt bei mir noch in der postprocessing queue...

Stefan Lang (Mar 22 2017 at 13:06):

Mir geht's im Grunde einzig darum, den Begriff Codesystem im FHIR-Kontext mit dem Begriff Codesystem im CDA-Kontext und im DIMDI-Bereich konsistent zu halten. Der ist nun mal relativ fix definiert. Technisch sind beide Lösungen äquivalent umsetzbar.

Stefan Lang (Mar 22 2017 at 13:08):

Was Grahame meint ist: wenn das ValueSet nur die Codes C50.0, C50.1 und C50.9 enthält, hat C50.9 eine andere Bedeutung, als wenn das ValueSet C50.0, C50.1 ... C50.4 und C50.9 enthält.

Simone Heckmann (Mar 22 2017 at 13:09):

Ach so, da geht's um die Bedeutung der "other"-Klasse. Ok, kapiert.

Stefan Lang (Mar 22 2017 at 13:09):

Terminologen sagen dazu: nee, C50.9 schließt immer C50.0 bis C50.8 aus

Simone Heckmann (Mar 22 2017 at 13:10):

Meine Meinugn dazu: Solche ValueSets einfach nicht machen :)

Stefan Lang (Mar 22 2017 at 13:10):

Joah, aber man könnte ...

Simone Heckmann (Mar 22 2017 at 13:15):

Klarer Fall für die 10 Gebote :)

Simone Heckmann (Mar 22 2017 at 22:00):

Ok. Um die Diskussion von ihrer etwas länglichen Tangente mal wieder zur Frage zurückzuholen:

Postkoordination: ja oder nein oder wie?

Meine Tendenz ist, die Lateralität und die Diagnose-Sicherheit auf FHIR-Attribute zu mappen und nicht am Code dran zu lassen, da das definitiv nicht Teil des Codesystems ist. Schon allein deswegen, weil die KBV ihre Codes jederzeit unabhängig von der ICD-Version ändern könnte.

Außerdem haben wir dann noch Sonderlocken wie dass bei stat. Diagnosen die Angabe der Sicherheit VERBOTEN ist etc. Darüber will ich mir in den FHIR-Basis-Profilen keine Gedanken machen müssen. Ob die Attribute für die Abrechnung wieder in KBV-Symbole gemapped werden müssen, darüber sollen sich die Abrechnungssysteme den Kopf zerbrechen...
Wir sollten aber nochmal die Eineindeutigkeit der Mappings überprüfen!

Simone Heckmann (Mar 22 2017 at 22:00):

Bleibt also die Frage nach dem Umgang mit der ICD-Postkoordination (+/*/!)
Momentan sehe ich zwei Varianten:
a) wie im Interop besprochen mit zwei unabhängige Conditions und den Extensions zur Verlinkung (H67.1 "dueTo" B05.3†)
b) wie von VOCAB vorgeschlagen als eine Condition mit einem einzigen postkoordinierten Code ("B05.3† H67.1*")

Letzteres wäre in der Implementierung natürlich deutlich einfacher zu handhaben. Aber wie Lloyd schon sagte: mit a) hat man mehr Möglichkeiten.

Simone Heckmann (Mar 22 2017 at 22:00):

Frage:
welche Sind das?
Brauchen wir die?
Was ist wäre der ausschlaggebende Nachteil der postkoordinierten Notation, der es vertretbar macht, den Implementieren den Mehraufwand der separaten, verlinkten Notation zuzumuten?

Stefan Lang (Mar 23 2017 at 09:55):

Bei der postkoordinierten Variante sehe ich eine Inkonsistenz - einen Teil (Lateralität, Sicherheit) packen wir damit als einzelne Attribute raus, aber in diesem Spezialfall dann nicht. Erschwerend kommt dann noch dazu, dass man dann noch einen Workaround finden muss für z.B. "X55.5L+ Y66.6*" (ich weiß nicht, ob es das gibt, würde aber mal davon ausgehen). Von daher: pro 2 Resourcen für +/*

Simone Heckmann (Mar 24 2017 at 07:36):

Frage: Kann eine Primär-DG mehrere !-Diagnosen haben?
Das wäre auch ein Argument fürs Splitten. Denn der Code "A11.1 !B22.2 !C33.3 !D44.4...." wäre etwas unpraktisch.

Was ich mich ebenfalls Frage: Was wäre denn nach ICD/KBV-Logik das Vorgehen bei einer +/*-Diagnose, wenn die Sekundärdiagnose abgeheilt ist, aber die Primärdiagnose weiter besteht? Oder anders gefragt: Kann sich der Status der beiden Diagnosen unabhängig voneinander ändern?

Stefan Lang (Mar 24 2017 at 14:11):

Prinzipiell kann sich das schon ändern. Die Frage ist, ob das dann nicht sowieso eine komplett neue Condition ist.

Stefan Lang (Mar 24 2017 at 14:14):

Die multiplen "!"-Diagnosen wären aber doch einzelne Conditions, oder? Also
1. "A11.1 B22.2!"
2. "A11.1 C33.3!"
usw.

Stefan Lang (Mar 24 2017 at 14:17):

Zum Thema exakte Syntax:
"Schlüsselnummern, die nur zusätzlich zu anderen, nicht optionalen Schlüsselnummern angegeben werden dürfen, sind durch ein angehängtes Ausrufezeichen gekennzeichnet.
Diese Konventionen können in anderen Druckwerken und in maschinenlesbaren Fassungen abweichen"
((Hervorhebung durch mich)

Simone Heckmann (Mar 24 2017 at 14:20):

...ist das Hochdeutsch für: " Macht doch, was ihr wollt...." ?

Stefan Lang (Mar 24 2017 at 14:21):

Nein, das ist hochdeutsch für "wir machen, was wir wollen - sucht Euch davon aus, was Ihr wollt" ;)

Stefan Lang (Mar 24 2017 at 14:22):

Ich bin tatsächlich dafür, mal eine kurze Telko mit Sylvia und/oder Heike anzuberaumen, um da mal einen definierten Informatiosstand zu bekommen.

Stefan Lang (Mar 24 2017 at 14:30):

Übrigens sind *-Diagnosen grundsätzlich optional, bringen aber im DRG u.U. höhere Entgelte.

Stefan Lang (Mar 24 2017 at 14:31):

Und noch was zum Thema eindeutige Syntax: "Auf den Abrechnungsunterlagen und Arbeitsunfähigkeitsbescheinigungen nach § 295 können Sie außerdem das Kreuz und den Stern weglassen, da diese Eigenschaften für alle Schlüsselnummern eindeutig vorgegeben sind: E10.30 H36.0"
(bedeutet im Umkehrschluss, dass ansonsten "+" und "*" explizit mit hin zu schreiben sind)

Simone Heckmann (Mar 24 2017 at 14:42):

+1 für TelKo

Stefan Lang (Apr 21 2017 at 15:44):

Ich bin gerade dabei, die Telko-Ergebnisse aufzuarbeiten.
Insbesondere haben wir uns ja entschieden, die ICD-10-GM-"Version" in URL aufzunehmen. Sprich: Condition.code.coding.system="http://hl7.org/fhir/sid/icd-10-de|2017" (als Beispiel).
Unabhängig davon, dass ich die Unterscheidbarkeit der Jahres"versionen" anhand von system für elementar halte: es gibt ja auch noch .....coding.version. Und dazu sagt http://www.hl7.org/implement/standards/fhir/datatypes.html#Coding folgendes:

"
A code system version may also be supplied. If the meaning of codes within the code system is consistent across releases, this is not required. The version SHOULD be exchanged when the system does not maintain consistent definitions across versions. Note that the following systems SHOULD always have a version specified:

• National releases of SNOMED CT (consistency of definitions varies amongst jurisdictions, and some jurisdictions may make their own rules on this)
• Various versions of ICD (note: the major releases are labeled as different code systems altogether, but there is variation within versions)

More generally, any classification (e.g. a code system that includes concepts with relative definitions such as "not otherwise coded" will require a version. See the discussion of code system versions in the Code System resource for further discussion on versioning.
"

Stefan Lang (Apr 21 2017 at 15:47):

Vor allem der letzte Absatz (und der zweite Punkt) trifft ja auf ICD-10-GM zu. Von daher müssen wir version für die ICD-10-GM-Profile auf 1..1 setzen. Widerspruch?

Simone Heckmann (Apr 21 2017 at 17:48):

Ja, ich denke in der Instanz eines ICD-Codings muss die Version als Coding.version angegeben werden. Die Schreibweise als Versionsspezifische URL ("http://hl7.org/fhir/sid/icd-10-de|2017") käme dann zum tragen, wenn man irgendwo auf auf das CodeSystem in einer bestimmten Version verweisen will (bspw. in einem Profil).

Stefan Lang (Apr 22 2017 at 07:18):

Hm, das sollten wir klar ziehen.
Zumindest in Bezug auf ICD-10-GM wollen wir in den Profilen und auch im zugehörigen ValueSet genau nicht auf die Version fixieren, d.h. zumindest für unsere Zwecke brauchen wir "|2017" dort nicht.
Daher dachte ich, die Diskussion dazu betieht sich auf die Instanz. Dort gibt es aber ohnehin version als separate Angabe, die nach dem oben zitierten Text de facto verpflichtend ist bzw, so profiliert werden sollte.
Wozu genau brauchen wir dann (wie gesagt: in diesem Kontext) die Pipe-Notation?

Stefan Lang (Apr 22 2017 at 07:19):

Weil: dann würde ich mal schnell den bp:Diagnosen Eintrag im Wiki und die Beispiele anpassen ;-)

Simone Heckmann (Apr 26 2017 at 16:51):

in diesem Kontext erstmal nicht... Aber es könnte abgeleitete Profile geben, die nicht nur das CodeSystem sondern auch dessen Version festlegen wollen. Da wäre das dann relevant.

Stefan Lang (Apr 28 2017 at 07:30):

Mathias Aschhoff (Jan 24 2018 at 08:32):

Wo wir schon dabei sind: wollen wir das Fass der Diagnosenkategorieren auch gleich mit aufmachen? Oder anders gefragt: Welche gibt es überhaupt. Mit meinem oblatendünnen Kodierrichtlinen-Dreiviertelwissen erinnere ich mich vage an "Hauptdiagnose, Nebendiagnose, Fachabteilungshauptdiagnose, Einweisungsdiagnose, Entlassdiagnose...?"

Offensichtlich habt ihr das Fass nicht aufgemacht. In der aktuellen Diskussion um den Entlassbrief würde ich aber zumindest gerne mit euch Diskutieren wie es prinzipiell gemacht wird. Als CDA Lösung schwebt mir ein qualifier vor mit einem Value Set aus LOINC wo ich zumindest primär und sekundär einteilen kann (was aber glaube ich nicht das selbe wie Haupt und Nebendiagnose ist?). Allerdings hat Simone ja schon mehrere Kategorien genannt, die wir auch abbilden können sollten. DIe Frage ist nun aber erst einmal was sieht FHIR vor gibt es hier schon einen Ansatz?
Merci!

Patrick Werner (Jan 24 2018 at 10:44):

Im §301 Datensatz festgelegt sind:
Aufnahmediagnose
Sekundär-Diagnose Aufnahme -
Einweisungsdiagnose -
Sekundär-Diagnose Einweisung
(jeweils + Lokalisation R rechts, L links, B beidseitig)
Fachabteilungdiagnose,&sekundär Diag.

Nachfolgediagnose,
mit Sekundär-Diagnose Arbeitsunfähigkeit

Haupt & Sekundärdiagnose

Patrick Werner (Jan 24 2018 at 10:45):

hier ab Seite 31 ganz gut dargestellt

Patrick Werner (Jan 24 2018 at 10:51):

http://www.dkgev.de/pdf/49.pdf

Stefan Lang (Jan 24 2018 at 10:51):

Das ValueSet sollte ganz sicher überall gleich sein. Da gibt es doch sicher schon was für unsere spezifisch deutschen Gegebenheiten, evtl. aus dem v2-Umfeld?
FHIR hat Condition.category, wo die Information IMHO gut hin passt.

Mathias Aschhoff (Jan 24 2018 at 13:03):

lucky you lucky fhir, ok also Aufgabe Value Set erstellen an die Terminologie-Gruppe und dann weiter machen. Danke!

Mathias Aschhoff (Jan 26 2018 at 12:13):

Ich habe da mal was angefangen - geht das in die richtige Richtung? http://art-decor.org/art-decor/decor-valuesets--elmgmt-?id=2.16.840.1.113883.3.1937.99.61.36.11.1
Denke das könnte man dann ja gemeinsam nutzen.

Michael Sauer (Jan 26 2018 at 22:29):

Leider geht das nicht wirklich in die richtige Richtung. Tatsächlich sind die Definitionen aus dem 301 in der Praxis gebräuchlich. Die LOINC Liste enthält offensichtlich ganz unterschiedliche Sachverhalte..

Stefan Lang (Jan 27 2018 at 02:11):

Ich denke auch, es macht Sinn, dass TC Term. sich darum kümmern, oder? @Heike Dewenter ;-)

Mathias Aschhoff (Feb 08 2018 at 17:39):

Hallo zusammen, in einem Telefonat mit Kai haben wir folgendes Value-Set gefunden. Wie wäre es damit?
https://art-decor.org/art-decor/decor-valuesets--hl7de-?id=1.2.276.0.76.11.62&effectiveDate=2013-02-15T00:00:00&language=de-DE

Patrick Werner (Mar 12 2018 at 08:41):

Moin, möchte ja nicht alte Kamellen aufwärmen. Aber wieso ist ICD10 GM nicht versioniert - sondern unterschiedliche CodeSysteme?

Patrick Werner (Mar 12 2018 at 08:45):

Weil sich die semantische Bedeutung ändern kann? Dafür gäbe es aber im Codesystem ja extra das versionNeeded flag

Christof Gessner (Mar 12 2018 at 17:08):

Siehe dazu Core Principles https://www.hl7.org/documentcenter/public_temp_0F8B9BD6-1C23-BA17-0C777585791F86ED/standards/V3/core_principles/infrastructure/coreprinciples/v3modelcoreprinciples.html#coreP_Coded_Properties-code-systems-versions bzw. neuere Versionen davon.

Patrick Werner (Mar 12 2018 at 18:02):

Danke Christof: In cases where the knowledge resource itself doesn’t enforce this (e.g. older versions of ICD-9-CM, where codes were retired and subsequently re-used to represent something different), then the version of the Code System in which the code is associated with the desired meaning must be included in the HL7 data type carrying the instance of the Code.

Patrick Werner (Mar 12 2018 at 18:03):

Würde ich dahingehend interpretieren, dass ICD-10-GM ein Codesystem ist, bei dem immer die Version angegeben werden muss. Also versionNeeded = true
Ich kann keine Notwendigkeit herauslesen für jede ICD-10 GM Version ein komplett neues CodeSystem, mit neuer URI zu definieren.

Patrick Werner (Mar 12 2018 at 21:26):

Ok, lesen hilft: laut der aktuellen Version der Basisprofile haben wir uns schon längst auf http://fhir.de/CodeSystem/dimdi/icd-10-gm|* geeinigt

Last updated: Apr 12 2022 at 19:14 UTC