Hier erhalten Sie einen Überblick über alle Kommentare, bei denen der Kommentator der Veröffentlichung zugestimmt hat.
-
-
Key
-
DDT1X0X0-60
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angaben sinnvoll für Devices/Implantate
-
Beschreibung
-
Vergleichbar mit den Angaben (communication und telecom) zum Patienten aus dem DiGA Tookit auch hier die Frage ob diese Angaben für das DiGA Device Toolkit sinnvoll und praxisbezogen sind bzw. welchen Mehrwert und welche Aktualität diese Informationen haben.
-
-
-
Key
-
DDT1X0X0-59
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Kontaktdaten (telecom)
-
Beschreibung
-
Die Praxis muss zeigen ob die Angabe von Telekommunikationsinformationen (z.B. Fax) an dieser Stelle sinnvoll ist und überhaupt Verwendung finden kann. Es ist schwer vorzustellen, dass das Device/Implantat die Aktualisierung dieser Daten im Fokus hat, falls sich diese ändern sollten.
-
-
-
Key
-
DDT1X0X0-58
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Fehlende Constraints
-
Beschreibung
-
Device.serialnumber
Wenn eine Limitierung feststeht, sollte man versuchen diese auch als entsprechende constraints abzubilden (alphanumeric maximum 20). Dies hilft bei der Implementierung und härtet die Qualität der Inhalte.
-
-
-
Key
-
DDT1X0X0-57
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Kodierung SNOMED CT/LOINC
-
Beschreibung
-
Die Vitaldaten sind in der Spec allgemein über SNOMED und LOINC zu kodieren. Wie kann gewährleistet werden, dass die Devices/Implantate Codes verwenden, die semantisch exakt das gleiche aussagen bzw. wie wird kontrolliert, ob diese Angaben valide sind und was passiert mit den Werten, wenn es (geringfügige) Abweichungen in der Bedeutung der beiden ausgewählten Codes gibt. Welche Angabe gewinnt scheint nicht möglich. Sind diese Werte dann insgesamt als ungültig zu setzen?
-
-
-
Key
-
DDT1X0X0-56
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Auswahl der beschriebenen Informationsobjekte ("nur" Vitaldaten)
-
Beschreibung
-
Gibt es eine Liste von existierenden bzw. potentiellen Devices die bei der Festlegung der Dateninhalte Pate stand? Die Auswahl erscheint im ersten Moment sehr exemplarisch und weniger praxisbezogen (ein Device oder Implantat das die Körpergröße oder den Kopfumfang misst...). Wie schnell können Daten anderer, den Markt betretenen Devices in Bezug auf deren spezifischen Datenerhebungen in dieses MIO und dann zeitversetzt auch in das MIO DiGA Toolkit aufgenommen werden, damit diese Daten dann in die ePA einfließen könnten?
-
-
-
Key
-
DDT1X0X0-55
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Einheitliche 'Comments' bei der Beschreibung der Elemente (max string size)
-
Beschreibung
-
Gibt es einen Grund dafür, dass unter 'Comments' zu einigen Elementen bei Data Type "string" der Hinweis auf max. Länge von Strings in FHIR (1 MB in size) hinterlegt ist und bei anderen nicht? Bei manchen wo man offensichtlich vermuten könnte, dass es "knapp" werden könnte fehlt dieser und bei anderen, wo es durch die Vorgabe des Inhaltes sehr unwahrscheinlich ist, dass dieser Wert gerissen wird ist dieser Hinweis teilweise angegeben. Eine einheitliche Vorgehensweise wäre zu überdenken.
-
-
-
Key
-
DDT1X0X0-26
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Verena KAIP
-
Organisation
-
MedTech Europe
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
A European medical technology industry point of view
-
Beschreibung
-
MedTech Europe would like to share some considerations on the current German “MIO42 DiGA device toolkit” public consultation.
We support the comments of our German member association BVMed and would like to add a European and international perspective, building on the MedTech Europe statement “A European industry perspective on the German draft law on digital care modernisation (DVPMG)” of 12 April 2021 (<span class="nobr"><a href="https://www.medtecheurope.org/resource-library/medtech-europe-perspective-on-the-german-draft-law-on-digital-care-modernisation-dvpmg/" class="external-link" rel="nofollow">https://www.medtecheurope.org/resource-library/medtech-europe-perspective-on-the-german-draft-law-on-digital-care-modernisation-dvpmg/<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> ).
Therefore, we would like to make the following three recommendations:
(1) Ensure compliance with international consensus standards:
- Previous mio42 toolkits included specifications that go beyond international standards by including country-specific elements. This has an impact on MIO DiGA devices, given the data models are closely interrelated and build on each other. Advanced connected medical technologies are designed for a global market. National-level regulations requiring local adaptions present considerable challenges and could constitute a barrier to the launch of medical technology solutions on the German market.
- The broader impact of interoperability requirements should be considered, and a regulatory approach is favoured where the German requirements are aligned with robust and recognised international consensus standards.
(2) Allow for appropriate transition times:
- Manufacturing devices to new specifications that are specific to Germany will present considerable barriers for the medical technology industry. The transition timeframe from 2022-2024 is too short.
- Furthermore, the expected regular updates of the MIO toolkits will significantly impact the medical technology industry, as they may even require recertification for medical and IVD devices.
(3) Work with the medical technology industry:
- When developing interoperability specifications for health data transfers, the medical technology industry, as well as international standards development organisations (SDOs), should be considered partners in the process.
Given that the medical technology industry makes devices for the European and global market, we urge coordination at European and international level. The SDOs have developed processes for this and are the appropriate mechanism.
We are ready to discuss any questions to support further improvements of the MIO DiGA device toolkit.
-
-
-
Key
-
DDT1X0X0-23
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Natalie Gladkov
-
Organisation
-
BVMed e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Patientenidentifikation nicht mit jedem medizinischen Device möglich
-
Beschreibung
-
Die Hersteller von Implantaten kennen i.d.R. nur die Seriennummern ihrer Devices. Ihnen liegen keine weiteren gesicherten Informationen zu den Patient:innen vor. Ohne Kenntnis der Patientenidentität ist demnach eine Zuordnung bzw. Kommunikation zu einer DiGA nicht möglich. Hier bedarf es einer grundsätzlichen Lösung im Rahmen des Datenaustauschs.
Im Gegensatz zu der semantischen Interoperabilität bleiben demnach Fragen bzgl. des Datenaustausches, der Identifikation und der Schnittstellen weiterhin offen. Damit das Datenmodell in der Praxis umgesetzt werden kann, müssen diese bis zum 30.06.2022 unbedingt ergänzend geklärt werden, um die notwendige Zeit der Umsetzung auf allen Ebenen sicherstellen zu können.
Da die Integration von Schnittstellen in ein Medizinprodukt eine Re- oder gar Neuzertifizierung des Produktes erforderlich machen würde, begrüßen wie ausdrücklich, dass hier ausschließlich über Backend-Backend-Kommunikation gesprochen wird. Dennoch müssen die Systeme und Prozesse im Austausch entsprechend definiert sein.
-
-
-
Key
-
DDT1X0X0-22
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Natalie Gladkov
-
Organisation
-
BVMed e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Mögliche Anwendungsfälle fehlen und kollidieren mit Medizinproduktevorgaben
-
Beschreibung
-
Im Rahmen der Konformitätsbewertung wird jedem Medizinprodukt, sowohl Implantat und Hilfsmittel wie auch DiGA, abhängig von der jeweiligen Zweckbestimmung eine Risikoklasse zugeordnet. Da datenverarbeitende Apps bisher als Zubehör des datengenerierenden Medizinproduktes gelten, orientiert sich ihre Einstufung an der des Medizinproduktes. So werden Medizinprodukte und die dazugehörigen Apps als Risikoklasse IIb und III eingestuft, wenn sie erhebliche Auswirkungen auf die Gesundheit und das Leben der Patienten haben können, bspw. durch aktive Warnungen bei bestimmten Vitalwerten.
Bei digitalen Gesundheitsanwendungen nach § 33a SGB V handelt es sich wiederum um eigenständige Medizinprodukte, die den Risikoklassen I und IIa zugeordnet werden. In den meisten Fällen weist eine DiGA somit eine niedrigere Risikoklasse als das datengenerierende Medizinprodukt, z.B. kardiale Implantate, auf.
Es lassen sich demnach aktuell nur ganz wenige Anwendungsfälle ableiten, im Rahmen derer eine DiGA durch die Verarbeitung der Daten nicht in ihrer Risikoklasse steigen würde und damit aus der Erstattung fiele. Es lässt sich auch nicht ausschließen, dass keine der im DiGA-Verzeichnis gelisteten DiGA die über die Schnittstelle verfügbaren Daten nutzen wird. Zugleich werden im MIO DiGA Device Toolkit an bestimmten Stellen „tiefergehende Daten“ angefordert.
Um eine übermäßige Belastung der Hersteller zu vermeiden, gilt es deshalb klare indikationsspezifische Anwendungsfälle zu formulieren, anhand derer das Toolkit aufgebaut werden kann.
-
-
-
Key
-
DDT1X0X0-21
-
Erstellt
-
07.02.2022
-
Portallink
-
Name
-
Natalie Gladkov
-
Organisation
-
BVMed e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Konsequente Nutzung von internationalen Standards
-
Beschreibung
-
Die Medizintechnikbranche ist grundsätzlich international aufgestellt. Standards sollten daher nicht einseitig für den deutschen Gesundheitsmarkt gesetzt werden, sondern anhand internationaler Standards erfolgen. Das MIO DiGA-Device-Toolkit folgt diesem Credo nicht durchgehend. Die Spezifikation geht an manchen Stellen über die FHIR-Spezifikation hinaus und enthält nationale Besonderheiten, die vermieden werden sollten.
-
-
-
Key
-
DDT1X0X0-8
-
Erstellt
-
01.02.2022
-
Portallink
-
Name
-
Pia Maier
-
Organisation
-
Bundesverband Internetmedizin
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Einige grundlegende Anmerkungen
-
Beschreibung
-
Das vorliegende Toolkit ist eine Übertragung des KBV-Basis-Vitalzeichen & Körpermaße-Profils, was einige grundlegende Probleme aufwirft, denn diese Inhalte ignorieren die Möglichkeiten der Devices und führen gleichzeitig sowohl zu unerfüllbaren Anforderungen wie auch zu ungehobenen Potenzialen.
Die Copy&Paste-Methode bringt auch eine Größe wie den Kopfumfang in das DiGA-Device-Toolkit. Derzeit ist kein Device oder Implantat bekannt, das den Kopfumfang messen könnte, und eine solche Entwicklung scheint eher unwahrscheinlich. Eine regelmäßige Erfassung dieses Körpermaßes durch Implantat oder Device und regelmäßige Übertragung der Daten scheint zumal wenig sinnvoll - dennoch steht dieser Bereich in der Liste ganz oben (vermutlich, weil er da schon im Basisprofil stand).
Im Abschnitt Glukosespiegel werden auch Richtgrenzen erfasst. Eine Richtgrenze wird definiert als ein Referenzbereich, ein therapeutischer Bereich oder ein Zielbereich - all das sind Größen, die interpretatorisch für den Einzelfall festgelegt werden. Hier geraten Meldung von Messungen und Interpretation durcheinander. Gleiches gilt für den Abschnitt Interpretation - was gilt, wenn "stark steigend" oder "leicht sinkend" unterschiedlich interpretiert wird? Was passiert, wenn ein Grenzwert in DiGA und Device unterschiedlich gesetzt wird?
Das Prinzip Copy&Paste ohne Anpassung an die hier relevanten Settings sticht auch bei den Referenzelementen zu Patient:innen ins Auge. Beispiel Kontaktkanal: Ein Implantat schickt eher kein Fax. Und telefoniert auch nicht mit den Patient:innen.
Neben vielen detaillierten Festlegungen fehlen andererseits aber Öffnungen für weitere Messwerte, die zwischen DiGA und Device vielleicht ausgetauscht werden könnten. Während das DiGA-Toolkit solche Öffnungen im Sinne von frei zu definierenden Feldern in vielen Abschnitten enthielt, haben wir es hier mit einer abgeschlossenen Liste von Vitalzeichen und Körpermaßen zu tun. Damit wird die aus dem Basisprofil stammende Logik in das Toolkit überführt - obwohl es für viele dieser Werte einfachere Methoden gibt als der Aufwand über ein Device oder Implantat. Einen Herzschrittmacher für die Bestimmung der Herzfrequenz zu nutzen unterschätzt dessen Fähigkeiten deutlich und ist mit einer Smartwatch jederzeit möglich.
Es fehlt bei der Vorbereitung dieses Toolkits an grundlegenden Überlegungen, was die Stärken von Devices und Implantaten sind und wie sie von DiGA genutzt werden können. Das ist allerdings ausdrücklich nicht MIO42 vorzuwerfen, sondern einem Konstruktionsfehler im Gesetz. Mit kurzer Fristsetzung soll hier die Standardisierung geschaffen werden für Umsetzungsmodelle, die es noch gar nicht gibt. Natürlich wäre es schön, wenn die Umsetzung gleich auf Standards beruhen würden, aber Standards schränken eben auch ein. Aus all den vielen potenziell möglichen Messungen werden hier nur die gängigen, schon in anderem Zusammenhang erfassten, gelistet. Die Frage, welche Messungen neue Möglichkeiten schaffen würden, können aber nicht Codierfachleute klären, sondern nur Expert:innen, die an DiGA und Devices arbeiten. Solange wir hier keine etablierten Prozeduren haben, macht die Standardisierung auf diesem detaillierten Niveau nicht nur wenig Sinn, sie erstickt auch neue Entwicklungen, die über bereits gelistete Standards hinausweisen würden.
-