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 ein Kommentar zu einer Überarbeitung des MIO oder zur Aufnahme von Operationalisierungsempfehlungen für die umsetzenden IT-Systeme geführt hat.
Das überarbeitete MIO wird im Rahmen der Benehmensherstellung dargestellt.
Inhalt
| 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 Angabe der bevorzugten Sprache liegt nicht zwingend in der DiGA vor. | 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. |
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. |
| Eine unstrukturierte Informationsabbildung, z.B. via PDF, sollte in der ePA möglich sein. | 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. 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. |
Codierung
| Kommentarthema | Ergebnis |
|---|---|
| Es wäre von Vorteil die SNOMED Bezeichner direkt in deutscher Sprache (genderneutral) mit zu veröffentlichen und dafür Sorge zu tragen dass die englisch-sprachen SNOMED Begriffe verbindlich zu nutzen sind, dies vereinfacht die Darstellung zugunsten einheitlich genutzter Begriffe in deutscher Sprache (genderneutral) | Vielen Dank für Ihren Kommentar! Die mio42 GmbH verwendet international gängige Terminologien, welche zumeist ihren Ursprung im englischsprachigen Raum haben. In großen Teilen ist für diese Terminologien noch keine offizielle Übersetzung vorhanden (z.B. SNOMED-CT oder LOINC). Daher entstehen vorläufige Übersetzungen, die im Austausch mit Mediziner:innen und Fachterminolog:innen erstellt werden. Sofern möglich wird in den Vorübersetzungen eine genderneutrale Sprache verwendet. Die Zuständigkeit für die offizielle Übersetzung englischsprachiger Terminologien liegt beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM). |
| Aufgenommene Kohlenhydratmengen ließen sich als Nahrungsmengen z.B. mit dem Typ "Carbohydrate food", SCTID 227991002 unter 2.4.1.5 “Details über die Gesamtzusammensetzung” eintragen, was aber nicht ganz richtig und daher eventuell irreführend ist, da auch fettreiche Mahlzeiten einen Kohlenhydratanteil haben, der für Diabetiker:innen maßgeblich ist. Diabetiker:innen dokumentieren ihre aufgeommenen Kohlenhydratmengen üblicherweise in g (Gramm), BE (Broteinheiten) oder KHE (Kohlenhydrateinheiten), vgl. https://de.wikipedia.org/wiki/Broteinheit | Vielen Dank für Ihren Kommentar! Theoretisch ist der von Ihnen vorgeschlagene Code an dieser Stelle möglich. Da er jedoch aus der Hierarchie Substance (227991002 |Carbohydrate food (substance)|) stammt, halten wir Ihn an der Stelle nicht für passend im beschriebenen Kontext geeignet. Ein mögliche Lösung wäre ein Code aus der Hierarchie Observable Entity: "788472008 |Carbohydrate intake (observable entity)|". Die Einheit, z.B. Gramm, könnte an der Stelle "Konsumierte Einheit" (https://mio.kbv.de/x/CZ1bBg) im Informationsmodell angegeben werden. Hier kann auch die Einheit Gramm UCUM-konform eingetragen werden. Broteinheiten lassen sich durch international anerkannte Fachterminologien (SNOMED ®, LOINC®) nicht abbilden. Daher möchten wir auch auf die Möglichkeit der Angabe von Freitext verweisen, sofern der oben dargestellte Lösungsansatz nicht ausreichend für Ihren Anwendungsfall ist. |
Codes werden laut MIO-Spezifizierung (inhaltlich sinnvoll) manchmal nach SNOMED CT® und manchmal nach LOINC® ausgewiesen. Zur Klarifizierung kann auf dieser Seite auch LOINC® erwähnt werden, da sich eine generelle Bevorzugung von SNOMED über LOINC nicht ableiten lässt. Beide System sind an den entsprechenden Stellen sinnvoll ausgewiesen. | Vielen Dank für Ihren Kommentar! Das Datenelement, das kommentiert wurde, ist ein wiederverwendbares Element, welches in der Erstellung des Informationsmodells kopiert wird. Daher kann bei diesem Element noch nicht abgesehen werden, ob ein SNOMED CT®-Code oder ein LOINC-Code im jeweiligen Kontext verwendet werden sollte. Die Beschreibung des Elements wird wie folgt angepasst: "Hier wird ein Code eingetragen, vorzugsweise aus dem Code-System SNOMED CT® beziehungsweise LOINC®." |
Technische Repräsentation
| Kommentarthema | Ergebnis |
|---|---|
| Frage ob Codes fest vorgegeben sind, da diese nicht als fixedValue eingetragen sind. | Vielen Dank für Ihren Kommentar! Der Code wurde als Pattern vorgegeben. Dadurch ist sichergestellt, dass nur der im Pattern definierte Code eingetragen werden kann. |
| Hinweis auf Verwendung der Extension_Lebensphase aus den deutschen Basisprofilen | Vielen Dank für Ihren Kommentar! Tatsächlich existiert die Lebensphase Extension bereits in den deutschen- und KBV-Basisprofilen, sodass aus Gründen der Interoperabilität eine dieser beiden Extensions verwendet werden sollte. Um eine möglichst hohe Kompatibilität zwischen den MIO-Spezifikationen zu erreichen, ist in der Benehmensversion die KBV_EX_MIO_Stage_Life Extension berücksichtigt. Zusätzlich beinhaltet die KBV_EX_MIO_Life_Stage bereits die Extension für die Angabe der deutschen Anzeigenamen, was für eine Verwendung dieser Extension spricht |
| Die Maßeinheit für einen Skalenwert ist falsch gewählt. Anstelle von "1" (Ganzzahl) sollte "Scale" oder "Score" hinterlegt werden. Außerdem sollte ein geeigneter Anzeigename fest hinterlegt werden. | Vielen Dank für Ihren Kommentar! Der Code ist geändert in der Benehmensversion. Es wird der Code "Score" verwendet. |
| Warum wird der Identifier als UUID immer verpflichtend verlangt? Was ist der Unterschied zu der Id der Ressource? | Vielen Dank für Ihren Kommentar! Aktualisierungen der Instanzen sind im DiGA-Toolkit möglich und vorgesehen. Der Behandlungsplan kann im Laufe der Zeit indikationsabhängig ergänzt werden. Das führt an dieser Stelle zu einem neuen FHIR®-Bundle und somit zu einer neuen Version des Behandlungsplanes. Damit die verschiedenen Versionen weiterhin zugeordnet werden können, muss eine UUID angegeben werden, welche über die unterschiedlichen Versionen hinweg identisch ist. |
Device.version sollte zugelassen werden. Der Grund hierfür ist, dass sich DiGA im Laufe der Zeit weiterentwickeln können und Inhalt und Umfang des Datenexportes dadurch Veränderungen unterworfen sein könnten. | Vielen Dank für Ihren Kommentar! Die Version des Gerätes als Element wird zugelassen und ist in der Benehmensversion geändert. |
| Lässt der Typ einer Frage beim Fragebogen eine Mehrfachauswahl zu? | Vielen Dank für Ihren Kommentar! Eine Mehrfachauswahl für den Typ einer Frage ist aufgrund der von FHIR® vorgegeben Kardinalitäten nicht möglich. |
| Verwendung der dt. Übersetzungen afür das Geschlecht aus den deutschen Basisprofilen | Vielen Dank für Ihren Kommentar! Die ConceptMap ist in der Benehmensversion entfernt. Es wird auf die Übersetzungen der deutschen Basisprofile zurückgegriffen. |
| Grund für Existenz der Anzeiename Extension an Questionnaire.item.type unklar. Übersetzung an dieser Stelle nicht notwendig, da dem Endnutzer diese Information nie angezeigt werden wird. | Vielen Dank für Ihren Kommentar! Es kann nicht vollkommen ausgeschlossen werden, dass dieses Element durch anzeigende System angezeigt wird. Aus diesem Grund wird die Extension nicht entfernt. |
| QuestionnaireResponse.item.text sollte zugelassen werden. Damit empfangendes System auch ohne den Questionnaire eine vollständige Darstellung anbieten kann. | Vielen Dank für Ihren Kommentar! Das Element QuestionnaireResponse.item.text ist in der Benehmensversion zugelassen. |
| Es sollte möglich sein ein Medikament als Freitext anzugeben. Bspw. Aspirin | Vielen Dank für Ihren Kommentar! Ein Medikament kann über das Element KBV_PR_MIO_DIGA_Medication_Free.code.text als Freitext angegeben werden. |
| FHIR-Mapping Links lösen nicht auf | Vielen Dank für Ihren Kommentar! Die FHIR®-Mappings sind in der Benehmensversion geändert. |
| Die FHIR-Struktur ist zu stark eingeschränkt für europäischen Use-Case. | Vielen Dank für Ihren Kommentar! Die elektronische Patientenakte (ePA) wird als nationaler Standard eingesetzt, weshalb wir den europäischen Anwendungsfall für dieses MIO zum jetzigen Zeitpunkt nicht identifizieren können. Sofern sich an der Ausrichtung der ePA im DiGA-Kontext etwas ändert, werden wir unsere Spezifikation dahingehend überprüfen. |
| Patient.communication.language lässt nur eine Sprache zu. Ein Patient kann aber mehrere Sprachen beherschen. | Vielen Dank für Ihren Kommentar! Innerhalb des Communication Elements kann nur eine Sprache angegeben werden. Es ist allerdings möglich mehrere Communication Elemente anzugeben, wodurch die Angabe mehrerer Sprachen möglich ist. |
| Einladung zur Mitwirkung bei der Entwicklung genereller Guideslines zur Abbildung von Scores und Skalen im Rahmen des TC FHIR von HL7 | Vielen Dank für Ihren Kommentar! Wir wirken gern an der Entwicklung der Guidelines mit. |
| Aus welchem Grund wurde Coding immer auf 0..1 gesetzt? Und wieso wurden alle Elemente, die darunter liegen mandatorisch gemacht? Dies begünstigt die Verwendung von Freitext | Vielen Dank für Ihren Kommentar! Die Kardinalität für das "coding" Attribut wird in der Version für die Benehmensherstellung in allen Anwendungsfällen, die es erlauben, auf 0...* gesetzt, so auch in diesem von Ihnen kommentierten Element. Die im Coding enthaltenen Elemente sind als mandatorisch vorgesehen, um eine eindeutige Zuordnung und Anzeige der Codes zu garantieren. Wir eruieren in der Fortschreibung, in welchen Fällen einzelne dieser Unter-Elemente in Codings optional gesetzt werden können. |
| Eine dauerhafte Fortschreibung von DiGa Daten bietet für Ärzte keinen Mehrwert. Sinnvoller wäre die Archivierung der Daten nach einer gewissen Zeit. Die archivierten Daten sollten als solche gekennzeichnet weiterhin in der ePA verfügbar sein. | Vielen Dank für Ihren Kommentar! In der Benehmensversion ist der Umgang mit Bundles geändert. FHIR®-Bundles werden für einen bestimmten Betrachtungszeitraum in der ePA vorliegen. Dadurch wird behandelnden Personen die Möglichkeit eingeräumt, lediglich einen relevanten Zeitraum zu betrachten. Weitere Informationen dazu hier: In der ePA zu speichernde FHIR®-Ressourcen, Phase II bzw. Betrachtungszeitraum für ePA-Einträge, Phase II |
| Wo können QuetionnaireResponse Instanzen im MIO referenziert werden? | Vielen Dank für Ihren Kommentar! QuestionnaireResponse-Instanzen können in KBV_PR_MIO_DIGA_Composition.section:frageboegen.entry referenziert werden. |
| Im Modell sind dem Patienten sechs Identifier zugeordnet. Das FHIR-Profil enthält nur fünf Identifier. Woher kommt die Abweichung? | Vielen Dank für Ihren Kommentar! Der zusätzliche Identifier ist in der Benehmensversion ergänzt. |
| Das DiGA-Toolkit MIO bildet bereits viele Use-Case ab. Es ist jedoch nicht sichergestellt, dass immer alle Daten exportiert werden können. Damit würden DiGA den §20 DSGVO nicht erfüllen und müssten ein weiteres Format implementieren. Daher wäre es am sinnvollsten, wenn DiGA die DiGA-Toolkit Spezifikation erweitern könnten. | Vielen Dank für Ihren Kommentar! Der DSGVO-konforme Export ist gemäß SGB V kein MIO-spezifischer Anwendungsfall. Wir werden jedoch prüfen, inwieweit der von Ihnen beschriebene Use-Case auch mittels des MIO abbildbar ist. |
| Das DiGA-MIO soll fortgeschrieben werden. Wo findet sich die Angabe, welcher Version des DiGA-MIO die in die ePA eingestellten Daten folgen? | Vielen Dank für Ihren Kommentar! Die Version ist im meta.profile. enthalten, zum Beispiel: Blood_Pressure|1.0.0 impliziert DiGA-Toolkit Version 1.0.0. In der ePA ist die Version des MIO im FormatCode enthalten. |
Spätestens mit der Geräteschnittstelle werden DiGA viele Vitalwerte nicht messen, sondern aus anderen Werten berechnen. KI-Verfahren - zB für kontaktlose EKG - werden immer stärker auch und gerade für DiGA interessant. Sofern die Quelle eines Wertes ein Algorithmus und kein Device ist: Soll das trotzdem über "Gerät - frei" abgebildet werden oder ist hier ein anderer Weg vorgesehen? | Vielen Dank für Ihren Kommentar! Durch KI generierte Werte können über das Element "method" abgebildet werden. Als Methode wäre dabei das jeweilige KI-Verfahren anzugeben. |
Operationalisierung
| Kommentarthema | Ergebnis |
|---|---|
Anregung für Export- /Import-Test:
| Vielen Dank für Ihren Kommentar! Die mio42 wird auch wie bereits bei anderen MIOs weitreichenden Support für das DiGA Toolkit anbieten. Wir planen aktuell die Umsetzung von DiGA-spezifischen Help-Sessions, auf die wir zum gegebenen Zeitpunkt auf unserer Kommentierungsplattform (https://mio.kbv.de) hinweisen werden bzw. Sie informiert werden, sofern Sie z.B. den IT-Newsletter abonnieren. Ebenso laden wir Sie zur Teilnahme an unseren Connectathons (https://mio.kbv.de/display/MIOATT/Connectathon) ein und zur Beteiligung an unserer Austauschplattform für MIO Export-Beispiele auf Github (https://mio.kbv.de/display/MIOATT/Austauschplattform+Beispieldateien), wo bereits mehrere Hersteller Beispiele für verschiedene MIO-Exporte für Import-Tests bereitgestellt haben. Zur Validierung der FHIR®-Profile kann der HL7-Validator genutzt werden. Inwiefern der MIO Viewer speziell für das DiGA Toolkit geeignet und verwendbar ist, wird aktuell geprüft. |
Redaktionell
| Kommentarthema | Ergebnis |
|---|---|
| Nicht-Familienmiglied -> t bei mitglied fehlt | Vielen Dank für Ihren Kommentar! Der Beschreibungstext ist geändert in der Benehmensversion. |
