Hier können Hinweise, die im Rahmen der Softwareumsetzung hilfreich sein können, hinterlegt werden. Sie richten sich dementsprechend an die Softwarehersteller. Operationalisierunghinweise müssen sinnvoll, zweckmäßig und im gesetzlichen Rahmen angesiedelt sein.

Derzeit sind folgende übergreifende Operationalisierungshinweise zum MIO vorgesehen:


Verwendung von Fragebögen:

Der Abschnitt Fragebögen sollte nur zur Abbildung von strukturierten Fragebögen verwendet werden, die eine Gesamtauswertung (wie z.B. einen Score) als Ergebnis haben. Der Abschnitt soll nicht verwendet werden, um einzelne Informationen zu erfassen, für die im MIO entsprechende Profile definiert wurden (z.B. Vitalparameter: Blutdruck).

Beispiele:

  • ✅ Der DASS (Depression Anxiety and Stress Scale) soll als Fragebogen abgebildet werden, da die erhobenen Werte genutzt werden, um verschiedene Scores als Gesamtauswertungen zu berechnen. Die versorgungsrelevanten Informationen Information sind die Scores, die als eigene Profile abgebildet werden und die den Fragebogen als Ableitungsquelle referenzieren können.
  • ❎ Die Erhebung der Blutdruckanamnese der letzten Woche soll als individuelle Blutdruckmessungen abgebildet werden, da hier die versorgungsrelevanten Informationen die Blutdrücke sind und diese auch in dem entsprechenden Profil abgebildet sein sollten, um weiter verwendet werden zu können.


Freie Profile:

Um möglichst viele Anwendungsfälle abzudecken, werden im MIO freie Profile genutzt, die keine Bindung an ein ValueSet haben und somit die Auswahl eines beliebigen Codes erlauben. Sofern für ein freies Profil ein Wert mit einem SNOMED CT®-Code repräsentiert werden kann, soll dieser auch verwendet werden. Perspektivisch werden im Kontext der MIO-Fortschreibung für häufig und zwischen DiGA gemeinsam genutzten Elemente ValueSets erstellt, um die Interoperabilität zu erhöhen und sicherzustellen, dass für gleiche Datenmodell-Elemente auch gleiche Codes verwendet werden.

Beispiele:

  • SNOMED CT® hat keinen Code für "Schachspielen", dieser könnte jedoch eine Aktivität sein, die im Rahmen einer DiGA-Anamnese erhoben wird. Durch das freie Profil "Aktivität" ist es trotzdem möglich, "Schachspielen" mit einem anderen Code aus einem anderen Code-System oder gegebenenfalls auch einem Freitext abzubilden.
  • "Pneumonie" könnte theoretisch über den MEDCIN Code "91983" ( pneumonia (diagnosis)) abgebildet werden. Die Codierung sollte jedoch in SNOMED CT® erfolgen, um die Interoperabilität zu erhöhen. In diesem Fall wäre die Verwendung des Codes "233604007" (Pneumonia (disorder)) zu empfehlen.


Profile mit untergeordneten Profilen:

Um möglichst viele Anwendungsfälle abzudecken, wurden Profile generisch und offen gestaltet, um zusammengehörige Informationen zu kategorisieren.

Beispiele:

  • Das Profil "Lebensstilfaktor - frei" könnte genutzt werden, um den Lebensstilfaktor "Rauchen" abzubilden. Um Informationen abzubilden, wie beispielsweise die Anzahl der "pack-years", wird das Profil "Ergebnis" genutzt. Dieses Profil gehört zu den sogenannten Referenz-Elementen. Hier würde der Code für die Anzahl der "pack-years" gemeinsam mit dem Messwert, der die Anzahl und die Einheit enthält, angegeben werden. Die Instanz des Profils "Ergebnis" wird dann im ausdefinierten Profil für "Rauchen" als Element referenziert.


Darstellung von Codes:

Ein Element mit dem Type Code entspricht einer Information, die durch einen definierten Code aus einem Code-System ausgedrückt wird. Verwendbare Codes können ggf. durch Wertelisten (sog. ValueSets) eingeschränkt sein. Bei der Verwendung dieses Datentyps wird in der Regel der Code, die Bedeutung (das Konzept) in Form eines Wiedergabenamens sowie das entsprechende Code-System angegeben.


Business Identifier:

Um die eindeutige Zuordnung der Profile zu ermöglichen, muss jeder Instanz eines Profils eine eindeutige UUID zugewiesen werden. Somit können beispielsweise länger bestehende Probleme oder Therapiepläne, die fortlaufend aktualisiert werden, korrekt identifiziert und zugeordnet werden.


Herkunftsdaten:

Jede Instanz eines Profils muss von mindestens einer Herkunftsdaten-Instanz (FHIR-Provenance) referenziert werden um festzuhalten wer an Erstellung oder Aktualisierung beteiligt, beziehungsweise verantwortlich war.




Kommentierungen

    • Key

    • DIGA1X0X0-67

    • Erstellt

    • 12.12.2021

    • Name

    • Jörg Caumanns

    • Organisation

    • fbeta GmbH

    • Zusammenfassung

    • Datenspende für die Forschung

    • Beschreibung

    • Ist sichergestellt, dass die Datenelemente klar erkennbar sind, in denen - z. B. durch Selbstangaben des Patienten - potenziell personenidentifizierende Daten enthalten sind, die bei einer Datenspende maskiert werden müssen?

    • Key

    • DIGA1X0X0-38

    • Erstellt

    • 08.12.2021

    • Name

    • Marvin Franke

    • Organisation

    • HelloBetter

    • Zusammenfassung

    • Anregung für Export-Test

    • Beschreibung

    • Keine inhaltliche Rückmeldung zur spezifischen Seite, sondern generell zur Operationalisierung der Einbindung.

      Um einen möglichst reibungslosen Export bei allen DiGA-Anbietern zu ermöglichen, wäre die Bereitstellung einer Art "MIO-Viewers" ein nützliches Tool. So könnten Beispielexports der Hersteller erstellt werden und über das Viewer-Tool wieder eingeladen und betrachtet (analog wie ein Behandler die Daten sehen würde). So könnte schon Hersteller-intern sichergestellt werden, dass alle Angaben so im Zielsystem erscheinen, wie angedacht.
      Eine inhaltliche Prüfung der Richtigkeit eines Exports durch eine externe Prüfstelle ist zwar durchaus möglich, aber eine Hersteller-interne Preview könnte den Prozess und das debuggen vereinfachen.

      Gleichzeitig wäre die Bereitstellung von Beispiel-Exports zum DiGA-Import hilfreich, um sicherzustellen, dass die Informationen so eingeladen werden können, wie erwünscht.