Kommentierungsüberblick

• Key

• DIGA1X0X0-74

• Erstellt

• 12.12.2021

• Portallink

• 1.1.3 Administratives Geschlecht, Phase I

• Name

• Pia Maier

• Organisation

• Bundesverband Internetmedizin

• Zusammenfassung

• Verschiedene Geschlechtsdefinition

• Beschreibung

• 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.

• Key

• DIGA1X0X0-73

• Erstellt

• 12.12.2021

• Portallink

• 1.1 Versicherte Person, Phase I

• Name

• Pia Maier

• Organisation

• Bundesverband Internetmedizin

• Zusammenfassung

• Datensparsamkeit

• Beschreibung

• Die Identifikation innerhalb einer DiGA muss nicht über Angaben zur Person erfolgen, daher kann er obligatorische Eintrag hier schwierig sein, jedenfalls kann die DiGA nicht sicherstellen, dass die Versichertennummer oder andere Angaben zur Person, die der/die Nutzende vornimmt, korrekt sind. Daher sollten alle Angaben hier möglich aber nicht verpflichtend sein.
  Im übrigen stimme ich dem vorherigen Kommentator hier zu.

• Key

• DIGA1X0X0-72

• Erstellt

• 12.12.2021

• Portallink

• 1.1.5 Name, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Pseudonyme Nutzung

• Beschreibung

• Für den DiGA-Hersteller ist und bleibt der Patient üblicherweise pseudonym. Wie wird dieses ausgedrückt? Im "normalen" FHIR würde ich eine pid angeben und einen ansonsten leeren HumanName mit use=anonymous (siehe <span class="nobr"><a href="https://www.hl7.org/fhir/valueset-name-use.html" class="external-link" rel="nofollow">https://www.hl7.org/fhir/valueset-name-use.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>). Im MIO sind aber Vor- und Nachname Pflichfelder, so dass das nicht geht. Wie soll ausgedrückt werden, dass der Patient durch den DiGA-Hersteller nicht identifiziert wurde?

• Key

• DIGA1X0X0-71

• Erstellt

• 12.12.2021

• Portallink

• 1.1.1 Identifikator, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Abweichung zwischen Modell und Simplifier

• Beschreibung

• Auf dieser Seite sind 6 Optionen für die ID aufgeführt, im Simplifier finde ich auf der Seite <span class="nobr"><a href="https://simplifier.net/dtk/kbvprmiodigapatient" class="external-link" rel="nofollow">https://simplifier.net/dtk/kbvprmiodigapatient^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> aber nur 5 Optionen. Was gilt?

• Key

• DIGA1X0X0-70

• Erstellt

• 12.12.2021

• Portallink

• 2. Abschnitte, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Geräteeinstellungen

• Beschreibung

• 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.

• Key

• DIGA1X0X0-69

• Erstellt

• 12.12.2021

• Portallink

• 2.2 Vitalzeichen und Körpermaẞe, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• abgeleitete Messwerte unterstützen

• Beschreibung

• 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.

• Key

• DIGA1X0X0-68

• Erstellt

• 12.12.2021

• Portallink

• 2.2 Vitalzeichen und Körpermaẞe, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Umgang mit berechneten Werten

• Beschreibung

• 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?

• Key

• DIGA1X0X0-67

• Erstellt

• 12.12.2021

• Portallink

• Übergreifende Operationalisierungshinweise, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Datenspende für die Forschung

• Beschreibung

• 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?

• Key

• DIGA1X0X0-66

• Erstellt

• 12.12.2021

• Portallink

• FHIR®, Phase I

• Name

• Veselin Markov

• Organisation

• adesso SE

• Zusammenfassung

• Zusätzliche FHIR-Ressourcen

• Beschreibung

• 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
  1. bis wann die DiGA verwendbar ist
  2. ist es ein Probelauf ohne ärztliche Verordnung
  3. wurde sie selbst oder auf Rezept durch die Krankenkasse bezahlt.
  Vielleicht ist FHIR-CarePlan hier eine Option das umzusetzen.

• Key

• DIGA1X0X0-58

• Erstellt

• 11.12.2021

• Portallink

• 2.2 Vitalzeichen und Körpermaẞe, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Erweiterbarkeit

• Beschreibung

• 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.

• Key

• DIGA1X0X0-57

• Erstellt

• 11.12.2021

• Portallink

• Observation_Diary_Entry, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Umgang mit Standard-Fragebögen

• Beschreibung

• 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.

• Key

• DIGA1X0X0-56

• Erstellt

• 11.12.2021

• Portallink

• Observation_Diary_Entry, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• QuestionnaireResponse

• Beschreibung

• eigentlich ist ja weniger der Fragebogen, als vielmehr die Antworten interessant. Wo findet sich die Möglichkeit, die entsprechendnen QuestionnaireResponse Ressourcen in das DiGA-MIO zu packen?

• Key

• DIGA1X0X0-55

• Erstellt

• 11.12.2021

• Portallink

• 2. Abschnitte, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Vollständige Abbildung der DiGA-Inhalte muss möglich sein

• Beschreibung

• Auch wenn die aufgeführten Abschnitte sicherlich sehr viele denkbare Inhalte einer DiGA abdecken, so ist doch nicht sichergestellt, dass jede DiGA alle bei der betroffenen Person erhobenen Daten über das DiGA-MIO ausspielen kann. Damit wird es DiGA geben, für die das DiGA-MIO nicht die Anforderung aus Art. 20 DSGVO (Datenportabilität) erfüllt. Hiermit müssen diese DiGA über die Vorschriften zum Export in die ePA hinaus ein weiteres interoparables Exportformat implementieren. Dies sollte vermieden werden. Die einfachste Lösung wäre, dass Hersteller das MIO über die von FHIR definierten Mechanismen so erweitern können, dass alle über eine EInwilligung erhobenen Inhalte abdeckbar sind. Wenn man dabei modifierExtensions ausschließt, wäre das auch für die Interoperabilität des DiGA-MIO unproblematisch.

• Key

• DIGA1X0X0-54

• Erstellt

• 11.12.2021

• Portallink

• 1.3 Metainformation, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Version des DiGA MIO

• Beschreibung

• Das DiGA-MIO soll fortgeschrieben werden. Wo findet sich die Angabe, welcher Version des DiGA-MIO die in die ePA eingestellten Daten folgen?

• Key

• DIGA1X0X0-53

• Erstellt

• 11.12.2021

• Portallink

• 1.1 Versicherte Person, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Pseudonyme Verarbeitung darf nicht durchbrochen werden

• Beschreibung

• Aktuell erhält der DiGA-Hersteller im Rahmen der Verordung/Bewilligung nur einen Freischaltcode, der keine identifizierenden Informationen enthält. Damit ist der Nutzer für den Hersteller pseudonym. Es ist (für die meisten DiGA) kein Zweck erkennbar, der ein Aufbrechen der so möglichen pseudonymen Verarbeitung erfordern würde. Im DiGA-MIO muss es daher der Standardfall sein, dass eine Identifizierung erleichternde Angaben wie Name, Kontaktdaten, Geburtsdatum NICHT angegeben werden. Dies sollte sich entsprechend in den Beschreibungen dieser Datenfelder wiederfinden.

• Key

• DIGA1X0X0-52

• Erstellt

• 11.12.2021

• Portallink

• 1.1.5 Name, Phase I

• Name

• Jörg Caumanns

• Organisation

• fbeta GmbH

• Zusammenfassung

• Pseudonyme Verarbeitung darf nicht durchbrochen werden

• Beschreibung

• Aktuell erhält der DiGA-Hersteller im Rahmen der Verordung/Bewilligung nur einen Freischaltcode, der keine identifizierenden Informationen enthält. Damit ist der Nutzer für den Hersteller pseudonym. Es ist (für die meisten DiGA) kein Zweck erkennbar, der ein Aufbrechen der so möglichen pseudonymen Verarbeitung erfordern würde. Es darf daher nicht sein, dass nur für die Zwecke des DiGA-MIO ein Name (oder andere identifizierende Daten) angegeben werden muss und damit die pseudonyme Verarbeitung durchbrochen wird. Die Angabe eines Namens muss daher optional sein.

• Key

• DIGA1X0X0-51

• Erstellt

• 10.12.2021

• Portallink

• 3.3 Arzneimittel - frei, Phase I

• Name

• Dr. med. Amin-Farid Aly

• Organisation

• Bundesärztekammer

• Zusammenfassung

• Struktur der Medikationsangaben

• Beschreibung

• 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?

• Key

• DIGA1X0X0-50

• Erstellt

• 10.12.2021

• Portallink

• 1.4.1.1 Quelle der Information, Phase I

• Name

• Hanna Pfenning

• Organisation

• HÄVG Hausärztliche Vertragsgemeinschaft AG

• Zusammenfassung

• Tippfehler

• Beschreibung

• Code-Tabelle, zweite Zeile, erste Zelle. Tippfehler im Wort "Nicht-Familienmitglied".

• Key

• DIGA1X0X0-49

• Erstellt

• 10.12.2021

• Portallink

• In der ePA zu speichernde FHIR®-Ressourcen, Phase I

• Name

• Hanna Pfenning

• Organisation

• HÄVG Hausärztliche Vertragsgemeinschaft AG

• Zusammenfassung

• Interpretation/Aggregation der Daten

• Beschreibung

• 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.

• Key

• DIGA1X0X0-48

• Erstellt

• 10.12.2021

• Portallink

• In der ePA zu speichernde FHIR®-Ressourcen, Phase I

• Name

• Hanna Pfenning

• Organisation

• HÄVG Hausärztliche Vertragsgemeinschaft AG

• Zusammenfassung

• Archivierung der Daten

• Beschreibung

• Eine dauerhafte Fortschreibung der Daten ist aus unserer Sicht nicht zielführend und bietet insb. den behandelnden Ärztinnen und Ärzten nach einer gewissen Zeit keinen Mehrwert. Wir möchten daher anregen, über eine Archivierung der erhobenen Daten nachzudenken, die als solche gekennzeichnet auch in der ePA verbleiben kann.

• Key

• DIGA1X0X0-47

• Erstellt

• 10.12.2021

• Portallink

• Composition, Phase I

• Name

• Hanna Pfenning

• Organisation

• HÄVG Hausärztliche Vertragsgemeinschaft AG

• Zusammenfassung

• Verpflichtende Angabe des "Performers"

• Beschreibung

• 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.

• Key

• DIGA1X0X0-46

• Erstellt

• 10.12.2021

• Portallink

• 1.1.7 Bevorzugte Sprachen, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• natürliche Sprache vs. Anzeigesprache

• Beschreibung

• 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.

• Key

• DIGA1X0X0-45

• Erstellt

• 09.12.2021

• Portallink

• 1.1.2 Anschrift, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• fehlende Zweckbestimmung

• Beschreibung

• Wir haben aus Sicht der technischen Schnittstellen (vgl. gematik-Spec gemF_ePA_DiGA_Anbindung) keine Notwendigkeit gefunden, die Anschrift des Versicherten zu erfassen. Auch ergibt sich für den ePA-Eintrag kein Mehrwert, da die Anschrift des Versicherten bereits in dessen Stammdaten hinterlegt ist.
  Auch sehen wir bei den aktuellen DiGAs keine therapeutischen Gründe, die für die Erfassung der Adressdaten des DiGA-Nutzers sprechen.
  Im Sinne "privacy by design" (vgl. DSGVO) sollten DiGA-Hersteller nicht verpflichtet werden, Adressdaten zu erfassen.
  Wir empfehlen daher, die Erfassung von Adressdaten zu ersatzlos zu streichen.

• Key

• DIGA1X0X0-44

• Erstellt

• 09.12.2021

• Portallink

• 1.1.3 Administratives Geschlecht, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• fehlende Zweckbestimmung

• Beschreibung

• Wir haben aus Sicht der technischen Schnittstellen (vgl. gematik-Spec gemF_ePA_DiGA_Anbindung) keine Notwendigkeit gefunden, das administrative Geschlecht des Versicherten zu erfassen. Auch ergibt sich für den ePA-Eintrag kein Mehrwert, da das Geschlecht des Versicherten bereits in dessen Stammdaten hinterlegt ist.
  Es kann therapeutische Gründe geben, das Geschlecht des DiGA-Nutzers abzufragen. Im Sinne "privacy by design" (vgl. DSGVO) sollten DiGA-Hersteller aber nicht verpflichtet werden, dieses zu erfassen.
  Wir empfehlen, die verpflichtende Angabe des administrativen Geschlechts ersatzlos zu streichen, mindestens aber als optional zu deklarieren.

• Key

• DIGA1X0X0-43

• Erstellt

• 09.12.2021

• Portallink

• 1.1.4 Geburtsdatum, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• fehlende Zweckbestimmung

• Beschreibung

• Wir haben aus Sicht der technischen Schnittstellen (vgl. gematik-Spec gemF_ePA_DiGA_Anbindung) keine Notwendigkeit gefunden, das Geburtsdatum des Versicherten zu erfassen. Auch ergibt sich für den ePA-Eintrag kein Mehrwert, da das Geburtsdatum des Versicherten bereits in dessen Stammdaten hinterlegt ist.
  Es kann therapeutische Gründe geben, das Alter des DiGA-Nutzers abzufragen. Im Sinne "privacy by design" (vgl. DSGVO) sollten DiGA-Hersteller aber nicht verpflichtet werden, das Geburtsdatum zu erfassen.
  Wir empfehlen, die verpflichtende Angabe des Geburtsdatum ersatzlos zu streichen, mindestens aber als optional zu deklarieren.

• Key

• DIGA1X0X0-42

• Erstellt

• 09.12.2021

• Portallink

• 1.1.1 Identifikator, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• Nur 10-stellige KVNR in ePA verwendbar?

• Beschreibung

• Wie oben richtig aufgelistet, bietet das FHIR-Profil die Möglichkeit, derzeit 6 Identifikatoren für versicherte Personen zur verwenden. Wir sind uns unsicher, ob diese mit Blick auf die gematik-Spezifikationen gemF_ePA_DiGA_Anbindung und gemILF_PS_ePA_V2.0.0 im produktiven Umfeld wirklich alle zum Einsatz kommen können. In gemILF_PS_ePA_V2.0.0 liegt der Fokus recht eindeutig auf der 10-stelligen KVNR. In gemF_ePA_DiGA_Anbindung sind wir uns nicht 100%ig sicher, denken aber auch hier, dass vorrangig die 10-stellige KVNR gemeint ist (vgl. Beispiele dort).
  Wir empfehlen daher, vor Verabschiedung des MIO zu prüfen, ob aktuelle ePA-Systeme mit Identifikatoren anders als der KVNR umgehen können.

• Key

• DIGA1X0X0-41

• Erstellt

• 09.12.2021

• Portallink

• 1.1 Versicherte Person, Phase I

• Name

• Marco Wagner

• Organisation

• W1 Software Engineering GmbH

• Zusammenfassung

• Detaillierte Erfassung von Patientendaten durch DiGA nicht datenschutzkonform

• Beschreibung

• Bezugnehmend auf die Spezifikationen der gematik (insb. gemF_ePA_DiGA_Anbindung) werden DiGA-Primärsysteme wie Primärsysteme auf Leistungserbringerseite behandelt. Diesem Ansatz folgend, wird für das DiGA-MIO das FHIR-Profil KBV_PR_MIO_DIGA_Patient verwendet zur Übertragung von Versichertendaten, was aus Sicht der Interoperabilität ein nachvollziehbarer Ansatz ist. Allerdings setzt dieses Profil betreffend seiner Vielzahl Pflichtfelder auch voraus, dass das betreffende Softwaresystem die Möglichkeit bietet, diese Daten auch zu erfassen und zu verwalten. Aus Sicht der DiGA-Hersteller ist diese Anforderung nicht praktikabel. Im Einzelnen wird in den Kommentierungen der Unterkapitel darauf eingegangen.
  Grundsätzlich sollten im Sinne "privacy by design" (vgl. DSGVO) DiGA-Hersteller NICHT mit der Erfassung und Speicherung von Daten beauftragt werden, für die keine explizite Zweckbestimmung vorliegt. Eine Zweckbestimmung liegt aus unserer Sicht genau dann vor, wenn Patientendaten aus therapeutischen Zwecken erhoben werden müssen oder es die Anbindung an die ePA aus technischer Sicht notwendig macht.

• Key

• DIGA1X0X0-40

• Erstellt

• 09.12.2021

• Portallink

• FHIR®, Phase I

• Name

• Thomas Liebscher

• Organisation

• Philips GmbH

• Zusammenfassung

• Allgemeine Bemerkung

• Beschreibung

• Es finden häufig unnötige Einschränkungen im Rahmen der Profilierung statt. Das macht es internationalen Anwendungen schwer, konform mit dem Profil zu sein, wenn man nicht gezielt dafür entwickelt. Das wiederum erhöht den Aufwand für internationale Anbieter.

  Im Sinne einer offenen und wiederverwendbaren Spezifikation müssen unnötige Einschränkungen und Extensions soweit es geht vermieden werden. Eine Kompatibilität von DIGAs/Apps/Anwendungen rein mit der Basisspezifikation muss immer noch eine Weiterverwendung durch EPA (und MIOs) nutzende Anwendungen ermöglichen. Wir leben in Europa mit einem europäischen Binnenmarkt. Lasst uns offene Spezifiktionen entwickeln und nicht solche eingeengten.

• Key

• DIGA1X0X0-39

• Erstellt

• 09.12.2021

• Portallink

• Patient, Phase I

• Name

• Thomas Liebscher

• Organisation

• Philips GmbH

• Zusammenfassung

• Profiling zu eng durchgeführt

• Beschreibung

• Es finden häufig unnötige Einschränkungen im Rahmen des Profiles statt. Das macht es internationalen Anwendungen schwer, konform mit dem Profil zu sein, wenn man nicht gezielt dafür entwickelt. Das wiederum erhöht den Aufwand für internationale Anbieter.

  Beispiele:
  Patient.text.status wird eingeschränkt auf “extensions”. Es kann aber in Zukunft wünschenswert sein, dass eine nicht spezifisch auf den deutschen Markt entwickelte Anwendung (das DIGA Modell soll von Frankreich und Belgien übernommen werden) im europäischen Ausland / Binnenmarkt Informationen in strukturierter Form über einen deutschen Staatsbürger in die EPA bereitstellt.

  Patient.communication.language wird auf eine einzige Sprache eingeschränkt. Auch hier sollte Flexibilität beibehalten werden. Ein Patient kann mehrere Sprachen beherrschen. Welche er jetzt warum verwendet hat in der DIGA/App kann unterschiedliche Gründe haben. Es sollte daher weiterhin möglich sein, mehrere Sprachen anzugeben.

  Diese Einschränkungen haben keine Berechtigung aus dem beschriebenen Use Case. Im Sinne einer offenen und wiederverwendbaren Spezifikation müssen Einschränkungen soweit es geht vermieden werden.

• Key

• DIGA1X0X0-38

• Erstellt

• 08.12.2021

• Portallink

• Übergreifende Operationalisierungshinweise, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• Anregung für Export-Test

• Beschreibung

• Keine inhaltliche Rückmeldung zur spezifischen Seite, sondern generell zur Operationalisierung der Einbindung.

  Um einen möglichst reibungslosen Export bei allen DiGA-Anbietern zu ermöglichen, wäre die Bereitstellung einer Art "MIO-Viewers" ein nützliches Tool. So könnten Beispielexports der Hersteller erstellt werden und über das Viewer-Tool wieder eingeladen und betrachtet (analog wie ein Behandler die Daten sehen würde). So könnte schon Hersteller-intern sichergestellt werden, dass alle Angaben so im Zielsystem erscheinen, wie angedacht.
  Eine inhaltliche Prüfung der Richtigkeit eines Exports durch eine externe Prüfstelle ist zwar durchaus möglich, aber eine Hersteller-interne Preview könnte den Prozess und das debuggen vereinfachen.

  Gleichzeitig wäre die Bereitstellung von Beispiel-Exports zum DiGA-Import hilfreich, um sicherzustellen, dass die Informationen so eingeladen werden können, wie erwünscht.

• Key

• DIGA1X0X0-37

• Erstellt

• 08.12.2021

• Portallink

• 4.2.1 Code, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• Ggf. Erwähnung von LOINC®

• Beschreibung

• 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 Bevorzungung von SNOMED über LOINC nicht ableiten lässt. Beide System sind an den entsprechenden Stellen sinnvoll ausgewiesen.

• Key

• DIGA1X0X0-36

• Erstellt

• 08.12.2021

• Portallink

• 3.1 Ergebnis - frei, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• FHIR-Mapping keine Verlinkung stattdessen %%

• Beschreibung

• Statt den FHIR-Mappings sind im gesamten Abschnitt (inkl. der Unterseiten!) Referenzen mit %% angegeben.

  z.B. auf dieser Seite "%KBV_PR_MIO_DIGA_Observation_Result_Free|KBV_PR_MIO_DIGA_Observation_Result_Free%"

  Wenn das so gedacht ist, könnte eine Erläuterung hilfreich sein.

• Key

• DIGA1X0X0-35

• Erstellt

• 08.12.2021

• Portallink

• 3.1.1 Identifikator - UUID, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• FHIR-Mapping hat keine Verlinkung

• Beschreibung

• Statt einer Verlinkung ist
  "%KBV_PR_MIO_DIGA_Observation_Result_Free|KBV_PR_MIO_DIGA_Observation_Result_Free.identifier%" angegeben

• Key

• DIGA1X0X0-34

• Erstellt

• 08.12.2021

• Portallink

• 1.3.1 Erstellungsdatum, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• Ggf. Ergänzen zu "Erstellungsdatum des Eintrags"

• Beschreibung

• Der Begriff "Erstellungsdatum" könnte als Erstellungsdatum des Accounts beim jeweiligen DiGA-Anbieter missverstanden werden.
  Vermutlich ist hiermit lediglich das Datum der Eintragung der DiGA-Daten gemeint. Die Überschrift könnte noch leicht angepasst werden, um dies klarer zu kommunizieren.

• Key

• DIGA1X0X0-33

• Erstellt

• 08.12.2021

• Portallink

• 2.6.1.2 Code/Bezeichnung, Phase I

• Name

• Andrea Essenwanger

• Organisation

• BIH@Charité

• Zusammenfassung

• warum code.coding auf max. Kardinalität von 1?

• Beschreibung

• Wir haben uns in unserem Team gefragt, warum hier entschieden wurde auf die von FHIR gegebene Möglichkeit mehrere Codings zu einem einzelnen CodeableConcept zu vergeben zu verzichten und das Profil dadurch stringenter gemacht wurde. Da auch kein Binding vorhanden ist, würde dies ja bedeuten dass es auch ziemlich wahrscheinlich ist, dass wenn sich Entwickler:innen dazu entscheiden hier einen Code zu vergeben, die Gefahr besteht bei den unterschiedlichen Umsetzungen auch immer unterschiedliche CodeSystems zu haben. Das erlauben von mehreren Codings, würde hier ja nicht bedeuten, dass man mehrere Konzepte abbildet, sondern mehrere Codes (Codings) für ein und das selbe Konzept angeben kann. Da außerdem in einzig erlaubten Coding Element zusätzlich fast alle Elemente mandatory gemacht worden sind, würde dies aus unserer Sicht die Verwendung von Freitext fördern, auch wenn vielleicht doch ein Code vorhanden wäre, und somit weniger maschinen-lesbar machen.

• Key

• DIGA1X0X0-32

• Erstellt

• 08.12.2021

• Portallink

• 1.1.5.2 Geburtsname, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• Geburtsname im Sinne der Datensparsamkeit optional machen

• Beschreibung

• Während der Vor- und Nachname ggf. zu einer Identifizierung notwendig sein könnte (siehe Kommentar auf entsprechender Seite), erschließt sich eine verpflichtende Erhebung und Übermittelung des Geburtsnamens im Rahmen der DiGAs nicht.

  Hier sollte im Sinne der Datensparsamkeit nur eine optionale Übermittlung vorgeschrieben sein, um DiGA-Hersteller nicht dazu zu verpflichten, diese - für die Behandlung unnötigen - Daten zu erfassen.

• Key

• DIGA1X0X0-31

• Erstellt

• 08.12.2021

• Portallink

• 1.1.5.1 Name, Phase I

• Name

• Marvin Franke

• Organisation

• HelloBetter

• Zusammenfassung

• Vor- und Nachname nicht zwangsläufig Teil der DiGA-Daten

• Beschreibung

• Im Rahmen der DiGA-Behandlung ist eine Erfassung der Vor- und Nachnamen nicht zwangsläufig nötig. Dem scheint entsprechend Rechnung getragen zu werden, dass das Szenario selbst nur "Required" ist. Vor- und Nachname werden dahingengen als "Mandatory" festgelegt.
  Hier wäre eine Klassifizierung im Sinne der Datensparsamkeit wünschenswert.

  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.

• Key

• DIGA1X0X0-30

• Erstellt

• 06.12.2021

• Portallink

• MedicationStatement_Medication_Request_Free, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Anforderungen an Codierung des Medikamentes zu hoch

• Beschreibung

• Es ist davon auszugehen, dass man bei vom Patienten selbst erfassten Medikamenten oft nur einen String bzw. den Handelsnamen des Medikamentes ("Aspirin") wird erheben können. Die Anforderung, hier auf strukturierte, codierte Merkmale eines Medikamentes zu referenzieren sind für DiGas vermutlich sehr schwer umzusetzen. Es sollte in Betracht gezogen werden, hier auch einfach nur medicationReference.display zu erlauben, ohne Link auf eine Medication-Ressource

• Key

• DIGA1X0X0-29

• Erstellt

• 06.12.2021

• Portallink

• Observation_Assessment_Score_Free, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Generelle Guidance zum Ungang mit Scores und Skalen fehlt

• Beschreibung

• Wir haben die Problematik beim Umgang mit Scores und (Nominal-/Ordinal-/Kardinal-)Skalen im Technischen Komitee für FHIR bei HL7 Deutschland aufgegriffen und sind dabei, eine generelle Guidance für den Umgang mit Scores und Skalen zu entwickeln. Wir würden uns hierbei über die Kooperation mit der MIO42 und ein Alignment der gemeinsamen Ergebnisse mit dem DiGa-Baukasten freuen. Die Diskussion erfolgt transparent über die FHIR-Community. Interessierte Entwickler/Hersteller sind ebenfalls eingeladen, sich an der Erarbeitung der Empfehlungen zu beteiligen: <span class="nobr"><a href="https://chat.fhir.org/#narrow/stream/179183-german-.28d-a-ch.29/topic/Skalen.20und.20Scores" class="external-link" rel="nofollow">https://chat.fhir.org/#narrow/stream/179183-german-.28d-a-ch.29/topic/Skalen.20und.20Scores^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

• Key

• DIGA1X0X0-28

• Erstellt

• 02.12.2021

• Portallink

• 2.4 Nahrung, Phase I

• Name

• Markus Bentrup

• Organisation

• Emperra GmbH

• Zusammenfassung

• Aufgenommene Kohlenhydratmengen ("Broteinheiten") für Diabetiker:innen

• Beschreibung

• 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. <span class="nobr"><a href="https://de.wikipedia.org/wiki/Broteinheit" class="external-link" rel="nofollow">https://de.wikipedia.org/wiki/Broteinheit^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

• Key

• DIGA1X0X0-23

• Erstellt

• 22.11.2021

• Portallink

• ConceptMaps, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Deutsche Übersetzungen für AdministrativGender sind bereits publiziert

• Beschreibung

• Siehe <span class="nobr"><a href="https://simplifier.net/basisprofil-de-r4/administrative-gender-supplement" class="external-link" rel="nofollow">https://simplifier.net/basisprofil-de-r4/administrative-gender-supplement^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
  HL7 Deutschland ist die authoritative Quelle für Übersetzungen, sofern es Terminologien von HL7 betrifft.

• Key

• DIGA1X0X0-22

• Erstellt

• 22.11.2021

• Portallink

• Device_DIGA, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Device.identifier unklar (fortsetzung)

• Beschreibung

• Sorry, ich hatte bei meinem vorherigen Kommentar übersehen, dass der Identifier.type durch ein Pattern definiert ist.
  Es ist also der Typecode "RI" (Resource Identifier) gesetzt.

  Dann muss ich jetzt aber fragen, was der Unterschied zwischen einem Identifier vom Typ "RI" und der ID der Ressource (Device.id) ist und warum man beides braucht...

• Key

• DIGA1X0X0-21

• Erstellt

• 22.11.2021

• Portallink

• Device_DIGA, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Device.identifier unklar

• Beschreibung

• System ist gefixed auf urn:ietf:rfc:3986, aber es ist dennoch unklar, ob hier eine UUID, OID oder URL o.ä. erwartet wird.
  Type ist verpflichtend, aber Werte sind nicht vorgegeben. Sollte bei URNs eigentlich nicht erforderlich sein. Der Typ ist ja bereits durch das System implizit.

  Falls unbedingt gewünscht, bitte Type vorgeben, ich wüsste jetzt nicht, welchen man da nehmen sollte...

• Key

• DIGA1X0X0-20

• Erstellt

• 22.11.2021

• Portallink

• Observation_Assessment_Score_Free, Phase I

• Name

• Simone Heckmann

• Organisation

• Gefyra GmbH

• Zusammenfassung

• Reference Range sollte unbedingt erlaubt sein (bei exotischen Skalen sogar verpflichtend!?)

• Beschreibung

• Insbesondere bei einem "freien" Profil, muss davon ausgegangen werden, dass hier Assemenst-Tools zum Rinsatz kommen, die der Empfänger nicht kennt und nicht zu interpretieren weiß. Daher sollte es unbedingt möglich (wenn nicht sogar erforderlich) sein, die Referenz-Bereiche und deren (textuelle) Interpretation mitzugeben:

  "Irritable Bowel Syndrome Symptom Severity Score = 115" sagt keinem was, aber zusammen mit der Info zu den Referenzbereichen

  <ul class="alternate" type="square">
• 0-74 → sehr milde Symptome
• 75-174 → milde Symptome
• 175-299 → moderate Symptome
• 300-500 → schwere Symptome

ist der Wert aussagefähig.