Stream: german (d-a-ch)
Topic: Körpergewicht
Simone Heckmann (Jul 22 2018 at 18:47):
Frage: Warum haben wir ein Profil für Körpergewicht in den deutschen Basisprofilen, das die Maßeinheit auf "kg" festlegt?
Ich finde es logisch, dass wir lbs etc. in Deutschland ausschließen, aber werden Säuglinge nicht üblicherweise in Gramm gewogen?
Simone Heckmann (Jul 22 2018 at 18:47):
https://simplifier.net/basisprofilde/observation-de-koerpergewicht-0.2
Stefan Lang (Jul 22 2018 at 19:19):
Das war die Rückleitung aus dem MPPlus-Profil, das auf kg festlegt.
Gramm könnte für's Basisprofil aber sinnvoll sein (müssen wir halt ein ValueSet erstellen) => bitte Github-Issue
Simone Heckmann (Jul 22 2018 at 19:28):
Done: https://github.com/hl7germany/basisprofil-de/issues/101
Die MPP-Constraints sollten für uns nicht maßgeblich sein. weshalb ich auch dafür votieren würde, vom internationalen Profile abzuleiten. was für den MPP bedeutet, dass er nicht vom deutschen Basisprofil ableiten kann, sondern ein eigenes Profil braucht.
Aber ich finde eine Gewichts-/Größenmessung ohne Angabe eines Datums (was im MPP möglich ist) sinnlos genug, um das nicht in die Basisprofile übernehmen zu wollen. (Zumal ein Datum in FHIR ja beliebig ungenau sein kann, zur Not reicht das Jahr)
Stefan Lang (Jul 22 2018 at 19:40):
In der Praxis kommen Gewichts- und Größenangaben ohne Datum leider durchaus vor. Die Sinnhaftigkeit sei dahin gestellt, aber es existiert.
Stefan Lang (Jul 22 2018 at 19:43):
Ein Ableiten der Observations von den Core-VitalSign-Profilen widerspricht außerdem unserem Paradigma, must-support nicht zu setzen. Das core-vitalsign-Profil hat fast alles auf must-support stehen. Vieles davon ist definitiv nicht in allen use cases relevant.
Christof Gessner (Jul 22 2018 at 19:48):
Hallo. Die Frage scheint mir zu sein: Ist in Deutschland eine Gewichtsangabe ohne Datum aus ärztlicher Sicht grundsätzlich wertlos? Wenn nicht, würde ich es weiteren Ableitungen überlassen, solche Verknüpfung verpflichtend zu machen, nicht der Basis.
Stefan Lang (Jul 22 2018 at 19:48):
+1
Stefan Lang (Jul 22 2018 at 19:51):
Die Angabe ist offenbar nicht immer sinnlos; immerhin haben sich ja auch beim BMP bzw. beim MPPlus Fachleute darüber Gedanken gemacht.
Und wie gesagt, ich habe das auch schon in anderen Kontexten ohne Datum gesehen.
Simone Heckmann (Jul 22 2018 at 19:59):
Ich wette Model-Agenturen sind da gewissenhafter als Hausärzte :D
Stefan Lang (Jul 22 2018 at 20:12):
Es kommt halt auf den Kontext an.
Bei Dialyse-Pat. ist sogar die Uhrzeit relevant, bzw. die Info "vor/nach Dialyse".
Chemo-Pat. werden normalerweise auch zu jedem Zyklus gewogen.
Für eine eigentlich qualitative Aussage ("Pat. ist zu fett") braucht es aber kein Datum - dieser Zustand ändert sich meist nicht so schnell ;)
Peter Scholz (Jul 23 2018 at 07:04):
Frage: Warum haben wir ein Profil für Körpergewicht in den deutschen Basisprofilen, das die Maßeinheit auf "kg" festlegt?
Ich finde es logisch, dass wir lbs etc. in Deutschland ausschließen, aber werden Säuglinge nicht üblicherweise in Gramm gewogen?
Jetzt muss ich mal den Chemiker raushängen lassen
kg und g ist dasselbe nämlich g (kilo ist lediglich eine vorsilbe die den Faktor 10^3 repräsentiert) gleiches gilt bei m und cm (c=centi = 10^-2)
Simone Heckmann (Jul 23 2018 at 07:19):
1[g] und 1[kg] sind doch aber nicht das selbe!?
Stefan Lang (Jul 23 2018 at 07:21):
Ebent.
Solange FHIR noch nicht die Faktoren für die Zehnerpotenzen automatisch umrechnet, muss man es trotzdem separat betrachten ;)
Peter Scholz (Jul 23 2018 at 07:21):
das ist korrekt, aber die Einheit ist dieselbe d.h. 1kg ist nur eine andere Schreibweise für 1*10^3 g
von daher müssten alle SI Präfixe in einem profil erlaubt sein. d.h. es muss auch zulässig sein das Körpergewicht mit jedem beliebigen SI Präfix anzugeben alles andere wäre kompletter unsinn
Stefan Lang (Jul 23 2018 at 07:23):
Ich neige nicht dazu, Körpergewicht auch in µg für sinvoll zu halten ...
Peter Scholz (Jul 23 2018 at 07:24):
ob es sinnvoll ist oder nicht steht aber nicht zu Debatte. De Fakto ist alles unabhängig von der Präsentation gramm und somit zulässig
Peter Scholz (Jul 23 2018 at 07:36):
d.h. entweder man erzwingt die jeweilige SI Einheit (also g und m) und verbietet alles andere oder man erlaubt alle präfixe
Christof Gessner (Jul 23 2018 at 07:37):
Die Debatte ist nicht neu. Auch in lb und oz sind gramm, siehe https://en.m.wikipedia.org/wiki/International_yard_and_pound. LOINC zum Beispiel legt daher die Messgröße fest und überlässt die Wahl der Maßeinheiten den Anwendern. FHIR Datentypen trennen PQ in value und unit. So ists nun Standard.
Peter Scholz (Jul 23 2018 at 07:40):
das ist aber ein kleiner Unterschied englische Masseinheiten sind zwar umrechenbar aber keine präfixe
kilo, centi, mega , femto und konsorten sind kurzschreibungen für 10er Potenzen.
Also: noch einmal für alle:
g und kg sind die selbe Einheit nämlich Gramm.
Pfund, yard, inch, stone, meile sind eigene Einheiten
Stefan Lang (Jul 23 2018 at 07:42):
Das ist wissenschaftlich korrekt Peter. g, kg, µg, sind alles Vielfache von g.
g und lbs drücken beide Masse aus.
Stefan Lang (Jul 23 2018 at 07:43):
Wir wollen aber korrekt im Sinn der Praxis sein. Und da sind g und kg eben die verwendeten vollständigen Einheiten-Symbole für Masse, wenn es um Körpergewicht geht
Stefan Lang (Jul 23 2018 at 07:45):
Für das Core-VitalSign-Profil ist z.B. explizit folgendes ValueSet aus UCUM definiert: kg, [lb_av], g
=> https://www.hl7.org/fhir/valueset-ucum-bodyweight.html
Christof Gessner (Jul 23 2018 at 07:46):
Was brauchts also fürs Basisprofil? Zwei Regeln:
a) welche Messgrößen sind hier zulässig? [zB Masse, Volumen] und
b) welche vollständigen Einheitensymbole für Einheiten und deren Vielfache
Bestes Beispiel sind die RTMMS-Tabellen beim NIST, auch im Hinblick auf Patient Safety.
Peter Scholz (Jul 23 2018 at 07:47):
Mag sein, ist aber das festzurren von Unfug und erhöht nicht zwangsläufig die Interoperabilität
Stefan Lang (Jul 23 2018 at 07:47):
UCUM selbst führt generell die gebräuchlichen Einheiten mit Faktor (wie kg) als eigene EInheit auf:
http://www.fhir.org/guides/argonaut/r2/ValueSet-ucum.html
Peter Scholz (Jul 23 2018 at 07:48):
q.e.d
Christof Gessner (Jul 23 2018 at 07:48):
Regeln a und b sind jeweils optional im Profil einzubauen, müssen aber konsistent sein, falls beide da sind.
Christof Gessner (Jul 23 2018 at 07:50):
Bitte nicht die Regeln zur Definition eines Codes (“vollständiges Einheitensymbol”) verwechseln mit den Regeln für das Befüllen des Datenfelds “unit” in PQ. Nur letzteres ist Aufgabe des Profils.
Stefan Lang (Jul 23 2018 at 07:50):
Regel a wäre technisch nur als Extension abbildbar. Ich würde dazu tendieren, das bestenfalls in Form der Beschreibung
Stefan Lang (Jul 23 2018 at 07:50):
@Christof Gessner +1
Stefan Lang (Jul 23 2018 at 07:52):
Wobei, um genau zu bleiben: eigentlich geht es (in FHIR) um das Element "code". "unit" ist Freitext, also quasi der display name dazu.
Peter Scholz (Jul 23 2018 at 07:52):
deswegen ist die Lösung doch auch einfach: einzig erlaubter Code ist g wer was anderes in seiner Applikation möchte kann und muss umrechnen
Christof Gessner (Jul 23 2018 at 07:53):
“Festzurren von Unfug” ist manchmal der einzige Weg zur Interoperabilität. Nennt man dann ggf. “Standardisierung” ;-)
Christof Gessner (Jul 23 2018 at 07:54):
Für FHIR ja, @Stefan Lang , ich bin ins CDA-Land abgedriftet...
Stefan Lang (Jul 23 2018 at 07:55):
@Christof Gessner Schon klar. Wollte es nur kurz erwähnen - unit vs. code ist in FHIR etwas unglücklich benannt, jeder will erstmal den Code für die Einheit nach "unit" schreiben ;-)
Christof Gessner (Jul 23 2018 at 07:56):
@Peter Scholz dann folgt bloß die nächste Diskussion: SI Basiseinheit für Masse ist....??? Aha!
Stefan Lang (Jul 23 2018 at 07:56):
"kg-m-s" :joy:
Christof Gessner (Jul 23 2018 at 07:57):
SI also auch wieder festgezurrter Unsinn. Funktioniert aber seit m-zig Jahren ganz gut.
Peter Scholz (Jul 23 2018 at 07:58):
autsch, erwischt ... Scheisse ziemlich inkonsistent
Peter Scholz (Jul 23 2018 at 07:58):
dafür gehört in der Tat jemand gesteinigt
Peter Scholz (Jul 23 2018 at 07:59):
ist dann die tonne ein Mg oder doch ein kkg ?
Stefan Lang (Jul 23 2018 at 08:00):
Mg. Das ist irgendwo erläutert
Peter Scholz (Jul 23 2018 at 08:00):
und wäre dann ein gramm ein mkg ?
Stefan Lang (Jul 23 2018 at 08:00):
Ein guter Parser für Einheiten würde das wahrscheinlich sogar verarbeiten können ;-)
Peter Scholz (Jul 23 2018 at 08:01):
nicht hier:
https://www.ptb.de/cms/fileadmin/internet/publikationen/broschueren/Einheiten_deutsch.pdf
Stefan Lang (Jul 23 2018 at 08:05):
Ich suche jetzt nicht raus, wo ich das vor n Jahren mal gefunden habe :-)
Peter Scholz (Jul 23 2018 at 08:06):
aber ob der Mists bei kg geb ich mich geschlagen ;)
Christof Gessner (Jul 23 2018 at 08:12):
Überlassen wir's also den UCUM- SNOMED- LOINC- ICD10-Parsern, innerhalb der Codesysteme herumzurechnen. Und beschränken uns in Basisprofilen auf use-case-offene Value Sets mit prä-koordinierten "vollständigen Symbolen". Deal?
Simone Heckmann (Jul 23 2018 at 08:16):
...heißt: g oder kg für Körpergewicht? Sagichdochdieganzezeit :D
Peter Scholz (Jul 23 2018 at 08:18):
@Simone Heckmann : dann in drei Teufels namen beides, denn beides ist übliche Praxis.
Stefan Lang (Jul 23 2018 at 08:18):
Gut, dass wir immer mal drüber reden :joy:
Christof Gessner (Jul 23 2018 at 10:05):
Noch ein Hinweis: Bei unserer Basisprofilierung sollten wir auch die Value Sets in RTMMS beachten (von IHE PCD gepflegt). Dazu gibt es ein ziemlich vollständiges LOINC-Mapping auch als Teil der LOINC-Distribution. Separat auch hier https://loinc.org/downloads/accessory-files/ als "LOINC/IEEE Medical Device Code Mapping Table". Für LOINC:29463-7 findet sich dort "kg g [lb_av] [oz_av]" - Unsere Wahl "kg g" passt dazu, weil echte Untermenge.
Ich schlage vor, diese Überprüfung bei allen Observations durchzuführen, die mit LOINC codiert sind und ggf. von Geräten bereitgestellt werden könnten.
Patrick Werner (Jul 25 2018 at 10:57):
Ein guter Parser für Einheiten würde das wahrscheinlich sogar verarbeiten können ;-)
https://github.com/FHIR/Ucum-java
Christof Gessner (Jul 25 2018 at 18:31):
Ist auf jeden Fall nützlich, um Value Sets auf korrekte UCUM Codes zu prüfen. Auch zum Verifizieren von Implementierungen. Und natürlich für Auswertung von Forschungsdaten Bevor ich sowas aber realtime in der Patientenversorgung einsetze, würde ich eine sehr gründliche Risikoanalyse vorschalten!
Stefan Lang (Jul 25 2018 at 19:28):
Hm, ja, die Konversion dürfte schon ins MPG fallen. Also nicht nur Risikoanalyse, sondern insgesamt nur im validierten und qualitätsgesicherten Entwicklungsprozess ...
dr Kai U. Heitmann (Aug 06 2018 at 16:17):
Die MPP-Constraints sollten für uns nicht maßgeblich sein. weshalb ich auch dafür votieren würde, vom internationalen Profile abzuleiten. was für den MPP bedeutet, dass er nicht vom deutschen Basisprofil ableiten kann, sondern ein eigenes Profil braucht.
Bei dem ganzen Rauschen auf diesem Stream weiß ich nicht was letztlich Ergebnis ist, aber der MPP SOLL ein sauberes Constraint auf das DE Basisprofil sein.
Christof Gessner (Aug 06 2018 at 17:21):
Ich habe die Entscheidung so gelesen: g oder kg für Körpergewicht in den Basisprofilen. Und Datum ist optional. Außerdem blieb mein Rat, sich an RTMMS zu orientieren bisher unwidersprochen.
Stefan Lang (Aug 07 2018 at 07:49):
Exakt, Christof. Hier nochmal das GitHub-Issue: https://github.com/hl7germany/basisprofil-de/issues/101
Und generell für Observations gesprochen: RTMMS enthält leider nicht für alle denkbaren quantitativen Observations Angaben, aber wo etwas existiert, sollte es natürlich berücksichtigt werden.
Last updated: Apr 12 2022 at 19:14 UTC
