Nach erfolgreich abgeschlossener Kommentierung läuft jetzt die Phase der Benehmensherstellung vom 14. März bis 11. April 2022. Eine Stellungnahme abgeben dürfen nur Organisationen, die im Rahmen der Benehmensherstellung zu beteiligen sind und einen Login von uns erhalten haben, siehe Im Benehmensverfahren beteiligte Verbände. Auf dieser Seite sehen Sie alle bisher abgegebenen Stellungnahmen, sofern diese der Netiquette (pdf) entsprechen und somit zur Veröffentlichung freigegeben wurden. Nach der Bewertung werden wir die Ergebnisse unter Stellungnahmeergebnisse veröffentlichen.


    • Key

    • DIGA1X0X0-82

    • Erstellt

    • 08.04.2022

    • Organisation

    • Verband der Privaten Krankenversicherung

    • Zusammenfassung

    • Identifikation von Privatversicherten

    • Beschreibung

    • 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:
      1. Auch Privatversicherte werden zukünftig zur Nutzung der Anwendungen der Telematikinfrastruktur digitale Identitäten (oder ggf. eGK) mit dem unveränderbaren Teil der Krankenversichertennummer nach § 290 Absatz SGB V erhalten (siehe hierzu § 362 SGB V). Somit sollte in Analogie zur VersichertenID_GKV (1.1.1.5) entsprechend auch eine VersichertenID_PKV im Informationsmodell abgebildet werden.
      2. Auch für Privatversicherte sollte die pseudonymisierte Nutzung einer DiGA ermöglicht werden. Dementsprechend bitten wir darum, ebenfalls eine pseudonymisierte Krankenversichertennummer für Privatversicherte aufzunehmen.

    • Key

    • DIGA1X0X0-81

    • Erstellt

    • 08.04.2022

    • Organisation

    • BfArM

    • Zusammenfassung

    • Stellungnahme des BfArM zum MIO DiGA Toolkit 1.0.0

    • Beschreibung

    • Fü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:
      Abschnitt Medikation

      MIO DiGA Toolkit:
      Code: 1003606003, Bezeichnung: Medication history section (record artifact), Codesystem: SNOMED CT®, 2021-07-31

      MIO PKA:
      Code: 736378000, Bezeichnung: Medication management plan (record artifact), Codesystem: SNOMED CT®, 2021-01-31

      MVC 5.1.0:
      Code: 10160-0, Bezeichnung: History of medication use, Codesystem: LOINC, 2.59

      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:
      Im MIO DiGA Toolkit kann das folgende Profil „frei“ kodiert werden:
      Condition_Problem_Free -
      Allerdings liegen in der MIO PKA Profile vor, die denselben medizinischen Sachverhalt mit einer spezifischen Codeangabe wiederspiegeln: KBV_PR_MIO_NFD_Condition -
      Beinhaltet die Vorgabe zur Nutzung von ICD-10-GM-, Alpha-ID-, SNOMED-CT- und Orphanet-Codes bei der Kodierung des Problems/Diagnose

      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.
      Es ist davon auszugehen, dass die vorliegende Herangehensweise zu einem erheblichen Mehraufwand bei der Entwicklung der DiGA sowie bei der Überprüfung dieser auf Seiten des BfArM führen wird.

      Beispiel:
      Abschnitt Vitalzeichen und Körpermaße
      Profil KBV_PR_MIO_DIGA_Observation_Blood_Pressure:
      Verwendung von Extensions zur Annotation eines Codes mit einem deutschsprachigen Bezeichner für LOINC und SNOMED CT –Codes namens „anzeigenameCodeLoinc“ und „anzeigenameCodeSnomed“.

      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:
      MIO DiGA Toolkit Profil- KBV_PR_MIO_DIGA_Observation_Peripheral_Oxygen und KBV-Basis-Profil - KBV_PR_Base_Observation_Peripheral_Oxygen_Saturation

      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:
      Um Kodiersysteme effizient nutzen und unmissverständlich interpretieren zu können, ist eine korrekte, konsistente Zuordnung dieser zu den FHIR-Datenelementen unabdingbar. Dementsprechend ist die Zuordnung der Valueset-Bindings zu überprüfen und gegebenenfalls anzupassen.

      Beispiel:
      Profil KBV_PR_MIO_DIGA_MedicationStatement_Medication_Request_Free

      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.