Stellungnahmeergebnisse

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.

Vielen Dank für Ihre Stellungnahme zum MIO Impfpass und den Anregungen zum Verfahren.

Gerne möchten wir im Folgenden auf Ihre Anmerkungen eingehen.
Das fachliche Informationsmodell soll dazu dienen, einem medizinisch fachlichen Publikum eine Übersicht über die Inhalte des MIOs zu geben. Wir haben den Hinweis aufgenommen, dass auf dieser Ebene keine Kardinalitäten und Optionalitäten aufgeführt sind, da diese sich zwischen den beiden definierten Szenarien unterscheiden und auf der Ebene der Anwendungsszenarien aufgeführt sind.

Die erwähnte „Lebensphase“ ist das Item zur Angabe mittels eines Value Sets, wann der „klinisch relevante Zeitraum“ einer durchlebten Erkrankung war, hier gibt es im Impfpass keine weiteren Attribute. Der Datentyp Count wurde geändert, da es sich hier um einen Fehler handelte.

Die Verlinkungen, wie von Ihnen angesprochen zum Geschlecht, führen zum Patientenprofil, in dem diese Angabe enthalten ist – eine dezidierte Verlinkung ist hier nicht möglich. Die angesprochene KVK als Patienten Identifier ist enthalten, da diese bei den sonstigen Kostenträgern (z.B. Bundeswehr) immer noch zum Einsatz kommt. Der Geburtsname wird auf Spezifikationsebene in FHIR korrigiert. Das Geburtsdatum ist durch den Datentyp, der im Informationsmodell angegeben ist, in FHIR min. auf JJJJ beschränkt. Dies kann aber auch genauer als JJJJ-MM /JJJJ-MM-TT angegeben werden, dies wird in der Beschreibung ergänzt.

Sie merken an, dass das Informationsmodell an einigen Stellen abweichende Informationen als die Profile selbst enthalten. Da unklar ist, wo dies der Fall ist, können wir leider keine abschließende Bewertung des Sachverhalts vornehmen.

Der Impfpass ist die Zusammenstellung der einzelnen Impfeinträge inkl. der Einträge zu durchlebten Erkrankungen und Immunreaktionen (Tests), welche auf Ebene der ePA erfolgt. Es wird eine Erläuterung aufgenommen, um diesen Sachverhalt besser herauszustellen.

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 https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Composition_Addendum 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 - http://terminology.hl7.org/CodeSystem/v2-0203 (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. „https://simplifier.net/BasisprofilDE/identifier-type-de-basis-2“. 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 […] 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®Ressource muss für die Umsetzung des Anwendungszenarios Daten nach 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 https://simplifier.net/im1x0/KBVVSMIOVaccinationAgeGroups, welches SNOMED-CT-Codes verwendet, aber nicht zu https://fhir.kbv.de/CodeSystem/KBV_CS_MIO_Vaccination_Age_Group_German
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

Vielen Dank für Ihre Stellungnahme zum MIO Impfpass.

Gerne gehen wir im Folgenden auf Ihre Ausführungen ein.
Sie merken an, dass der elektronische Impfpass den papiergebundenen Impfpass nicht ersetzen kann und der elektronische Impfpass rein informativen Charakter aufweist. Hierzu erläutern sie später, dass nur der papiergebundene Impfpass signiert werden muss und es sich, wenn eine elektronische Signatur gesetzt wird, nicht um eine QES handeln muss. Im Rahmen des sog. Masernschutzgesetzes wurde der § 22 IfSG geändert, sodass die Impfdokumentation schriftlich wie elektronisch erfolgen kann: es muss die „Bestätigung in Schriftform oder in elektronischer Form mit einer qualifizierten elektronischen Signatur oder einem qualifizierten elektronischen Siegel durch die für die Durchführung der Schutzimpfung verantwortliche Person“ enthalten sein. Die Möglichkeit der Nutzung des qualifizierten elektronischen Siegels wurde in der Beschreibung ergänzt.

Um auf das von Ihnen angesprochene Zusammenspiel von MIO-Definition, ePA und MIO-Viewer einzugehen, ist herauszustellen, dass der Auftrag der KBV die Gewährleistung der syntaktischen und semantischen Interoperabilität der Inhalte der elektronischen Patientenakte ist – aus diesem Grund besteht der MIO Impfpass aus strukturierten Daten und ist kein PDF. Nichtsdestoweniger steht dies dem Einstellen von PDFs in die ePA nicht entgegen. Die ausgeführten Punkte wie das Löschen, Metadaten und Rechtevergabe betrifft die technische Spezifikation der ePA durch die gematik. Funktionalitäten wie das Suchen oder Sortieren werden vom IT-System umgesetzt – hierzu gibt es keine Vorgaben seitens der KBV. Der MIO-Viewer soll die Möglichkeit schaffen, auch ohne anderes IT-System (PVS/KIS/FdV) die Inhalte des MIOs zur Ansicht zu bringen. Die Umsetzung im MIO-Viewer ist dabei nur beispielhaft zu sehen.

Die Basis-Profile werden so weit wie möglich in den einzelnen medizinischen Informationsobjekten genutzt. Trotzdem gibt es immer eine Ableitung/Spezifizierung von den Basisprofilen in den Projekten (Bsp. PR_MIO_Vaccination_Patient), u.a. um den jeweiligen Rechtsgrundlagen der Dokumente gerecht zu werden, diese können dann auch jeweils kommentiert werden.

Um auf Ihre Anmerkung bezüglich des Auseinanderlaufens des Informationsmodells und der FHIR-Profile einzugehen, ist zu sagen, dass Addendum und Prime die beiden Szenarien „Daten eintragen“ und „Daten ein- oder übertragen“ abbilden; ein entsprechendes Mapping findet sich in den Anwendungsszenarien bzw. in der MIO-Festlegung um Kapitel "FHIR®- Ressourcen". Generell werden Impfpass-Einträge definiert; die einzelnen Einträge werden als Impfpass durch die ePA nach gematik-Spezifikation geklammert. Dies ist im Informationsmodell jedoch trotzdem aufgeführt, um dem fachlichen Publikum den Zusammenhang darzustellen.

Im Weiteren möchten wir auf die spezifischen von Ihnen angesprochenen Punkte eingehen:

• Es sind diverse Identifier vorhanden, da aber insgesamt min. ein Identifier gefordert ist, muss ein sehr "freier" Identifikator vorhanden sein. Es muss auch kein globaler Identifikator sein, da im System das organisationsspezifische System mitgegeben werden kann. Die vorgehenden Instanzen beziehen sich auf die vorherigen Einträge dieses Patienten.
• Der Hinweis in der Beschreibung, dass es sich bei „Terminologie Assoziation: MR -http://terminology.hl7.org/CodeSystem/v2-0203" lediglich um den Namen und nicht, um einen funktionierenden Link handelt, ist uns bewusst. Leider ist es nicht möglich hier einen Link anzugeben, da HL7.org die Auflösung zwischen Link und Codesystem nicht ermöglicht.
• Der Feldlänge der Versicherten ID GKV wurde in der FHIR Umsetzung korrekt angepasst, die Beschreibung auf der informativen Seite wurde nun nachgezogen.
• Die ZANR ist im Impfpass nicht vorhanden. Das Profil (ad Versichertennummer_PKV) ist durch Hl7 definiert, bitte wenden Sie sich an den Herausgeber.
• Der vollständige Name ist eine Möglichkeit, optional die korrekte Reihenfolge der Namensteile bei z.B. vielen Titeln abzubilden. Der Titel ist Teil des vollständigen Namens, dies wurde entsprechend angepasst. Der Geburtsname wurde aufgrund der bereits ausgeführten Überlegungen aufgenommen – die Angabe des Geburtsnamens ist optional.
• Wir stimmen überein, dass es das Ziel der Umsetzung sein sollte, möglichst viele Inhalte des digitalen Impfpasses automatisch zu generieren. Dies obliegt den umsetzenden IT-Systemen – eine entsprechende Operationalisierungsempfehlung finden Sie im informativen Teil des MIO Impfpass. Die Operationalisierung im Hinblick auf die ATC-Liste bedeutet, dass die Auswahl durch den Anwender nicht aus der ATC-Liste erfolgen sollte, sondern aus der besser lesbaren SNOMED Mapping Tabelle und die ATC-Codes daraus abgeleitet dann automatisiert befüllt werden.
• Die Nutzung von präcoordinierten SNOMED Konzepten ist anzustreben, jedoch nicht immer möglich, wenn diese nicht vorhanden sind.
• ATC Codes sind keine klassischen Wirkstoffcodes da sie sich auf das zugelassene Anwendungsgebiet beziehen). In bisherigen Ausgestaltungen, auch auf EU-Ebene wird mit der "Product" Achse gearbeitet. Die "Substance" Hierachie wird eher parallel zu ASK-Nummern gesehen - die hier explizit nicht mit aufgenommen wurden.
• Die Liste der Funktionsbezeichnungen ist eine eingekürzte Liste der IHE sowie KBV-Erweiterungen - dies wird entsprechend als Quelle ergänzt. Sie setzt sich aus verschiedenen Codesystemen zusammen, diese sind im Value Set mit ihrer OID aufgeführt.
• Der Disclaimer wurde in Hinweis umbenannt.
• Ihre Anmerkung zu den Codierungen von vorausgegangenen Hepatitis Erkrankungen wurde aufgenommen und angepasst (im Falle von Hepatitis A wird jedoch immer von einer „akuten“ Hepatitis A gesprochen).
• Der Datentyp des Geschlechts wurde angepasst.
• Die Definition des Must-Support ist kein Standard und muss nach der FHIR-Spezifikation für jede Anwendung einzeln definiert werden.
• In der Extension https://fhir.kbv.de/StructureDefinition/KBV_EX_MIO_Vaccination_Age_Groups im Element Extension.value[x]:valueCodeableConcept.text ist ein entsprechender Beschreibungstext, wie mit den Conceptmaps und damit auch mit dem Codesystem umgegangen werden soll. Die Codes sind zur Verknüpfung notwendig.
• Es ist ein Feld für die Version des Codesystems und damit auch für den einzelnen Code vorhanden. Dieses soll nach dieser Spezifikation auch gefüllt werden.

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.

Vielen Dank für Ihre Stellungnahme zum MIO Impfpass.

Im Rahmen der Kommentarbearbeitung haben wir alle Kommentare gesichtet, bewertet und beantwortet - jeder Kommentar bekommt i.d.R. eine E-Mail Lösung zugeschickt. Sollten Sie zukünftig feststellen, dass Kommentare nicht beantwortet werden, bitten wir um eine kurze Rückmeldung.

Die KBV ist mit der Erstellung der MIOs für die semantische und syntaktische Interoperabilität der Inhalte der elektronischen Patientenakte verantwortlich. Das bedeutet - auch für den Impfpass – dass ausschließlich die Datenstruktur definiert wird. Die Umsetzung von Algorithmen z.B. zum Abgleich mit STIKO Empfehlungen und daraus abgeleiteten Erinnerungsfunktionen ist nicht Teil der MIO Festlegung und obliegt den Umsetzenden IT-Systemen. Nichtsdestoweniger haben wir übergreifende Operationalisierungshinweise formuliert, in denen auch die Umsetzung von Impfmanagementfunktionen im Hinblick auf den Abgleich mit STIKO Empfehlungen aufgenommen wurde.

Gerne gehen wir auf die von Ihnen angebrachten einzelnen Punkte im Folgenden ein:

• Das Feld „Datum der Folgeimpfung“ ist als Datenfeld für die Angabe des Datums einer möglichen Folge- oder Auffrischimpfung vorgesehen. Das Hinterlegen von Logiken zur Berechnung und Vorausfüllung eines Vorschlages liegt, wie bereits oben erläutert, bei den umsetzenden IT-Systemen.
• Gleiches gilt für die Nutzung des Feldes „Grundimmunisierung abgeschlossen“. Zu diesem Feld ist jedoch anzumerken, dass es nur für den Übertrag/Nachtrag von Impfungen vorgesehen ist, um den Dokumentationsaufwand gering zu halten.
• Der von Ihnen adressierte Punkt, dass nicht jeder behandelnde Arzt/ jede behandelnde Ärztin weiß, dass bei zweimaliger Masern-Impfung und anschließender Antikörperbestimmung unterhalb des Grenzwertes trotzdem von einer Immunität ausgegangen werden kann, ist nachvollziehbar. Es bleibt jedoch die Frage offen, wie die Datenstruktur des digitalen Impfpasses hier Abhilfe schaffen kann; Datenseitig ist die Information zur Antikörperbestimmung hinterlegt, ob eine Immunität erreicht ist oder nicht. Vielmehr wäre es bezüglich dieses Sachverhalts eventuell hilfreich, hier mit Hinweisen seitens des Praxisverwaltungssystems (In der Hand der IT-Umsetzung) oder gezielter Information der Ärzte zu arbeiten.
• Die Unterscheidung zwischen der Herpes Zoster und der Windpocken-Impfung sollte durch den 7-stelligen ATC gegeben sein. Es erfolgte eine erneute Prüfung der Präparate in den Arzneimitteldatenbanken, woraufhin ein Fehler in der ATC-Zuordnung in der verwendeten Datenbank auffiel. In der Spezifikation wurden daraufhin alle ATCs dieser Gruppe aufgenommen. Nichtsdestoweniger gibt es im Bereich der SNOMED CT Nutzung für diese Impfstoffe Klärungs- bzw. Anpassungsbedarf an die Deutschen Gegebenheiten. Hierzu erfolgt ein Austausch mit den Kollegen des BfArM.

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 [Presence] in Serum) equivalent Tuberkulose-Mendel-Mantoux-Test-positiv (Tuberkulose - Mendel-Mantoux-Test positiv)
26643-7 (Clostridium tetani toxoid Ab [Presence] in Serum) equivalent Tuberkulose-Mendel-Mantoux-Test-negativ (Tuberkulose - Mendel-Mantoux-Test negativ)
30546-6 (Polio virus 1 Ab [Presence] in Serum) equivalent Tuberkulose-Interferon-gamma-assay-positiv (Tuberkulose - Interferon gamma assay positiv)
31998-8 (Bordetella pertussis Ab [Presence] 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.

Vielen Dank für Ihre Stellungnahme zum MIO Impfpass.

Gerne gehen wir im Folgenden auf die von Ihnen benannten Aspekte ein.

Wie Sie korrekt beschreiben, werden CodeSystems herangezogen, wenn es keine deutschsprachigen Anzeigenamen in den ValueSets (bzw. der genutzten Terminologien) gibt. Diese werden dann über die ConceptMap miteinander verbunden und der „Displayname“, der dem Nutzer zur Anzeige gebracht wird, daraus generiert. Dies wird bei Vorhandensein deutscher Bezeichnungen zum Teil obsolet werden. ValueSets und CodeSystem sind dabei nicht alternativ zu sehen. Der zu speichernde Code ist in den einzelnen Ressourcen vorgegeben (beispielsweise SNOMED CT), das CodeSystem liefert dabei den für den Anwender sichtbare Namen. Vor diesem Hintergrund steht das Vorgehen „CrossBorder“ Aktivitäten nicht entgegen. Die Terme im CodeSystem bilden zudem die Brücke zwischen allen gemappten ValueSets über die ConceptMap. Es soll wie bereits ausgeführt den Wiedergabenamen für den Nutzer stellen und möglichst verständlich sein. Zukünftig wird jedoch darauf geachtet, dass bei deutschsprachigen Terminologien die deutschen Namen möglichst auch als Wiedergabenamen in einer ConceptMap übernommen werden.

Die Nutzung eines ATC-Codes einer höheren Hierarchie für „Impfstoffe spezifiziert“, wie von Ihnen vorgeschlagen, ist leider so einfach nicht möglich, da mit diesem Feld sowohl aktive als auch passive Immunisierungen dokumentiert werden können, welche jedoch unterschiedliche ATC-Codes aufweisen.

Die Erweiterung um weitere pharmazeutische Informationen zum Impfstoff wird geprüft, sobald die entsprechenden Codesysteme zu Verfügung stehen.

Bei der Benennung von Valuesets etc. erfolgte eine Anpassung; zukünftig wird stärker darauf geachtet, diese entsprechend der Inhalte zu benennen. Die Ausprägungen der Tuberkulose-Tests in LAB TITER ANTIBODY PRESENCE (neu: LAB_ ImmuneReaction_Test_PRESENCE) wurden nach intensiven Abwägungen weiterhin in den Codes behalten, da auf diese Weise die konsistente Nutzung der SNOMED Hierarchie „finding“ möglich war. Es wurde entschieden, sich auf ein Konzept je Terminologie und Ausprägung des Datenfeldes festzulegen. Der Umgang mit related Terms wird zukünftig diskutiert werden. Es wurden die fehlenden Konzepte aus SNOMED CT zu den Antikörperbestimmungen ergänzt sowie der Fehler bei der Zuordnung in der ConceptMap in FHIR behoben.

Die Nutzung von nicht endständigen ICD-10 Codes im Rahmen des MIO Impfpass dient nicht der abrechnungsrelevanten Morbiditätscodierung. Hier dient es als übergeordneter Code, der den Systemen eine Erkennung im Hinblick auf im Primärsystem bereits dokumentierte Codes erleichtern soll.

Sobald ICD-10-GM Z23ff. Codes bzw. die Korrespondierenden Alpha IDs für alle Impfungen vollständig zur Verfügung stehen, wird die Aufnahme in den digitalen Impfpass im Rahmen einer Überarbeitung geprüft. Ebenso die Aufnahme weiterer neuer Codes sowie des LOINC LongCommonName in deutscher Sprache. Hier begrüßen wir ausdrücklich den konstruktiven Austausch mit dem BfArM.

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 https://www.meineimpfungen.ch). 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.

Grundsätzliche Einschätzung
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.

Abgrenzung der Bewertung
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.

Vollständigkeit des Impfpasses
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.

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