Übersicht der FHIR-Ressourcen

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.

Nur Kommentar:

Mit dieser Tabelle wird ein Impfstoff mit der Krankheit verknüpft, gegen die geimpft wird.

Diese Information ist in SNOMED CT nicht gegeben, obwohl dies ja relativ einfach möglich wäre.

Ist geplant, den Inhalt der Tabelle in de SNOMED CT einzubringen (Intl oder Deutsch)?

Sie haben den „Masern, Röteln Impfstoff“ über eine SNOMED CT Expression definiert, da es wohl kein präkoordiniertes Konzept in der International Edition gibt.

Da SNOMED CT auf einer Subsumptions-Semantik beruht, wird “Measles + mumps + rubella + varicella vaccine (product)” von der Definition von “Vaccine product (product): Has active ingredient (attribute) = Measles vaccine (substance), Rubella vaccine (substance) = ” subsumiert, d.h. entgegen dem natürlichsprachlichen Verständnis ist in der SNOMED-CT-Modellierung (so wie ich das verstehe) jeder „Masern, Mumps, Röteln, Varicella-Impfstoff“ auch ein „Masern, Röteln-Impfstoff“, d.h. die Kodierung in der Tabelle ist nicht eindeutig was die Auswahl der richtigen "Zeile" erschwert.

Man sieht dies daran, dass „Masern, Mumps, Röteln, Varicella-Impfstoff“ vier Has-active-Ingredient-Attribute verfügt, von denen zwei das Konzept „Masern, Röteln-Impfstoff“ triggern.

Liebes Team,

da wir mit Herrn Roos ausgemacht haben, dass wir auch noch den eImpfpass kommentieren dürfen, haben wir alles in diese Kommentarfeld geschrieben. Die gesammelten Kommentare stammen von Frau Koch und Frau Küpke.

2.3. Impfdatum
• Bei Anwendung eines Algorithmus muss man den Impfabstand ja wochengenau kalkulieren. Dazu ist eine tagesgenaue Angabe des Impfdatums essentiell.

2.4. Datum der Folgeimpfung:
• Datumsangabe muss sicherstellen, dass der Mindestabstand eingehalten wird

2.6 Informationsquelle:
• Ärztliches Zeugnis aufnehmen?

2.7. Grundimmunisierung abgeschlossen
• Sehr problematisch, Einschätzung, ob GI vollständig erfolgt ist. Ist von Alter des Impflings abhängig. Dazu sollte es einen Algorithmus geben, der anhand der Einträge prüft, ob ein Impfschutz vollständig ist. Siehe bereits vorliegende Kommentare.

2.8 Anmerkung zur durchgeführten Impfung
• Die Meldung von Impfkomplikationen sollte in der Auflistung der Impfbuchdokumentation einen eigenen Unterpunkt bekommen. Hier sollten auch die Meldebögen direkt verlinkt sein, mit denen die Meldung von Impfnebenwirkungen an das GA, das PEI und die Ärztekammer erfolgen kann.
• Anmerkung zur durchgeführten Impfung: Zählt hierunter auch die Impfreaktion? Falls nicht: Wo wird die vermerkt?

2.11 Disclaimer:
• "In diesem Element ist ein Hinweistext für ungewöhnliche Impfreaktionen hinterlegt." - Das könnte man so verstehen, als würden hier ungewöhnliche Impfreaktionen vermerkt werden. Dann finde ich allerdings die Benennung irreführend. Ich schließe mich außerdem den bereits vermerkten Kommentar an: Impfreaktion und SUAW sowie Impfschaden werden hier nicht korrekt voneinander getrennt. Eigentlich gibt es nur ein Sammelfeld für alles. Ggf. soll hier auch nur §22 (3) abgedeckt werden. Dann bleibt für mich die Frage, wo Impfreaktionen notiert werden.

3. Impfrelevante Erkrankungen:
• Wie wird hier vermerkt, dass für Masern z.B. nur die AK-Bestimmung als Nachweis für eine durchgemachte Erkrankung gilt? (für Personen, die vom MSG betroffen sind)?

3.1. Diagnosecode:
• Keuchhusten hinterlässt nicht unbedingt eine lebenslange Immunität: sollte hier nicht aufgeführt werden

3.2. Klinisch relevanter Zeitraum
• Überschrift könnte besser formuliert werden, damit klar ist was hier eingetragen werden soll
• Falls bekannt, wäre die Eingabe eines genauen Alters nach Jahren wünschenswert
• Alterszeiträume überlappen sich zum Teil oder sind nicht korrekt:
Säugling ab Beginn des 29. Lebenstages bis zum vollendeten 12. Lebensmonat= <12 Monate
Kleinkind ab Beginn des 2. bis zum vollendeten 3. Lebensjahr = ≥12 Monate bis <4 Jahre
Kind ab Beginn des 4. bis zum vollendeten 12. Lebensjahr = ≥4 Jahre bis < 12 Jahre
Jugendlicher ab Beginn des 13. bis zum vollendeten 18. Lebensjahr = ≥12 Jahre bis < 18 Jahre
Erwachsener ab Beginn des 19. Lebensjahres = ≥ 18 Jahre

3.4. Vorgaben: Angaben zur Labordiagnose anbieten

3.5 Meta-Informationen (Quelle der Information):
• Hier fehlt dann m. M. nach die explizite Auflistung eines ärztlichen Zeugnisses .

4.2 Immunität
• Die Immunität wird dieser Darstellung nach dichotom anhand eines Grenzwerts bestimmt (liegt vor oder nicht), allerdings weisen wir in einer FAQ extra darauf hin, dass bei zweimaliger Masern-Impfung und AK-Bestimmung, die unterhalb des Grenzwertes liegt, trotzdem von einer Immunität ausgegangen werden kann - wie lässt sich eine solche Situation hier abbilden?

Hintergrundinformationen: Statt Herdenschutz lieber Gemeinschaftsschutz verwenden (gilt für mehrere Seiten)

Vielen Dank. Für Rückfragen stehen wir gerne zur Verfügung.

Mit freundlichen Grüßen
im Auftrag

Yvonne Bichel

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.

<strong><span class="error">[per Mail über Duria an die KBV]</span></strong>

Von: Stefan Streit <<span class="nobr"><a href="mailto:stefan.streit@op-info.de" class="external-link" rel="nofollow">stefan.streit@op-info.de^{<img class="rendericon" src="/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span>>

Gesendet: Sonntag, 2. Februar 2020, 17:15

An: <span class="nobr"><a href="mailto:info@duria.de" class="external-link" rel="nofollow">info@duria.de^{<img class="rendericon" src="/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span>

Betreff: MIO Umsetzung für Ärzte

Sehr geehrte Damen und Herren,

bitte leiten Sie diese Mail weiter an Herrn Dr. Gehlen. Vielen Dank.

Sehr geehrter Herr Dr. Gehlen, wir hatten uns seinerzeit über die Einführung des Bundesmedikationsplans in der KV unterhalten.

Nun ist es wieder so weit. Bitte machen Sie Ihren Einfluss für uns Ärzte bei der KBV geltend. Die KBV ruft unter der Adresse zu Kommentierung der MIO-Planung auf. <span class="nobr"><a href="https://mio.kbv.de/display/IM1x0" class="external-link" rel="nofollow">https://mio.kbv.de/display/IM1x0^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> Ich sehe hier wenig Chancen als Privatperson durchzudringen. Deshalb möchte ich Ihnen folgende Entwurf aus ärztlicher Sicht zur Verfügung stellen, den sie beliebig weitergeben können.

Die geplanten MIO als externe Datenmodule <span class="nobr"><a href="https://mio.kbv.de/display/IM1x0/Daten+eintragen" class="external-link" rel="nofollow">https://mio.kbv.de/display/IM1x0/Daten+eintragen^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> kommen erst mal nicht so rüber als würde der Aufwand für uns Ärzte kleiner.  Innerhalb der Praxisverwaltungssoftware verfügen wir gegenwärtig über Arbeitshilfen, wie selbstkonfigurierte Eingabemasken, die Teilinformationen auf verschieden Textgruppen aufteilen, Makros, Textbausteine, expandierende Kürzel, sowie Kopplungen von bestimmten Eingaben an Abrechnungsziffern usw..  Alle diese Hilfen w erden durch die MIOS wegfallen. Das war beim Bundesmedikamentenplan auch schon so.

Für das digitale Impfmodul wäre aus ärztlicher Sicht Folgendes erforderlich:

1. Digitale Archivierung des Papierimpfausweises Wir brauchen ein automatisiertes Fotografieren der vielseitigen (2 bis 24 seitigen) analogen Impfpässe. Ein Scann fällt wegen des erforderlichen Umblätterns der kleinen Heftschen wohl weg. Die Bilddatei muss so erstellt werden, dass alle Seiten des Dokuments später mit dem Namen, der nur auf der ersten Seite steht, endgültig verknüpft werden. Dies ist erforderlich, damit die analoge Datenlage dokumentiert werden kann. Die Impfpässe sind 30 bis 40 Jahre alt, mal mitgewaschen, haben herausgerissene Seiten, wurden im nachhinein erneut ausgestellt usw. Außerdem gibt es viele verschiedene Papier Formate. Die ältesten sind die langen weißen Stoffpässe, die auch die Bundeswehr verwendete. Dann die roten Bücher aus der ehemaligen DDR und etliche gelbe Heftchen in denen sich die Impfungen an unterschiedlichen Seiten finden. Dazu kommt das Problem, dass viele Patienten zwei und mehr Impfausweise haben. Die Patienten werden weiterhin den Papierausweis mit sich führen müssen, weil nur hier Unklarheiten im nachhinein geklärt werden können. Außerdem ist es extrem mühsam in zwei Fenstern eine PC die digitale Reproduktion mit den digitalen Einträgen zu vergleichen. Das wird in der Folge wahrscheinlich dazu führen, das entweder ausgedruckt werden muss oder größere Monitore angeschafft werden müssen.

1. Digitalisierung der Einträge aus dem Papierimpfausweis in die Eingabemaske Die Übertragung der Impfbucheinträge in die ARztakte während der Sprechstunde findet im unmittelbaren Kontext der Impfüberlegungen statt. So gibt es für viele Impfungen mehrere Impfschemata. In der Regel ein Schnellimmunisierungsschema und ein Standardschema. Liegt der analoge Papierimpfpass vor, dann reicht ein Blick auf die Daten der früheren Impfungen, und die Impfentscheidung kann gelingen. Möchte man einen Impfpass vom Papier in das digitale Modul übertragen, dann müsste für eine valide Entscheidungsbasis für jede Impfung der Tag, der Monat und das Jahr der Impfung eingegeben werden. Davon hängt bei einigen Impfungen (Hepatitis, FSME) ab, ob 3 oder 4 Injektionen erforderlich sind. (Die vierte Impfung wird ein Jahr später erforderlich!) Außerdem gibt es Kombinationimpfstoffzubereitungen, in denen eine Komponente mit halbem Impfstoffgehalt verimpft wird. Auch hier ist das Impfstoffschema anders als beim Volldosisimpfstoff. Deshalb reicht es beispielsweise nicht einfach einen Eintrag für die Hepatitis A und Hepatitis B Impfung an einem Tag vorzunehmen. Hier muss zusätzlich dokumentiert werden, ob der Kombiimpfstoff oder zweimal ein Einzelimpfstoff gegeben wurden. Außerdem kommen immer wieder völlig irreguläre Impfabstände vor, meist im Zusammenhang mit kurzfristigen Reisen. Dies war im Moment der Impfung verständlich, erfordert zu einem späteren Zeitpunkt aber ggf. zusätzliche Impfungen, weil Mindestabstände nicht eingehalten wurden. Wenn Sie sich den Regelimpfkalender anschauen, können Sie sich sicherlich vorstellen, das hier schnell mal 30, 40 manchmal bis zu 100 Einzeleinträge zusammenkommen.(Bei den Kindern werden 7-Fachimpfstoffe verimpft, macht also schon mal 7 Datumseinträge für eine Impfung. Nein, nicht immer steht der Impfstoffname im Impfbuch, wie es eigentlich heute gefordert ist. Auch im Papierimpfausweis sind hier nur Kreuzchen zwischen einem Datum und einer Unterschrift. Schauen Sie mal in Ihren Impfpass und den ihrer Familienangehörigen, dann wissen Sie was ich meine.) Für Impfungen, die länger zurückliegen, wird man keine Chargendokumentation mehr brauchen. Es sei denn es wurde Fremdeinweis appliziert, wie dies beispielsweise bei unklarem Tetanusimpfstatus früher recht großzügig gehandhabt wurde. Die Chargennummer der Fremdeinweisgabe, wie bei solchen Antikörpern üblich, ist häufig nur im Impfpass eingetragen und unterliegt einer erweiterten Dokumentationserfordernis. Jeder der behauptet man brauche das alles nicht, der hat noch nie Einträge aus einem Impfausweis digitalisiert. Wir machen dies seit Jahren und wissen wovon wir reden.

1. Eintrag der Dokumentation für eine vorgenommene Impfung in die Eingabemaske Zu einer Impfdokumentation nach einer Impfung, gehört das Datum, der Impfstoffklarname und die Chargennummer, Stempel und Unterschrift. Gegenwärtig wird ein Aufkleber von der Impfstoffampulle abgezogen, ins analoge Papierimpfbuch geklebt, Datum davor, ein paar Kreuze in den Spalten der Krankheiten gegen die geimpft wurde, Unterschrift, Stempel fertig. Dazu kommt die Dokumentation in der Arztakte. In einer Papierkartei wird hinter einem Datumseintrag, der extra dafür vorhandene, zweite Aufkleber eingeklebt. Die Abrechnungsziffer muss gesondert in den PC eingegeben werden. Erfolgt die Dokumentatin digital, dann wählen wir in einer dafür von uns selbst erstellten Eingabemaske den entsprechenden Impfstofftyp aus, dort wird durch einen Klick der Impfstoffname und die Chargennummer aktiviert. Da es sich häufig um Großpackungen handelt, muss dieser Eintrag nur verändert werden, wenn eine neue Großpackung angebrochen wird. Gleichzeitg mit der Ablage dieses Eintrags wird automatisch die Abrechungsziffer, die genau für diese Impfung vorgesehen ist, abgelegt. (Eine einzelne Tetanusimpfung hat eine andere Abrechnungsziffer wie eine Kombinationsimpfung gegen Tetanus-Diphterie und Keuchhusten. Es gibt ca. 50 5-stellige Abrechnungsziffern für die verschiedenen Impfungen. Digitalisierung hilft hier dem Arzt.) Eine digitale Impfstoffdokumentation, die diesen Namen auch verdient, erforderte einen kleinen QR-Code auf der Impfstoffampulle, der automatisiert alle diese Schritte (Datum, Klarnameneintrag, Chargennummer, Kreuzchen bei der Krankheit, Signatur und Abrechnungsziffer) automatisch auslöst. Dafür braucht man am Impfplatz einen Handscanner und einen allgemeingültigen QR-Code auf der Impfstoffampulle.

Also ich prognostiziere mal, wie es werden wird:

Die Nichtärztlichen-Entscheider werden sich auf den Standpunkt stellen, die Archivierung des Papierimpfausweises sei nicht erforderlich oder die Durchführung sei das Problem des Arztes. Die Digitalisierungseeinrichtung des Papierimpfausweises wird es nicht geben. (Ein Impfpass kann weder über einen Einzugsscanner <span style="text-decoration: line-through; ">über den viele Praxen verfügen</span> noch in angemessener Zeit über einen Flachbettscanner digitalisiert werden.) Wahrscheinlich wird bei der Digitalisierung der früheren Impfeinträge nur das Jahr der Impfungen in die Maske eingegeben werden und es wird stillschweigend davon ausgegangen, dass die Patienten weiterhin den Papierimpfausweis vorhalten, damit ärztliche Impfentscheidungen getroffen werden können. Die Eingabe der Impfdokumentaton vom gerade vorgenommenen Impfungen (Datum, Klarnameneintrag, Chargennummer, Kreuzchen bei der Krankheit, Signatur und Abrechnungsziffer) wird - bis auf das Datum - komplett manuell erfolgen müssen. Eine Nachbesserung mit Arbeitshilfen, so wie sie jetzt (noch) haben, wird für die Version 7.2 in Aussicht gestellt, aber nie realisiert. Die ärztliche Forderung nach einem QR-Code auf der Impfstoffampulle, einem Handscanner und einem im Modul vorinstallierten Dokumentations- und Abrechungsprozess, wird als unverhältnismäßig aufwendig und teuer niedergeredet. Ich unterstelle einmal, dass wir Ärzte hinter jeder einzelen Krankheit gegen die geimpft wurde einen Klick machen müssen, dann ein weitere Klicks für die Eigenschaft Kombinationsimpfstoff, danach wird eine händische Eingabe des Impfstoffklarnamens und der Chargennummer über Pflichtfelder erzwungen. Die Eingabehilfen, über die wir gegenwärtig verfügen, werden in dem Impfpassmodul nicht funktionieren. Deshalb werden wir dann noch einmal gesondert die Abrechnungsziffer in unsere Praxisinformationsoftware eingeben. Ach ja, fast hätte ich es vergessen. Es wird so sein, dass in den ersten drei Monaten, alle drei bis vier Tage, ein Korrektur-Update eingespielt werden muss. Jedesmal ändert sich dann die Eingabemaske, automatisch ablaufende Tippfolgen müssen jedesmal mühsam umgelernt werden.  Danach wird immer dann, wenn es irgendein wichtiger Datenabnehmer eine Änderung am Datenformat wünscht, die Eingabemaske "weiterentwickelt". Also wird die Maske und die Eingaberoutine mit dem nächsten Update auch später immer mal wieder geändert. Diese Updateproblematik gab es ebenfalls schon beim Bundesmedikamtenplan. Aus diesem Grunde ist der Bundesmedikamentenplan als das erste MIO anzusehen. Wenn Sie sich für die Umstände interessieren, wie dieser Plan eingeführt wurde, schauen sie bitte unter diesem Link: <span class="nobr"><a href="https://media.ccc.de/v/gpn19-80-von-analogien-nach-digitalien#t=827" class="external-link" rel="nofollow">https://media.ccc.de/v/gpn19-80-von-analogien-nach-digitalien#t=827^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> (Der Einsprung geht direkt zur Einführung des Bundesmedikamentenplans!) Professionell war das nicht!

So wie es jetzt geplant ist, findet wieder mal die Digitalisierung in der Medizin nicht für Ärzte statt!

Vielen Dank dass Sie bis hier gelesen haben. Ich freue mich immer über einen Anruf von Ihnen. Die Zeit drängt ein bisschen, die Frist zur Kommentierung bei der KBV läuft am 28.2.2020 ab. Danach wird Herr Dr. Kriedel  sagen, alle hätten Gelegenheit gehabt sich zu diesem Projekt äußern. Es sei jetzt aber alles mit allen Beteiligten abgestimmt worden, und keiner hätte sich beschwert...

herzliche Grüße von Köln nach Düren

Stefan Streit

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>

Von: Caroline Agricola <schriftfuehrerin@dghwi.de>
Gesendet: Freitag, 28. Februar 2020 18:28
An: >VP: KBV MIO <MIO@kbv.de>
Betreff: Kommentierung elektronischer Impfpass

Sehr geehrte Damen und Herren,

da wir einen allgemeingültigen Kommentar zum elektronischen Impfpass formuliert haben, sende ich Ihnen diesen per Mail zu.

Mit freundlichen Grüßen,

Caroline Agricola

Elke Mattern M.Sc. (Vorsitzende)

Prof. Dr. phil. Dorothea Tegethoff MHA (Stellvertr. Vorsitzende)

Kerstin Böhm M.A. (Schatzmeisterin)

Caroline Agricola, B.Sc. (Schriftführerin)

Prof. Dr. Barbara Baumgärtner (Beisitzerin)

Prof. Dr. Jessica Pehlke-Milde (Beisitzerin)

Prof. Dr. Astrid Krahl (Beisitzerin)

ich möchte aus Sicht des Hausarztes meine Hochachtung für Ihr MIO-Impfen Konzept zum Ausdruck bringen, auch wenn es beim „Expertentreffen“ vereinzelte andere Ansichten gab. Ich glaube, dass wir damit die gestellten Ziele erreichen können, nämlich eine verlustfreie Speicherung, ein effizientes Erinnerungssystem sowie eine Verbesserung des QM.

Ich möchte gerne nochmal bei Ihnen persönlich das Thema „geschlechtsspezifische Impfungen" ansprechen. 

Es gibt tatsächlich geschlechtsspezifische Impfempfehlungen insbesondere für Frauen im gebärfähigem Alter, sowohl im Standard- als auch im Indikationsbereich. 

z.B.:

• Röteln (Frauen 2 Dosen, Männer nur beruflich eine Dosis)
• Pertussis (Frauen regelmäßige Auffrischungen, Schwangerschaftsindikation)
• Influenza (Frauen - Schwangerschaftsindikation)
• MMRV, Gelbfieber u.a. (Frauen - Kontraindikation bei Schwangerschaft)
• Varizellen (empfängliche Frauen)

Es mag sein, dass die Angabe des Geschlechts zusätzlich im MIO redundant ist, aber auch andere Angaben sind redundant. Auf der anderen Seite kann/soll ein MIO-Impfen vielleicht zukünftig „gekapselt“ genutzt werden können (wie ein Teilnehmer bemerkte), u.a. auch durch Zugriff von Erinnerungssystemen, zum Nachweis der gesetzlichen Impfpflicht oder im Ausland. 

Wir dürfen auch nicht vergessen, dass die geschlechtsspezifischen Impfungen besonders sensible Gruppen betrifft, die uns bei der Impfprävention besonders am Herzen liegen wie junge Frauen im gebärfähigen Alter, Schwangere und indirekt Ungeborene. Auch die STIKO und die BZgA hat diese Gruppen immer wieder besonders im Blick, weil keine ausrechende Impfprävention vorliegt.

Ich befürchte auch, dass die Bedeutung des Geschlechts beim MIO leicht übersehen wird, wenn es „nur“ in der Akte steht. Es würde auch die Sensibilität für dieses Merkmal und die damit verbundenen Gruppen stärken, wenn es einen Platz im MIO selber finden würde. 

Ich möchte Sie deshalb bitten, in Ihrem internen Kreis im Sinne der Frauen und Ungeborenen für die Aufnahme der Geschlechtskennung zu plädieren. 

Der papiergebundene Impfausweis, indem das Geschlecht tatsächlich nicht aufgeführt ist, kann man m.E. nicht als Begründung heranziehen. Beim Papierausweis erkennt man das Geschlecht an der Person, die vor einem steht. Beim MIO wird es zukünftig Situationen geben, bei denen die Auswertung virtuell stattfindet und der Patient nicht anwesend ist. Früher gab es noch den Vornamen als Kennung für das Geschlecht, das ist aber mittlerweile auch unsicher.

Ich hoffe, Sie können meine Einwände nachvollziehen.

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?

Wie bereits unter "Informationsmodell" geschrieben, stellt der Patient eine Spezilisierung 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?

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?

Wozu gibt es dieses Feld. Hierbei handelt es sich m.E.n. aus einer Kombination der anderen Felder.

Zusätzliche Komplexität, falls Daten aktualisiert werden müssen (z. B. durch Hochzeit o.ä.).

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.

Die abgebildeten Objekte sind falsch spezifiziert. Wie bereits auf der Hauptseite geschrieben stellt "Patient eine Spezialisierung von Person dar, die Attribute aus den Klassen "Identifier" und "Name" sind direkt Attribute einer der beiden Klassen und gehören nicht in eigene Klassen, da sie keine "Datentypen" im eigentlichen Sinne darstellen.

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.

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.

VACCINATION IMMUNIZATION ORIGIN CODE

• S.o. Klärung der Lizenzsituation und der Vorgehensweise für eine abgestimmte Übersetzung.

VACCINE

• Die Darstellung von Vaccines entspricht den Gegebenheiten, die bei eHDSI verwendet werden.
• Für einige Impfstoffe gibt es derzeit keine Produkte auf dem Markt (z.B. Brucellose, Pest, Tuberkulose). Sind diese in der Auflistung entbehrlich?

Wurde der amtliche Deutsche ATC wie referenziert verwendet? Es fehlt der WHO-ATC-Code J07AR, J07AR01 und J07AX. Es fehlen die Codes des amtliche Deutschen ATCs J07AX01, J01AX02 und J07AX03, J07BX02.

• Wie wird mit den Resteklassen umgegangen? Unter J07AX Other bacterial vaccines werden z.B. Immunisationen mit Lactobacillus oder Enterobakterien kodiert, die als IGEL-Leistungen angeboten werden.
• Darstellung von allen Kombinations-Impfstoffen in SNOMED möglich?

• Entität „Impfstoff“:

o 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.
o 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.
o Hier bietet sich die ASK-Nummer an, die als Link zum Referenzdatensatz § 31b SGB V als auch zukünftig zu den ISO IDMP-Aktivitäten (EU SRS) dienen kann.

• Warum werden für UNDERGONE DISEASE (SNOMED + ICD-10-GM) und TARGET DISEASE (SNOMED + AlphaID) unterschiedliche KodeSysteme verwendet? Da ja auch die alphaID eine Synonymliste für ICD-10-Codes ist, wäre es konsequent, hier auch alphaID-Einträge zu verwenden.
• Ist die Infektionslage in Deutschland vollständig abgebildet (es fehlen z.B. Influenza oder Pneumokokken-Infektion)?
• Die LAB TITER sollten komplementär zu UNDERGONE DISEASE sein. Im Vergleich sind bei LAB TITER zusätzlich Titer für Diphtherie, Polio, Tetanus und Haemophilus B aufgelistet, bei UNDERGONE DISEASE zusätzlich Gelbfieber
• Im Vergleich zu vs Undergone disease fehlt bei cs undergone disease translation der Eintrag „Gelbfieber“
• Der NullValue „Nicht aufgeführt (unspezifiziert)“ ist im CodeSystem aufgelistet. Da ValueSets sich aus mehreren underliegenden Quellen zusammensetzen, sollte dieser besser dem ValueSet zugeordnet werden.

• Warum werden für UNDERGONE DISEASE (SNOMED + ICD-10-GM) und TARGET DISEASE (SNOMED + AlphaID) unterschiedliche KodeSysteme verwendet?
• Aus klassifikatorischer Sicht der ICD-10-GM sollten ICD-10-Codes unter Z23ff (Notwendigkeit der Impfung gegen …) bzw. deren alphaIDs herangezogen werden.
• Eine separate Liste für fehlende alphaIDs sollte vermieden werden. In Abstimmung mit DIMDI sollten fehlende alphaIDs nachgetragen werden. Die alphaID für Brucellose ist I13550. Die alphaID für Haemophilus Influenzae B fehlt tatsächlich, sie wird von DIMDI nachgetragen.
• Statt „Anthrax“ sollte im Sinne der Einheitlichkeit zwischen TARGET DISEASE und VACCINES das deutsche Wort „Milzbrand“ (I14685) verwendet werden.

Folgende Erweiterungen der alphaID durch DIMDI werden vorgeschlagen. Wir bitten um Rückmeldung, ob die Ergänzungen der AlphaID im Sinne der MIO-Entwicklung sinnvoll ist:

• Für bessere Sortierbarkeit sollte überlegt werden, folgende alphaIDs unter A und B aufzunehmen:
  o Meningokokken-Infektion
  o Humanes-Papilloma-Virus-Infektion
  o Pneumokokken-Infektion
  o Rotaviren-Infektion
• Fehlende alphaID für
  o Haemophilus influenzae-B-Infektion

• Unter Z23 ff fehlen folgende AlphaIDs:
  o Enzephalitis-Vakzination
  o Milzbrand-Vakzination
  o Brucellose-Vakzination
  o Varizella-Zoster-Vakzination (wird im ATC als Subtyp differenziert)

• Folgende alphaID sollte für bessere Sortierbarkeit und Konsistenz unter Z23ff aufgenommen werden
  o Röteln-Vakzination
  o Humanes-Papillomavirus-Vakzination
  o Meningokokken-Vakzination
  o Pneumokokken-Vakzination
  o Pocken-Vakzination
  o Impfung gegen Pocken
  o Rotaviren-Vakzination
  o Haemophilus influenzae Typ b-Vakzination
  o Für alle Einträge unter Z23ff sollte „Impfung gegen“ und „XY-Impfung“ ergänzt werden kann.
  o Es sollte geprüft werden, ob Typhus und Paratuphus zusätzlich getrennt angegeben werden sollen.
  o Ist „prophylaktische Impfung gegen Pocken“ sinnvoll?

• Für PS und eP in Europa wird die ISCO-88 Klassifikation verwendet, die in deutscher Sprache über Statistik Austria bereitgestellt wird

<span class="nobr"><a href="http://www.statistik.at/KDBWeb/kdb_DownloadsAnzeigen.do?KDBtoken=ignore&&AUFRUF=klass&&NAV=DE&&KLASSID=10519&&KLASSNAME=ISCO" class="external-link" rel="nofollow">http://www.statistik.at/KDBWeb/kdb_DownloadsAnzeigen.do?KDBtoken=ignore&&AUFRUF=klass&&NAV=DE&&KLASSID=10519&&KLASSNAME=ISCO^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>. PRACTITIONER FUNCTION ist feingranulärer, ein Mapping für den CROSS BORDER Kontext sollte daher gegeben sein.

• Aus fachlicher Sicht könnte überlegt werden, ob das angebotene ValueSet auf übliche impfende oder eintragende Berufsgruppen beschränkt wird (kein Bestatter, Taxifahrer oder Seelsorger!)

• Hier wird der LOINC LongCommonName angegeben.
• Eine qualitätsgesicherte Übersetzung für den LongCommonName ins Deutsche ist bisher nicht erfolgt. Von der Adhoc AG LOINC (unter Teilnahme der KBV) wurde vorgeschlagen, die Übersetzung für den LongCommonName regelbasiert aus den Parts zu generieren. Dies widerspricht dem Übersetzungsvorschlag in der MIO.
• Formal muss die deutsche Übersetzung bei Regenstrief (durch DIMDI) angemeldet werden, bevor diese genutzt werden kann. Gemäß der Lizenzbedingungen für LOINC ist bei Nutzung der Kodes ein Verweis auf das Quellsystem erforderlich. <span class="nobr"><a href="https://loinc.org/license/" class="external-link" rel="nofollow">https://loinc.org/license/^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
• Die Auswahl der betreffenden LOINC-Codes sollte in Abstimmung mit den Fachexperten erfolgen, bevorzugt in der von der KBV vorgeschlagenen zu gründenden AG LOING unterhalb des KKG1.
• Nach Abgleich mit TARGET DISEASE und VACCINE LIST sind die Einträge zu Antikörperbestimmungen nicht vollständig. Es ist davon auszugehen, dass von der KBV geprüft wurde, ob gängige Titerbestimmungen abgedeckt sind.
• Sollten LAB TITER als komplementär zu UNDERGONE DISEASE zu sehen sein? Im Vergleich sind bei LAB TITER zusätzlich Titer für Diphtherie, Polio, Tetanus und Haemophilus B aufgelistet, bei UNDERGONE DISEASE zusätzlich Gelbfieber.

1 <span class="nobr"><a href="https://www.dimdi.de/dynamic/de/klassifikationen/koop/kkg/" class="external-link" rel="nofollow">https://www.dimdi.de/dynamic/de/klassifikationen/koop/kkg/^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

• Aus den Darstellungen auf der Kommentierungsplattform zum Informationsmodell wird nicht klar, wo das ValueSet SOURCE OF INFORMATION zu verorten ist. Sollte das alternativ zu IMMUNIZATION ORIGIN CODE im Datenfeld „Informationsquelle“ verwendet werden?

• Im Impfpass der GEVKO und auch in der gelben Papierversion können auch Impfungen zur passiven Immunisierung eingegeben werden. Das ist hier out of scope. Sollte dazu ein Hinweis erfolgen?

• Harmonisierung im D-A-CH-Bereich? Wie bei den Hintergrundinformationen angegeben, schafft ELGA derzeit auch die Voraussetzungen für einen elektronischen Impfpass. Es ist anzunehmen, dass dort ähnliche ValueSets vorgeschlagen werden. Sollte eine Abstimmung der ValueSets erfolgen (z.B. bei der Auswahl der LOINC-Codes für Titer oder der Bereitstellung von SNOMED ValueSets)?
  VACCINATION AGE GROUP
• Im regulatorischen Bereich wird für Altersangaben folgendes Codesystem verwendet (s. RMS von SPOR bzw. ISO IDMP <span class="nobr"><a href="https://spor.ema.europa.eu/rmswi/#/lists/100000000001/terms" class="external-link" rel="nofollow">https://spor.ema.europa.eu/rmswi/#/lists/100000000001/terms^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span> (für Human- und Tierarzneimittel)
• Da Zulassungsangaben üblicherweise Kinder bis 12 Jahre ausschließen, wird die Altersgrenze für Jugendliche von 12 bis 18 Jahre angegeben
• Bei Erwachsenen wird noch eine zusätzliche Altersgruppe > 65 eingeführt, die möglicherweise auch im Studienumfeld relevant ist.
• Da ja zugelassene Arzneimittel verabreicht werden, sind diese Altersgrenzen möglicherweise relevant.

1. Die Abgrenzung von CodeSystem und ValueSet sollte klarer ausgearbeitet bzw. erklärt werden.
a. Im OID-Umfeld steht CodeSystem für ein komplettes Terminologiesystem ohne Anwendungsbezug, ValueSet steht für ein Subset mit einem bestimmten Anwendungsbezug, das aus mehreren „Auszügen“ von Kodesystemen bestehen kann (s.. <span class="nobr"><a href="https://fhir-drills.github.io/ValueSet-And-CodeSystem.html" class="external-link" rel="nofollow">https://fhir-drills.github.io/ValueSet-And-CodeSystem.html^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>)
b. Wenn „CodeSystem“ als komplette Klassifikation oder Terminologie zu verstehen ist, sollten für den Anwendungszweck wie „Impfpass“ nur ValueSets definiert werden. Aus fachlicher Sicht ist es daher nur erforderlich, auf CodeSystems (z.B: ATC, ICD-10, …) zu referenzieren. Wäre es daher möglich, im Simplifier ausschließlich ValueSets darzustellen und auf die Listung von CodeSystems zu verzichten?
c. Dadurch würde sich die Problematik unter Punkt 2 ebenfalls auflösen.

2. CodeSystems sind allgemeingültig. Es ist davon auszugehen, dass weitere MIOs auf dasselbe CodeSystem referenzieren werden (z.B. SNOMED CT, ICD-10, Practioner function). Wie wird verfahren, wenn das CodeSystem in einem anderen MIO ebenfalls verwendet wird (Benennung, canonical URL, etc)? Wie werden diese benannt oder zusammengeführt?

3. Angaben zum Codesystem
a. Zusätzlich zum Codesystem sollten im Simplifier Angaben zur Version bzw. zum Stand der Information für das betreffende ValueSet gemacht werden

4. Versionierung
a. Wie wird zukünftig mit Versionierung verfahren?
b. Welche Update-Zyklen sind geplant?
c. Wie wird mit „historischen“ / Abgelösten / deprecated Kodes verfahren?
Im Zusammenhang der Weiterentwicklung der verwendeten Klassifikationen und Terminologien sollte ein Standardvorgehen etabliert werden (z.B.: Was passiert bei Änderungen der verwendeten Alpha-IDs?).

5. Datenpflege und Erweiterung der ValueSets
a. Nach welchen Verfahren erfolgt die Erweiterung und Aktualisierung von ValueSets?
Siehe Kommentar bei Versionierung

6. Im eHDSI-Kontext wurde viel diskutiert, wie mit „leeren Datenfeldern“ bei der Datenübermittlung umzugehen ist, insbesondere bei Pflichtfeldern. Es werden für den Anwender Unsicherheiten genommen, wenn dargestellt werden kann ob eine Diagnose, ein Titer etc. nicht vorhanden ist, nicht durchgeführt wurde oder nicht bekannt ist.
a. Je nach Setting sollte darüber nachgedacht werden, verschiedene „Null Flavours“ zu definieren. Diese könnten dann an jedes ValueSet mit angefügt werden oder generisch als „NullFlavours“ bereitgestellt werden. Als „Null Flavours“ im EU Kontext wurden für Pflichtfelder definiert „no information <span class="error">[provided]</span>“ und „no known information about XY“.
b. Für die MIO Impfpass werden NullFlavours bisher nur für „Source of Information Translation“ und „undergone disease translation“ angegeben. Warum nicht für die anderen ValueSets?

7. Referenzierung über OIDs
a. Werden die der KBV zugeordneten OIDS 1.2.276.0.76.3.1.1.5 noch dem DIMDI zur Eintragung ins OID-Register mitgeteilt?

Stand 27.02.2020
Referenzierte Quellen:

• <span class="nobr"><a href="https://mio.kbv.de/display/IM1x0/IMPFPASS" class="external-link" rel="nofollow">https://mio.kbv.de/display/IM1x0/IMPFPASS^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
• <span class="nobr"><a href="https://simplifier.net/im1x0" class="external-link" rel="nofollow">https://simplifier.net/im1x0^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>

Zu Hintergrundsinformationen:
Als zusätzliche Quelle sollte die ECDC-Untersuchung von 2018 mit aufgenommen werden: <span class="nobr"><a href="https://www.ecdc.europa.eu/sites/default/files/documents/designing-implementing-immunisation-information-system_0.pdf" class="external-link" rel="nofollow">https://www.ecdc.europa.eu/sites/default/files/documents/designing-implementing-immunisation-information-system_0.pdf^{<img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/>}</a></span>
Allgemein zur Verfahrensweise der Bereitstellung von ValueSets

• Nutzung von alphaIDs: Die alphaID wird von DIMDI als Synonymverzeichnis gepflegt und jährlich als aktualisierte Version bereitgestellt. Als Prozess für die Bereitstellung fehlender bzw. besser passender zusätzlicher alphaIDs wird vorgeschlagen, diese alphaIDs vorab gemeinsam mit dem DIMDI zu entwickeln. Der weitere Prozess bis zur Veröffentlichung der Alpha-ID sollte gemeinsam weiter formalisiert werden.

• Nutzung von LOINC-Übersetzungen: Übersetzungen von LOINC ins Deutsche müssen vor ihrer Nutzung bei Regenstrief registriert werden. Die Veröffentlichung von LOINClinguisticVariants erfolgt in halbjährlichen Zyklen. Das DIMDI stellt eine qualitätsgesicherte Übersetzung von LOINC-Termen aus dem Laborbereich bereit. In 2019 hat sich eine Arbeitsgruppe gebildet, die diese Übersetzung und die Bereitstellung von LOINC ValueSets qualitätsgesichert und sektorenübergreifend weiterentwickeln möchte. Wir regen an, die Übersetzungsarbeiten zu LOINC in einen gemeinsamen Workflow zu überführen.

• Nutzung von HL7 Übersetzungen: Sinnvoll sind einheitliche Übersetzungen von deutschsprachigen Übersetzungen von HL7 ValueSets. Das DIMDI ist im Rahmen der Nutzung von HL7 ValueSets für die Umsetzung der CrossBorderDirective und das eHDSI Implementationsprojekt derzeit mit HL7 Deutschland (und HL7 International) in Verhandlungen bzgl. einer Lizenzvereinbarung.

• Nutzung des Amtlichen Deutschen ATC: Das Urheberrecht des WIdO ist zu beachten. DIMDI ist derzeit in Verhandlungen bzgl. einer Nutzung des WHO ATC im EU Umfeld mit dem WHO Collaboration Centre in Uppsala.