Auf Observations, in denen nur ein Code und ein ValueString angegeben werden dürfen, bieten keinen Mehrwert gegenüber der direkten Einbettung der jeweiligen Inhalte in Composition.section.code und Composition.section.text.
Letzteres würde die Implementierung jedoch erheblich vereinfachen und das Gesamtvolumen und die Komplexität des Dokumentes reduzieren.

Wenn es einen UseCase gibt, in dem eine Loslösung einzelner textueller Beobachtungen aus dem Entlassbrief und eine maschinelle (!!) Weiterverarbeitung, unabhängig von dem Quelldokument angedacht ist, dann sollte dieser ausführlich umschrieben sein, um den Mehraufwand bei der Implementierung zu rechtfertigen.

Beispiele: <span class="nobr"><a href="https://simplifier.net/packages/kbv.mio.kh-entlassbrief/1.0.0-kommentierung/files/769358" class="external-link" rel="nofollow">https://simplifier.net/packages/kbv.mio.kh-entlassbrief/1.0.0-kommentierung/files/769358^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> <span class="nobr"><a href="https://simplifier.net/packages/kbv.mio.kh-entlassbrief/1.0.0-kommentierung/files/769333" class="external-link" rel="nofollow">https://simplifier.net/packages/kbv.mio.kh-entlassbrief/1.0.0-kommentierung/files/769333^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

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 KH-Entlassbrief-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 Hersteller offen gestellt werden. Insbesondere, da nicht davon ausgegangen werden darf, dass diese Daten ausschließlich im Kontext des Entlassbriefes genutzt werden.

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!

Siehe <span class="nobr"><a href="https://build.fhir.org/ig/FHIR/ig-guidance/best-practice.html#profiles" class="external-link" rel="nofollow">https://build.fhir.org/ig/FHIR/ig-guidance/best-practice.html#profiles^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Die Darstellung von MIOs im Allgemeinen und Entlassbriefen 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 Entlassbriefes vollständig maschinell weiterzuverarbeiten (wozu auch?).
Realistischer wäre ein Mischbetrieb, in dem für die Weiterbehalndlung relevante, homogene Informationen (z.B. Vitaldaten, Medikation, Diagnosen) importiert werden können, der Rest des Dokumentes aber nur Betrachtet bzw. unstrukturiert übernommen werden kann. Dazu wäre besonders hilfreich für die Implementierung, wenn die einzelnen Sections des Briefes ü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 Entlassbrief-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 der Entlassbrief-Spezifikationen HTML-Templates und -Tools publiziert werden sollten, die es den Herstellern ermöglichen, einheitliche Repräsentationen ihrer Daten zu erzeugen.