Nach Abschluss der Kommentierung und der Prüfung sowie Bewertung aller eingegangenen Kommentare ist hier ein Überblick zu den eingegangenen Kommentaren und den Bewertungsergebnissen einsehbar. Hier kann entnommen werden, an welchen Stellen Kommentar zu einer Überarbeitung des MIO oder zur Aufnahme von Operationalisierungsempfehlungen für die umsetzenden IT-Systeme geführt haben.
Das überarbeitete MIO wird im Rahmen der Benehmensherstellung dargestellt.
Inhalt
| Kommentarthema | Ergebnis |
|---|---|
Assessment_Score (Profil Score)
| Grundsätzliche Anmerkung: Nach Analyse aller eingegangenen Kommentare werden in der Benehmensversion die Profilelemente "Score" und "Bewertungsskala" durch das neue Profilelement "Score/Bewertung anhand einer Skala" zusammengefasst. Das neue Profilelement "Score/Bewertung anhand einer Skala" enthält die Gruppe "Wertebereich" mit angepasster Kardinalität (0..*). |
Assessment_Score (Profil Score)
| Grundsätzliche Anmerkung: Nach Analyse aller eingegangenen Kommentare werden in der Benehmensversion die Profilelemente "Score" und "Bewertungsskala" durch das neue Profilelement "Score/Bewertung anhand einer Skala" zusammengefasst. Das neue Profilelement "Score/Bewertung anhand einer Skala" enthält die Gruppe "Kategorie - Code/Bezeichnung" mit der Untergruppe "Code-Auswahl" sowie das Item "Freitext Bezeichnung". In der Gruppe "Code-Auswahl" ist die Verwendung des FHIR®-Valuesets Observation Category Codes oder die Verwendung eines beliebigen anderen Codes möglich. Alternativ kann die Kategorisierung eines Scores durch Angabe eines Freitextes erfolgen. |
Assessment_Scale (Profil Bewertungsskala)
| Grundsätzliche Anmerkung: Nach Analyse aller eingegangenen Kommentare werden in der Benehmensversion die Profilelemente "Score" und "Bewertungsskala" durch das neue Profilelement "Score/Bewertung anhand einer Skala" zusammengefasst. Das neue Profilelement "Score/Bewertung anhand einer Skala" enthält die Gruppe "Körperstelle - Code/Bezeichnung" mit der Untergruppe "Code-Auswahl" sowie das Item "Freitext Bezeichnung". In der Gruppe "Code-Auswahl" ist die Verwendung eines beliebigen Codes möglich. Alternativ kann die Körperstelle als Freitext angegeben werden. |
Codierung
| Kommentarthema | Ergebnis |
|---|---|
| Reduktion von postkoordinierten SNOMED-Codes | In der Benehmensversion ist das Profil "Assessment_Scale" entfernt. Dadurch gibt es an dieser Stelle kein Fixed Value mehr. Wir teilen Ihre Einschätzung, zurückhaltender mit postkoordinierten SNOMED CT®-Ausdrücken umzugehen und werden dies, sofern möglich, in anderen MIOs und für das MIO DiGA Toolkit berücksichtigen. |
| Code für UCUM-Einheit im Profil Assessment_Score | Die Profilelemente "Score" und "Bewertungsskala" werden durch das neue Profilelement "Score/Bewertung anhand einer Skala" in der Benehmensversion zusammengefasst. Dementsprechend wurden die Profile "Assessment_Scale" und "Assessment_Score" inklusive UCUM-Einheit entfernt. Für das neue, zusammengefügte Profil "Score/Bewertung anhand einer Skala" wird keine Einheit vorgegeben. |
| Code für UCUM-Einheit im Profil Assessment_Scale | Das Profil "Assessment_Scale" wurde entfernt. Dementsprechend auch der Fixed Value. Im neuen, zusammengefügten Profil Scores und Skalen wird keine Einheit vorgegeben. |
Technische Repräsentation
| Kommentarthema | Ergebnis |
|---|---|
| Profil nicht zur Abbildung von Ordinalskalen geeignet | Wir verstehen den Bedarf für Ordinal- und Nominalskalen. Im Rahmen der fachlichen Bearbeitung des "Profils Assessment_Scales" sowie "Assessment_Score" haben wir uns entschieden, diese Profile zusammenzulegen. Die Abbildung von "Scores und Skalen" wird künftig in einem offeneren Profil "Score/Bewertung anhand einer Skala" realisiert. Ein CodeableConcept als Ergebnis-Möglichkeit sowie auch ein quantitatives Ergebnis wurde in diesem Profil berücksichtigt. Das Potenzial für spezifischere Profile für Scores und Skalen bleibt perspektivisch erhalten. Wir sehen den Empfehlungen von HL7-DE für Scores und Skalen entgegen. |
| Extension statt Composition.event.period für Betrachtungszeitraum | Wir verstehen den Gedanken und haben in der Entwicklungsphase des MIO bereits die Nutzung des Composition.event.period-Elements untersucht. Jedoch ist das Composition.event-Element beschrieben als ein Element, welches Kontext und Verbindung zwischen der Composition und einer Event-Ressource herstellt. Das Composition.event.period-Element ist zwar als "Period of time covered by the documentation" beschrieben, jedoch weiterhin mit der Bedeutung "it documents events during this time". Somit drückt dieses Element unserer Ansicht nach nicht die gewünschte Semantik aus, sondern bezieht sich klar auf spezifische Events, während der Betrachtungszeitraum eine technische Entscheidung der Teilung aller Daten bei zu großer Datenmenge ermöglicht. |
| Narratives (HTML) für Abschnitte mit Composition.section.text | Wir sind uns bewusst, dass die Daten aus DiGA-Anwendungsfällen zu spezifisch und divers für eine übergreifende Auswertung auf einem gleich hohen Niveau durch anzeigende Systeme sind. Deshalb stehen wir bereits im Austausch mit Hersteller:innen nicht nur schreibender Systeme (DiGAs), sondern ebenfalls anzeigender Systeme. Diese setzen aktuell auf generischere Darstellungen, durch die aktuell noch keine komplexen Analysen ähnlich in DiGAs möglich sind, jedoch auch kein Informationsverlust entsteht. Durch das aktuell in der Bearbeitung stehende Krankenhauspflegeentlastungsgesetz (KHPflEG) erhält die mio42 voraussichtlich künftig den Auftrag, zusätzlich zu den MIO-Spezifikationen auch Vorschläge für Visualisierungen zu veröffentlichen. Mit dieser Thematik beschäftigen wir uns bereits jetzt. Zunächst fokussieren wir uns auf die im Gesetzesentwurf angeführten Beispiele für Technologien, beispielsweise Stylesheets. Diese hätten den Vorteil, einmalig von den Hersteller:innen hinterlegt werden zu können und nicht den Umfang aller MIO-Einträge zu erhöhen. Im Fall von lesenden Systemen, wie z.B. den PVS, könnten Stylesheets als rein anzeigende Lösung insbesondere im DiGA-Kontext zu einer vereinfachten Nutzung von DiGA-Daten im Behandlungsalltag führen. Wir planen diesen Fokus zunächst beizubehalten und sehen deshalb von einer Anpassung an dieser Stelle ab. Sobald zu den MIO-Visualisierungen weitere Informationen und Zeitpläne vorliegen, werden wir dazu transparent und öffentlich über die bekannten Kanäle informieren. |
| meta.profile darf nicht auf 1..1 constrained werden | Die von Ihnen beschriebenen Nutzungsszenarien können wir nachvollziehen und öffnen künftig die Angabe von "meta.profile" in unseren Profilen. Dafür haben wir ein offenes Slicing an "meta.profile" eingeführt, mit einem verpflichtenden Slice mit dem vorgegebenen Profil als Pattern. Somit müssen Nutzer:innen künftig mindestens das von uns hinterlegte Profil angeben, haben jedoch die Möglichkeit, weitere Profile, zu denen die Instanz konform ist, zu hinterlegen. |
