Nach Abschluss der Kommentierung und der Prüfung sowie Bewertung aller eingegangenen Kommentare ist hier ein Überblick zu den eingegangenen Kommentaren und den Bewertungsergebnissen einsehbar. Hier kann entnommen werden, an welchen Stellen Kommentare zu einer Überarbeitung des MIOs oder zur Aufnahme von Operationalisierungsempfehlungen für die umsetzenden IT-Systeme geführt haben.
Das überarbeitete MIO wird im Rahmen der Benehmensherstellung dargestellt.
Die Kommentare wurden entsprechend ihres Inhalts in folgende Kategorien eingeteilt:
Inhalt
Kommentarthema | Ergebnis |
|---|---|
| Warum sind Risikofaktoren (Erkrankungen, Allergien, Medikation) nicht Teil des digitalen Impfpasses? | Der gesamte Bereich der Risikofaktoren (dies betrifft sowohl Erkrankungen, Allergien als auch Medikation wie z.B. Immunsuppressiva) ist bis jetzt nicht im elektronischen Impfpass abgebildet. Zum einen, da diese Informationen nicht als einheitliche Vorgabe im Papierimpfpass enthalten sind und zum anderen da es Überschneidungen mit anderen Dokumenten bzw. Verortungen dieser Informationen gibt. Es sollte unbedingt vermieden werden, dass diese Angaben mehrfach gemacht werden müssen sowie, dass die Informationen auseinander laufen und damit nicht mehr klar ist, welcher Stand korrekt ist. Diese wichtigen Informationen sollten an anderer (zentraler) Stelle dokumentiert werden und dann vom behandelnden Arzt mit in die Impfentscheidung einbezogen werden. |
| Warum ist die Reisepassnr. als Identifier des Patienten enthalten? | Die Reisepassnummer ist in der Vorlage des WHO-Impfpasses (International Certificate of Vaccination) enthalten. Sie kann im Kontext von Reiseimpfungen (bes. Gelbfieber) relevant sein. |
| Warum ist das Impfdatum (Format) nicht mit der Angabe eines Tages definiert? | Das Feld Impfdatum ist für beide Szenarien (Eintrag und Nachtrag) vorgesehen. Bei einem Nachtrag ist u.U. das genaue Datum nicht bekannt, daher hier als mind. JJJJ modelliert. Bei einem Eintrag ist das Datum als TT/MM/JJJJ anzugeben. Die Beschreibung wird ergänzt. Der Unterschied ist in den FHIR Profilen abgebildet |
| Woher stammt die Liste der impfrelevanten Erkrankungen, ist diese vollständig? | Die Liste der impfrelevanten Erkrankungen beruht auf eigener Recherche auf Basis der publizierten Informationen des RKI - die Informationsquelle wird ergänzt. Nicht gelistete Erkrankungen, können mit NICHT AUFGEFÜHRT (UNSPEZIFIZIERT) codiert werden. Falls Erkrankungen fehlen, kann die Liste in der Zukunft angepasst werden. |
| Wie ist mit der Information "Grundimmunisierung abgeschlossen" umzugehen? | Die Entscheidung, ob und wann eine Grundimmunisierung vorliegt, obliegt dem eintragenden Arzt, der dies dann mit seiner Unterschrift bestätigt. Diese Funktion bezieht sich ausschließlich auf einen Nachtrag; durchgeführte Impfungen müssen entsprechend des Infektionsschutzgesetzes mit allen definierten Informationen einzeln eingetragen werden. Die Erfassung als "Grundimmunisierung abgeschlossen" soll eine Erleichterung im Übertrag aus einem Papierimpfpass bieten - in dem nicht alle Einzelimpfungen übertragen werden müssen, und trotzdem die gleiche Aussage erlangt wird. Es können auch immer alle Impfungen einer Impfserie einzeln übertragen werden. Wie bei allen Nachträgen ist die Validität des Nachtrages durch den nachfolgenden Arzt zu beurteilen. In der Beschreibung wird der Sachverhalt präzisiert. Grundsätzlich ist ein allgemeines Freitextfeld zu jedem Eintrag/Nachtrag vorgesehen. |
| Aufnahme des Geschlechtes | Auf Wunsch der Kommentierenden erfolgt die Aufnahme des administrativen Geschlechts, analog zu VSDM. |
| Warum ist das Datum der Folgeimpfung überhaupt enthalten und an eine Impfung geknüpft, sollte die Modellierung nicht besser außerhalb der Impfung erfolgen? | Die Möglichkeit ein Datum für eine Folge- oder Auffrischimpfung angeben zu können, ist eine Vorgabe des §22 IfSG. Aufgrund dieser Vorgabe ist das Datum der Folgeimpfung als Teil der Impfung selbst modelliert. Das Datum der Folgeimpfung ist eine Empfehlung bzw. ein Vorschlag (nicht unbedingt ein fester Termin) des Arztes, der die Impfung durchgeführt hat. Systeme können unabhängig davon auch "dynamische" Empfehlungen entsprechend der Impfung und des Impfdatums erstellen/aussprechen. |
| Warum ist es nicht möglich die Messwerte und Methode der Antikörperbestimmung strukturiert anzugeben? | Der Titer wird als Überschrift synonym für alle Antikörperbestimmungen genutzt; eine Anpassung des Wordings (Antikörpernachweis) kann erfolgen um Missverständnisse zu vermeiden. Dabei wird die Frage beantwortet, ob eine Immunität vorliegt (Codierung über "Antikörper vorhanden"/Antibody present) es wird kein Wert mit Einheit angegeben. Wenn die Angabe des Messwertes vom Anwender als notwendig erachtet wird, ist der Eintrag über Freitext möglich. Ein separates Feld ist dafür nicht vorgesehen (LOINC Codierung würde deutlich komplexer ausfallen, da die Bestimmungsmethode mit in die Codierung einfließt und diese im Vorhinein nicht per se bekannt ist). Die genaue Angabe des gemessenen Wertes inkl. der Methode mit entsprechender Codierung sollte im Laborbericht verortet sein. |
Warum werden Titerbestimmungen dezidiert angegeben, obwohl sie selten und in vielen Fällen obsolet sind? | Titer- bzw. Antikörperbestimmungen sind in der Regel nicht empfohlen. Es gibt jedoch Ausnahmefälle, in denen Antikörperbestimmungen angezeigt sind. Hierfür wird die Option gegeben das Ergebnis (keine Messwerte) in strukturierter Weise zu dokumentieren - wie dies auch im Papierimpfpass möglich ist. |
| Welche Organisationen sollen zusätzlich im Benehmensherstellungsverfahren beteiligt werden? | Die vorgeschlagene/n Institution/en wird/werden in den Benehmensherstellungsprozess einbezogen, da eine maßgebliche Betroffenheit vorliegt. |
| Welche Organisationen sollen zusätzlich im Benehmensherstellungsverfahren beteiligt werden? | Die vorgeschlagene/n Institution/en wird/werden nicht in den Benehmensherstellungsprozess einbezogen, da eine maßgebliche Betroffenheit nicht vorliegt oder dies keine bundesweite Organisation ist. (DVV, BAEMI, DGHM, BDL, DGKL |
| Welche Organisationen sollen zusätzlich im Benehmensherstellungsverfahren beteiligt werden? | Die vorgeschlagene/n Institution/en ist/sind bereits Teil des Benehmensherstellungsprozesses. (STIKO über das RKI) |
| Warum sind keine weiteren Informationen zum Patienten wie die Adresse, Ort und Kontaktdaten enthalten? | Es wurde sich am Papierimpfpass orientiert, wo diese Informationen nicht enthalten bzw. wenn enthalten nicht verpflichtend sind. Auch wenn zusätzliche Informationen durchaus sinnvoll sein können, sollten Informationen zum aktuellen Wohnort und Kontaktdaten nicht pro Impfeintrag gespeichert werden. Diese Informationen können bei Bedarf über andere Quellen bezogen werden. |
| Warum ist der Geburtsname enthalten? | 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). Es erfolgt eine Anpassung der Modellierung analog des Namens. |
| Warum gibt es keine Möglichkeit die Länge der Immunität nach einer Impfung zu dokumentieren? | Die Länge des Zeitraum einer Immunität ergibt sich aus der Impfung und den offiziellen Impfempfehlungen und bedarf keines eigenen Feldes. |
| Warum wurde der Familienstand nicht aufgenommen? | Die Angabe des Familienstandes wird für die Dokumentation einer Impfung als nicht relevant eingeschätzt. |
| Warum gibt es keine Dokumentationsmöglichkeit für passive Impfungen/Gabe von Immunglobulinen? | Die Dokumentationsmöglichkeit für passive Immunisierungen/Gabe von Immunglobulinen wird bei dem Eintrag einer Impfung als Impfstoff ergänzt. |
| Wieso wurde das Beispiel der Dosisreduktion für die Anmerkung zur durchgeführten Impfung (Kommentarfeld) gewählt? | Dieses Beispiel kann besonders im Kontext von Lieferengpässen relevant und passend sein z.B. wenn der Kinderimpfstoff nicht lieferbar ist und ein Erwachsenenimpfstoff verimpft wird. Als Beispiel in der Beschreibung soll es nur verdeutlichen, was hier eingetragen werden könnte - und gerade da dieses Szenario nicht den Regelfall darstellt, ist kein eigenes Feld sondern die Anmerkung dafür vorgesehen. |
| Warum gibt es ergänzende Angaben zur Person (Patient)? | Das Feld wird aufgrund der Rückmeldungen und nach Rücksprache entfernt. |
| Wieso fehlt die Packungsgröße? | Die Packungsgröße des Fertigarzneimittels (ob z.B. eine oder zehn Fertigspritzen enthalten waren) ist nicht relevant für die Abbildung des Impfstoffes im Impfpass und wird daher nicht aufgenommen. |
| Woher kommen die Titerbeschreibungen? und welche Ressourcen und normativen Dokumente wurden verwendet (Referenzen)? | Die deutschen Bezeichnungen sind als Konzept zu den LOINC Codes gemappt - sie bilden eine Art Überschrift in deutscher Sprache und beschreiben, um welche Antikörperbestimmung es im Folgenden geht.Normative Dokumente zu Antikörperbestimmungen sind nicht bekannt. Empfehlungen gibt es vom RKI und aus wissenschaftlichen Publikationen z.B. zu Impfungen bei Immundefizienz (Literaturstellen werden aufgenommen). |
| Warum sind in der Liste der Funktionsbezeichnung nur Ärzte enthalten? | Das gesamte Value Set enthält neben Ärzten auch andere Professionen (auf Deutsch). Die angesprochene Liste https://simplifier.net/im1x0/kbvcsmiovaccinationpractitionerfunction enthält den Display-Namen für den einen ergänzten Code aus SNOMED CT(R). Da zu Beginn der Kommentierung noch keine SNOMED CT(R) Codes zur Verfügung standen, war dies eventuell nicht ersichtlich. Anmerkung: Es ist zu dokumentieren wer für die Impfung verantwortlich ist und nicht, wer sie praktisch durchgeführt hat. Die Verantwortliche Person sind ausschließlich ärztlich (und Apotheker in Modellprojekten für Grippeimpfungen bei >18 Jährigen). |
| Warum können Tuberkulin-Tests nicht dokumentiert werden? | Die Möglichkeit das Ergebnis eines Tuberkulin-Tests zu dokumentieren, wird ergänzt. |
| Warum enthält die Liste der Informationsquelle weitere Angehörige nicht separat? | Dies ist ein bestehendes Value Set, das neben den Patient/Eltern/Erziehungsberechtigten keine separate Codierung von anderen Angehörigen vorsieht. Dieser Code ist praktisch als anamnestische Angabe einer nicht medizinischen Person zu verstehen und würde damit auch andere Angehörige inkludieren. Eine extra Ergänzung des bestehenden Value Sets scheint nicht sachgerecht. |
| Warum ist kein Datum für eine nächste Titerbestimmung vorgesehen? | Titerbestimmungen sind nicht grundsätzlich empfohlen. Die Notwendigkeit eines extra Feldes scheint vor dem Hintergrund der seltenen Nutzung nicht sachgerecht. Wenn sich zu einem späteren Zeitpunkt die Notwendigkeit ergibt, könnte es in Betracht gezogen werden. |
| Ergänzende Angaben zur Person (Arzt) streichen | Wir sehen keine Notwendigkeit das Element zu streichen. In diesem Feld können z.B. Zusatzqualifikationen angegeben werden, wenn dies erforderlich oder gewünscht ist. |
| Ist die "verantwortliche Person" immer ärztlich? und wie unterscheidet sich diese von der "eintragenden Person"? Haftet die "eintragende Person" für den Eintrag? | Mit dem in Kraft treten des Masernschutzgesetzes dürfen auch Apotheker (in Modellprojekten Patienten über 18 gegen Grippe) impfen, sodass die "verantwortliche Person" zwar meistens ärztlich ist, jedoch nicht immer sein muss. Aus diesem Grund ist die „ID – nicht näher spezifizierter Identifikation einer nicht ärztlichen, behandelnden Person" mit aufgenommen worden. Im Gegensatz zur "verantwortlichen Person", die eine durchgeführte Impfung verantwortet, ist bei der "eintragenden Person" vorgesehen, dass hier die Person genannt wird, die die Eintragung vornimmt. Im Falle eines Nachtrags kann dies durchaus durch eine Unterschrift bestätigt werden, die die die Richtigkeit des Eintrags bestätigt (dies bedeutet jedoch nicht die Haftung für die Impfung). |
| Warum ist die EFN enthalten, ist die Arztnummer als Identifikator nicht ausreichend? | Das Modell soll auch geeignet sein perspektivisch Einträge von Nicht-Vertragsärzten abzubilden, welche zur Zeit keine lebenslange Arztnummer haben. |
| Ergänzung des Datums des Nachtrags | Das Datum, wann ein Eintrag erstellt wurde, ist in der FHIR Spezifikation enthalten. Dies wird in der Überarbeitung im Informationsmodell angepasst. |
| Warum sind impfrelevante Erkrankungen und Titerbestimmungen nicht im Nachtrag enthalten? | Die Dokumentation von durchlebten impfrelevanten Erkrankungen und Titerbestimmungen, sind meist in der Vergangenheit liegende Ereignisse, die mit dem entsprechenden Datum bzw. Zeitraum dokumentiert werden; dies ist auch bei einem Übertrag möglich. Das Szenario Nachtrag bezieht sich nur auf die Impfungen; dies ist notwendig, da sich Kardinalität und Konformität zwischen einem Eintrag und einem Nachtrag unterscheiden. |
| Warum sind keine Titercodes von nicht impfpräventablen Erkrankungen enthalten? | Der Impfpass soll u.a. Auskunft über den Immunitätsstatus einer Person geben. Dafür werden Impfungen dokumentiert und die Möglichkeit gegeben zu dokumentieren, dass eine Immunität auf Grund einer durchlebten Erkrankung anzunehmen ist. In Ausnahmefällen werden zu diesen Erkrankungen Antikörperbestimmungen vorgenommen, um über einen Impferfolg oder eine notwendige Impfung zu entscheiden. Der Impfpass scheint nicht der richtige Ort zur Dokumentation von Nachweisen von nicht-impfpräventablen Infektionskrankheiten (z.B. HIV). |
Wo kann Dokumentiert werden, dass eine Impfung bzw. eine Folge-/Auffrischimpfung aus medizinischen Gründen nicht möglich ist? | Für die Angabe dass eine Auffrischimpfung aus medizinischen Gründen nicht indiziert ist, kann das generische Freitextfeld (Ergänzende Angaben zur durchgeführten Impfung) genutzt werden. Der Impfpass dient als Ort zur Dokumentation von durchgeführten Impfungen. Aus medizinischen Gründen erfolgte Nicht-Impfungen, sind auch bisher nicht im Impfpass vorgesehen und sollten in der Krankenakte separat dokumentiert werden. Im Kontext der zum Teil geltenden Masern-Impfpflicht könnten dafür zukünftig entsprechende Bescheinigungen ausgestellt werden. |
| Ist es möglich eine nicht-ärztliche Person (den Organisationsmitarbeiter), die den Eintrag tätigt, zu erfassen? | Der Organisationsmitarbeiter, der den Eintrag tätigt, kann über das Element "eintragende Person" erfasst werden; diese Person kann eine nicht-ärztliche Person sein. Anmerkung: laut Auslegung des RKI ist eine i.A. Unterschrift bei einem Impfeintrag (entsprechend §22 IfSG) nicht zulässig, siehe dazu auch FAQs des RKI https://www.rki.de/SharedDocs/FAQ/Impfen/AllgFr_RechtlFragen/FAQ04.html. Die "verantwortliche Person" ist daher immer der Arzt, der die Impfung verantwortet und mit seiner Unterschrift bestätigt. |
| Können Einträge oder einzelne Inhalte eines Eintrages korrigiert werden | Dies betrifft die Regelungen und Ausgestaltungen der ePA bei der gematik. |
| Warum ist nur die Reisepassnummer enthalten und nicht die Personalausweisnummer? | Der Hintergrund der Reisepassnummer sind die Vorgaben des International Certificate of Vacination der WHO im Kontext von Reiseimpfungen. Die Dokumentation der Personalausweisnummer scheint nicht notwendig. Wenn diese Nummer im Einzelfall erfasst werden soll, könnte dies über die PID erfolgen. |
| Warum sind die über 60 Jährigen nicht im klinisch relevanten Zeitraum separat abgebildet? | An dieser Stelle dient der klinisch relevante Zeitraum der Dokumentation des Zeitraums, wann eine immunisierende Erkrankung durchgemacht wurde. Hierfür scheint diese weitere Unterscheidung nicht so relevant; an anderen Stellen ist diese genauere Beschreibung jedoch wichtig, daher wird das Value Set ergänzt. |
| Ergänzung eines Unterpunktes um Impfschäden zu dokumentieren | Der Impfpass dient der Dokumentation einer durchgeführten Impfung, diese wird mit einer Unterschrift bestätigt und der Eintrag ist damit abgeschlossen. Eine Dokumentation eines Impfschadens sollte separat in der Krankenakte erfolgen. Frontends für Versicherte können den Nutzern weitere Informationen wie auch Hinweise zur online-Meldung von Nebenwirkungen geben. |
Sind Einträge durch den Patienten möglich? - dies widerspricht §22 IfSG | Die Dokumentation von Einträgen im Impfpass von Patienten selber, ist bisher nicht vorgesehen. Falls dies in der Zukunft etabliert würde, dann wäre dies kein Eintrag entsprechend §22 IfSG, sondern ein Nachtrag, der als solcher - vom Patienten erstellt - erkenntlich wäre und sich in einem separaten Bereich der ePA befinden würde. |
| Wieso ist kein Use Case "ICV ertellen/aktualisieren" abgebildet? | Das ICV ist der Nachweis über eine durchgeführte Gelbfieberimpfung. Dies kann so bereits im Szenario "Eintrag" abgebildet werden. Die Formalien des Ausdrucks eines ICV müssen allerdings geklärt werden, damit es den Vorgaben der WHO entspricht - bis dies nicht erfolgt ist, ist ein zusätzliches Ausfüllen notwendig. Ein Zusätzlicher Use Case scheint nicht notwendig. |
| Wieso ist der Vormund/gesetzlicher Beistand eines Patienten nicht im Impfeintrag enthalten? | Dies ist eine relevante Information für die Zugang zur jeweiligen ePA - auch im Kontext der Vertreterregelung. Damit ist die Dokumentation für den einzelnen Impfeintrag entbehrlich. |
| IHE: Erstellung eines offiziellen mobile Immunization content | Müsste über IHE angestoßen werden |
| Wie wird die Validität der Dokumentation einer impfrelevanten Erkrankung gewährleistet? | Der Umgang mit den Informationen zu impfrelevanten Erkrankungen durch den behandelnden Arzt sind prozessuale Fragen, die auch schon jetzt bestehen und die der digitale Impfpass nicht beantworten kann. |
| Wieso gibt es in der Liste des klinisch relevanten Zeitraums uneinheitliche Zeitbezüge beim Alter (Monate vs. Jahre), dies erschwert die Verarbeitung. | Die Beschreibung der Codes sind "Display-Names" die gewährleisten sollen, dass der Wert menschenlesbar und interpretierbar ist. In den meisten Fällen ist dieser Wert vom Anwender aktiv auszuwählen, da es sich um eine in der Vergangenheit liegende Erkrankung handelt und nicht eine zum Zeitpunkt der Dokumentation festgestellte - und das Feld damit mit dem Alter des Patienten automatisch zu befüllen wäre. |
Ist ein eigenes Feld für "verabreichtes Volumen" und "Impfstelle" erforderlich? | Ist in den meisten Fällen nicht relevant. Wenn es separat modelliert wäre, würde es beim Ausfüllen immer als Feld auftauchen. Diese Information ist zudem im Papierimpfpass nicht enthalten. Bisherige Rückmeldungen zu der Fragestellung ergaben keine Notwendigkeit für ein extra Feld - das Freitextfeld scheint daher ausreichend. |
| Warum wurde der Aktivitätsstatus beim Practitioner gestrichen? | Die Informationen über den Aktivitätsstatus zum Impfzeitpunkt entsprechen nicht notwendigerweise dem Aktivitätsstatus zum Zeitpunkt des Auslesens der Information und sie werden zwischenzeitlich nicht aktualisiert. |
| Wieso wurden die entsprechenden Identifier gewählt, sollte nicht eine Zuordnung über eine eindeutige ID erfolgen, z.B. bei Geburt unveränderlich zugeteilte 11-stellige ID-Nummer? | Die Reisepassnummer ist im WHO-Dokument enthalten. Beliebige weitere IDs können im Feld PID eingetragen werden. Im Kontext des Datenschutzes ist auch zu hinterfragen, ob diese Nummer wirklich zur Identifikation von Patienten genutzt werden sollte. |
| Welche Person wird im Impfpass betrachtet (GKV/PKV/Selbstzahler)? | Der Nutzerkreis des digitalen Impfpasses als Teil der ePA ist Teil der Ausgestaltung der gematik. Die Spezifikation soll möglichst einen Impfpass für jeden Patienten abbilden können. Jeder Impfeintrag bildet einen Snapshot mit der Kassen-Zugehörigkeit zu diesem Zeitpunkt ab. Ein Versicherungswechsel hat daher keinen Einfluss auf den Eintrag. |
| Sind die Inhalte des § 22 Absatz 3 Infektionsschutzgesetz in der Spezifikation enthalten? | Die Inhalte des § 22 Absatz 3 Infektionsschutzgesetzes - Hinweis zum Verhalten bei ungewöhnlichen Impfreaktionen - sind im "Disclaimer" enthalten. Dies ist ein feststehender Text der dem Patienten zur Anzeige gebracht werden soll. Die Beschreibung und die Rationale für den Disclaimer wurden entsprechend des aktuellen Infektionsschutzgesetzes (Stand März 2020) angepasst. |
| Wieso ist die Impfindikation nicht zu dokumentieren? | Die Impfindikation scheint für die Dokumentation einer Impfung im Impfpass nicht notwendig. Unbenommen davon, ist diese Information in den Praxisverwaltungssystemen von Vertragsärzten zu Dokumentations- und Abrechnungszwecken ggf. zu erfassen und kann von Impfmanagementsystemen genutzt werden. |
| Wie stehen eine Titerbestimmung und eine Impfung im Impfpass miteinander im Verhältnis und wie wird dies abgebildet? | Die Antikörperbestimmung und die Dokumentation einer durchgeführten Impfung stehen separat im Impfpass. Ein Titer kann vor, nach oder auch unabhängig von einer Impfung bestimmt werden. Der Zusammenhang geht aus dem bestimmten Titer und der durchgeführten Impfung sowie dem jeweiligen Datum hervor. Der Aufbau einer direkten Beziehung zwischen den beiden Einträgen in diesem Modell scheint nicht notwendig. |
| Erfolgen Abstimmungen mit maßgeblichen Organisationen wie dem DIMDI? | Ja, es erfolgen Abstimmungen. |
Kodierung
Kommentarthema | Ergebnis |
|---|---|
| Ist ein ValueSet Diagnose vorhanden? | ValueSet vorhanden: https://simplifier.net/im1x0/kbvvsmiovaccinationundergonediseaseicd |
| Warum fehlt der Code für Brucellose? | Der Alpha-ID Code I13550 für die Erkrankung Brucellose wird ergänzt. Ein Austausch mit dem Dimdi erfolgt. |
| Funktionsbezeichnung | Die Auflistung der Berufsgruppen wird überprüft und auf das Notwendigste beschränkt. Für die Funktionsbezeichnungen wurde ein ValueSet der IHE verwendet. Die Überschriften in den Spalten werden verständlich angepasst. |
| Warum werden SNOMED CT® ConceptMaps verwendet? | Die Verwendung von ConceptMaps erfolgt derzeit, da nicht der Anschein einer Übersetzung erzeugt werden soll. |
| Bezieht sich die Bezeichnung "Product Code" auf Concepts? | Die Beschreibung wird in SNOMED CT® Concept - Pharmaceutical / biologic product (product) angepasst. |
| Warum werden für die Erkrankungen Alpha-IDs anstatt ICD-Codes verwendet? | Die Alpha-ID basiert auf dem Alphabetischen Verzeichnis zur ICD-10-GM und identifiziert den Eintrag eindeutig. Die Erkrankungen stehen hier nicht im Fokus und es wird nur beschrieben, dass gegen eine bestimmte Erkrankung geimpft wird. Daher keine Verwendung von ICD-Codes. |
| Warum werden die Stoffbezeichnungen nicht aus der Referenzdatenbank übernommen? | Die Referenzdatenbank nach §31b existiert derzeit noch nicht, zusätzlich ist IDMP nicht kostenfrei über das DIMDI verfügbar. Die ASK-Nummer kann integriert werden, wenn diese Teil der Referenzdatenbank ist. |
Klassifikationssysteme Mapping | SNOMED CT ist die bevorzugte Codierung. Wir bilden die unterschiedlichen Anwendungsgebiete mit den jeweiligen Klassifikationssystemen ab, die diese semantisch eindeutig identifizieren. Mappings von unterschiedlichen Klassifikationssystemen auf SNOMED CT und umgekehrt werden von der KBV erstellt. Die Zuordnung der Impfstoffe zu den jeweiligen Krankheiten erfolgt über die technische Umsetzung der Hersteller. Diese Auflistung dient als Mapping. Die nationale Lizenz wird für Deutschland erworben. Das BfArM wird SNOMED CT verwalten und deutsche Übersetzungen anbieten. |
| Sollte die Angabe der Laborergebnisse auch die Codierung des verwendeten Testreagenzes aus der EUDAMED-Datenbank beinhalten? | Kein Zugriff auf die Datenbank über das DIMDI. Die Codierung von Titer erfolgt über das weit verbreitete Codesystem LOINC und evtl. über SNOMED CT. Im Impfpass wird die Antikörperbestimmung lediglich übergreifend beschrieben (Codierung - "Antibody present"). Die genaue Angabe des gemessenen Wertes inklusive des durchgeführten Tests mit Testreagenz sollte im Laborbericht verortet sein und werden im weiteren Verlauf des Projektes diskutiert. |
| Werden deutsche Bezeichnungen nur zum Zweck der Ansicht verwendet? | Die deutschen Bezeichnungen dienen als Mapping für englischsprachige Codes für die es bisher keine offizielle Übersetzung gibt. Dies ist weniger als Vorgabe für die Ansicht zu sehen, sondern vielmehr für die Sicherstellung der Einheitlichkeit und Korrektheit der Inhalte. |
| Warum wird anstelle der Bezeichnung 'recall' nicht 'memory' verwendet? | Dies ist ein Ausschnitt eines bestehenden Codesystems von HL7. Siehe http://www.hl7.org/fhir/valueset-immunization-origin.html. |
| Muss die Revision der vorgelegten LOINC-Codes für die Titer-Angaben im Impfpass bedacht werden? | Die genaue Angabe des gemessenen Wertes mit dem dazugehörigen spezifischen LOINC-Codes sollte im Laborbericht verortet sein. Im Impfpass wird lediglich der Immunitätsstatus abgebildet. Dies erfolgt über die übergeordneten Codes. |
| Könnten tatsächlich gemessene Werte mit einem Finding-Konzept modelliert werden? | Die Konzepte für den Status der Immunität werden angepasst. |
| Kosten im Einsatz von SNOMED CT® seien zu bedenken. | Vielen Dank für diesen Hinweis. Wir werden Ihr Feedback an die relevanten Stellen weiterleiten. Die nationale Lizenz wird für Deutschland erworben. Das BfArM wird SNOMED CT verwalten und deutsche Übersetzungen anbieten. |
| Code fehlerhaft/ Änderungsvorschlag | Der Code und die Bezeichnung für den Cholera, Typhus-Impfstoff werden angepasst. Der Impfstoff (426081003 |Diphtheria + tetanus + pertussis + recombinant hepatitis B virus vaccine (product)| ) wird zu Hepatitis B angepasst. Der Code und die Bezeichnung für die Erkrankung Rotavirus wird angepasst. |
| Post-coordinated Syntax | Laut SNOMED CT Concept Model sollten Postcoordinated Expressions für die Domäne Pharmaceutical / biological product (product) mittels sich wiederholender Attritbut Groups gebildet werden. Siehe: https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=71172323). Die Syntax für die Postcoordinated Expressions werden angepasst. Im Impfpass stehen Wirkstoffe nicht im Fokus. Der Impfstoff wird hier als Produkt abgebildet und daher als Postcoordinated Expressions dargestellt. |
| Lebensphase | Die Konzepte der Lebensphase werden in (qualifier value) angepasst. |
| Diagnosecode | Das Konzept für nicht spezifizierte Infektionskrankheit wird angepasst. |
| Verfügbarkeit Impfstoffe | Wir haben vorsorglich alle im amtlichen Deutschen ATC enthaltenen Impfstoffe aufgelistet, da wir die Marktverfügbarkeit der Produkte nicht überprüfen bzw. beobachten können (Aktualisierung alle 14 Tage). Die Hersteller sollten nur die Impfstoffe zur Auswahl geben, zu denen es auch Produkte auf dem Markt gibt. |
| Warum wurde der Impfstoff für Masern und Röteln über eine Expression definiert? | 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. |
| Version der ATC-Klassifikation | Die Version der genutzten deutschen amtliche Fassung der Anatomisch-Therapeutisch-Chemischen (ATC) Klassifikation wird ergänzt |
| Notwendigkeit der Unterscheidung zwischen Herpes zoster Tot- und Lebendimpfstoff | Die Unterscheidung Tot-/Lebendimpfstoff wird mit aufgenommen - allerdings ist in SNOMED CT bisher keine Unterscheidung zwischen Herpes zoster/Varicella zoster möglich, da es sich inhaltlich gesehen um den gleichen Erreger handelt. Eine Aufnahme wird diskutiert werden müssen (hier müssen sich die Prozesse erst etablieren). |
| Wie kann vermieden werden, dass das Mapping 5-stelliger ATC-Codes auf den entsprechenden SNOMED CT Code nicht den 7-stelligen ATC-Code mit eigenem Mapping umfasst? | Bei Auswahl aus einer Arzneimitteldatenbank und dem Mapping des ATC-Codes auf den entsprechenden SNOMED CT® Code sollte das System zuerst auf Ebene des 7-stelligen ATC-Codes prüfen, ob ein solches Mapping vorliegt. Wenn dies nicht der Fall ist, ist auf eine Entsprechung auf Ebene des 5-stelligen ATC-Codes zu prüfen und diese 1:1 Verbindung zu nutzen. Dies wird als Operationalisation ergänzt. |
Technische Repräsentation
Kommentarthema | Ergebnis |
|---|---|
| Wozu dient das Attribut "vollständiger Name"? | Der vollständige Name ist als optionales Attribut gedacht, um die korrekte Reihenfolge anzugeben. Dies sollte sich mit der strukturierten Angabe decken. |
| EFN sei keine gängige Angabe | Die EFN wird als einer von diversen Identifikatoren genutzt. Es geht darum auch Ärzte ohne ANR einen Identifikator bereitzustellen. Aus diesem Grund können nicht immer alle IDs gesetzt werden. |
| Warum wurden die vorhandenen Use-Cases gewählt und keine anderen? | Die folgenden Use-Cases sollen durch die Gematik abgedeckt werden, da die KBV für die syntaktische und semantische Definition zuständig ist.
Das gilt ebenfalls für eventuelle Transaktionsdiagramme |
| Ist der Titel kein Bestandteil des vollständigen Namens? | Die Beschreibung des vollständigen Namens wird präzisiert. |
| Müssen bei jedem Use-Case "Daten eintragen" alle Felder nochmal neu befüllt werden? | Nach den Kardinalitäten müssen einige Felder zwangsläufig befüllt werden. Eine darüber hinausgehende Übernahme ist nicht notwendig. |
| Spielt die Gültigkeit des Passes bei der Reisepassnummer eine Rolle? | Da die ID zu jeder Impfung gespeichert wird, ist die zu diesem Zeitpunkt gültige Nummer gemeint - das Gültigkeitsdatum/-zeitraum spielt dabei keine Rolle. Es können auch ausländische Reisepässe verwendet werden |
| Warum wird der Datentyp "date" für das Geburtsdatum verwendet? | Mit dem Datentyp date können auch nur Jahreszahlen übertragen werden. Die Datentypen werden nochmal genauer erläutert. |
| Warum werden Dummy-Werte anstelle von SNOMED CT®-Codes verwendet? | Die Dummy-Werte sind Platzhalter bis SNOMED CT®-Codes verwendet werden dürfen. |
| Warum erhalte ich eine Fehlermeldung beim Aufrufen der Ressource auf Simplifier? | Es scheint ein technisches Problem bei Simplifier zu geben. Der Support wurde verständigt. |
| Warum gibt es Abweichungen zwischen dem Informationsmodell und den FHIR®-Profilen? | Die referenzierte Darstellung soll nur eine grobe Übersicht bieten. Es wird zu jedem einzelnen Attribut im Informationsmodell ein Mapping auf die entsprechende Stelle in FHIR angegeben. |
| Welche Rolle haben die FHIR®-Profile und in welchem Verhältnis stehen sie? | Die Rolle der Profile zu einander ist zwar implizit beschrieben. Dieses wird aber nochmal expliziter gemacht. Auch die Profilhierarchie wird nochmal genauer dargestellt. |
| Informationsmodell sei inkonsistent | Die Darstellung wird angepasst. |
| Warum ist die Anzahl der Zeichen beim Identifikator "PKV-Versichertennummer" nicht klar definiert? | Da nicht einheitlich definiert ist, wie eine PKV-Nummer aussieht, kann diese auch nicht näher spezifiziert werden. |
| Warum wurde für die GKV-Versichertennummer eine Ausprägung von 0-10 Zeichen gewählt? | Die Feldlänge wird auf genau 10 Zeichen gesetzt. |
| Benennung von Feldern sei nicht eindeutig | Die Benennung wird nochmal überprüft. Die Bennennung zu versichertenID_GKV ist durch die Basis-Profile vorgegeben. |
| Warum existiert keine Bedingung, die ein Befüllen beider Felder ("GKV-Versichertennummer" und "PKV-Versichertennummer") bei einem neuen Eintrag ausschließt? | Eine solche Bedingung ist nicht notwendig, da es sich hier nur um Identifier handelt und daher beide gleichzeitig vorhanden sein können. |
| Ist die Zahnarztnummer aus dem richtigen Codesystem? | Bitte wenden Sie sich dafür an den Herausgeber des Codesystems. |
| Warum werden keine CVX-Codes verwendet? | Die CVX-Codes scheinen ein Codesystem zu sein, welches Impfstoffe verwaltet, die in den USA erhältlich sind. Wir haben mit SNOMED CT® das deutlich breitere Codesystem gewählt. Die CVX-Codes sind in FHIR® nur als example angegeben. |
| Ist eine Composition für den Impfpass notwendig? Warum können Blutgruppen nicht angegeben werden? | Eine Composition ist die Abbildung eines Dokumentes, daher ist diese notwendig. Blutgruppen sind zur Abbildung einer Impfung nicht notwendig |
Wofür stehen die Inhalte der Spalte 'Datentyp CC'? | Die Erklärungen der Datentypen und Kardinalitäten werden angepasst. Auch die Verbindung zu Art-Decor wird explizit dargelegt. |
| Was passiert, wenn die Versichertennummer oder die Versicherungsart sich ändern? | Da die ID zu jeder Impfung gespeichert wird, ist die zu diesem Zeitpunkt gültige Nummer gemeint - der Gültigkeitszeitraum spielt dabei keine Rolle. |
| Sollte es eine Kombinationsmöglichkeit von digital, Bescheinigung und Eintrag im Impfpass geben? | Es gibt nur die angegeben Kombinationen. Eine Kombination aus digital, als Bescheinigung und Eintrag im Impfausweis ist nicht möglich. |
| Warum werden unterschiedliche FHIR®-Profile verwendet? | Die unterschiedlichen Profile sind zur expliziteren Beschreibung der Szenarien definiert worden. Als Beispiel: Bei Prime ist der Use-Case "Daten eintragen" beschrieben und bei Addendum ist der Use-Case "Nachtragen" beschrieben. |
| Wurde ein eigenes Codesystem verwendet? | Es wurde kein eigenes Codesystem verwendet, sondern ein durch die KBV erweitertes Valueset mit Basis von IHE. |
| Lässt sich die Ressource ImmunizationEvaluation nutzen, damit keine eigene Observation profiliert werden muss? | Die Ressource ImmunizationEvaluation ist als Auswertung einer Impfung zu verstehen, diese ist hier aber nicht nur gemeint. Eine Titerbestimmung kann auch ohne Impfung erfolgen. |
| Wäre es möglich statt Extension die Ressource ImmunizationRecommendation zu nutzen? | Es wäre möglich diese Ressource zu nutzen, allerdings ist der Aufwand um genau ein Attribut(Information) dieser Ressource zu nutzen relativ hoch. |
| Warum wurde Extension verwendet? | Diese Ressource wurde zur Vervollständigung (Stichwort: Selfcontained) der Ressource Immunization entwickelt und ist nur eine Vorausschau auf eine folgende Änderung (FHIR TC) der Ressource an sich. Die Beschreibung der Extension "Enterer" wird angepasst. |
| Wird nur in Teilen auf das deutsche Basisprofil verwiesen? | Alle Identifier und Namen, wenn bei HL7 vorhanden, sind von den deutschen Basisprofilen abgeleitet. Explizit auch die erwähnte GKV-ID oder der name.prefix. |
| Gibt es einen Unterschied zwischen ANR und LANR? Wieso wird bei der BSNR ein eigenes identifier system verwendet? | Die ANR wird umgangssprachlich auch LANR genannt. Siehe Definition im Informationsmodell Punkt 2.9.1. Die Arztnummer und Betriebsstättennummer wird von der KBV definiert und daher werden die deutschen Basisprofile dahingehend angepasst. |
| Warum fehlt die Angabe der Zeichenanzahl? | Die Zeichenzahl ist in einigen Fällen durch die EGK begrenzt. Diese Werte werden wir auch durchgehend übernehmen. Andere Zeichenlängen sind durch FHIR begrenzt (1MB). Datumsformate werden noch explizit im Informationsmodell angegeben |
| Wozu gibt es die Extension beim Geburtsdatum? | Die Extension erlaubt das Geburtsdatum in absoluten Sonderfällen nicht anzugeben (Wert der EGK 00000000) |
| Worauf bezieht sich die PID? | Die PID kann eine organisationsbegrenzte ID sein, daher kann das System frei vergeben werden. Die Vergabe einer UUID ist nur ein Vorschlag. |
| Könnte man den Namen Observation_Immunization_Status ändern zu Antibody_Status? | Die Benennung kann geändert werden. |
| Warum wird im Addendum Immunization.primarySource mit "false" als Konstante gesetzt? | PrimarySource kann fest auf true gesetzt werden. |
| Sollte die Kardinalität von Immunization.note nicht anders angegeben werden, um doppelte Einträge und erzwungene "Anmerkungen" zu vermeiden? | Der Slice sollte korrekt gesetzt sein. Es gibt den Disclaimer verpflichtend (1..1). Insgesamt darf es max. 2 Notes geben, daher ist noch ein Note frei. |
| Warum wird ValuesetBinding anstatt Extension verwendet? | Wir möchten an der Stelle nicht auf den expliziten SNOMED CT®-Code in der Instanz verzichten. |
| Warum wurden einige mögliche Attribute weggelassen? | Aus Gründen der Datensparsamkeit haben wir uns entschlossen nur Dinge zuzulassen, die entweder notwendige Informationen sind oder aber zu einer großen Vereinfachung führen. |
| Warum fehlt im Simplifier-Projekt eine Dependency auf die deutschen Basisprofile? | Wir warten darauf, dass die Basis-Profile einen festen Stand haben. |
| Wird die KBV eigene Basis-Profile definieren? | Die KBV entwickelt in Abstimmung mit der MII und HL7 eine gemeinsame Basis. |
| Lob | Danke! |
| Welcher Vorteil ergibt sich durch die Verwendung einer NullFlavor-Extension für vaccineCode? | VaccineCode ist eine Pflichtangabe. Wenn kein Impfstoff vorhanden ist, sollte das lieber durch eine explizite Angabe kenntlich machen als durch einen Code, um zuzeigen dass hier etwas nicht wie erwartet ist. Zusätzlich müsste man dann noch einen Code für NICHT-Vorhanden einführen. |
| Profilierung von Provenance | Sobald eine KBV-Basis entwickelt worden ist, wird diese Ressource auch breiter verwendet werden. |
| Anpassung der Beschreibung | Die Beschreibung wird überprüft und konkretisiert. |
| Ist eine Anpassung der Extension Grundimmunisierung "abgeschlossen" erforderlich? | Die Benennung einer Serie sollte nicht "abgeschlossen" lauten, das ist eher eine Eigenschaft einer Serie. Daher ist der Einsatz der Extension hier nicht verkehrt. |
| Warum wird kein Code anstelle von codeableconcept verwendet? | Die Angabe eines Codesystems, in dem der Code nochmal erläutert ist, macht die Angabe genauer, da "legal" an sich nicht genau genug selbsterklärend ist. |
| Wo werden die Kardinalitäten dargestellt? | Die Kardinalitäten sind derzeit in den Szenarien abgebildet, werden aber voraussichtlich zukünftig auch in den Bildern zu erkennen sein. |
| Ist es denkbar die Observation Titer unter Berücksichtigung verschiedener Anwendungsszenarien zu modellieren? | Wir sind derzeit in der Entwicklung solcher global einsetzbaren Basis-Profile. |
| Warum wird PID verwendet? | Es soll eine ID vorhanden sein, um eine mögliche noch unbekannte Weiterverwendung dieser Instanz zu ermöglichen. PID ist ein Notfallidentifier, wenn kein Anderer bekannt ist. |
| Warum wird eine vom Basisprofil Patient abweichende Ressource "Basis Patient" verwendet? | In R4 gibt es den deutschen Basis-Patienten nicht mehr. Es ist jetzt ein Baukastensystem. |
| Sollte nicht die Bezeichnung "Krankenversichertennummer" verwendet werden? | Ist korrekt, wird angepasst. |
| Informationsmodell sei lückenhaft | Die Modellierung und Darstellung ist für eine fachliches Publikum gedacht. Es gibt aber immer ein FHIR-Mapping, um die genau Position in der FHIR-Umsetzung zu erkennen. Die Darstellung der Attribute und Klassen ist auch durch das Tool ART-Decor bestimmt, wird aber nochmal konkretisiert. |
| Sollten sich Kardinalität und Optionalität im Informationsmodell wiederfinden, damit korrekte Ableitungen in die Use Cases verifiziert werden können? | Wenn sichergestellt ist, dass alle Use_Cases zur Datenerstellung angegeben sind, dann ist das Modell eindeutig beschrieben. Die Darstellung ist durch das Tool Art-Decor bestimmt. |
| Informationsmodell | Verantwortliche Person" und "Eintragende Person" sind zwei abgeleitete Behandelnde. Die Darstellung ist durch das Tool Art-Decor bestimmt und wird ergänzt wenn die KBV-Basisprofile veröffentlicht werden. |
| Könnte die description in Bezug auf die Verwendung von SNOMED CT® angepasst werden? | Die Description kann angepasst werden. Die Verwendung von ConceptMaps erfolgt derzeit, da nicht der Anschein einer Übersetzung erzeugt werden soll. |
| Welche Verwendung hat PZN Display? | Die Bezeichnung (Display) des Codes kann optional gesetzt werden. |
| Was genau ist der Anwendungsfall der Extension zu doseNumber? | Dosenumber ist eine Pflichtangabe und muss daher durch das explizite Setzen einer Nullflavor-Extension als nicht-vorhanden gesetzt werden. |
| Ist ein Implementationguide geplant? | Derzeit ist kein Implementationguide geplant. Die Informationen auf mio.kbv.de werden noch erweitert. |
| Warum ist die Profilhierarchie nicht in der Namenskonvention ersichtlich? | Die Hierarchie ist projektintern beschrieben. Projektübergreifend sollte dies in Zukunft bedacht werden. |
| Warum fehlt die Spezifizierung der Signatur? | Die Art und Weise, als auch der Prozess der Signaturerstellung wird gerade mit der gematik geklärt. |
| Postfach/Land/Postleitzahl | Die Angaben werden korrigiert |
| Wie ist der Anwendungsfall für das Feld "Ergänzende Angaben"? | Das Feld wird entfernt. |
Operationalisierung
Kommentarthema | Ergebnis |
|---|---|
Gibt es Eingabeunterstützungen? [Automatisierte Erfassung und Übernahme von Datenfeldern des 2 D-Barcodes über Scanner, aus Arzneimitteldatenbanken, aus Primärsystemen und zurück, aus dem Laborinformationssystem usw.] | Das Datenmodell unterstützt die (teil-)automatisierte Erfassung von Datenfeldern (z.B. aus dem Primärsystem, Arzneimitteldatenbanken, über Scanner, Datenübernahme aus dem LIS, Arztangeben aus dem Primärsystem). Die Umsetzung und der Funktionsumfang der Eingabeunterstützung ist Aufgabe der Primärsysteme und kann nur abhängig von der jeweiligen Praxis- und Softwareausstattung erfolgen. |
Werden Impfempfehlungen und Impfmanagementfunktionen unterstützt? [Abgleich der Impf- und Patientendaten (auch aus anderen Teilen der ePA zu Allergien, Komorbiditäten etc.) mit Impfempfehlungen z.B. der STIKO bzw. regionalen Kommissionen, das Aufzeigen von eventuellen Impflücken, abgeleitete Erinnerungsfunktionen für ärztlich tätige Personen bzw. über das Frontend des Versicherten und weitere Funktionalitäten. Einfacher und schneller Zugang zu Informationen (Verfügbar machen von Informationen zu Erregern, Erkrankungen und der Impfung)] | Das Datenmodell unterstützt durch die Abbildung von Informationen zu durchgeführten Impfungen, durchgemachten Erkrankungen und Antikörpernachweisen jedoch nicht die Funktionen eines Impfmanagementsystems. Die Umsetzungen von Impfempfehlungen (z.B. STIKO) oder andere Impfmanagementfunktionen (Erinnerungen, Vollständigkeiten o.ä.) kann in den Funktionsmodulen der Primärsysteme oder des Frontends des Versicherten erfolgen. Das Feld für Folgeimpfungen kann zur Dokumentation von geplanten Impfungen gegen die gleiche Erkrankung genutzt werden und ist nicht als übergreifendes Erinnerungsfeld gedacht. |
Fragen zu Anwendungsszenarien [Leichte automatisierte Dokumentation der vielseitigen und sehr unterschiedlich gestalteten alten analogen Impfpässe. Beachtung der Prozesse im Praxisalltag bei der Implementierung für eine praktikable Nutzung.] | Das Datenmodell unterstützt den Einsatz der Impfdokumentation für viele Anwender (z.B. Arztpraxen, Notfallambulanzen, öffentlicher Gesundheitsdienst, Betriebsärzte) und in einem breiten Spektrum von Anwendungen (z.B. für unterschiedliche Patientengruppen, unterschiedliche Indikationen, Impfnachträge etc.). Sender sind dabei ausschließlich die ärztlichen Anwender und deren Primärsysteme mit denen Einträge erfasst und erstellt (oder nachgetragen) werden können. Empfänger sind die elektronische Patientenakte des Versicherten und die Anwendungssysteme (Primärsysteme der Anwender und Frontend des Versicherten) in denen die Daten angezeigt oder genutzt werden (nachdem diese aus der ePA des versicherten geladen wurden). Die Identifikation und Umsetzung von szenariospezifischen oder besonderen Funktionsanforderungen (z.B. auch der Umgang mit fehlerhaften oder fehlenden Angaben) obliegt den Herstellern von Primärsystemen. Die Schaffung der technischen Zugriffsmöglichkeit obliegt den Betreibern der Telematikinfrastruktur. |
Darstellung eines Impfpasses [Notwendigkeit der Anzeige aller Impfeinträge als ein Impfpass. Intelligente Sortierung von zusammenhängenden Impfungen sowie Anzeige von Rangfolgen der Impfungen für einen besseren Überblick. Funktionalitäten wie Suchen, Sortieren.] | Das Datenmodell unterstützt die Erfassung und Dokumentation von Informationen zu durchgeführten Impfungen, durchgemachten Erkrankungen und Antikörpernachweisen, jeweils durch einzelne Impfeinträge. In der ePA werden all diese Einträge unter dem Meta-Label "Impfpass" strukturiert und in sich konsistent (und signiert) abgelegt. Die Anzeige und weitere funktionelle Verarbeitung (Suchen, Sortieren, Impfmanagement) der Information erfolgt durch die Anwendungssysteme (Primärsysteme der Anwender und Frontend des Versicherten) nach dem Download aus der ePA und der Entschlüsselung. Der digitale Impfpass ist dabei die Summe der abgelegten Impfeinträge in der vom Patienten gepflegten ePA. Die Umsetzung der Darstellung ist stark anwendungs- und anwenderbezogen und erfolgt durch die Hersteller der Anwendungssysteme. Die KBV stelle eine beispielhafte, frei verfügbare Implementierung in Form eines "MIO-Viewers" zur Verfügung. |
| Fragen zur Signatur | Das Datenmodell unterstützt eine qualifizierte elektronische Signatur des Impfeintrags oder -nachtrags. Die technische Spezifikation hierzu wird gemeinsam mit der gematik entwickelt. |
Ausdruck [Notwendigkeit der Erstellung von Bescheinigungen für die Vorlage von Impfinformationen.] | Für die Vorlage von Impfinformationen bei Stellen, die nicht auf die Inhalte der Telematikinfrastruktur zugreifen können (z.B. Kitas, Schulen, Grenzkontrollstellen, etc.), wird die Implementierung einer Druckfunktion der vorliegenden Impfinformationen empfohlen. |
| Scans von Impfdokumenten | Bereits mit der ePA 1.1 wird es möglich sein Bilder, PDFs, und Word-Dokumente in die ePA einzustellen. MIOs sind per Definitionem strukturierte Informationen im FHIR-Format. |
| Eintragende und verantwortliche Person | Das Datenmodell unterstützt mit den beiden beschriebenen Szenarien die Erfassung von durchgeführten Impfungen und das Nachtragen von Impfungen. Dabei ist jeweils die die Impfung verantwortende Person in dem Abschnitt der "verantwortlichen Person" zu erfassen und bei Nachträgen die den Nachtrag durchführende Person im Abschnitt "eintragende Person" zu erfassen. Es ist nicht vorgesehen, dass der Patient eigenständig qualifiziert Impfdaten erfasst. |
| gesonderte Metadaten | Aktuell sind neben den Metadaten der ePA-Dokumentendefintion keine weiteren gesonderten Metadaten vorgesehen. Mit der gematik sind wir in der Abstimmung zu ergänzenden Funktionen (z.B. Suchen, Sortieren) und deren Umsetzung. |
Redaktionell
Kommentarthema | Ergebnis |
|---|---|
| Beschreibung Name des Behandelnden | Die Beschreibung wird angepasst - "Person, analog den Vorgaben des VSDM" |
| Anpassung von fehlerhaften Bildern /Grafiken | Erstellung eines neuen Bildes und Austausch auf der MIO Homepage ist bereits erfolgt. |
| Fragen zum Wording | Redaktionelle Anpassung erfolgt im Rahmen der Überarbeitung. |
| Umlaute in den Codes vermeiden | Die wird dahingehend angepasst. |
| Warum wird die eintragende Personen immer gleich beschrieben auch wenn unterschiedliche Einträge gemacht werden (Impfung/Impfrelevante Erkrankung)? | Die eintragende Person ist von einer generischen Person abgeleitet, die immer gleich modelliert ist, daher war auch die Beschreibung die gleiche. Die Beschreibung wird dahingehend angepasst, dass dies deutlicher wird. |
| Erläuterung Reisepassnummer | Die Beschreibung wird dahingehend angepasst bzw. ergänzt, dass es sinnvoll/zweckmäßig sein kann das Feld auszufüllen, vor allem bei Reiseimpfungen - insbesondere Gelbfieber. |
| Änderung des Begriffs "Titer" | Es erfolgt eine Änderung der Begrifflichkeit als übergeordneter Begriff, der keine Bestimmungsmethode (wie der Titer) impliziert. |
Beschreibungsergänzung Grundimmunisierung abgeschlossen | Da es hier vermehrt zu Missverständnissen gekommen ist, wird die Erläuterung angepasst. |
| Anmerkungen zu Informationsmodell - Darstellung | Die aktuell verwendeten Instrumente zur Erstellung und Pflege von MIOs unterstützen nur einen bestimmten Umfang an Darstellungsoptionen. Durch die Kombination der Angaben aus der graphischen Darstellung mit weiteren Informationen (z.B. aus den Szenarien oder den FHIR-Spezifikationen) ergibt sich in der Regel ein umfassendes Bild. Wir nehmen die Anregung auf und arbeiten an einer verbesserten Darstellung. |
| Orientierung an der WHO-Papierversion | Das Datenmodell orientiert sich sehr eng an der WHO-Papier-Fassung eines Impfpasses und den gesetzlichen Vorgaben gemäß Infektionsschutzgesetz. |
| Funktionsbezeichnungen gendern | Das Value Set der Funktionsbezeichnungen setzt sich aus verschiedenen bestehenden Value Sets zusammen (unter anderem der IHE). Die Anmerkung wird weiter gegeben. |
