Stellungnahmen

<strong>Grundsätzliche Einschätzung</strong>
Die Bundesärztekammer begrüßt die Transparenz der Arbeiten der KBV insbesondere hierbei ausdrücklich die Einbeziehung der medizinischen Fachgesellschaften an den Arbeiten für das Medizinische Informationsobjekt (MIO) Impfpass.
Die Bundesärztekammer stimmt der inhaltlichen Ausarbeitung der Datenobjekte für den Impfpass zu. Alle inhaltlich notwendigen Informationen über eine Impfung können erfasst werden.
Die Bundesärztekammer hält die Nutzung der qualifizierten elektronischen Signatur mittels des elektronischen Heilberufsausweises für die Dokumentation von einzelnen Impfungen im elektronischen Impfpass für angemessen und sinnvoll.

<strong>Abgrenzung der Bewertung</strong>
Die Bundesärztekammer sieht es nicht als ihre Aufgabe an, die Verknüpfung der medizinischen Inhalte zu Terminologiesystemen (SNOMED) oder Ressourcen (hier FHIR) im Einzelnen zu überprüfen. Inwiefern die vorgeschlagenen Value Sets sinnvoll und praktikabel sind, wird sich erst bei Gebrauch dieser Listen zeigen. Daher empfiehlt die Bundesärztekammer MIOs entsprechend vorab ausreichend zu testen.

<strong>Vollständigkeit des Impfpasses</strong>
Die Bundesärztekammer legt großen Wert auf die Vollständigkeit der Informationen eines Impfpasses. Der elektronische Impfpass sollte mehr als eine Sicht auf einzelne Impfungen sein, die der Patient zur Ansicht freigegeben hat. In einem Impfpass sollten vollständig alle Impfungen aufgeführt sein. Einzelne Impfungen dürfen vom Patienten nicht selbstständig entfernt werden können.
Zumindest sollten aber alle Impfungen von einer Instanz (das könnte auch ein MIO sein) zusammengehalten werden. Der Patient sollte in die elektronische Patientenakte (ePA) nur den kompletten Impfpass einstellen und nicht nur einzelne vom Patienten ausgewählte Impfungen. Die Bundesärztekammer empfiehlt den Impfpass als geschlossenes Dokument zu betrachten, das die gesamte Impfdokumentation eines Patienten enthält. Genauso wie jetzt der Impfpass als Papierdokument die einzelnen Einträge zusammenhält, muss es auch eine digitale Möglichkeit geben, die Informationen beieinander zu halten.

Wir bedanken uns für die Gelegenheit zur Stellungnahme und bitten um die Berücksichtigung der folgenden Aspekte :

Generelle Punkte:
Konzept „CodeSystem“:
Im Kontext des Impfpasses wird „CodeSystem“ verwendet, wenn keine deutschsprachige Übersetzung der zugrundeliegenden ValueSets vorliegt. Es wird nicht klar, ob dieses Vorgehen aufgegeben wird, wenn deutschsprachige Übersetzungen der ValueSets (SNOMED CT, LOINC Terme) verfügbar sind. Wir empfehlen entsprechende Erklärungen für die Anwender zur Verfügung zu stellen.

Alternativen ValueSets+CodeSystem – Bedeutung für Software-Nutzer und „CrossBorder“Aktivitäten:
Es wird nicht klar, was die Bereitstellung von alternativen ValueSets sowie eines inhaltsgleichen CodeSystems für Softwareenutzer und ein CrossBorder Szenario bedeutet. Müssen alle 3 Alternativen als Ausgangs-Strukturen auf europäische Referenzsysteme im MVC gemappt werden? Oder kann die Festlegung auf je ein einziges ValueSet im Sinne eines „Preferred Set“ getroffen werden? Wir bitten um Klarstellung und ggf. um Festlegung auf das Preferred Set.

Identische Bezeichnung von Code und Term in CodeSystem:
Üblicherweise werden Informationen kodiert, um diese sprachunabhängig zu halten, komplexe Entitäten zu bezeichnen und technisch gut interpretierbar zu sein. Ist es sinnvoll, im CodeSystem den Code und den Term gleich zu benennen (insb. bei Lab Titer Antibody Presence, Immunization origin codes, Practitioner, Source of information)? Wir empfehlen zu überprüfen, ob hier z.B. eine sprachunabhängige Nummerierung eingesetzt werden kann, die sich systematisch über alle MIOs erstreckt.

Erweiterung des Informationsmodells Impfstoff um „Wirkstoff“ und „wirksamkeitsbestimmender Stoff“, sobald ein geeignetes Codesystem (SPOR ISO IDMP) bzw. eine Referenzdatenbank § 31b SGB V verfügbar ist:
Zusätzlich zu Handelsnamen, Hersteller, PZN, Chargenbezeichnung, ATC bzw. SNOMED CT Code sollten weitere, genauere Informationen zum Wirkstoff und zu den Adjuvantien mit aufgenommen werden, da der ATC-Code hier nicht ausreichend Information insbesondere für klinische Fragen zu Impfreaktionen, Boosterung etc. bietet. Wirkstoffe und Adjuvantien sollten zusätzlich (optional) erfasst werden, insbesondere weil (historische) Informationen über die lebenslange Laufzeit eines Impfpasses oft nicht mehr nachgehalten werden können.

Spezifische Punkte:
LAB TITER ANTIBODY PRESENCE - Bezeichnung der Entität:
Im ValueSet werden nicht nur „antibodies“ abgebildet. Sollte die Benennung des ValueSets, Conceptmap dem Rechnung tragen?

LAB TITER ANTIBODY PRESENCE - ValueSet: Information zur Ausprägung / Nachweisbarkeit separat oder im Code:
Warum wird beim Mendel-Mantoux Test und beim Tuberkulose-Interferon-Gamma Test die Ausprägung (positiv und negativ) mit in den Code genommen? Wir empfehlen, diese Einträge zu überprüfen und die Ausprägung ggf. separat anzugeben.

LAB TITER ANTIBODY PRESENCE - ValueSet: Bereitstellung des LOINC LongCommonName in deutscher Übersetzung:
Es ist geplant, den LongCommonName in deutscher Übersetzung über die offizielle Website von LOINC bereitzustellen. Wir empfehlen, die Übernahme der offiziellen Übersetzung dann als DisplayName in das ValueSet zu übernehmen.

LAB TITER ANTIBODY PRESENCE - ValueSet: Nutzung spezifischerer LOINC-Terme, Erweiterung des ValueSets:
Sofern laborseitig spezifischere LOINC Terme (z.B. definierte Terme für Messung von IgG, IgA, IgM) genutzt werden, sollten diese ergänzt werden, ggf. als related Terms in der ConceptMap.

LAB TITER ANTIBODY PRESENCE - ValueSet und ConceptMap: SNOMED CT Term Interferon-gamma-assay und Tuberculose-Test:
Wir empfehlen bei der ConceptMap die Zuordnung für die Tuberkulose-Tests zu überprüfen. Die angegebenen Zuordnung für die folgenden Einträge sind als “equivalent“ angegeben:
22600-1 (Varicella zoster virus Ab <span class="error">[Presence]</span> in Serum) equivalent Tuberkulose-Mendel-Mantoux-Test-positiv (Tuberkulose - Mendel-Mantoux-Test positiv)
26643-7 (Clostridium tetani toxoid Ab <span class="error">[Presence]</span> in Serum) equivalent Tuberkulose-Mendel-Mantoux-Test-negativ (Tuberkulose - Mendel-Mantoux-Test negativ)
30546-6 (Polio virus 1 Ab <span class="error">[Presence]</span> in Serum) equivalent Tuberkulose-Interferon-gamma-assay-positiv (Tuberkulose - Interferon gamma assay positiv)
31998-8 (Bordetella pertussis Ab <span class="error">[Presence]</span> in Serum) equivalent Tuberkulose-Interferon-gamma-assay-negativ (Tuberkulose - Interferon gamma assay negativ)

TARGET DISEASE - Bereitstellung der notwendigen alphaIDs für TargetDisease:
Fehlende alphaIDs (z.B. für Haemophilus Influenzae B) werden für das Publikationsjahr 2021 bereitgestellt. Die alphaIDs werden der KBV zur Verfügung gestellt, sobald sie vorliegen.

TARGET DISEASE - Abbildung von Target Disease mit alphaIDs, die den ICD-10-GM Codes Z23ff zugeordnet sind.
Wir empfehlen zu prüfen, ob für „Target disease“ eine Nutzung der ICD-10-GM Codes unterhalb Z23ff (Notwendigkeit einer Impfung gegen…) gewählt werden sollte. Klassifikatorisch wäre diese Zuordnung korrekt. Sollten bei diesem Kode Einträge in der AlphaID fehlen, so können diese nach Abstimmung ergänzt werden.

PRIOR DISEASE - Kodierung von Prior Disease (ICD):
Im ValueSet werden teilweise nicht-endständige ICD-10-Kodes verwendet. Zur Anwendung kommen in der Morbiditätskodierung nur endständige Kodes mit minimalen Ausnahmen. Wir empfehlen zu überprüfen, ob alle endständigen Kodes zu den jeweiligen Erkrankungen aufgenommen werden sollen oder ob der jeweilige XXX.9-Kode angewendet werden soll.
In diesem Zusammenhang weisen wir darauf hin, dass alle ValueSets zum Impfpass nochmal auf fehlende Kodes aus den verschiedenen Terminologien überprüft werden sollten.

VACCINE - CodeSystem: Übersetzungen der deutschen Terme im CodeSystem Vaccine:
Warum werden im CodeSystem Vaccine die deutschsprachigen Terme des ATC-Codes noch einmal übersetzt, und nicht nur der SNOMED CT Term?
Könnte statt des Eintrags „Impfstoffe unspezifiziert“ eine höhere Hierarchiestufe des ATC-Codes verwendet werden (damit wäre auch eine zweite ConceptMap entbehrlich)? Wir empfehlen eine Überprüfung dieser Einträge.

Im Rahmen der Benehmensherstellung nimmt das Robert Koch-Institut, Fachgebiet Impfprävention, zu dem MIO Impfpass wie folgt Stellung:

Grundsätzlich begrüßt das Robert Koch-Institut die Entwicklung eines elektronischen Impfpasses. Die Dokumentation und Nachvollziehbarkeit von Impfungen wird maßgeblich vereinfacht, Impferinnerungssysteme können etabliert werden und die Hürde des nicht-auffindbaren Impfpasses ist beseitigt. Das Nachholen verpasster Impfungen wird durch den integrierten Algorithmus für die impfenden ÄrztInnen einfacher und die standardisierte Kontrolle des Impfstatus der PatientInnen kann problemlos bei jedem Praxisbesuch erfolgen. Verpassten Impfchancen, einer der wichtigsten Impfhindernisse, kann so konstruktiv begegnet werden.

Es ist anzumerken, dass das Fachgebiet Impfprävention (FG33) nicht von Beginn an in die Entwicklung des MIOs Impfpass einbezogen wurde. Das Fachgebiet Impfprävention konnte bei der Entwicklung eines Impfalgorithmus für die STIKO-App (www.rki.de/stiko-app) bereits wertvolle Erfahrungen sammeln, die es gerne frühzeitig in die Entwicklung des MIO Impfpass eingebracht hätte. Da sich die Empfehlungen der STIKO in unterschiedlichen Zeitabständen fortlaufend verändern und mindestens 1-mal jährlich aktualisiert werden, muss beispielsweise gewährleistet werden, dass der hinterlegte Algorithmus des MIO Impfpass immer und rechtzeitig den angepassten und aktuell gültigen Impfempfehlungen folgt.

Das aufbereitete Informationsmodell (Phase II) für die Benehmensherstellung wurde von uns erneut geprüft, allerdings sind die Änderungen nicht immer transparent angegeben. Zu einigen der von uns abgegebenen Kommentare (z. B. IM1X0-670) erging an uns kein Kommentierungsergebnis.

Daher bitten wir um erneute Prüfung folgender Anmerkungen:

• 2.4. Datum der Folgeimpfung: Es wäre wünschenswert, wenn hier der Mindestabstand der Impfstoffdosen automatisch berücksichtigt werden würde. Auch wenn die Sicherstellung des Mindestabstandes grundsätzlich durch den behandelnden Arzt/ die behandelnde Ärztin zu erfolgen hat, wäre eine automatische Information bei unzureichendem Abstand zur vorherigen Impfstoffdosis eine sinnvolle Ergänzung.

• 2.7 Grundimmunisierung abgeschlossen: Auch hier sollte nach Möglichkeit ein Algorithmus hinterlegt sein, der den behandelnden Arzt/ die behandelnde Ärztin informiert.

• Anmerkungen zu Impfreaktionen: Den Vorschlag, Versicherten „weitere Informationen wie auch Hinweise zur Online-Meldung von Nebenwirkungen“ zu geben, halten wir im Hinblick auf eine vereinfachte Meldung von über das übliche Maß einer Impfreaktion hinausgehenden gesundheitlichen Schädigung für begrüßenswert.

• 4.2 Immunität: Insbesondere im Rahmen des Masernschutzgesetzes tritt die Frage nach der Immunitätsbestimmung immer wieder auf. Diese Information im zur Verfügung stehenden Freitextfeld zu ergänzen oder zu erläutern ist nicht benutzerfreundlich. Es kann nicht davon ausgegangen werden, dass jeder behandelnde Arzt/ jede behandelnde Ärztin weiß, dass beispielsweise bei zweimaliger Masern-Impfung und anschließender Antikörperbestimmung unterhalb des Grenzwertes trotzdem von einer Immunität ausgegangen werden kann.

Einige der weiteren Anmerkungen betrafen die Auflistung von Impfstoffen, die aus dem amtlichen ATC-Index für Deutschland stammen: Einer unserer Vorschläge wäre zum Beispiel, dass klar zwischen der Herpes Zoster-Impfung und der Impfung gegen Windpocken unterschieden werden muss.
Wir bitten daher um Weiterleitung dieser Anmerkungen und Abstimmung mit den entsprechenden Stellen (DIMDI), um das MIO Impfpass für die Endnutzer so benutzerfreundlich wie möglich zu gestalten.

Das MIO Impfpass bewerten wir als eine grundsätzlich gelungene Umsetzung. Das öffentliche Kommentierungsverfahren ist geeignet, um die Umsetzung des MIO transparent zu gestalten. Wie bereits eingangs erwähnt, wäre eine frühere Einbindung des Fachgebiets Impfprävention und der STIKO-Geschäftsstelle wünschenswert gewesen. So hätten neben den Erfahrungen zum Bau eines Impfalgorithmus auch die Rückmeldungen der impfenden Ärzteschaft durch die Impf-Hotline in die Entwicklung des MIO Impfpass Einzug finden können.

Mit freundlichen Grüßen
im Auftrag

Robert Koch-Insititut
Fachgebiet Impfprävention (FG33)

Aus Sicht der Kommission für Infektionskrankheiten und Impffragen der DAKJ begrüßen wir die Einführung eines elektronischen Impfausweises, wir sehen aber auch die Komplexität dieses Unterfangens. Wir möchten in dieser Stellungnahme auf einige zentrale Elemente aus der Sicht des Benutzers eingehen.
Ein elektronischer Impfpass muss von der Gestaltung und Bedienung her einfach sein, damit
1) er ohne große Einarbeitung und ohne viele Fehlermöglichkeiten im Praxisalltag und in anderen relevanten Settings (öffentlicher Gesundheitsdienst, Betriebsarzt etc.) funktioniert,
2) sowohl die Dateneingabe als auch die Ausgabe einfach sind und
3) Benutzer einen relevanten Vorteil im Vergleich zu der bisherigen Dokumentationsform sehen.
4) Die zur Initiierung und Pflege notwendige Software sollte allgemein verfügbar und einsetzbar sein.
Nur dann wird er auch eine breite Akzeptanz finden.

Zur Eingabe von Daten:
Alle (auch zurückliegende Impfungen) sollten dokumentiert werden. Es muss eine Möglichkeit geben, Impfungen, die im Ausland durchgeführt wurden und bei denen etwa die Grundimmunisierung unterschiedlich war, ebenfalls zu dokumentieren. Bei der Grundimmunisierung gibt es Unterschiede hinsichtlich des Schemas, der Applikationszeitpunkte sowie der Zusammensetzung der Impfstoffe.
Änderungen des Impfplanes sind häufig, auch darauf muss sich der elektronische Impfausweis einstellen. So ist es z.B. schon mehrfach vorgekommen, dass die Zahl der Impfungen, die für eine Grundimmunisierung erforderlich ist, verändert wurde oder deren Zeitpunkte angepasst wurden.
Auch zukünftige neue Impfungen sollten problemlos aufgenommen werden können.

Ferner sollte es eine Möglichkeit zur Dokumentation von unerwünschten Wirkungen nach vorangegangenen Impfungen bzw. Informationen zu Kontraindikationen geben.

Dokumentation der Immunität mit Antikörpern: da sollte man sich strikt an die aktuellen gesetzlichen oder STIKO-Vorgaben halten: Dokumentation von Masern-AK bei Ungeimpften; Hepatitis B (anti-HBs). Andere Antikörper nicht, insbesondere keine Röteln-AK und keine Hepatitis-A-AK.

Zur Ausgabe von Impfdaten:
Der Impfpass sollte automatisch freigeschaltet sein, also die durchgeführten Impfungen sind zugänglich wie Notfalldaten. Dadurch kann der Impfausweis bei Kontakt mit einer leseberechtigten Person sofort eingesehen werden und z.B. auf anstehende Impfungen hingewiesen werden.
Der Schweizerische elektronische Impfausweis hat ein gutes Verfahren mit Erinnerungsfunktion an ausstehende und fehlende Impfungen (siehe <span class="nobr"><a href="https://www.meineimpfungen.ch/" class="external-link" rel="nofollow">https://www.meineimpfungen.ch^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>). Dieser ist für Laien einfach zu verstehen und auch für medizinisches Personal einfach anwendbar.
In jedem Fall sollte es eine Pilotphase in Praxen und bei anderen Anwendern geben. Und erst nach Auswertung der hier gewonnenen Erfahrungen sollte eine endgültige Basisform des Ausweises festgelegt werden.

Aus Sicht des Bundesverbandes Gesundheits-IT – bvitg e. V. enthält das MIO zum „Impfpass“ (Impfdokumentation) noch einige Fehler, die im Rahmen der Implementierung und auch bei der anschließenden Nutzung zu Problemen führen werden. Die Fehler müssen behoben werden, bevor das MIO „Impfpass“ freigegeben wird.
Wir bewerten es positiv, dass die KBV generell eine öffentliche Kommentierungsphase anbietet. Diese wurde aus unserer Sicht angenommen und es haben die unterschiedlichsten Stakeholder Kommentare eingereicht. Jedoch werden die Kommentare aus unserer Perspektive nur unzureichend aufgenommen. Intentional sind Kommentierungsrunden dazu gedacht, eine Diskussion über einzelne Punkte anzustoßen, was hier aber nicht erkennbar ist. Anhand der Ergebnisse sehen wir deutlich, wieso die Standardisierungsorganisationen mehrere Kommentierungsrunden durchlaufen. Nur durch solche Iterationen kann ein bestmögliches Ergebnis produziert werden, das nicht durch neue Überarbeitungen neue Fehler injiziert bekommt.
Die eingereichten Kommentare wurden durch die KBV zusammengeführt und beantwortet. Die geleistete Arbeit ist anzuerkennen, jedoch sind bei der Zusammenführung einige Kommentare aus dem Kontext gerissen worden, wodurch eine Rückmeldung im Sinne des eigentlichen Kommentares ausblieb. Um den Prozess in Zukunft transparenter zu gestalten, bitten wir die KBV in den weiteren Verfahren darum, die Antworten direkt unter dem zugehörigen Kommentar zu veröffentlichen. Dies würde den Prozess der Benehmensherstellung deutlich erleichtern.
Teilweise gibt es inhaltlich identische Kommentare. An dieser Stelle wäre es begrüßenswert, wenn es im Rahmen der Kommentierungsphase die Möglichkeit gäbe, bereits vorhandene Kommentare zu unterstützen, z.B. durch einen entsprechenden Button. Dies würde auch die Arbeit der KBV erleichtern, indem doppelte Kommentare vermieden werden und gleichzeitig Rückschlüsse auf die Bedeutung des jeweiligen Kommentars möglich werden.
An einigen Stellen gab es im Vergleich zu der zur Kommentierung veröffentlichten Version grundsätzliche Änderungen in der Spezifikation. Diese erfolgten zum Teil basierend auf Kommentaren in der Kommentierungsphase, jedoch gab es auch Anpassungen, die nicht aus den Kommentaren hervorgehen. An diesen Stellen ist nicht transparent, wieso diese Überarbeitungen vorgenommen wurden. Ein Beispiel hierfür ist die Krankenversichertenkarte, deren Aufnahme wir als überflüssigen Implementierungsmehraufwand sehen, da diese seit 2015 ungültig ist und keine Verwendung mehr findet. Ebenfalls ist nach Abschluss der Kommentierungsphase das administrative Geschlecht Bestandteil der Spezifikation geworden. Solche grundsätzlichen Änderungen müssten erneut zur Kommentierung zur Verfügung gestellt werden, da nur so auszuschließen ist, dass Fehler unentdeckt bleiben.
In einem Prozess der Standardisierungsorganisationen würden die Spezifikation in der aktuellen Fassung nicht bestehen, da sie keine ausreichende Qualität aufweisen. Insgesamt müssen wir konstatieren, dass eine proprietäre Spezifikation vorliegt, die nicht internationalen Standards entspricht. Der aktuelle Prozess dokumentiert sogar, dass die technische Umsetzung (FHIR) nicht konform zu den eigenen Vorgaben („Informationsmodell“) ist.

Anbei finden Sie Beispiel-Kommentare zu einem Teil der Spezifikation, dem Patienten-Profil:

• Informationsmodell: In dem „Informationsmodell“ fehlen die Kardinalitäten und „Konformitäten“ (Optionalitäten). Unklar ist die Modellierungssprache. Zudem gibt es keine eindeutigen Namen für Klassen, wie z.B. den Namen. Nach der Darstellung des Modells gibt es einige Redundanzen. Oder werden z.B. die Namen aus Darstellungsgründen wiederholt? Eine solche Darstellung ist in Informationsmodellen unzulässig und trägt zur Verwirrung bei. Modelle sind wichtig, um einen ersten Überblick sowohl über die Inhalte als auch für die Implementierung zu bekommen. Aus diesem Grund sollten solche Modelle fein säuberlich mit entsprechenden Standards, wie z.B. UML, umgesetzt werden. Welche Informationen stellen die unterschiedlichen Farben dar? Nach unserer Auffassung ist kein Informationsmodell erkennbar.
• Informationsmodell: Was hat es mit dem „klinisch relevanten Zeitraum“ und der „Lebensphase“ auf sich? In dem Modell sind keine weiteren Attribute enthalten.
  Informationsmodell/Erläuterungen: Der Datentyp Count wird an keiner Stelle beschrieben.
• Informationsmodell/Erläuterungen: Das Informationsmodell enthält an einigen Stellen andere Informationen als in den Profilen selbst. An dieser Stelle stellen die Profile keine konforme Umsetzung des Informationsmodells dar. Die Informationen müssen auf allen Ebenen unbedingt überein-stimmen, da es ansonsten zur Verwirrung kommt.
• 1. Patient (administratives Geschlecht): Der Datentyp Count („Informationsmodell“) ist nicht geeignet für das administrative Geschlecht. Hier wird als Datentyp code… benötigt.
• 1. Patient (Geschlecht FHIR-Extension): Die Verlinkungen zu den FHIR-Profilen/Extension führen nicht auf die richtige Seite oder bilden etwas anderes ab, als beschrieben.
• 1.1 Identifier: Mit welcher Begründung wurde die Krankenversichertenkarte (KHK) aufgenommen? Die Karte kann seit Anfang 2015 nicht mehr eingelesen werden. Aus diesem Grunde ist die Eingabe dieser Nummer nicht von Bedeutung. Der Datentyp Count ist an dieser Stelle zudem unpassend.
• 1.2 Name: Geburtsname: der vollständige Name ist in FHIR nicht enthalten, anders als in der Beschreibung und dem Informationsmodell. Was ist hier richtig?
• 1.3 Geburtsdatum: Unklar ist, in welcher Präzision das Geburtsdatum genau angegeben werden soll und wann dieses als valide gilt.

Abschließend möchten wir mitteilen, dass es sich unserer Bewertung nach bei dem MIO um eine Impfdokumentation und nicht um einen Impfpass handelt. Wir würden uns freuen, wenn der Name dementsprechend angepasst wird, um Irreführungen zu vermeiden. Zudem ist es denkbar, dass der Impfpass in Zukunft digitalisiert wird und dieser dann auch in die ePA aufgenommen wird, hier kann es dann zu Problemen im Rahmen der Namensgebung kommen.

I. Allgemeine Anmerkungen

1. Der von der KBV definierte elektronische Impfpass wird unserer Einschätzung nach den papiergebundenen Impfpass sowie Impfbescheinigungen zurzeit leider noch nicht ersetzen können, da zum einen die gesetzliche Grundlage hierfür fehlt (IfSG), zum anderen die ePA eine freiwillige Anwendung ist, die nicht von allen Versicherten genutzt werden wird. D.h., im Allgemeinen wird dennoch ein Impfbucheintrag erstellt oder eine Impfbescheinigung ausgestellt werden müssen. Zusätzlich muss der MIO-Impfpass erstellt und in die ePA eingestellt werden. Dieser stellt eine zusätzliche Information für Versicherte und Leistungserbringer dar, die über die ePA genutzt werden kann. Hieraus ergeben sich einige Implikationen bezüglich Fragen der Signatur, Vermeidung von Doppelerfassungen und Mehraufwänden, sowie der Handhabbarkeit für Versicherte und Leistungserbringer. Unsere Anmerkungen hierzu haben wir an verschiedenen Stellen der Stellungnahme konkretisiert.

2. Die Spezifikation der KBV verfolgt den Ansatz, keinen „Gesamt-Impfpass“ an sich zu spezifizieren sondern „Einträge“ und „Nachträge“ für die ePA. Wir halten dies im Falle des Impfpasses für einen gangbaren Weg. Dennoch werden Versicherte und Leistungserbringer in ihren Frontendes bzw. Primärsystemen eine Gesamt-Ansicht eines Impfpasses oder von Auszügen daraus erwarten. Fragen der Nutzbarkeit können deshalb nur in einer Gesamtbetrachtung von gematik-ePA, MIO Viewer sowie Primärsystemimplementierungen beantwortet werden.

3. Insbesondere beim Zusammenspiel von MIO-Definition, ePA und MIO-Viewer liegt uns noch kein vollständiges Bild vor, z.B. hinsichtlich Metadaten, Rechtevergabe, Recherche/Suche, Darstellung, Handling in der ePA (z.B. Löschen), Primärsystemintegration etc. Wir stellen deshalb fest, dass eine abschließende Beurteilung des elektronischen Impfpasses an Hand der MIO-Definition allein nicht möglich ist. Die MIO-Definition erlaubt nur eine Prüfung der Datenmodellierung und FHIR-Implementierung.

4. Welche Rolle spielen die KBV-Basisprofile in Bezug auf die Benehmensherstellung? Eine Kommentierung dieser Profile durch die DKG wird nicht vorgenommen, da wir davon ausgehen, dass die MIO-spezifischen Ressourcen (Patient etc.) aus diesen Basis-Profilen abgeleitet wurden.

5. Sie werden hier einige Kommentare wiederfinden, die wir bereits in der Kommentierungsphase eingebracht haben. Dies bedeutet, dass wir bezüglich Ihrer Stellungnahme nach wie vor eine andere Einschätzung bzw. weiteren Diskussionsbedarf haben. Zum Teil sind auch einige Dinge nicht (anders als in der Stellungnahme angegeben) umgesetzt worden.

6. Wir haben uns als Spitzenverband der Krankenhausträger darauf konzentriert, ob die MIO-Definitionen für den Krankenhausbereich fachlich passend sind. Insofern lag der Fokus unserer Prüfung auf dem „informativen“ Teil und nicht so sehr auf den FHIR-Profilen, die wir jedoch auch geprüft haben. Es ist deshalb aus unserer Sicht bedauerlich, dass „informativer Teil“ und Spezifikation an einigen Stellen stark divergieren. So gibt es beispielsweise kein Profil „Impfpass“, obwohl hierfür ein Informationsmodell angegeben wird. Entsprechend gibt es FHIR-Profile wie <span class="nobr"><a href="https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Composition_Addendum" class="external-link" rel="nofollow">https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Composition_Addendum^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> für die es kein Gegenstück im informativen Teil gibt.

7. Wie bereits an mehreren Stellen angemerkt, hätten wir es für wünschenswert gehalten, von Anfang an auch PDFs o.Ä. im Rahmen der MIOs zuzulassen, um eine schnelle und breite Nutzung der ePA zu unterstützen (z.B. durch PDF-Export von mit MIO-Metadaten versehenen Impfbescheinigungen in die ePA). Systeme zur strukturierten MIO-Erzeugung müssen erst implementiert und beschafft werden. Systeme zur Erstellung von Impfbescheinigungen, aus denen heraus ein PDF-Export in die ePA möglich wäre, gibt es hingegen schon. Wir befürchten deshalb, dass es einige Zeit dauern wird, bis sich die MIO-Nutzung durchsetzen wird.

8. Mit der Einführung der ePA und der MIOs ist mit einem ganzen „Zoo“ von Impfbüchern und Bescheinigungen zu rechnen: papiergebunde Impfpässe und –Bescheinigungen. Elektronische Varianten hiervon in der ePA als Exporte oder Scans, evtl. auch eingestellt durch den Patienten. Dazu kommen Einträge und Nachträge in MIO-Form in elektronischer Form und als Ausdrucke. Im Hinblick auf eine sinnvolle Nutzung dieser Möglichkeiten durch Versicherte und Leistungserbringer muss eine gemeinsame Klammer geschaffen werden (Metadaten, Verlinkung etc.).

II. Informationsmodell

1. Da kein „Impfpass“ als Ganzes definiert wird, sondern nur Einträge und Nachträge, und nie gesagt wird, wie sich aus diesen ein Impfpass ergibt, ist es nicht sachgerecht, ein Informationsmodell für einen Gesamt-Impfpass anzugeben. Bitte den verfolgten Spezifikationsansatz klarer darstellen, indem man (beispielsweise) das „Informationsmodell eines Impfpasses“ als „Grundgerüst des Informationsmodells für Einträge und Nachträge“ kennzeichnet. Generell würde man ein Informationsmodell auch als Teil einer Spezifikation betrachtetn.

2. Im Hinblick auf den Kommentierungsaufwand wollten wir fragen, ob sich nicht Komplexität reduzieren lässt. Im konkreten Fall gibt es drei Varianten des Informationsmodells sowie z.T. auseinanderlaufende textuelle und grafische Darstellungen plus zusätzlich die FHIR-Profile. Eine kompaktere Darstellung halten wir wünschenswert, insbesondere im Hinblick auf die kommenden komplexeren Dokumente.

A. Patient

1. 1.1. Identifier

a) PID

1. Der Sinn, eine UUID mitzuführen, erschließt sich nicht, zumal diese noch nicht einmal zwingend gefordert ist, so dass man beispielsweise nicht auf eine Eigenschaft, wie global mit hoher Wahrscheinlichkeit eindeutig zu sein, aufsetzen kann. Bitte die UUID streichen, da andere Identifikationsmöglichkeiten gegeben sind.

2. Es ist unklar, was „vorgehende Instanzen“ sind. Wer prüft, ob bereits eine UUID vergeben ist, und was dann passieren soll je nach Ergebnis der Prüfung? Bitte Formulierung anpassen oder Erläuterung einfügen.

3. „Terminologie Assoziation: MR - <span class="nobr"><a href="http://terminology.hl7.org/CodeSystem/v2-0203" class="external-link" rel="nofollow">http://terminology.hl7.org/CodeSystem/v2-0203^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> (nur Name, kein funktionierender Link)“. Unklar, was diese Information bedeutet. Kann nicht geprüft werden.

b) VersichertenID_GKV

1. „VersichertenID_GKV“: Diese ist genau 10 Zeichen lang und nicht 0 bis 10 Zeichen. Bitte korrigieren oder klarstellen, in welchen Fällen diese 0 Zeichen lang sein kann. Dies ist ein wiederholter Kommentar aus der öffentlichen Kommentierung auf den Sie geantwortet hatten: „Die Feldlänge wird auf genau 10 Zeichen gesetzt.“

2. „<span class="nobr"><a href="https://simplifier.net/BasisprofilDE/identifier-type-de-basis-2" class="external-link" rel="nofollow">https://simplifier.net/BasisprofilDE/identifier-type-de-basis-2^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>“. Die ZANR ist überhaupt keine Versichertennummer – wieso gibt es diesen Code neben GKV und PKV? Bitte Code-System modifizieren oder durch sinnvolles Codes-System ersetzen. Dies ist ein wiederholter Kommentar. Sie hatten geantwortet: „Bitte wenden Sie sich dafür an den Herausgeber des Codesystems.“ Wir würden die KBV als Verantwortlicher für die Spezifikation bitten, dies ggf. selber zu tun.

c) Versichertennummer_PKV

1. „Identifikator für eine Privatversichertennummer.“ ist irreführend. Ersetzen durch „Versicherten-Identifikator einer privaten Krankenkasse“ oder „Privatversichertennummer.“

2. 1.2 Name

a) VOLLSTÄNDIGER NAME

1. Der vollständige Name ist nicht Teil des VSD und sollte deshalb entfernt werden, da er leicht aus den Bestandteilen erzeugt werden kann und sollte. Gäbe es hier Abweichungen, so stellte sich die Frage, wie mit diesen umgegangen werden sollte (z.B. in der Anzeige). Bitte also streichen.

2. Bitte klarstellen, ob der Titel Teil des vollständigen Namens ist oder nicht.

b) GEBURTSNAME

1. Der Geburtsname ist nicht Teil des VSD und sollte gestrichen werden. Es erschließt sich nicht, wozu dieser benötigt wird, und ein manuelles Eintragen verursacht unnötige zusätzliche Aufwände. Dies ist ein wiederholter Kommentar. Sie hatten geantwortet „Der Impfpass ist im Gegensatz zu vielen anderen Dokumenten (z.B. eMP oder NFDM) ein lebenslanges Dokument, das sich aus vielen einzelnen Einträgen zusammen setzt. Jeder Eintrag bildet einen Snapshot zum Zeitpunkt X ab. Die Aufnahme des Geburtsnamens soll die (lesbare) Zugehörigkeit der einzelnen Einträge zueinander abbilden (können).“ Unsere Antwort: Einträge und Nachträge stellen Impf-Informationen zu einer Person dar und sind insofern für den aktuellen Zeitpunkt relevant. Eine Nachvollziehbarkeit von Namenswechseln ist nicht relevant.

B. 2 Impfung

1. Die grafische Darstellung des Informationsmodells stimmt in ihrer Gliederung nicht mit der Modellierung überein. Bitte entweder übereinstimmende (möglichst automatisch generierte) Darstellungen verwenden, da sich ansonsten der Prüfaufwand sehr erhöht und kein Nutzen gegeben ist.

1. 2.1 Impfstoff

1. Es muss Ziel der Modellierung sein, dass Informationen insbesondere zu Wirkstoffen automatisch aus einer Arzneimitteldatenbank übernommen werden können. Unnötige manuelle Mehraufwände sind unbedingt zu vermeiden.

a) ATC

1. Operationalisation: Warum sollte der ATC-Code nicht aus der ATC-Tabelle ausgewählt werden (die ja angegeben ist), wenn keine Arzneimittel-DB vorhanden, ist sondern aus der SNOMED-CT-Mapping-Tabelle? Bitte erläutern.

2. Was bedeutet der folgende Satz: „Sollte der Anwender <span class="error">[…]</span> er an der 2.2 Erkrankung gegen die geimpft wird, Phase II orientiert werden.“ Bitte durch verständliche Formulierung ersetzen.

3. Mapping-Tabelle (SNOMED CT vs. ATC-Code). Nach der Semantik von SNOMED ist im Gegensatz zur natürlichsprachlichen Bedeutung jeder „Diphtherie-Haemophilus influenzae B, Pertussis, Tetanus, Hepatitis B-Impfstoff“ auch ein „Diphtherie, Haemophilus influenzae B, Pertussis, Tetanus, Hepatitis B, Meningokokken A + C-Impfstoff“ (sog. Subsumption). Das hieße gemäß Tabelle, dass jeder Wirkstoff mit Code J07CA13 auch ein Wirkstoff mit Code J07CA11 wäre. Das ist offensichtlich falsch. Eine Lösung wäre die Verwendung von präkoordinierten Codes. Dies ist ein wiederholter Kommentar. Ihre Stellungnahme: „Die aufgelisteten Impfstoffe sind einzelne Produkte, die aus den jeweiligen Substanzen bestehen. Auch die postkoordinierten Codes sind in sich abgeschlossen. Die Impfstoffe sind so auszuwählen, dass nur die benötigten Substanzen in dem jeweiligen Produkt enthalten sind.“ Die von Ihnen vorgeschlagene Herangehensweise ist im Hinblick auf die ATC-Codes korrekt, aber m.E. nicht im Hinblick auf die SNOMED CT Expressions, da diesen eine grundsätzliche andere Semantik zu Grunde liegt.

4. Es ist nicht ganz klar, warum die „product“-hierarchie gewählt wurde und nicht die „substance“-Hierarchie. ATC-Codes beschreiben ja erstmal Wirkstoffe und nicht Produkte. Bitte prüfen.

5. Eine Anmerkung allgemeiner Natur: Im Hinblick auf eine für die Forschung vorbereitete, interoperable Akte sollte nicht nur Wertemengen für Attribute mit Codes annotiert werden, sondern auch die Attribute selber.

2. 2.6 Informationsquelle

1. „Parent/Guardian/Patient Recall“ wurde unvollständig mit „Eltern/Patienten Erinnerung“ abgebildet. Bitte deutsche Übersetzung ergänzen

3. Verantwortliche Person

a) ID

1. Vgl. Kommentare zum Patienten

b) NAME

1. VSD bedeutet ja Versichertenstammdatenmanagement. Uns ist kein System bekannt, dass leistungserbringerseitig VSD mit seiner Ausdifferenzierung von z.B. Adelstiteln in Namenszusatz und Vorsatzwort unterstützt. Aus Sicht der DKG wäre ein vollständiger Name ausreichend, um hier unnötige manuelle Aufwände zu erreichen.

2. Ansonsten siehe Kommentare zu „PATIENT“

c) Einrichtung / KONTAKT

1. „Dieses Element beschreibt die Kontaktinformationen einer Person.“ Bitte „Person“ durch „Organisation“ ersetzen

d) Funktionsbezeichnung

1. Hier wäre eine „Rationale“ hilfreich, um nachvollziehen zu können, woher die Liste kommt. Bitte Verweis auf Anlage 1 der ANRV Vereinbarung aufnehmen.

4. 2.11 Disclaimer

1. „DISCLAIMER“ wird normalerweise i.S.v. „Haftungsausschluss“ verwendet. Dies trifft hier nicht zu. Bitte durch „HINWEISE“ (oder Ähnliches) ersetzen.

C. 3 Impfrelevante Erkrankung

1. Diagnosecode

1. SNOMED CT-Code und ICD-10-Codierung weichen bei Hepatitis A und B bezüglich „akut“ voneinander ab. Warum wurde nicht der SNOMED Code z.B. für „Acute type A viral hepatitis (disorder)“ gewählt? Warum sind chronische Verläufe nicht Impfrelevant. Bitte erläutern / glattziehen.

III. Anwendungsszenarien

1. Die gewählt Darstellung macht einen „Eintrag“ bzw. einen „Nachtrag“ zu speziellen „Impfpässen“, da jeweils das Informationsmodell des Impfpasses profiliert (konkretisiert) wird.

A. Daten Eintragen

1. ADMINISTRATIVES GESCHLECHT: hier ist eigentlich ein Code-System vorgesehen, als Datentyp steht aber String.

2. Generell haben unseres Erachtens die verwendeten Bezeichnungen das Verständnis der Modellierung erschwert. „Eintrag“ könnte man beispielsweise als „Entry“ oder „Record“ übersetzen. Wir würden anregen, nachvollziehbarere Bezeichnungen zu verwenden.

B. Übergreifende Operationalisierungshinweise

1. Umsetzungshinweise zu geben sind sicher sinnvoll. Es fehlen jedoch Umsetzungshinweise zu einigen wichtigen Fragen wie z.B. zum „Parallelbetrieb“, zum Nachtragen etc. Wir schlagen deshalb vor, die Umsetzungshinweise zu systematisieren und zu vervollständigen statt sich auf Kommentare aus der Kommentierungsphase zu beschränken.

2. „Beachtung der Prozesse im Praxisalltag bei der Implementierung für eine praktikable Nutzung“: bitte beachten, dass die Spezifikation auch für den stationären Sektor geeignet sein muss („in der Praxis und im Krankenhaus“)

3. „Beachtung der Prozesse im Praxisalltag bei der Implementierung für eine
praktikable Nutzung“: Aus unserer Sicht ist dies unabdingbar, aber die Aussagekraft ist auch relativ gering. Evtl. streichen oder konkretisieren.

4. „Notwendigkeit der Anzeige aller Impfeinträge als ein Impfpass“: Bitte ergänzen Sie Bezüge zum MioViewer, da dann ja eine solche Information zur Verfügung stellen sollte, und ob dieser entsprechende Funktionen zur Verfügung stellt.

IV. Signatur

1. Der elektronische Impfausweis hat zurzeit rein informativen Charakter, wie einleitend ausgeführt. Tatsächlich signiert werden müssen aktuell nur die Papierdokumente. Der Bezug auf das IfSG ist für Signatur des elektronischen Impfpasses nicht zielführend, da dieser kein amtliches Dokument darstellt. Es sind deshalb alle Aussagen zur Notwendigkeit einer irgendwiegearteten Signatur zu streichen, um zu vermeiden, dass ein Leistungserbringer erst Ausdrucken und manuell signiert und dann noch das MIO mit dem HBA signieren muss. Andere aus dem Primärsystem in die ePA eingestellte Dokumenten müssen auch nicht noch einmal signiert werden.

2. Die Erstellung einer QES ist mit hohen Aufwänden verbunden und nicht in allen Fällen notwendig. Aus Sicht der DKG ist im Rahmen der stationären Versorgung eine Signatur etwa mit der SMC-B ausreichend. Bitte den Satz „Bei der Signatur handelt es sich um eine Qualifizierte elektronische Signatur (QES) mit einem elektronischen Heilberufeausweis“, da es sich in Bezug auf den elektronischen Impfpass um eine Vorfestlegung handelt, für die es keine rechtliche Grundlage gibt.

3. Der Arzt kann nicht eine komplexe XML-Datei signieren, sondern muss eine vollständige Darstellung vor sich haben. D.h. hier liegt die Verantwortung beim Primärsystem. Welche Überlegungen gibt es hierzu?

V. FHIR-Profile

1. Bitte beachten Sie die Kommentare zum Informationsmodell. Wir haben diese bei den FHIR-Profilen nicht noch einmal wiederholt

A. In der ePA zu speichernde FHIR-Ressourcen

1. „Für diese an die ePA zu übertragende FHIR®<span style="text-decoration: line-through; ">Ressource muss für die Umsetzung des Anwendungszenarios Daten nach</span> oder übertragen eine Composition gemäß Profil Composition_Prime, Phase II enthalten sein.“ Wäre „Addendum“ richtig? Bitte korrigieren

B. Must-Support

1. Must-Support ist ja Standard in FHIR. Es erschließt sich nicht, warum hier eine extra Unterseite eingeführt wurde. Gibt es Unterschiede zur „ursprünglichen“ Auslegung? Eine kurze Erläuterung wäre hilfreich.

VI. FHIR-Ressourcen

A. Basic Immunization

1. FHIR-Profil lässt sich nicht öffnen

B. Age Groups

1. Man kommt von der Extension Age_Groups zum Value Set <span class="nobr"><a href="https://simplifier.net/im1x0/KBVVSMIOVaccinationAgeGroups" class="external-link" rel="nofollow">https://simplifier.net/im1x0/KBVVSMIOVaccinationAgeGroups^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>, welches SNOMED-CT-Codes verwendet, aber nicht zu <span class="nobr"><a href="https://fhir.kbv.de/CodeSystem/KBV_CS_MIO_Vaccination_Age_Group_German" class="external-link" rel="nofollow">https://fhir.kbv.de/CodeSystem/KBV_CS_MIO_Vaccination_Age_Group_German^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
Letztere enthält deutschsprachige Codes (was unnötig ist) mit deutschsprachigen Displays (was sinnvoll ist). Der Zusammenhang ist nicht klar. Eine Erläuterung zur Struktur der Code-Systeme wäre hilfreich.

C. KBV_PR_MIO_Vaccination_Condition

1. Condition.code.coding:icd-10-gm Eine Festlegung auf die ICD-10 erscheint nicht sinnvoll, da diese fortgeschrieben werden wird. Bitte die Code-Version als separates Element vorsehen

Sehr geehrte Damen und Herren,

wir bedanken uns für die Möglichkeit zur Abgabe einer Stellungnahme.

Wir sind mit der digitalen Umsetzung der beiden medizinischen Informationsobjekte "Impfpass" und "Zahnärztliches Bonusheft" einverstanden und haben keine Einwände.

MIt vielen Grüßen

Derzeit sind die Aufzählungen in den beiden Punkten abschließend. Dies stellt einen Rückschritt gegenüber den Möglichkeiten der Papierversion des Dokumentes dar. In der Praxis werden im Papierimpfpass häufig weitere relevante Informationen (z.B. Ringelröteln durchgemacht, Toxoplasmose positiv o.ä.) notiert, die für zukünftige ärztliche Entscheidungen wichtig sind und Doppeluntersuchungen vermeiden können sowie bei der Interpretation von Testergebnissen helfen (Kreuzreaktionen, Titerverläu-fe). Zudem ist damit zu rechnen, dass immer wieder neue Erkrankungen (COVID-19) auftauchen, gegen die auch Impfungen entwickelt werden, deren Dokumentation im Impfpass dann unkompliziert und schnell möglich sein sollte.

Sehr geehrte Damen und Herren,
wir bitten um Prüfung, ob der in Punkt 2.9.5 verwiesene Standard FHIR in Bezug auf bisher verwandte Schlüsselverzeichnisse vollständig ist bzw. übertragbar ist.
Viele Grüße und Danke