Nach Abschluss der Benehmensherstellung und der Prüfung sowie Bewertung aller eingegangenen Stellungnahmen ist hier ein Überblick zu den Ergebnissen einsehbar.
| Stellungnahme | Antwort |
|---|---|
https://mio.kbv.de/display/BASE1X0/1.1.3+Versichertennummer_PKVFür die Herstellung des Benehmens, insbesondere unter dem Aspekt der Berücksichtigung semantischer Interoperabilitätsfestlegungen für den europäischen Datenaustausch (§ 219d Abs. 6 SGB V) möchten wir eine Diskussion der folgenden Aspekte anregen: Einheitliche Bezeichnung von inhaltsgleichen Abschnitten zwischen DIGA – PKA und EU Patient Summary: Es ist im Sinne der Interoperabilität wünschenswert, inhaltsgleiche Informationen in gleichnamigen Abschnitten zu dokumentieren um diese eindeutig zuordnen zu können. Die Benennung der Abschnitte erfolgt über LOINC-Sections bzw. SNOMED CT Document Sections. Wenn diese einheitlich kodiert werden, können Informationen aus einer DIGA den inhaltsgleichen Abschnitten einer elektronischen Patientenakte zugeordnet werden. Eine Harmonisierung der Bezeichnungen für die Dokumentabschnitte innerhalb des MIO DiGA Toolkits und der MIO PKA wird deshalb empfohlen. Dies gilt ebenso für die Harmonisierung dieser Abschnitte in Bezug auf die crossborder electronic patient summary für die Gewährleistung des europäischen Datenaustauschs gemäß SGB V §219d Absatz 6. Beispiel: MIO DiGA Toolkit: MIO PKA: MVC 5.1.0: Einheitliche Kodierungsvorschläge für inhaltsgleiche Informationen mit der MIO PKA: Für die Profile des DiGA Toolkits ist eine bevorzugte Verwendung von Codesystemen wie SNOMED CT wünschenswert. Diese Empfehlung sollte im Simplifier und der technischen Spezifikation konkretisiert werden. Sobald Codesysteme vorhanden und für bestimmte Inhalte, wie beispielsweise Informationen, die auch in der PKA konkret vorgegeben sind, wäre es von Vorteil, diese Codesysteme auch im DiGA Toolkit explizit vorzugeben. Beispielsweise könnte das bevorzugte Codesystem als Binding mit einer Gewichtung preferred in der Spezifikation hinterlegt werden. Eine „freie“ Profilierung sollte auf die Anwendungsgebiete ohne Schnittmenge zur PKA und wenn keine verfügbaren SNOMED-Codes vorliegen, beschränkt werden. Beispiel: Reduzierung der Komplexität bei der Bereitstellung deutscher Übersetzungen: Im Sinne der besseren Überprüfbarkeit und Implementierbarkeit der in der DiGA genutzten Codesysteme wäre es wünschenswert eine alternative Herangehensweise zur Darstellung von deutschsprachigen Display-Werten zu etablieren. Die Darstellung der Übersetzungen von Codesystemen innerhalb Extensions sollte diskutiert werden. Beispielsweise könnte für die deutschsprachige Repräsentation das FHIR-Element Text innerhalb des zugehörigen Code-Elements verwendet werden. Beispiel: Des Weiteren möchten wir folgende Punkte anmerken: Anpassung der MIO DiGA Toolkit-Profile an die KBV-Basis-Profile: KBV-Basis-Profile dienen als Grundlage für die Entwicklung medizinischer Informationsobjekte. Im Sinne der Interoperabilität ist es empfehlenswert, dass auch die Profile des MIOs DiGA Toolkit an die aktuellen KBV-Profile angepasst werden. Explizit ist hier die inkonsistente Bezeichnung von Extensions mit identischer URL zu überprüfen und gegebenenfalls anzupassen, um potentielle Validierungsprobleme zu vermeiden. Beispiel: Innerhalb des DiGA Profils für die periphere arterielle Sauerstoffsättigung wird in der Methode auf eine Extension namens anzeigenameMethod zurückgegriffen. Das entsprechende KBV-Profil enthält hingegen im Element Methode eine Extension namens anzeigenameMethodSnomed mit einer identischen URL. Zuordnung von Valuesets zu FHIR-Datenelementen: Beispiel: Innerhalb des DiGA Profils zur Arzneimittelanamnese erfolgt eine Zuordnung des Valuesets KBV_VS_MIO_DIGA_Dosage_Point_Of_Time im Datenelement Timing. Zusätzlich wird im Element Timing.code ein Binding zum Valueset TimingAbbreviation angegeben. | Wir haben Ihre Stellungnahme in folgende Teile gegliedert:
1. Bereich Vergleich zu IPS und PKA:
2. Bereich Angabe von Übersetzungen als Extensions:
3. Bereich: Deckungsgleichheit mit den KBV-Basisprofilen:
|
Wir bedanken uns für die Möglichkeit der Stellungnahme und bitten um die Berücksichtigung der folgenden Aspekte: Bezugnehmend auf den Identifikator der versicherten Person (1.1.1) im Informationsmodell möchten wir die folgenden zwei Aspekte zur Identifikation von Privatversicherten einbringen: | Zu Punkt 1: Das Profil zur versicherten Person im MIO DiGA Toolkit basiert auf der Definition des KBV-Basis-Profils "PatientIn". In Zukunft wird das MIO DiGA Toolkit zum Ende jedes Kalenderhalbjahres fortgeschrieben. In diesem Kontext werden wir eine Erweiterung des im MIO genutzten Profils überprüfen, um die beschriebene ausdifferenzierte ID für PKV Versicherte (Entsprechung des unveränderbaren Teil der Krankenversichertennummer nach § 290 Absatz SGB V), in Abstimmung mit dem KBV-Basis-Profil, zu ergänzen. Zu Punkt 2: Sofern eine ausdifferenzierte ID für PKV Versicherte in Zukunft Berücksichtigung findet, wird auch eine pseudonymisierte Krankenversichertennummer für PKV Versicherte aufgenommen. |
Der SVDGV begrüßt die Möglichkeit, an der Benehmensphase teilnehmen zu dürfen und möchte die folgenden Änderungen anregen: 2. Verständlichere Beschreibung einzelner Datensätze Im sich anschließenden Punkt 1.4.1.2 heißt es in der Beschreibung: "Hier werden die/der AkteurIn referenziert". Was letztendlich damit gemeint ist, bleibt jedoch unklar. Hilfreich wären hier insbesondere Erklärungen, aus welchen Gründen dies erfolgen sollte. Häufig wird entstammen die Beschreibungen aus dem Versicherungskontext und sind damit für DiGA-Hersteller nicht nachvollziehbar. Da allerdings ausgerechnet Letztere das MIO implementieren müssen, wird angeraten, den Standard sprachlich zu überarbeiten und eine klare, kontextneutrale Wortwahl zusammen mit hinreichend umfassenden Beschreibungen zu liefern. Die Seite "Erläuterungen", welche Definitionen enthält, sollte vervollständigt und um alle Begriffe erweitert werden, deren Konnotation sich nicht aus dem normalen Sprachgebrauch entnehmen lässt. Die Darstellung der Datenfelder des MIOs auf der Webseite der KBV sollte für Dritte in sich schlüssig und vollkommen nachvollziehbar sein, ohne dass man die Verlinkungen auf Simplifier.net als Auslegungshilfe heranziehen muss. 3. Umfang der bisher definierten Datenfelder Das MIO definiert zahlreiche Datenfelder, welche jedoch von den DiGA-Herstellern nicht erhoben werden, z.B. Reisepassnummer, Versicherungsnummer, Anschrift. gemäß § 341 Abs. 1 SGB V dient die ePA dazu Befunde, Diagnosen, durchgeführte und geplanten Therapiemaßnahmen sowie Behandlungsberichte, für eine einrichtungs-, fach- und sektorenübergreifende Nutzung für Zwecke der Gesundheitsversorgung, insbesondere zur gezielten Unterstützung von Anamnese und Befunderhebung, barrierefrei elektronisch bereit zu stellen. Aus der abschließenden Aufzählung des Abs. 2 ergibt sich, dass lediglich Gesundheitsdaten in die ePA übertragen werden. Diesen Grundsatz verletzt die aktuelle Fassung des DiGA-MIOs mit einer Vielzahl von Feldern zu Stammdaten, welche aus Sicht des Gesetzgebers nicht in die ePA übertragen werden sollen. Dies ist auch nachvollziehbar, da sämtliche, die versicherte Person identifizierenden Daten bereits auf Seiten der Krankenversicherungen vorhanden sind, welche die ePAs betreiben. Für ein Verknüpfen der zu übertragenden Daten genügt daher eine einzige ID. Der Sinn des gesamten Abschnittes 1.1 mit Ausnahme von 1.1.1.6 wird somit in Abrede gestellt. Das gleiche Argument gilt auch gegenüber weiteren Feldern, deren Daten zwar nicht vom Hersteller gesammelt, jedoch scheinbar generiert werden sollen. Hier wird wieder auf das Beispiel der AkteurIn des Punktes 1.4.1 verwiesen. Die Herkunft der Daten einer DiGA stammt zwangsläufig immer vom Patienten. Selbst wenn man bereits in die Zukunft blicken möchte und einen Datenaustausch zwischen DiGAs annähme, stammten die Daten immer noch von der selben Person, selbst wenn die Daten vorher aus einer anderen DiGA importiert wurden. Auch bei DiGAs, welche Daten aus Sensoren verarbeiten, wäre diese umständehalber klar erkennbar, welche Daten vom Patienten selbst und welche vom Sensor stammen würden. Insofern ist hier der Sinn des Datenfeldes nicht nachvollziehbar. Dieser scheint eher anderen medizinischen Kontexten zu entstammen, welche im Bereich der DiGAs nicht sinnvoll erscheinen. | Zu Punkt 1: Die von Ihnen dargestellte Situation ist uns bekannt und wir werden eingehend prüfen, welche englischsprachigen Angebote bereitgestellt werden können. Um insbesondere einen effizienten und barrierefreien Support für die erstmalige Implementierung des MIO auf Seiten der DiGA-Hersteller:innen zeitnah sicherzustellen, bieten wir die Möglichkeit, Fragen sowohl in deutscher als auch englischer Sprache über unser Support-Formular sowie im Rahmen unserer technischen Help-Sessions einzureichen. Zu Punkt 2: Im Rahmen der Fortschreibung werden wir die Verwendung von Begriffen überarbeiten und diese, z.B. mit Hilfe eines Glossars, einordnen. Die Beschreibungstexte werden in der Fortschreibung, wenn notwendig, erweitert sowie um Beispiele ergänzt. Für die erstmalige Festlegung wird bereits der Begriff "Datenquelle" anstelle von "AkteurIn" verwendet. Zu Punkt 3, Absatz 1: In der erstmaligen Festlegung werden die optionalen Datenelemente weiterhin berücksichtigt. Damit wird sichergestellt, dass jede DiGA tatsächlich nur die Informationen befüllen muss, die für den jeweiligen Bestimmungszweck notwendig in die ePA zu übermitteln sind. Im Rahmen der Fortschreibung wird die Verwendung der pseudonymisierten ID in den Fokus genommen. Sofern sich abzeichnet, dass die Verwendung einer sogenannten Pseudo-ID im DiGA-ePA-Prozess hinreichend ist, werden die optionalen Datenelemente wie von Ihnen vorgeschlagen entfernt. Zu Punkt 3, Absatz 2: Nach unserer Einschätzung und den Rückmeldungen, die wir im Rahmen von Expertenaustauschen mit Hersteller:innen und Fachverbänden bekommen haben, liegt die Herkunft bzw. die Quelle von Daten, welche innerhalb einer DiGA verwendet werden und demzufolge auch im Rahmen eines Exports in die ePA übermittelt werden, nicht ausschließlich bei der versicherten Person. Eine Diabetes-DiGA könnte Glucosewerte automatisch über ein Gerät erfassen bzw. manuell von einer versicherten Person abfragen. Dabei muss die Diabetes-DiGA keine Insulintherapie ableiten, sondern lediglich ein digitales Blutzucker-Tagebuch anbieten. |
