Kommentierungsüberblick

Die codierte Darstellung einer dimensionslosen Einheit in UCUM sollte "1" lauten, nicht "{score}". Die Curly-Brace-Notation in UCUM wird nur genutzt, wo eine menschenlesbare Darstellung der dimensionslosen Einheit benötigt wird. Dafür gibt es im FHIR-Datentyp Quantity jedoch ein separates Feld: Quantity.unit

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^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

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.

Die Darstellung von MIOs im Allgemeinen und DiGa-Exporten im Besonderen stellt Entwickler komsumierender Software aufgrund von deren Komplexität und Vielfältigkeit vor enorme Herausforderungen. In den meisten UseCases wäre jedoch die menschenlesbare Darstellung der Informationen völlig ausreichend. Es ist davon auszugehen, dass konsumierende Systeme, wie z.B. PVSse oder Patienten-Apps niemals in der Lage sein werden, den Inhalt eines DiGa-Exportes <strong>vollständig</strong> maschinell weiterzuverarbeiten.

Realistischer wäre ein Mischbetrieb, in dem relevante, homogene Informationen (z.B. Vitaldaten, Medikation, Diagnosen) importiert werden können, der Rest des Exportes aber nur Betrachtet bzw. unstrukturiert übernommen werden kann.

Dazu wäre besonders hilfreich für die Implementierung, wenn einzelne Sections des Exportes über einen Narrative verfügen, um Daten, die nicht maschinell verarbeitet werden können/müssen, einfach und sicher darstellbar zu machen.

Diesen Zweck erfüllt in FHIR Composition.section.text, ein Element, dass in der DiGa-Profilierung jedoch verboten worden ist.

Es sollte geprüft werden, ob Composition.section.text nicht zu einem unablässigen Pflichtfeld erklärt werden müsste und gemeinsam mit den DiGa-Spezifikationen HTML-Templates publiziert werden sollten, die es den DiGA-Herstellern ermöglichen, einheitliche Repräsentationen ihrer Daten zu erzeugen.

Warum wird hier eine proprietäre Extension "Betrachtungszeitraum" verwendet, wenn es ein Core-Element gibt, das semantisch äquivalent ist:
Composition.event.period: The period covered by the documentation

Dieser Kommentar betrifft ALLE Profile dieser und anderer MIO-Spezifikationen:

Das Constrainen von meta.profile (fixed value, 1..1) verstößt gegen best practice-Empfehlungen in FHIR. Es muss immer davon ausgegangen werden, dass Ressourcen gegen mehrere Profile gleichzeitig valide sind und auch sein müssen, da sie nicht einem einzigen UseCase dienen. Zum Beispiel kann eine DiGa-Observation mit einem Vitalparameter zwar einerzeits einem KBV-Profil entsprechen, aber idealerweise ist sie auch kompatibel mit dem entsprechenden Deutschen Basisprofil, dem ISiK-Profil und den internationalen VitalSigns. Eine solche Kompatibilität herbeizuführen, zu prüfen und auszuweisen, muss jedem DiGa-Hersteller offen gestellt werden. Insbesondere, da nicht davon ausgegangen werden darf, dass diese Daten ausschließlich im Kontext von Deutschen DiGa-Exporten genutzt werden. Hersteller agieren mitunter international, oder möchten vielleicht auch Export-Funktionen für andere Zwecke bereitstellen.

Die Festlegung, dass alle Ressourcen die KBV-Profil-URLs ausweisen müssen und gleichzeitig auf diese URLS beschränkt sind, schließt jegliche Interoperabilität mit anderen Festelegungen von vorne herein - by design - aus!

Um die Einschätzung und Interpretation des Punktwertes durch eine Person zu ermöglichen, die mit einem Scoring-System z.B. IBS-QOL nicht vertraut sind, sollten die Referenzbereiche und deren Bedeutung mit übermittelt werden. Die ist im DiGa-Profil jedoch nicht möglich, da die Kardinalität von Observation.referenceRange auf 0..1 begrenzt ist, IBS-QOL, jedoch beispielsweise 4 Punktwertbereiche von Sehr Mild, Mild ober Moderat bis hin zu Schwer definiert. Sollte hier dem Profil Observation_Free Vorzug gegeben werden, da dort die verwendung von Observation.ReferenceRange erlaubt ist, obgleich es sich um einen Score handelt, für den die KBV ein dediziertes Profil publiziert hat?

Für die Bewertung von Scores (z.B. Erzielte Punktwerte bei der Durchführung von Kontraktionsübungen) ist die Information zur bodySite (z.B. "Beckenboden") von hoher Relevanz, kann jedoch hier nicht abgebildet werden. Ebenso könnten Punktwerte für Kraft/Koordination/Ausdauer separat für die rechte und linke Körperhälfte erhoben werden und müssten über bodySite unterschieden werden.

Hier bleibt nur die Möglichkeit, das ganze in den SNOMED-Code für Observation.code per Postkoordination hineinzudrücken, was die Komplexität für die Interpretation und Auswertung der Informationen erheblich erhöht.

Scores können sowohl therapeutisch als auch diagnostisch sein, oder (insbesondere im Kontext einer DiGa) auch einfach nur Aktivitäten bewerten. Mit dem Verbot der Verwendung von Observation.category (warum überhaupt?!) fehlt ein wichtiges Unterscheidungsmerkmal für die Kategorisierung verschiedener Scores.

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^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</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.