Seitenhistorie
...
| Kommentarthema | Ergebnis |
|---|---|
| Aus der Graphik und aus der FHIR-Repräsentation geht hervor, dass es sich bei dem Punkt "Lebensstilfaktoren" um einen Container für mehrere Beobachtungen handelt. Dies geht aus dem Text leider nicht hervor und könnte ggf. deutlicher herausgestellt werden. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist der Beschreibungstext geändert. Darüber hinaus ist ein Beispiel berücksichtigt, welches die Nutzung und Funktionsweise des Elements verdeutlicht. |
| Es wäre sinnvoll, Beispiele für Referenzierungen zu nutzen, um Sinn und Zweck zu verdeutlichen. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist der Beschreibungstext geändert. |
Nutzen des Profils Tagebucheintrag unklar. Um im Endeffekt nur das Wertepaar "Tagebucheintrag: <Freitext>" übertragen zu können, ist das Profil extrem komplex. | Vielen Dank für Ihren Kommentar! Das Profil "Tagebucheintrag" soll dazu dienen, verschiedene Profile zu bündeln. Dies ist eine Funktion, welche durch eine/n DiGA-HerstellerIn ausdrücklich gewünscht wurde. Zusätzlich zu der Patientennotiz ermöglicht das Profil die Referenzierung anderer Instanzen, um zum Beispiel auszudrücken, dass die Kopfschmerzsymptomatik am Morgen und die darauf folgende Medikamenteneinnahme in Verbindung stehen. |
| Reference Range sollte unbedingt erlaubt sein (bei exotischen Skalen sogar verpflichtend!?) | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist der Referenzbereich ergänzt. Aufgrund der vielen unterschiedlichen Nutzungsmöglichkeiten und -szenarien des Referenzbereiches ist dieser im Modell nicht verpflichtend vorgegeben. |
Unklar, was mit "Eintrag" gemeint ist. Registrierungsdatum auf Seiten des Herstellers, Erstellungsdatum des zu exportierenden Datensatzes etc. Der Begriff "Erstellungsdatum" könnte als Erstellungsdatum des Accounts beim jeweiligen DiGA-Anbieter missverstanden werden. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist der Beschreibungstext geändert, um die Verwendung des Elements zu präzisieren. |
Im Rahmen der DiGA-Behandlung ist eine Erfassung vielen Elementen nicht zwangsläufig notwendig. Durch Aktivierung mittels DiGA-sollte ohnhin bereits eine Verknüpfung im System zu den persönlichen Daten der Person in den Krankenkassensystem möglich sein.
"Wir empfehlen daher, vor Verabschiedung des MIO zu prüfen, ob aktuelle ePA-Systeme mit Identifikatoren anders als der KVNR umgehen können." | Vielen Dank für Ihren Kommentar! Da es nicht möglich ist, leere Instanzen zu erstellen, wurde entschieden, dass die Instanz für die Versicherte Person mindestens einen Identifikator enthalten muss. Im Sinne der Datensparsamkeit und Anforderungen von DiGA sind in der Benehmensversion alle weiteren Elemente der Versicherten Person als optional definiert. Der Beschreibungstext zur Versicherten Person ist in der Benehmensversion geändert und enthält unter anderem folgenden Hinweis: "Wir möchten (...) darauf hinweisen, dass für den Export in die ePA alle relevanten Anforderungen entsprechend des Gematik-Leitfadens zur Anbindung Digitaler Gesundheitsanwendungen an die elektronische Patientenakte zu erfüllen sind. Der Feature-Entwurf zur ePA-DiGA-Anbindung (Stand: 09.02.2022) kann unter nachfolgendem Link abgerufen werden: https://fachportal.gematik.de/fileadmin/Fachportal/Downloadcenter/Vorabveroeffentlichungen/VorabV_ePA_Maintenance_21.1/gemF_ePA_DiGA_Anbindung_V1.0.0_CC.pdf." |
| Die Strukturierung der Angaben zur Medikation ist anders als die in den bereits bestehenden Strukturen (BMP, eMP, NFD) und wie sie in der Patientenkurzakte (PKA ) vorgesehen ist. Warum wird bei den DiGA ein eigener Weg gewählt der ggf. Probleme bei der Übertragung der Daten in bereits bestehenden Strukturen erzeugen kann? | Vielen Dank für Ihren Kommentar! Primär orientieren sich alle Projekte an den KBV-Basis-Profilen, sofern Basisinhalte existieren, die die benötigten Angaben abbilden. Der Kommentierungsstand des DiGA Toolkits war mit der Basis-Version 1.1.3 verknüpft, die diese Informationen bisher nicht enthielt. In der Benehmensversion ist das MIO auf Basis 1.2.1 aktualisiert. Grundsätzlich ist zu berücksichtigen, dass sich die Anforderungen des DiGA Toolkits von bisherigen MIOs unterscheiden, da es sich hier nicht um primär ärztlich erstellte Inhalte handelt. |
| Wird es den DiGA-Herstellern ermöglicht, neben den unverarbeiteten Daten aus den einzelnen Sections auch eine Interpretation bzw. Aggregation in die ePA zu übertragen? Aufbereitete Daten mit einem Vorschlag zur Verwertung der Daten durch den Arzt unter Einbezug der Methodik der DiGA bieten aus unserer Sicht einen großen Mehrwert für die behandelnden Ärztinnen und Ärzte. | Vielen Dank für Ihren Kommentar! Die Darstellung und Auswertung von Inhalten aus der ePA liegen in Verantwortung der darstellenden Systeme. Eine Verarbeitung akkumulierter Daten ist im DiGA Toolkit nicht vorgesehen. Auch sind die Möglichkeiten, diese in FHIR abzubilden, eingeschränkt. Es ist natürlich möglich, dass DiGA-HerstellerInnen den darstellenden Systemen zur Aufbereitung der Daten Hilfestellungen zur Verfügung stellen. Hinweise hierzu nehmen wir gerne entgegen, um diese in den Operationalisierungshinweisen der Datenelemente zu berücksichtigen. |
| Insbesondere die Psychotherapie-DiGA nutzen oftmals Standard-Fragebögen, die zumindest teilweise auch eine OID haben (oder denen man eine geben könnte). Die sollte man referenzieren können, ohne dass man in solchen Fällen den ganzen Fragebogen umständlich als Questionnaire nachbilden muss. | Vielen Dank für Ihren Kommentar! Ein darstellendes System muss den Fragebogen abbilden. Dazu muss dieser in FHIR vorliegen, um die Informationen zur Darstellung zur Verfügung zu stellen. Allein durch die Angabe der URL oder einer OID hat das darstellende System keine Möglichkeit, auf diese wichtige Information in einem nutzbaren Format zuzugreifen. Die Quelle eines verwendeten Fragebogens ist jedoch eine wichtige Information. In der Benehmensversion ist das Element "URL", das die Angabe einer OID erlaubt, als optionales Datenelement ergänzt. |
| Verstehe ich das richtig, dass in der definierten Struktur nur die als untergeordnete Inhalte aufgeführten Vitaldaten erfasst werden können und dass für weitere Arten von Vitaldaten dann eine Extension angelegt werden muss? Falls de so ist, halte ich das für ziemlich unglücklich; Erweiterungen sollten innerhalb der definierten Struktur möglich sein. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist ein Profil zur Erfassung eines freien Ergebnisses unter dem Abschnitt Befunde/Ergebnisse ergänzt. Dieses Profil soll nur dann verwendet werden, wenn der gewünschte Wert nicht durch ein vorhandenes Profil, z.B. die Vitalparameter, abgebildet werden kann (s. dazu auch Operationalisierungshinweis im Element "Ergebnis"). |
| Die Kommunikation mit dem Patienten erfolgt in aller Regel via E-Mail, sodass die Erfassung der E-Mail Adresse in der DiGA höchstwahrscheinlich erfolgen wird. Aber warum sind die Angaben zu den Kontaktkanälen für die ePA relevant. Möglicherweise möchte der Patient, dass die DiGA selbst z.B. Ergebnisse aus der DiGA per E-Mail zur Verfügung stellt, aber seine/diese Kontaktdaten nicht in die ePA einstellen. Das würde dazu führen, das der Patient in der DiGA angeben müsste welche Daten in die ePA sollen/dürfen oder nicht. Das erscheint sehr unpraktisch. Die Angaben zu den Kontaktkanälen können auch nicht auf Aktualität verifiziert werden, so dass in der ePA nicht valide Daten eingestellt würden. | Vielen Dank für Ihren Kommentar! Die Angabe der Kontaktdaten ist optional. Daher ist die Erfassung sowie der Export dieser Informationen für eine DiGA auch nicht verpflichtend. |
| Die Angabe der bevorzugten Sprache liegt nicht zwingend in der DiGA vor. Die DiGA werden in aller Regel als Anzeigesprache nur ein paar wenige Sprachen unterstützen. Von der ausgewählten Anzeigesprache kann man aber nicht zuverlässig auf die "bevorzugte Sprache" schließen, so dass diese Angabe zur Übergabe an die ePA keinen verbindlichen Mehrwert bietet. | Vielen Dank für Ihren Kommentar! Die Angabe der bevorzugten Sprache ist optional. Daher muss die DiGA diese Informationen nicht verpflichtend exportieren, wenn diese nicht versorgungsrelevant im DiGA-Kontext erscheint. Mit dem Element "Sprachen" sind Sprachen gemeint, welche zur Kommunikation zwischen versicherter Person und behandelnder Person verwendet werden können. |
| Die Angaben zur Aktivität sind gekoppelt an die konkreten indikationsbezogenen DiGA-Inhalte, wie z.B. die Erfassung von Werten und Tätigkeiten im Sinne der DiGA. Es ist möglicherweise sinnvoll unabhängig von der aktiven Befüllung von Informationen in der DiGA auch dessen einzelne Nutzung (z.B. wie oft die DiGA gestartet/aufgerufen wurde, wie lange diese verwendet wurde, ...) zu erfassen und in der ePA strukturiert zur Verfügung zu stellenAngabe der bevorzugten Sprache liegt nicht zwingend in der DiGA vor. | Vielen Dank für Ihren Kommentar! Aus unserer Sicht handelt es sich hierbei um nicht unmittelbar versorgungsrelevante Daten für die versicherte und behandelnde Person. Die Angabe der bevorzugten Sprache ist optional. Daher muss die DiGA diese Informationen nicht verpflichtend exportieren, wenn diese nicht versorgungsrelevant im DiGA-Kontext erscheint. Mit dem Element "Sprachen" sind Sprachen gemeint, welche zur Kommunikation zwischen versicherter Person und behandelnder Person verwendet werden können. |
Zwei zusätzliche FHIR-Ressourcen für eine Einwilligungserklärung und für die Verschreibung der DiGA sind nötig. Jede DiGA muss von den Nutzern eine Zustimmung für das Verarbeiten der Daten holen. Der FHIR-Consent braucht dafür ein passendes Profil. Die DiGAs werden verschrieben und können dann bis zu drei Monaten genutzt werden. Aus dem definierten Profil muss ersichtlich sein | Vielen Dank für Ihren Kommentar! Aus unserer Sicht handelt es sich hierbei um nicht unmittelbar versorgungsrelevante Daten für die versicherte und behandelnde Person. |
| Ergänzung zum vorherigen Kommentar: Vitalwerte können aus anderen Werten berechnet/abgeleitet sein. FHIR sieht hierfür in der "Observation" das Element "derivedFrom" vor. Dieses ist im DiGA-MIO aber gestrichen. "derivedFrom" sollte für alle Observations zulässig sein, um angeleitete Werte darstellen zu können. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist ein Profil zur Erfassung eines freien Ergebnisses im Abschnitt Befunde/Ergebnisse ergänzt. Wie auch im Operationalisierungshinweis beschrieben, soll das freie Profil nur für solche Werte genutzt werden, welche nicht mittels der konkreten Profile abbildbar sind. |
| Die amtliche deutsche Erfassung des Geschlechts ist so in den internationalen Klassifikationen nicht vorgesehen. Im Sinne der einfachen internationalen Nutzbarkeit sollte hier auf eine allgemeinere Fassung zurückgegriffen werden, auch wenn sie nicht alle deutschen Möglichkeiten abbildet. | Vielen Dank für Ihren Kommentar! In den MIOs werden die Basisprofile der Kassenärztlichen Bundesvereinigung (KBV) verwendet. Das MIO DiGA Toolkit soll von den durch die KBV abgestimmten Profilen möglichst nicht abweichen. Das KBV-Basisprofil orientiert sich an der FHIR®-Ressource "Patient", in der das hinterlegte ValueSet eine verpflichtende Bindung hat. Darüber hinaus ist das DiGA Toolkit gemäß der gesetzlichen Vorgaben für den nationalen Anwendungsfall vorgesehen. |
| Die Angabe des „Performers“ ist in den referenzierten Sections als optionale Angabe (Kardinalität 0..1) gestaltet. Dies kann nach unserem Verständnis dazu führen, dass Informationen in der ePA vorgehalten werden, deren Ursprung nicht bekannt ist. Wir möchten daher anregen, die Angabe des „Performers“ verpflichtend zu gestalten, um insbesondere den behandelnden Personen (Ärztinnen, Ärzte, Psychotherapeutinnen, Psychotherapeuten) die Quelle der Information ersichtlich zu machen. | Vielen Dank für Ihren Kommentar! Generell ist die Kardinalität nur ein Teil der Vorgaben, die in der Implementierung des MIO DiGA-Toolkits berücksichtigt werden müssen. Daneben sollen auch die Operationalisierungshinweise beachtet werden. Hier ist angegeben, dass in FHIR alle Instanzen eines Profils von einer Herkunfts-Instanz referenziert werden sollen. Die Herkunfts-Instanz drückt aus, wer für die Erstellung beziehungsweise die Herkunft der Information verantwortlich ist. |
| Es muss möglich sein, über das DiGA-MIO Geräteeinstellungen (z. B. Konfguration einer Insulinpumpe) auszuspielen. Ich habe hierzu im MIO nichts gefunden, wo das hineinpassen würde. | Vielen Dank für Ihren Kommentar! Zum Zeitpunkt der Bedarfsermittlung für das DiGA Toolkit wurde kein Bedarf festgestellt, Geräteeinstellungen mittels MIO abzubilden. In der Bedarfsermittlung für die Fortschreibung des DiGA Tookits werden wir eine Berücksichtigung von Geräteeinstellungen prüfen und bei Versorgungsrelevanz eine Ergänzung in einer nächsten Version des MIO vorsehen. Das MIO ist nach § 355 Absatz 2a Satz 2 SGB V zum Ende jedes Kalenderhalbjahres fortzuschreiben. In der Benehmensversion dieses MIO ist ein Profil zur Erfassung eines freien Ergebnisses unter Befunde/Ergebnisse ergänzt. Das Profil könnte aktuell bereits zur Abbildung der Insulinpumpen-Konfiguration genutzt werden.der Insulinpumpen-Konfiguration genutzt werden. |
| Eine unstrukturierte Informationsabbildung, z.B. via PDF, sollte in der ePA möglich seinNeben der angestrebten rein strukturierten Abbildung der Informationen sollte auch die Möglichkeit einer unstrukturierten Informationsabbildung z.B. in Form von PDF-Dokumenten gegeben sein. Informationen/Werte können einzeln abgebildet werden, manche Werte werden durch gleichzeitige statt einzelner Betrachtung zu einer anderen Gesamtbewertung führen. Diese Gesamtbewertung kann durch strukturiert abgebildete Einzelwerte nicht übermittelt werden. Nicht jedes System ist in der Lage die strukturierten Informationen aus der ePA zu verarbeiten, einfach weil die Systeme nicht alle Einzelinformationen unterstützen. Wenn es dann nur darum geht die Informationen im Primärsystem zu visualisieren, dann wäre die Möglichkeit unstrukturiert Informationen in die ePA einzustellen hilfreich. | Vielen Dank für Ihren Kommentar! Gemäß § 6a Absatz 2 Digitale Gesundheitsanwendungen-Verordnung (DiGAV) ermöglichen digitale Gesundheitsanwendungen ab dem 01. Januar 2023 den Datenexport in die elektronische Patientenakte gemäß einer Festlegung für die semantische und syntaktische Interoperabilität von Daten der elektronischen Patientenakte nach § 355 Absatz 2a des Fünften Buches Sozialgesetzbuch. Demzufolge ist zukünftig vorgesehen, dass versorgungsrelevante Daten aus einer DiGA in einem strukturierten Format in die ePA einer versicherten Person übertragen werden. |
Die Angaben zum Hersteller der DiGA (Name, Anschrift, Website) lässt sich über die PZN der DiGA bzw. (stets aktuell) aus dem BfArM Verzeichnis ableiten. Auch wenn die Angaben optional sind, stellt sich der Mehrwert (u.a. wg. Prinzip der Datensparsamkeit) nicht unbedingt klar dar. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist die PZN als verpflichtendes Element ergänzt. Um das FHIR-Konzept in sich abgeschlossener Ressourcen zu unterstützen und zu ermöglichen, können Angaben zu Hersteller:in der DiGA weiterhin bei Bedarf über die optionalen Elemente "Name", "Anschrift" und "Website" abgebildet werden. |
| 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? | Vielen Dank für Ihren Kommentar! Aktuell wird das Thema unter anderem zwischen Gematik GmbH und GKV-SV abgestimmt, um einen Prozess rund um das Thema Datenspende und Pseudonymisierung von Daten zu definieren. In diesem Prozess sollen voraussichtlich weitere Akteure, wie die KBV und der BfDI, einbezogen werden. Es kann angenommen werden, dass einzelne Elemente eines MIO entsprechend des Pseudonymisierungsbedarfs eingeordnet werden. |
| Die Darreichung digitaler therapeutischer Inhalte durch DiGA-Hersteller wird vorrangig in deutscher Sprache erfolgen. Weitere Applikationssprachen werden sicher über die Zeit folgen. Die "Anzeigesprache" einer DiGA hat aus unserer Sicht nur einen unscharfen Bezug zum FHIR-Mapping, das durch KBV_PR_MIO_DIGA_Patient.communication adressiert wird. Es geht hier um die Kommunikation des Versicherten betreffend medizinischer Themen mit natürlichen Personen. Grundsätzlich ist es sinnvoll, die bevorzugte Sprache des Versicherten in der ePA zu hinterlegen. Wir möchten lediglich zur Diskussion stellen, ob diese Information überhaupt gesichert durch eine DiGA bereitgestellt werden kann. | Vielen Dank für Ihren Kommentar! Wir teilen die Einschätzung, dass die Information zur bevorzugten Sprache einer versicherten Person sinnvoll und wichtig ist. Die Anzeigesprache einer DiGA ist jedoch von den Dispositionsmöglichkeiten der jeweiligen DiGA abhängig. Daraus lässt sich nicht eindeutig ableiten, welche die bevorzugte Sprache einer versicherten Person ist. Daher wird die Anzeigesprache nicht als versorgungsrelevant identifiziert. Die DiGA könnte hingegen die bevorzugte Sprache in der Anwendung direkt erfragen und somit wertvolle Informationen in die ePA übertragbar machen. |
...
