Stream: german (d-a-ch)
Topic: Grad der Behinderung
Simone Heckmann (Jun 15 2021 at 12:18):
Wir haben aktuell in einem Projekt den Bedarf, den Grad der Behinderung einer Person abzubilden.
Hat sich dazu schon jemand Gedanken gemacht?
Es geht einerseits um die Angabe des Grades (20,30,40...100) [%]? und der Merkzeichen entsprechend der Angaben auf dem Behindertenausweis.
Simone Heckmann (Jun 15 2021 at 12:18):
Sollte m.E. in die Deutschen Basisprofile einfließen...
Simone Heckmann (Jun 15 2021 at 12:19):
Mareike Przysucha (Jun 17 2021 at 12:30):
Ich habe gerade gelesen, dass der Grad der Behinderung NICHT in % angegeben wird, sondern einfach als Zehnerzahl zwischen 20 und 100 (also wie oben beschrieben, nur ohne %).
Mareike Przysucha (Jun 17 2021 at 12:38):
Erste Ideen meinerseits zur Repräsentation in FHIR:
- Vorschlag A: Observation Profile, 1x Grad der Behinderung (codiert), 1x Merkzeichen (codiert), 1 zusammenfassende Ressource mit 1..1 Verweis auf Grad der Behinderung und 0..* Verweisen auf Merkzeichen
- Vorschlag B: 1 Observation mit 1..1 Component zum Grad und 0..* Componenten mit den Merkzeichen - wobei ich aktuell unsicher bin, ob das vom slicing her funktioniert, müsste aber.
Vorschlag B würde ich bevorzugen und Vorschlag A nur nehmen, wenn Vorschlag B nicht funktioniert.
Freue mich aber auch über andere Vorschläge.
Simone Heckmann (Jun 17 2021 at 12:43):
Vorschlag C: Observation mit 1x Grad der Behinderung (codiert), Merkzeichen als Extensions (ist schon was sehr spezielles...)
Simone Heckmann (Jun 17 2021 at 12:46):
...um ein Gefühl zu vermitteln wie speziell diese Merkzeichen sind:
image.png
Simone Heckmann (Jun 17 2021 at 12:48):
Also egal wie wir's lösen, dieses Profil wird bestenfalls zu sich selbst kompatibel sein :D
Mir würde die Lösung mit der Observation+Merkzeichen-Extension gefallen, da die Merkzeichen in vielen Fällen vermutlich gar nicht relevant sind und daher als ignorierbare Details ganz gut aufgehoben wären, wo hingegen der Grad der Behinderung die eigentlich relevante Aussage ist, die in den meisten Fällen benötigt wird.
Mareike Przysucha (Jun 17 2021 at 12:49):
Die Frage ist aus meiner Sicht gerade an die Community: Wer außer dem von Simone angedeuteten Projekt benötigt die Merkzeichen?
Wenn der Bedarf größer ist, würde ich Variante B bevorzugen, wenn die sonst kaum jemand benötigt, wäre ich bei Simones Extensions.
Mareike Przysucha (Jun 17 2021 at 12:49):
@Simone: Wir haben parallel geschrieben...
Simone Heckmann (Jun 17 2021 at 12:50):
Mareike Przysucha said:
Ich habe gerade gelesen, dass der Grad der Behinderung NICHT in % angegeben wird, sondern einfach als Zehnerzahl zwischen 20 und 100 (also wie oben beschrieben, nur ohne %).
Ist das % hier nicht implizit. Man spricht ja Umgangssprachlich immer von "50%iger Behinderung", nicht von "50er Behinderung"...?
Simone Heckmann (Jun 17 2021 at 12:51):
@Mareike Przysucha ; d'Accord: Wenn davon auszugehen ist, dass alle/die meisten, die sich für den Grad der Behinderung interessieren auch für die Merkzeichen interessieren, dann B, sonst C
Mareike Przysucha (Jun 17 2021 at 12:51):
Stimmt, da gebe ich Dir recht. Wir müssen nur darauf achten, das richtig zu formulieren.
Simone Heckmann (Jun 17 2021 at 12:52):
Frage ans TC Terminologien (@Elisabeth Pantazoglou, @Patrick Werner ): Mögt ihr euch schon mal Gedanken über die Terminologie für die Merkzeichen machen ( Herausgeber, Canonical, Codes...)
Simone Heckmann (Jun 18 2021 at 12:32):
Gerade gefunden: https://mio.kbv.de/display/INK/Condition_Disability_Free
Leider ist der Simplifier-Link offenbar noch nicht freigeschaltet...
Simone Heckmann (Jun 21 2021 at 14:29):
Das Profil ist jetzt freigeschaltet: https://simplifier.net/pku/kbvprmiopsconditiondisabilityfree
Kommt es mir nur so vor, oder ist der SNOMED-Code in Condition.category unnötig kompliziert...?
code: 246464006:704326004=21134002
display: Function (observable entity) : Precondition (attribute) = Disability (finding)
Simone Heckmann (Jun 21 2021 at 14:31):
version: http://snomed.info/sct/900000000000207008/version/20210131
...als Pflichtfeld...
Mareike Przysucha (Jun 21 2021 at 14:48):
kann man das nicht eleganter umschreiben bzw. braucht es die category?
Für den Grad der Behinderung habe ich den Code 116149007 (Disability percentage (finding)) gefunden, den könnte man für den code nehmen.
Simone Heckmann (Jul 16 2021 at 12:48):
Ich bin der Ansicht, dass Condition hier falsch ist. Entweder ich gebe den GRAD der Behinderung an - das ist ganz klar eine Observation, da Code/Value-Paar - oder, ich benenne eine konkrete, die Behinderung verursachende Diagnose, das dann gerne als Condition, wobei sich hier dann aber die Frage aufdrängt, wozu dafür eine separates Condition-Profil erforderlich ist. Warum sollte sich eine solche Diagnose strukturell von einer gewöhnlichen (z.B. ICD-)Diagnose unterscheiden?
Simone Heckmann (Jul 16 2021 at 13:00):
Ich bin mir gerade unsicher, ob der fixed value der KBV auf Condition.category auf 21134002 ("Disability") kompatibel ist zu FHIR Core.
Condition.category ist 0..* CodeableConcept mit extensible Binding auf ein VS (problem-list-item | encounter-diagnosis)
Man könnte argumentieren, dass es sich um eine Extension des VS handelt, allerdings ist das Konzept "Disability" nicht disjunkt zu den vorhandenen Codes. Eine Diagnose würde sehr wahrscheinlich sowohl in die Kategorie "problem-list-item" als auch "Disability" fallen.
Ob die Argumentation "ja, aber category ist doch 0..*, das ist halt eine andere category als die in Core" erlaubt wäre, da bin ich mir gerade unsicher. :thinking:
Simone Heckmann (Jul 23 2021 at 14:16):
Ich kopiere hier mal der Übersicht wegen das Ergebnis des TC-Meetings von gestern rein:
Motion Behinderungsgrad:
Observation.code = SNOMED-Code 116149007 (Disability percentage (finding))
(Es erfolgt dazu noch Abstimmung mit TC Terminologien)
Observation.valueQuantity = 10-100 {percent}
Invariante, die prüft, dass nur Zehnerschritte zwischen 10 und 100 möglich sind
Observation.component.code enthält Binding auf die Deutschen Merkzeichen
Observation.component.valueBoolean (fixed=true) 0..1
ZUSÄTZLICH wird eine Empfehlung formuliert, wie die Merkzeichen auf https://www.hl7.org/fhir/v3/PersonDisabilityType/cs.html gemappt werden können (unsinnige Flags wie “Rundfunk/Fernsehen”, “1. Klasse” etc fallen ggf. raus) und in der Extension disability http://hl7.org/fhir/extension-patient-disability.html zu den Patientenstammdaten hinzugefügt werden können.
Vote: 8-0-0
siehe: Protokoll vom TC-Meeting am 22.7.2021
Simone Heckmann (Oct 01 2021 at 07:43):
...uuund wir haben die Antwort bezüglich der Frage nach Observation vs. finding:
https://chat.fhir.org/#narrow/stream/179202-terminology/topic/SNOMED.20findings.20in.20Observation.2Ecode
Mareike Przysucha (Oct 13 2021 at 12:53):
Ich überarbeite gerade den ersten Entwurf.
@Alexander Zautke: Deinen zweiten Slice-Vorschlag kann ich gerade nicht verorten: Willst Du die % slicen oder die Component. Letzteres würde nämlich keinen Sinn ergeben... Bin daher minimal verwirrt und freue mich über eine kurze Rückmeldung. Danke Dir.
Alexander Zautke (Oct 13 2021 at 13:03):
Der Kommentar bezog sich auf das Slicing der Component. Wieso würde das keinen Sinn ergeben?
Mareike Przysucha (Oct 13 2021 at 14:20):
Vllt. unglücklich ausgedrückt. Ich würde vielleicht eher den Code bei der Composition slicen und nicht die Composition selbst.
Mareike Przysucha (Oct 13 2021 at 14:30):
Die Frage ist ja, welche Components außer den Merkzeichen wollen wir vorsehen?
Alexander Zautke (Oct 13 2021 at 14:51):
Weiß nicht aber vielleicht hat ein abgeleitetes Profil einen Use Case den wir ansonsten so blockieren würden
Mareike Przysucha (Oct 13 2021 at 15:00):
wie sehen die anderen das?
Mareike Przysucha (Oct 13 2021 at 15:32):
Der Entwurf kann hier eingesehen werden: https://simplifier.net/mareikestestwiese/gradderbehinderung.
Patrick Werner (Oct 14 2021 at 09:38):
Finde slicing auf component gut, ermöglicht downstream use-cases.
Mareike Przysucha (Nov 02 2021 at 07:33):
Hallo zusammen,
aufbauend auf der Diskussion letzten Donnerstag habe ich eine neue Version erstellt.
Über Kommentare freue ich mich hier im Forum bis Donnerstag Abend (gerne auch vom TC Terminologien, @Elisabeth Pantazoglou , @Patrick Werner), ansonsten kommt der geänderte PullRequest am Freitag.
Danke für die konstruktive Diskussion!
Patrick Werner (Nov 03 2021 at 09:12):
finde ich gut. .code muss man nicht unbedingt slicen, ein pattern ohne slicing ohne code hätte hier denselben Effekt. Aber das ist nur eine Stilfrage. Und sieht jeder etwas anders.
Stefan Lang (Nov 03 2021 at 09:51):
Will man evtl. auch ausdrücken, wenn der GdB nicht vorhanden ist? In diesem Fall value[x] auf 0..1, da es in der Observation ja ein dataAbsentreason-Element gibt (und man eher nicht die Extension verwenden würde).
Stefan Lang (Nov 03 2021 at 09:52):
(und ggf. noch eine explizite Invariante valueInteger XOR dataAbsentReason)
Patrick Werner (Nov 03 2021 at 09:53):
Jopps, verstehe nicht wieso die invariant in der core spec so schwach ist
Patrick Werner (Nov 03 2021 at 09:53):
bzw or statt xoer
Patrick Werner (Nov 03 2021 at 09:53):
*xor
Stefan Lang (Nov 03 2021 at 09:53):
Eigentlich ein NOT ;-)
Mareike Przysucha (Nov 03 2021 at 09:55):
kann FHIR xor oder muss ich das anders formulieren (das bekomme ich dann schon hin).
Stefan Lang (Nov 03 2021 at 09:56):
Yep, XOR gibt's
Mareike Przysucha (Dec 16 2021 at 15:42):
Hallo zusammen. Auch wenn es vermutlich eher zu #german/terminologien gehört, passt es hier gut:
Wir wurden gebeten, für das zugehörige Codesystem eine OID zu beantragen. Das Profil und die Terminologien sind nun auf Simplifier verfügbar, die Seite für den Antrag beim BfArM ist aber aktuell nicht verfügbar. Eine Anfrage an die oid-Registierung beim BfArM ist versendet. Je nachdem, wann die Seite wieder verfügbar ist, reiche ich den Antrag schnellstmöglich ein (@Francois Peverali, @Luise Oeppert).
Last updated: Apr 12 2022 at 19:14 UTC
