Diese Seite soll nur einen ersten Überblick verschaffen. Die FHIR®-Ressourcen können im Detail unter der unten stehenden Verlinkung eingesehen werden.

Kurzbeschreibung

Dieses Profil bildet eine Bewertungsskala ab. Die im FHIR®-Profil abgebildete Information findet sich im Informationsmodell unter 2.14.5.2 Bewertungsskala, 2.19.5.2 Bewertungsskala, 2.25.9.2 Bewertungsskala, 2.29.5.2 Bewertungsskala, 2.7 Bewertungsskala, 2.7.1 Identifikator - UUID, 2.7.1.1 System, 2.7.1.2 UUID, 2.7.10 Wertebereich, 2.7.10.1 Minimum, 2.7.10.2 Maximum, 2.7.10.3 Einheit, 2.7.10.4 Typ, 2.7.11 Zeitpunkt, 2.7.2 Code/Bezeichnung, 2.7.2.1 Code-Auswahl, 2.7.2.2 Freitext Bezeichnung, 2.7.3 Skalenniveau, 2.7.4 Ergebnis, 2.7.4.1 Wert, 2.7.5 Methode, 2.7.6 Interpretation, 2.7.9 Teil von und 3.9.2 Bewertungsskala.

Bezeichnung der FHIR®-Ressource

Der FHIR®-Identifikator der FHIR®-Ressource lautet:

https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_DIGA_Observation_Assessment_Scale

Die Ressource kann auf Simplifier.net unter folgendem Link eingesehen werden:

Übersichtsabbildung des Profils





Kommentierungen

    • Key

    • DIGA1X1X0-14

    • Erstellt

    • 16.10.2022

    • Name

    • Simone Heckmann

    • Organisation

    • HL7 Deutschland e.V.

    • Zusammenfassung

    • Der Anzeigetext einer Skala sollte nicht "1" lauten. Die Codierte Einheit darf nicht fixiert werden.

    • Beschreibung

    • Quantity.unit dient dazu, neben der codierten Darstellung einer Maßeinheit zusätzlich auch einen menschenlesbaren Anzeigetext darzustellen, der unmittelbar zur Visualisierung einer Quantity in der UI verwendet werden kann.

      Hier wurde der Wert auf "1" gesetzt. Hier sollte eine sinnvollere Repräsentation der Einheit (z.B. "Punkte" oder "%") gewählt werden.

      "12 %" bzw. "12 Punkte" ist für den menschlichen Benutzer verständlich, "12 1" hingegen nicht.

      Weiterhin ist zu beachten, dass die Maßeinheit einer quantitativen Skala (z.b. die metrische Skala, Temperatur) keineswegs als <strong>fix</strong> angesehen werden kann.
      Eventuell wurden hier die Konzepte von Quantitativen und Scores verwechselt?

      Bitte die Best Practice Empfehlungen von HL7 DE beachten: <span class="nobr"><a href="https://docs.google.com/document/d/1_Tyfqwk_g8nAowoGOhqPqtGuOwg-K9zc_I6s2GRh8pw" class="external-link" rel="nofollow">https://docs.google.com/document/d/1_Tyfqwk_g8nAowoGOhqPqtGuOwg-K9zc_I6s2GRh8pw<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>

    • Key

    • DIGA1X1X0-13

    • Erstellt

    • 16.10.2022

    • Name

    • Simone Heckmann

    • Organisation

    • HL7 Deutschland e.V.

    • Zusammenfassung

    • Auf postkoordinierte SNOMED Codes sollte - wo möglich - verzichtet werden

    • Beschreibung

    • Observation.category ist auf gefixed auf "Assessment score (observable entity):Scale type (attribute)=Quantitative (qualifier value)".
      Die Verwendung von postkoordinierten SNOMED Codes sollte mehr als eine theoretische Überlegung zur erweiterten Nutzung von SNOMED angesehen werden, weniger als ein praktisches Werkzeug. Es gibt kaum Tools, die in der Lage sind, postkoordinierte Codes zu erzeugen, zu validieren, oder über die FHIR API partiell zu suchen. Postkoordination wird in der Praxis kaum bis gar nicht genutzt. Die Verwendung solcher Codes stellt die Implementierer vor enorme Herausforderungen.
      Dies wäre höchstens vertretbar, wenn es semantisch zwingend erforderlich wäre. Das ist hier aber nicht der Fall. Die Tatsache, dass es sich hier um eine Quantitative Skala handelt, ergibt sich aus dem Datentyp von Observation.valueQuantity. Dies in die Kategorie hineinzufalten ist semantisch redundant. Hier sollte zugunsten der einfachen Verständlichkeit und Implementierbarkeit auf unnötige Komplexität verzichtet werden.

    • Key

    • DIGA1X1X0-3

    • Erstellt

    • 05.10.2022

    • Name

    • Simone Heckmann

    • Organisation

    • HL7 Deutschland e.V.

    • Zusammenfassung

    • Profil nicht zur Abbildung von Ordinalskalen geeignet

    • Beschreibung

    • Das Profil AssessmentScale der KBV ist ausschließlich zur Abbildung von Kardinalskalen geeignet (siehe SNOMED-Code in Observation.category), jedoch nicht für Ordinalskalen. Für Ordinalskalen ist der Datentyp "Quantity" ungeeignet, hier wird ein CodeableConcept benötigt. Siehe dazu Draft des TC FHIR von HL7 Deutschland mit Empfehlungen zum Umgang mit "Scores und Skalen" (<span class="nobr"><a href="https://docs.google.com/document/d/1_Tyfqwk_g8nAowoGOhqPqtGuOwg-K9zc_I6s2GRh8pw/edit#heading=h.p8ovjsrvkuvo" class="external-link" rel="nofollow">https://docs.google.com/document/d/1_Tyfqwk_g8nAowoGOhqPqtGuOwg-K9zc_I6s2GRh8pw/edit#heading=h.p8ovjsrvkuvo<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>)

      Bei AssesmentScore ist zwar die Möglichkeit gegeben, CodeableConcepts zu verwenden, dies steht jedoch den o.g. Empfehlungen des TCs entgegen. Außerdem passt die Definition von Score nicht zur verwendeten Ordinalskala.

      Es bleibt daher nur die Verwendung von Observation_Free, obgleich es sich um eine Skala handelt, für die von der KBV ein dediziertes Profil herausgegeben wurde.

      Es ist aus Sicht eines DiGa-Herstellers unklar, wie hier vorgegangen werden soll.