Kommentierungsüberblick Impfpass

Es wäre wünschenswert, dass Berufsbezeichnungen nicht nur in männlicher Form aufgenommen werden.

In den Primärsystemen werden gepflegte ICD-Kataloge verwendet.
Ein Ergänzung des Mappings um ICD-10 Codes wäre wünschenswert/sinnvoll.

Übersichtlicher wäre eine Abbildung einheitlich über ATC5-Codes (und dabei jeweils alle aufzuführen) anstelle einer Mischung von ATC4- und ATC5-Codes.

Da wo vierstellige ATC-Codes verwendet werden, ist wohl die gesamte Gruppe gemeint.
Dies würde aber teilweise zum Mapping von Einzelimpfstoffen auf ATCs von Kombinationsimpfstoffen führen.
Zum Beispiel würde der Snomed-Code 386012008 (Masernimpfstoff) durch das Mapping auf J07BD sowohl auf Masernimpfoff als Monopräparat (J07BD01) als auch auf diverse Kombinationsimpfstoffe gemappt, z. B. J07BD51 (Masern, Kombinationen mit Mumps, lebend abgeschwächt).
An anderer Stelle wird jedoch genau dieser ATC-Code auf den Snomed-Code 785865001 (Masern, Mumps-Impfstoff) gemappt, so dass es sich um einen Fehler zu handeln scheint.

Da die ATC-Klassifikation jährlich überarbeitet wird, sollte als Bezugsinformation auch die Version der Klassifikation in Form der jeweils gültigen Jahresangabe ergänzt werden. Es könnten theoretisch ältere Codes in einer aktuellen Fassung fehlen.

Bei Röteln ist ein Impfstoff aufgelistet, den es nicht gibt (Vaccine product (product): Has active ingredient (attribute) = Diphtheria vaccine (substance), Rubella vaccine (substance), Tetanus vaccine (substance)

Für Herpes zoster kann nur ein Impfstoff eingetragen werden (Impfpassmodell), hier ist es wichtig zwischen Lebend- und Totimpfstoff zu differenzieren (andere Impfschemata etc.).

Herpes zoster-Impfstoffe nicht unter Varicella zoster auflisten, hier sollten nur Windpocken-Impfstoff gelistet werden.

Encephalitis-Impfstoffe: unter Erregern auflisten (FSME, Japanische Encephalitis).

O.g. Konzept ist in diesem ValueSet nicht sinnvoll, da ein Zusammenhang mit Erkrankungen sich erst aus dem Kontext ergeben könnte.
Soll eine nicht weiter spezifizierte Infektionskrankheit nutzbar sein, bietet sich das allgemeine Konzept 40733004 |Infectious disease (disorder)| an.
Im ICD10-ValueSet ist jedoch auch kein "nicht-spezifiziert" Eintrag enthalten...

Observable Entity-Konzepte werden benutzt, um beobachtbare Parameter zu beschreiben (z.B. Blutdruck). Ein tatsächlich gemessenes Ergebnis (z.B. erhöhter Blutdruck) ist hingegen mit einem Finding-Konzept zu modellieren.
Hier ließe sich dementsprechend 365861007 |Finding of immune status (finding)| nutzen, als postkoordinierter Ausdruck mit dem Attribut 363713009 |Has interpretation (attribute)| und den genannten positive/negative Qualifier Values, also:
365861007: 363713009 = 10828004 bzw.
365861007: 363713009 = 260385009.
Beispiel eines ähnlichen, bestehenden Konzepts: <span class="nobr"><a href="https://browser.ihtsdotools.org/?perspective=full&conceptId1=293721000119101&edition=MAIN/2020-03-09&release=&languages=en" class="external-link" rel="nofollow">https://browser.ihtsdotools.org/?perspective=full&conceptId1=293721000119101&edition=MAIN/2020-03-09&release=&languages=en^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Mir erscheint die anzugebende Lebensphase eher als eine Eigenschaft der Person (nicht als Person eines bestimmten Alters selbst); von daher bietet sich eine Modellierung über Person-Konzepte meiner Meinung nach nicht an.
Stattdessen könnten die sechs Unterkonzepte von 767023003 |Period of life beginning after birth and ending before death (qualifier value)| genutzt werden, inklusive Adolescence, Adulthood, Childhood, Infancy, Middle age, Old age.

Krankheiten, die in einem gewissen Lebensabschnitt auftreten, werden in bestehenden Disorder-Konzepten entsprechend über Occurence + Qualifier Value definiert, z.B.: <span class="nobr"><a href="https://browser.ihtsdotools.org/?perspective=full&conceptId1=233678006&edition=MAIN/2020-03-09&release=&languages=en" class="external-link" rel="nofollow">https://browser.ihtsdotools.org/?perspective=full&conceptId1=233678006&edition=MAIN/2020-03-09&release=&languages=en^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

426081003 |Diphtheria + tetanus + pertussis + recombinant hepatitis B virus vaccine (product)| ist derzeit bei Hepatitis A statt B aufgeführt.

Für o.g. Eintrag erscheint mir das Oberkonzept 18624000 |Disease caused by Rotavirus (disorder)| mit dem Synonym "Rotavirus infection" passender.

Wie in IM1X0-345 gut angemerkt, erscheint es auch mir richtig, die Wirkstoffe mithilfe von Substance- statt Product-Codes darzustellen.
In diesem Fall vereinfachen sich die postkoordinierten Ausdrücke, da die verschiedenen Substanzen direkt mit '+' kombiniert werden können.
Beispiel: 428126001 + 412374001 + 396433007 + 412375000 + 396424005 + 768365004 + 768366003

Den bisherigen Ausführungen stimme ich größtenteils zu. Lediglich sollte der richtige postkoordinierte Ausdruck mittels sich wiederholender Attribute Groups gebildet werden, siehe SNOMED CT Concept Model zu Products (<span class="nobr"><a href="https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=71172323" class="external-link" rel="nofollow">https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=71172323^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>).
Das Beispiel müsste dann folgendermaßen lauten:
787859002: 127489000 =
{ 127489000 = 428126001 }
{ 127489000 = 412374001 }
{ 127489000 = 396433007 }
{ 127489000 = 412375000 }
{ 127489000 = 396424005 }
{ 127489000 = 768365004 }
{ 127489000 = 768366003 }
Dieses Vorgehen findet sich auch in der Definition bei anderen, präkoordinierten Kombinationsimpfstoffen, z.B. 427542001 (<span class="nobr"><a href="https://browser.ihtsdotools.org/?perspective=full&conceptId1=427542001&edition=MAIN/2020-03-09&release=&languages=en" class="external-link" rel="nofollow">https://browser.ihtsdotools.org/?perspective=full&conceptId1=427542001&edition=MAIN/2020-03-09&release=&languages=en^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> unter 'Expression' unten).

Cholera, Typhus-Impfstoff: Mit Typhus ist der englische Begriff "Typhoid" gemeint. Im Englischen steht Typhus für Fleckfieber. Beim Typhus-Impfstoff ist es richtig, nur hier nicht.

Meiner Meinung nach gibt es syntaktische Fehler bei den post-koordinierten Konzepten. Die post-koordinierten Konzepte für einige Kombinationsimpfstoffe sollten laut SNOMED CTs "Normative Specification" (<span class="nobr"><a href="https://confluence.ihtsdotools.org/display/DOCSCG/5.1+Normative+Specification" class="external-link" rel="nofollow">https://confluence.ihtsdotools.org/display/DOCSCG/5.1+Normative+Specification^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>) folgendermaßen aufgebaut sein:

focusConcept: attributeName = (conceptReference + ... + conceptReference)

Somit würde folgendes Beispiel:

787859002: 127489000 = 428126001, 412374001, 396433007, 412375000, 396424005, 768365004, 768366003

Eher so aussehen:

787859002: 127489000 = (428126001 + 412374001 + 396433007 + 412375000 + 396424005 + 768365004 + 768366003)

Siehe auch das erste Beispiel auf "Expression With Nested Refinements": <span class="nobr"><a href="https://confluence.ihtsdotools.org/display/DOCSCG/6.5+Expression+With+Nested+Refinements" class="external-link" rel="nofollow">https://confluence.ihtsdotools.org/display/DOCSCG/6.5+Expression+With+Nested+Refinements^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Wie bereits unter "Informationsmodell" geschrieben, stellt der Patient eine Spezialisierung einer Person dar, dies kann auch entsprechend sachlich korrekt in einem Informationsmodell ausgedrückt werden.

Die Attribute der Klassen "Identifier" bzw. "Name" sind direkte Attribute einer dieser Klassen. Daher ist es fachlich falsch diese in eigene Klassen/Datentypen zu kodieren.

Die angegebenen Identifier besitzen als Datentyp ebenfalls Identifier, ist das eine Selbstreferenz und somit eine Rekursion? Wie genau ist der Datentyp eines Identifiers spezifiziert?

An dieser Stelle muss die komplette gesetzliche Anforderungen von §22(3) Satz 1 IfSG abgedeckt sein. Der hier beschriebene Inhalt scheint jedoch zu kurz zu kommen. Es sollte bitte nochmals geprüft werden, ob alle Anforderungen des Satzes aus dem IfSG hier berücksichtigt worden sind.

Die gematik geht von der Annahme aus, dass im Context von ePA beim Einstellen eines Impfpassdokuments die Signatur des BUNDLE_ENTRY <span class="nobr"><a href="https://simplifier.net/im1x0/kbvprmiovaccinationbundleentry" class="external-link" rel="nofollow">https://simplifier.net/im1x0/kbvprmiovaccinationbundleentry^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> verwendet wird. Hier ist genau zu spezifizieren, was und wie signiert wird:

• welche Anteile des Impfeintrages signiert werden sollen,
• das Canonisierungsverfahren, welches zur Aufbereitung der zu signierenden Daten verwendet werden soll,
• welche Signaturtyp verwendet werden soll (z.B. CAdES detached)
  Das zu signierende Dokument muss alle Resourcen als vollständige Daten enthalten, die für das Impfpassdokument relevant sind. Referenzen auf Ressourcen sind nicht sinnvoll, da diese in einem ePA Client nicht aufgelöst werden können.

Zwischen einer Impfung und einer Titerbestimmung besteht eine optionale Beziehung. Man kann eine Titerbestimmung vor oder nach einer Impfung durchführen, jenachdem welcher Zweck damit verfolgt wird. Dies geht aus diesem "Modell" in keiner Weise hervor.
Dieses "Modell" ist somit fachlich nicht haltbar.

Wie ist der Zusammenhang des "Informationsmodells" und den spezifizierten FHIR Ressourcen beispielsweise bei der Klasse "Person/Patient". Hier existiert nur die FHIR Ressource "Patient"!

Allgemein lässt sich nur schwer ein Bezug herstellen!

Bedeutet das, dass diese Bundleressource den eigentlichen eImpass darstellt, der z.B. auch in die ePA eingestellt werden würde?

Warum werden hier wieder Sonderlocken spezifiziert? In der Regel heißen diese Felder "Typ" und "Wert" bzw. "Value".

Wie lang darf eine "Eintrag" maximal sein?

Es sollte sich auf EINE eindeutige Indentifikationsmethode beschränkt werden!

Das Informationsmodell ist inhaltlich falsch. "Verantwortliche Person" und "Eintragende Person" sind direkte Attibute und könnten als Datentyp "Person" referenzieren!

Wie ist der Anwendungsfall für dieses Feld?
Wie lang darf der Wert dieses Feldes maximal sein?

Mir ist nicht klar wozu eine oder alle dieser Identifier genutzt werden sollen. Der eImpfass ist als ein Objekt/Dokument der ePA bestimmt. Hier beinhalten die Metadaten bereits eine nach gematik vorgeschriebene Patienten ID.

Wozu ist hier eine Reisepassnr. oder eine PKV Nummer notwendig? Die ePA wird zunächst eh nur für gesetzlich versicherte existieren. Wenn diese irgenwann auch für privat versicherte zur Verfügung steht, gilt es einen einheitlichen Weg zu finden die PID zu kodieren.

Bei der gezeigten Darstellung ist nur schwer ein tatsächliches Informationsmodell zu erkennen. Es sieht eher wie eine Art „MindMap“ aus, die nur unzureichend die Eigenschaften einzelner Objekte noch die Relationen zwischen Objekten ausdrückt. Weder Optionalitäten noch Kardinalitäten sind erkennbar.
Ein Informationsmodell soll eine abstrakte Darstellung von Objekten inkl. ihrer Eigenschaften und Beziehungen untereinander wiedergeben, damit auch fachfremde Personen die Zusammenhänge und Bedeutung erkennen können. Hier fehlen selbst rudimentärste Angaben, bzw. sind schlicht weg falsch.
Beispiel Person/Patient: Patient stellt eigentlich eine Spezialisierung einer Person da und kann auch so in einem Informationsmodell ausgedrückt werden. Daten die aktuell in der Klasse „Name“ bzw. „Identifier“ enthalten sind, stellen eigentlich direkte Attribute dieser Klassen dar und gehören daher nicht in eine eigene Klasse. Ggf. benötigt es spezielle Datentypen/Klassen für Attribute, die nicht über primitive Datentypen ausgedrückt werden können.
Beispiel "Identifier": In dieser Klasse finden sich Attribute die als Datentype wiederum "identifier" angegeben haben. Dieser Datentyp ist nirgends in der Darstellung vorhanden. Stellt dies eine Selbstreferenz und somit eine Rekursion da?
Weiterhin sind in dieser Darstellung Klassen/Objekte mehrfach vorhanden („Identifier“/“Name“, etc.) was ebenfalls in einem Informationsmodell ungültig ist.

Fazit: Das hier angegebene "Informationsmodell" ist grob fehlerbehaftet und darf so keinesfalls finalisiert werden.

Wie sieht das konkrete Datumsformat aus ("YYYYMMDD")?
Wie kann ein korrektes Datum validiert werden, ist z. B. "01.01.0001" valide?

Es sollten nur Codes von Berufsgruppen aufgeführt sein, durch die eine impfrelevante Erkrankung sinnvollerweise dokumentiert werden kann; hier werden jedoch auch in diesem Kontext teilweise abstrus erscheinende Berufe aufgeführt (z. B. Yogalehrer, Tai-Chi-Chuan- und Qigong-Lehrer, Fachkraft Beauty und Wellness, Seelsorge)

Es fehlen die Bezeichnungen für die Spaltenköpfe 3+4 (derzeit leer).
Durch überlappende Codes in Spalte 2 (Code) wie im Falle Code mit der Wertigkeit 1 weitere Erschwernis in der Lesbarkeit.
Es sollte überlegt werden die Tabelle "besser" zu sortieren und lesbarer zu gestalten. Teilweise über mehrere Bildschirmseiten Eintragungen zu einem Code (z.B. 22) ohne das dies auf den weiteren Bildschirmseiten noch ersichtlich ist.

S.g. Damen und Herren,
offener Posten ist noch die Revision der vorgelegten LOINC-Codes für die Titer-Angaben im Impfpass.
Hierzu finden sich mehrere Lösungsansätze, die Sender- und Empfängersystem verstehen sollten.
In der Kürze der Zeit ist mir die Zurverfügungstellung fristgerecht nicht mehr möglich.
Können Sie mir bitte eine eMail-Adresse zukommen lassen, an die ich diese Anregungen per xls-Datei verschicken kann.
Vielen Dank im Voraus
Ihr
Bernhard Wiegel

EFN ist keine gängige Angabe, die z. B. in einem AIS/PVS vorgehalten wird

Es sollte ausführlicher beschrieben werden, wie genau die Identifikation erfolgen soll. Gerade vor dem Hintergrund, wenn mehr als einer der ID´s (ID, EFN, ANR) angegeben werden kann. Wie ist dann die Handhabung in den Systemen? Aus unserer Sicht ist die Speicherung aller drei ID-Arten in den Systemen notwendig, weil man nicht weiß welche Art der ID vom abgebenden System benutzt wird.

EFN ist keine gängige Angabe, die z. B. in einem AIS/PVS vorgehalten wird

Es sollte ausführlicher beschrieben werden, wie genau die Identifikation erfolgen soll. Gerade vor dem Hintergrund, wenn mehr als einer der ID´s (ID, EFN, ANR) angegeben werden kann. Wie ist dann die Handhabung in den Systemen? Aus unserer Sicht ist die Speicherung aller drei ID-Arten in den Systemen notwendig, weil man nicht weiß welche Art der ID vom abgebenden System benutzt wird.

Hier würde es sich anbieten, den Begriff der impfrelevanten Erkrankung weiter zu fassen und nicht nur Erkrankungen, die zu einer Immunität geführt haben, zu dokumentieren, sondern auch individuelle Gefährdungsgrößen im Sinne impfrelevanter Indikationen und Kontraindikationen (z. B. chronische Erkrankungen).

Sofern durch die Impfungen schon eine Immunität erreicht wurde, sollte angegeben werden können, wie lange diese gilt.

Im Impfpass könnten auch die durch den Patienten abgelehnte Impfungen (mit Begründung) dokumentiert werden.

Der Impfpass könnte und sollte auch dazu genutzt werden, den Impfungen zugeordnete Impfempfehlungen abzubilden.
Hierzu würden sich die folgenden Kategorien anbieten: Standardempfehlungen, Indikationsempfehlungen, Reiseempfehlungen, Postexpositionsindikationen, Berufsgruppenempfehlungen.

Bitte prüfen und bewerten ob ein zusammenfassender Gesamtimpfstatus ergänzt werden könnte, ermittelt aus dem Status aller enthaltenen Impfungen, impfrelevanter Erkrankungen sowie Titerbestimmungen und ggf. weiteren Angaben wie individuellen Impfempfehlungen.
Dieser Gesamtstatus könnte die Anamnese erleichtern.

Bitte prüfen und bewerten ob Kontaktdaten an dieser Stelle ergänzt werden können.
Es kann möglicherweise Sinn manchen mit der Person bzw. dem Patienten Kontakt aufzunehmen (z.B. eMailadresse, Mobilfunknummer).

Unserer Erfahrung nach kann die Information "Familienstand" Familienstand für Impfempfehlungen relevant sein.
Wir bitten um diesbezügliche Überprüfung.

Es sollte die Möglichkeit geschaffen werden, auch die Gabe von Immunglobulinen zu dokumentieren, diese fehlt derzeit.

"Unveränderlicher Teil der einheitlichen Krankenversicherungsnummer der GKV gemäß § 290 SGB V“
Redaktioneller Hinweis: Richtig wäre "Krankenversichertennummer"

Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.

Es sollten nur Codes von Berufsgruppen aufgeführt sein, durch die eine impfrelevante Erkrankung sinnvollerweise dokumentiert werden kann; hier werden jedoch auch in diesem Kontext teilweise abstrus erscheinende Berufe aufgeführt (z. B. Yogalehrer, Tai-Chi-Chuan- und Qigong-Lehrer, Fachkraft Beauty und Wellness, Seelsorge)

Es fehlen die Bezeichnungen für die Spaltenköpfe 3+4 (derzeit leer).
Durch überlappende Codes in Spalte 2 (Code) wie im Falle Code mit der Wertigkeit 1 weitere Erschwernis in der Lesbarkeit.

Es sollte überlegt werden die Tabelle "besser" zu sortieren und lesbarer zu gestalten. Teilweise über mehrere Bildschirmseiten Eintragungen zu einem Code (z.B. 22) ohne das dies auf den weiteren Bildschirmseiten noch ersichtlich ist.

Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.

Bezüglich der Abgrenzung/Operationalisierung "eintragende Person" vs. "verantwortliche Person" siehe auch "2.10 Eintragende Person"

Redaktioneller Hinweis: Da es hier um impfrelevante Erkrankungen und nicht um Impfungen geht, sollte das auch so im Text stehen.

Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.

Hier empfiehlt sich ggf. eine Operationalisierung, z. B. dass dies nur anzugeben ist, wenn eintragende und verantwortliche Person nicht identisch sind.

Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.