Hier erhalten Sie einen Überblick über alle Kommentare, bei denen der Kommentator der Veröffentlichung zugestimmt hat.
-
-
Key
-
IM1X0-676
-
Erstellt
-
29.04.2020
-
Portallink
-
Name
-
Dr. Petra Gurn
-
Organisation
-
DIAKO Ev. Diakonie-Krankenhaus gemeinnützige GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Gendergerechte Sprache
-
Beschreibung
-
Es wäre wünschenswert, dass Berufsbezeichnungen nicht nur in männlicher Form aufgenommen werden.
-
-
-
Key
-
IM1X0-675
-
Erstellt
-
29.04.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unterstützung/Ergänzung von ICD-10
-
Beschreibung
-
In den Primärsystemen werden gepflegte ICD-Kataloge verwendet.
Ein Ergänzung des Mappings um ICD-10 Codes wäre wünschenswert/sinnvoll.
-
-
-
Key
-
IM1X0-674
-
Erstellt
-
29.04.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
SNOMED CT Code Tabelle-Unübersichtliche Darstellung mit Fehlerpotenzial
-
Beschreibung
-
Ü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.
-
-
-
Key
-
IM1X0-673
-
Erstellt
-
29.04.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
ATC-Klassifikation Angabe referenzierte Version fehlt
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-669
-
Erstellt
-
24.04.2020
-
Portallink
-
Name
-
RKI, Fachgebiet Impfprävention
-
Organisation
-
RKI, Fachgebiet Impfprävention
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Rötel-Impfstoff
-
Beschreibung
-
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)
-
-
-
Key
-
IM1X0-668
-
Erstellt
-
24.04.2020
-
Portallink
-
Name
-
RKI, Fachgebiet Impfprävention
-
Organisation
-
RKI, Fachgebiet Impfprävention
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Impfstoff-Auflistung
-
Beschreibung
-
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).
-
-
-
Key
-
IM1X0-667
-
Erstellt
-
15.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Non-specific (qualifier value) keine "Undergone_Disease"
-
Beschreibung
-
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...
-
-
-
Key
-
IM1X0-666
-
Erstellt
-
14.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Finding statt Observable Entity
-
Beschreibung
-
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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-665
-
Erstellt
-
14.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Kodierung über Qualifier Value statt Person
-
Beschreibung
-
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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-664
-
Erstellt
-
14.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Impfstoffe zu Hepatitis A/B
-
Beschreibung
-
426081003 |Diphtheria + tetanus + pertussis + recombinant hepatitis B virus vaccine (product)| ist derzeit bei Hepatitis A statt B aufgeführt.
-
-
-
Key
-
IM1X0-663
-
Erstellt
-
14.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Code für "Infektion durch Rotaviren"
-
Beschreibung
-
Für o.g. Eintrag erscheint mir das Oberkonzept 18624000 |Disease caused by Rotavirus (disorder)| mit dem Synonym "Rotavirus infection" passender.
-
-
-
Key
-
IM1X0-661
-
Erstellt
-
09.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Zu IM1X0-345 und IM1X0-660: Postkoordination für Substances
-
Beschreibung
-
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
-
-
-
Key
-
IM1X0-660
-
Erstellt
-
09.04.2020
-
Portallink
-
Name
-
Cora Drenkhahn
-
Organisation
-
Universität zu Lübeck
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Ergänzung zu IM1X0-658: Syntaktische Fehler bei Postkoordination
-
Beschreibung
-
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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> unter 'Expression' unten).
-
-
-
Key
-
IM1X0-659
-
Erstellt
-
06.04.2020
-
Portallink
-
Name
-
Andrea Essenwanger
-
Organisation
-
Berlin Institute of Health
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Falscher Code bei "Cholera, Typhus-Impfstoff"
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-658
-
Erstellt
-
06.04.2020
-
Portallink
-
Name
-
Andrea Esseenwanger
-
Organisation
-
Berlin Institute of Health
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Syntaktische Fehler bei post-koordinierten Konzepten
-
Beschreibung
-
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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-655
-
Erstellt
-
28.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Unklare Kodierung
-
Beschreibung
-
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?
-
-
-
Key
-
IM1X0-654
-
Erstellt
-
28.02.2020
-
Portallink
-
Name
-
Steffen Hennecke
-
Organisation
-
gematik GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Umfang und Inhalt des Disclaimers unzureichend genau definiert
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-653
-
Erstellt
-
28.02.2020
-
Portallink
-
Name
-
Steffen Hennecke
-
Organisation
-
gematik GmbH
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Festlegungen zu Signature
-
Beschreibung
-
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<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></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.
-
-
-
Key
-
IM1X0-652
-
Erstellt
-
28.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Beziehung Impfung - Titer
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-651
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Zusammenhang FHIR Ressourcen & Informationsmodell unklar
-
Beschreibung
-
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!
-
-
-
Key
-
IM1X0-650
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Klarstellung erbeten
-
Beschreibung
-
Bedeutet das, dass diese Bundleressource den eigentlichen eImpass darstellt, der z.B. auch in die ePA eingestellt werden würde?
-
-
-
Key
-
IM1X0-649
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Unklare Kodierung
-
Beschreibung
-
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?
-
-
-
Key
-
IM1X0-648
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Eindeutige Identifizierung notwendig
-
Beschreibung
-
Es sollte sich auf EINE eindeutige Indentifikationsmethode beschränkt werden!
-
-
-
Key
-
IM1X0-647
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Falsches Informationsmodell
-
Beschreibung
-
Das Informationsmodell ist inhaltlich falsch. "Verantwortliche Person" und "Eintragende Person" sind direkte Attibute und könnten als Datentyp "Person" referenzieren!
-
-
-
Key
-
IM1X0-646
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Anwendungsfälle unklar! Fehlende Längenangabe!
-
Beschreibung
-
Wie ist der Anwendungsfall für dieses Feld?
Wie lang darf der Wert dieses Feldes maximal sein?
-
-
-
Key
-
IM1X0-644
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Anwendungsfälle unklar!
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-643
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Kein Informationsmodell erkennbar
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-642
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Sven Lüttmann
-
Organisation
-
VISUS Health IT GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Unklare Kodierung
-
Beschreibung
-
Wie sieht das konkrete Datumsformat aus ("YYYYMMDD")?
Wie kann ein korrektes Datum validiert werden, ist z. B. "01.01.0001" valide?
-
-
-
Key
-
IM1X0-637
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Sinnvolle Befüllung
-
Beschreibung
-
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)
-
-
-
Key
-
IM1X0-636
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Unübersichtlich
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-626
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Vorlage entsprechender LOINC-Code-Bündel für Sender- und Empfängersystem
-
Beschreibung
-
S.g. Damen und Herren,
offener Posten ist noch die Revision der vorgelegten LOINC-Codes für die Titer-Angaben im Impfpass.
Hierzu finden sich mehrere Lösungsansätze, die Sender- und Empfängersystem verstehen sollten.
In der Kürze der Zeit ist mir die Zurverfügungstellung fristgerecht nicht mehr möglich.
Können Sie mir bitte eine eMail-Adresse zukommen lassen, an die ich diese Anregungen per xls-Datei verschicken kann.
Vielen Dank im Voraus
Ihr
Bernhard Wiegel
-
-
-
Key
-
IM1X0-625
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
EFN => keine gängige Angabe für AIS/PVS
-
Beschreibung
-
EFN ist keine gängige Angabe, die z. B. in einem AIS/PVS vorgehalten wird
Es sollte ausführlicher beschrieben werden, wie genau die Identifikation erfolgen soll. Gerade vor dem Hintergrund, wenn mehr als einer der ID´s (ID, EFN, ANR) angegeben werden kann. Wie ist dann die Handhabung in den Systemen? Aus unserer Sicht ist die Speicherung aller drei ID-Arten in den Systemen notwendig, weil man nicht weiß welche Art der ID vom abgebenden System benutzt wird.
-
-
-
Key
-
IM1X0-624
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
EFN => keine gängige Angabe für AIS/PVS
-
Beschreibung
-
EFN ist keine gängige Angabe, die z. B. in einem AIS/PVS vorgehalten wird
Es sollte ausführlicher beschrieben werden, wie genau die Identifikation erfolgen soll. Gerade vor dem Hintergrund, wenn mehr als einer der ID´s (ID, EFN, ANR) angegeben werden kann. Wie ist dann die Handhabung in den Systemen? Aus unserer Sicht ist die Speicherung aller drei ID-Arten in den Systemen notwendig, weil man nicht weiß welche Art der ID vom abgebenden System benutzt wird.
-
-
-
Key
-
IM1X0-623
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Weiterfassung Begriff der impfrelevanten Erkrankung
-
Beschreibung
-
Hier würde es sich anbieten, den Begriff der impfrelevanten Erkrankung weiter zu fassen und nicht nur Erkrankungen, die zu einer Immunität geführt haben, zu dokumentieren, sondern auch individuelle Gefährdungsgrößen im Sinne impfrelevanter Indikationen und Kontraindikationen (z. B. chronische Erkrankungen).
-
-
-
Key
-
IM1X0-622
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Immunität nach Impfung
-
Beschreibung
-
Sofern durch die Impfungen schon eine Immunität erreicht wurde, sollte angegeben werden können, wie lange diese gilt.
-
-
-
Key
-
IM1X0-621
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Abgelehnte Impfungen
-
Beschreibung
-
Im Impfpass könnten auch die durch den Patienten abgelehnte Impfungen (mit Begründung) dokumentiert werden.
-
-
-
Key
-
IM1X0-620
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Individuelle Impfempfehlungen
-
Beschreibung
-
Der Impfpass könnte und sollte auch dazu genutzt werden, den Impfungen zugeordnete Impfempfehlungen abzubilden.
Hierzu würden sich die folgenden Kategorien anbieten: Standardempfehlungen, Indikationsempfehlungen, Reiseempfehlungen, Postexpositionsindikationen, Berufsgruppenempfehlungen.
-
-
-
Key
-
IM1X0-619
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Gesamtimpfstatus
-
Beschreibung
-
Bitte prüfen und bewerten ob ein zusammenfassender Gesamtimpfstatus ergänzt werden könnte, ermittelt aus dem Status aller enthaltenen Impfungen, impfrelevanter Erkrankungen sowie Titerbestimmungen und ggf. weiteren Angaben wie individuellen Impfempfehlungen.
Dieser Gesamtstatus könnte die Anamnese erleichtern.
-
-
-
Key
-
IM1X0-618
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Fehlende Angaben
-
Beschreibung
-
Bitte prüfen und bewerten ob Kontaktdaten an dieser Stelle ergänzt werden können.
Es kann möglicherweise Sinn manchen mit der Person bzw. dem Patienten Kontakt aufzunehmen (z.B. eMailadresse, Mobilfunknummer).
-
-
-
Key
-
IM1X0-617
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Familienstand
-
Beschreibung
-
Unserer Erfahrung nach kann die Information "Familienstand" Familienstand für Impfempfehlungen relevant sein.
Wir bitten um diesbezügliche Überprüfung.
-
-
-
Key
-
IM1X0-616
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Ergänzung Immunglobulinen
-
Beschreibung
-
Es sollte die Möglichkeit geschaffen werden, auch die Gabe von Immunglobulinen zu dokumentieren, diese fehlt derzeit.
-
-
-
Key
-
IM1X0-615
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Falsche Bezeichnung der Nummer
-
Beschreibung
-
"Unveränderlicher Teil der einheitlichen Krankenversicherungsnummer der GKV gemäß § 290 SGB V“
Redaktioneller Hinweis: Richtig wäre "Krankenversichertennummer"
-
-
-
Key
-
IM1X0-614
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Verwendung unklar
-
Beschreibung
-
Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.
-
-
-
Key
-
IM1X0-613
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Sinnvolle Befüllung
-
Beschreibung
-
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)
-
-
-
Key
-
IM1X0-612
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Unübersichtlich
-
Beschreibung
-
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.
-
-
-
Key
-
IM1X0-611
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Verwendung unklar
-
Beschreibung
-
Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.
-
-
-
Key
-
IM1X0-610
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unklare Verwendung
-
Beschreibung
-
Bezüglich der Abgrenzung/Operationalisierung "eintragende Person" vs. "verantwortliche Person" siehe auch "2.10 Eintragende Person"
Redaktioneller Hinweis: Da es hier um impfrelevante Erkrankungen und nicht um Impfungen geht, sollte das auch so im Text stehen.
-
-
-
Key
-
IM1X0-609
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Verwendung unklar
-
Beschreibung
-
Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.
-
-
-
Key
-
IM1X0-608
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe im Zusammenspiel mit "verantworliche Person"
-
Beschreibung
-
Hier empfiehlt sich ggf. eine Operationalisierung, z. B. dass dies nur anzugeben ist, wenn eintragende und verantwortliche Person nicht identisch sind.
-
-
-
Key
-
IM1X0-607
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Verwendung unklar
-
Beschreibung
-
Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.
Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.
-
-
-
Key
-
IM1X0-606
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
weitere Patienten FHIR Ressource
-
Beschreibung
-
neue FHIR Ressource bzw. andere Definition als das Basis Profil. Eine Verwendung der selben Ressourcen wäre wünschenswert.
-
-
-
Key
-
IM1X0-605
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
keine Umlaute
-
Beschreibung
-
Code: Säugling12 → Umlaute sind zu vermeiden, vor allem wenn man an die Internationalisierung denkt
-
-
-
Key
-
IM1X0-604
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Andere Handhabung der Signatur als bei anderen Objekten
-
Beschreibung
-
bei Unterschrift/Signatur wird anders Verfahren als bei anderen Objekte die durch die gematik spezifiziert wurden (signatur des gesamten Objekts). Woher kommt der Unterschied zustande?
-
-
-
Key
-
IM1X0-603
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Falsche Codeliste?
-
Beschreibung
-
Falsche Codeliste? Soll eine Impfung durch einen "Musiktherapeut" dokumentiert werden können oder gibt es irgendwelche Einschränkungen?
-
-
-
Key
-
IM1X0-602
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Bsp. der Erklärung
-
Beschreibung
-
Ein Kommentarfeld ist immer gut, das beschriebene Bsp der "Dosisreduktion" ist jedoch im niedergelassenen Bereich bei den Impfplanern nicht vorhanden, spielt also wenn überhaupt nur eine untergeordnete Rolle.
-
-
-
Key
-
IM1X0-601
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Bezeichnung "Recall"
-
Beschreibung
-
Code "recall": Bezeichnung hat mehrerer Bedeutungen. Recall hat im niedergelassenen Bereich auch eine andere Bedeutung (--> Recall Termine...)
→ Vorschlag: memory
-
-
-
Key
-
IM1X0-598
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Ralf Franke
-
Organisation
-
gevko GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Verwendung unklar
-
Beschreibung
-
Wozu dient das Attribut „vollständiger Name“ ?
Es handelt sich um eine redundante Information und stellt eine Abweichung zu den Versichertenstammdaten auf der eGK.Es wäre wünschenswert für die Abbildung der "richtigen" Reihenfolge eine technische Lösung in der FHIR Resource zu finden statt ein Freitextfeld zu verwenden.
-
-
-
Key
-
IM1X0-595
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Feld für Impfplaner nicht nötig
-
Beschreibung
-
Alle im niedergelassenen Bereich etablierten Impfplaner im berechnen das Datum anhand der vorhandenen Impfdaten. Für Praxen mit Impfplaner ist dieses Feld irrelevant.
-
-
-
Key
-
IM1X0-594
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Potenzielle Fehlerquelle
-
Beschreibung
-
Potenzielle Fehlerquelle falls sich an den Empfehlungen der z.B. STIKO etwas ändert.
-
-
-
Key
-
IM1X0-593
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ICD10 verwenden
-
Beschreibung
-
Weshalb wird nicht der ICD 10 verwendet? In Deutschland wird der ICD im niedergelassenen Bereich durch alle etablierten Impfplaner verwendet.
-
-
-
Key
-
IM1X0-592
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Ergänzende Angaben nicht nötig
-
Beschreibung
-
Zweck/Mehrwert nicht ersichtlich bzw. nicht beim eImpfpass nötig.
Künsternamen etc. werden auch z.B. im AIS/PVS auch nicht abgebildet.
-
-
-
Key
-
IM1X0-591
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Redundante Information
-
Beschreibung
-
Die Information ist doppelt. Was wäre wenn sich die Vorname, Nachname,... und Vollständiger Name unterscheiden?
-
-
-
Key
-
IM1X0-590
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Reisepass nicht nötig
-
Beschreibung
-
Ein konkreter Anwendungsfall wäre interessant, aktuell ist der Mehrwert der Information nicht ersichtliche. Unter dem Gesichtspunkt der "Datensparsamkeit empfehlen wir diese Information zu streichen.
-
-
-
Key
-
IM1X0-589
-
Erstellt
-
27.02.2020
-
Portallink
-
Name
-
Dr. Justin Doods
-
Organisation
-
CompuGroup Medical
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
PatientenID nicht nötig
-
Beschreibung
-
Eine ePA ist einem Patienten zugeordnet, in der ePA befindet sich der eImpfpass. Welchem Verwendungszweck dient eine eindeutige Patienten ID (lokale oder globale)? Ein Anwendungsfall wäre interessant zu wissen.
Unter den aktuellen Gesichtspunkten ist PatientenID nicht nötig
-
-
-
Key
-
IM1X0-587
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Sebastian Lindemann
-
Organisation
-
IBM Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Ergänzung um CVX-Codes
-
Beschreibung
-
CVX ist ein Standard-Codesystem, welches von der HL7 anerkannt ist. Es zielt zwar hauptsächlich auf den amerikanischen Markt, bildet jedoch die relevanten Impfungen ab und ist somit im Sinne der weltweiten Interoperabilität. Beinhalten tut es um die 200 verschiedene Codes.
Ebenfalls beinhaltet es Informationen, ob die Impfung derzeit aktiv oder inaktiv ist. Somit ist es noch möglich, Impfungen anzuzeigen, die heutzutage nicht mehr durchgeführt werden.
Dies kann interessant sein, sollten Impfungen nachgetragen werden, um eine komplette Impfhistorie abzubilden.
Es wäre somit wünschenswert zu den Systemen Snomed, ATC und PZN den HL7-Standard CVX mit aufzunehmen.
-
-
-
Key
-
IM1X0-586
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Thomas Freier
-
Organisation
-
medavis GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ReisepassNr.
-
Beschreibung
-
Der Reisepass hat eine Gültigkeit, die zu berücksichtigen ist.
Ist ReisepassNr. als Szenario eines ausländischen Besuchers vorgesehen?
-
-
-
Key
-
IM1X0-585
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Thomas Freier
-
Organisation
-
medavis GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Person/Patient
-
Beschreibung
-
Geburtsdatum sollte nicht date sein. Es gibt Fälle bei denen Tag oder Monat nicht feststehen.
Objekt Identifier: unklar was mit dem Datentyp identifier gemeint ist. Sollte genauer spezifiziert werden.
Falls Bezug auf das FHIR Basisprofil gemeint ist sollten exakt die gleichen Element IDs verwendet werden.
-
-
-
Key
-
IM1X0-526
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Ergänzung CVX CODES gemäß FHIR
-
Beschreibung
-
Derzeit wird der Impfstoff sowohl nach einem ATC-CODE als auch nach SNOMED CT (geplant) kodiert. (Vgl. <span class="nobr"><a href="https://mio.kbv.de/display/IM1x0/2.1+Impfstoff" class="external-link" rel="nofollow">https://mio.kbv.de/display/IM1x0/2.1+Impfstoff<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>)
Für die Kodierung der Impfstoffe sollte, neben SNOMED CT und den ATC-CODES auch der FHIR-STANDARD CVX genutzt werden, um eine FHIR Interoperabilität herzustellen.
Es ist nicht nachvollziehbar, warum gerade an dieser Stelle auf den FHIR Standard verzichtet wird, wo ansonsten eine klare Ausrichtung auf FHIR besteht.
Im Sinne der (weltweiten) Interoperabilität und der Lizenzfreien Nutzung seitens FHIR, wird eine Ergänzung der CVX Codes angemerkt.Die CVX CODES gemäß FHIR sollten ergänzt werden.
(Vgl. Fhir 4: <span class="nobr"><a href="https://www.hl7.org/fhir/cvx.html" class="external-link" rel="nofollow">https://www.hl7.org/fhir/cvx.html<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>)
(Vgl. Fhir 3: <span class="nobr"><a href="http://hl7.org/fhir/STU3/cvx.html" class="external-link" rel="nofollow">http://hl7.org/fhir/STU3/cvx.html<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>)
-
-
-
Key
-
IM1X0-525
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Ergänzung von durchgemachten Erkrankungen, Titerbestimmungen, passiven Impfungen und Postexpositionsprophylaxen
-
Beschreibung
-
Auch bei Übertragungen sind diese Informationen essentiell und sollten nicht verloren gehen.
-
-
-
Key
-
IM1X0-524
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Ergänzung eines Feldes zum Eintragen von durchgeführten passiven Impfungen und Postexpositionsprophylaxen
-
Beschreibung
-
Die Information zu durchgeführten Passivimpfungen und Postexpositionsprophylaxen ist aus infektionshygienischer Sicht notwendig und sollte erfassbar sein.
-
-
-
Key
-
IM1X0-523
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Verortung von passiven Impfungen/Immunglobulingaben und Postexpositionsprophylaxen
-
Beschreibung
-
Allgemeiner Hinweis zur Verortung von passiven Impfungen/Immunglobulingaben und Postexpositionsprophylaxen.
Diese Beispiele sind bis jetzt weder unter Impfstoff noch unter Erkrankung, gegen die geimpft wird, explizit enthalten. Eventuell lohnt sich die Aufnahme einer eigenen Ziffer z.B. 5. Passive Impfung und Postexpositionsprophylaxe.
-
-
-
Key
-
IM1X0-522
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Vorschlag zur Aufnahme weiterer Titercodes/-Bezeichnungen
-
Beschreibung
-
Auch Titerbestimmungen zu nicht impfpräventablen Erkrankungen können aus infektionshygienischer Sicht sehr relevant sein: z.B. Hep C oder HIV, Parvovirus B 19, CMV.
Zudem könnte vielleicht an dieser Stelle Angaben zu erfolgten TB-Testungen: Mendel-Mantoux, Tine-Test, IGRA verortet werden.
-
-
-
Key
-
IM1X0-521
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Vorschlag Textergänzung zur Beschreibung von „Immunität erreicht“
-
Beschreibung
-
„Der Wert erreicht den Grenzwert oder liegt oberhalb des definierten Grenzwertes“
Ohne diese Ergänzung entsteht das logische Problem, dass wenn der Titer genau auf dem Grenzwert liegt, weder die eine noch die andere Kategorie zutrifft.
-
-
-
Key
-
IM1X0-520
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
GKV-Spitzenverband
-
Organisation
-
GKV-Spitzenverband
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Vorschlag zur Änderung der Beschreibung "HANDELSNAME"
-
Beschreibung
-
Vorschlag zur Textänderung statt „Name des herstellenden bzw. des anbietenden des Handelsnamens des verabreichten Impfstoffs.“
„Name des Handelsnamens des verabreichten Impfstoffs.“ verwenden
-
-
-
Key
-
IM1X0-519
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Composition notwendig?
-
Beschreibung
-
Ob eine Composition in der hier vorliegenden Form des Impfpasses notwendig ist, erschließt sich mir noch nicht auf Anhieb. Das müsste genauer geprüft werden.
Interessant ist die Nutzung von Condition, die letztendlich nur für den Text genutzt wird. Das könnte man evtl. auch in Section unterbringen...
Auch muss die Nutzung von Observation noch genauer geklärt werden. Eine Titerbestimmung ist eine, die für eine (mögliche) Impfung relevant ist, was dann auch noch im Mutterpass relevant wird. Allerdings lässt ein Impfpass bspw. auch die Angabe einer Blutgruppe zu, was mir bisher hier komplett fehlt...
-
-
-
Key
-
IM1X0-518
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Profilhierarchie ist nicht vorhanden
-
Beschreibung
-
Die Aussage "hat daher mehr Zwänge als das Profil KBV_PR_MIO_Vaccination_Record_Addendum" bestätigt den Schluss, dass es sich um eine Hierarchie handelt. Diese sollte sowohl in den Vorgaben (Informationsmodell), dem Datensatz und auch in der Profilausarbeitung in FHIR transparent und deutlich gemacht werden.
PS: Mit den bereits vorhandenen anderen Kommentaren erübrigt sich hiermit eine weitere Prüfung, da eine komplette Überarbeitung notwendig ist.
-
-
-
Key
-
IM1X0-517
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Transaktionsdiagramm fehlt
-
Beschreibung
-
Ein Transaktionsdiagramm, aus dem die Interaktionen hervorgehen, fehlt. Es sollte die Akteure mit den Informationsobjekten, die verändert werden, enthalten.
-
-
-
Key
-
IM1X0-516
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
"vernünftige" Use Cases
-
Beschreibung
-
Als Use Cases im Sinne der Nutzung eines Impfpasses hätte ich jetzt erwartet:
- Impfpass anlegen
- Impfpass korrigieren
- Impfung eintragen
- Impfung nachtragen
- Impfung korrigieren
Aus der Vorstellung am 20.2. ist aber klargeworden, dass es gar keinen Impfpass gibt, sondern nur eine Impfdokumentation.
Hier müssen wir mEn noch einmal ganz von vorne anfangen, um die Use Cases entsprechend aufzubereiten und das Informationsmodell - als "vollständiges" UML-Klassendiagramm und nicht als Mindmap/Treeview - anzupassen, und dann daraus die Daten für die Use Cases abzuleiten.
-
-
-
Key
-
IM1X0-515
-
Erstellt
-
26.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Spalte "Datentyp CC" erklären
-
Beschreibung
-
Die Spalte ist erklärungsbedürftig:
Zum einen entält sie die Kardinalität, zu der es bereits andere Kommentare gibt.
Dann gibt es Attribute "R" bzw. "M", die nicht erklärt sind. Grundsätzlich müssen alle Felder unterstützt werden. Die Verwendung von Null-Werten muss geklärt werden, vermutlich sind diese nicht zulässig.
Die Datentypen selber (string, identifier, ..) sind noch einmal separat zu erklären.
-
-
-
Key
-
IM1X0-513
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Dr. Elisabeth Fix
-
Organisation
-
Deutscher Caritasverband e.V., Bundesarbeitsgemeinschaft der Freien Wohlfahrtspflege (BAGFW)
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Operationalisierungsempfehlung für Erinnerungswesen
-
Beschreibung
-
Um das Erinnerungswesen bei möglichen und erforderlichen Folge- und Auffrischungsimpfungen zu stärken, sollte die KBV den Arztpraxen in den Operationalisierungsempfehlungen den Hinweis geben, in der Arztpraxis eine entsprechende Software für das Impfmanagement zu verwenden.
-
-
-
Key
-
IM1X0-512
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Dr. Elisabeth Fix
-
Organisation
-
Deutscher Caritasverband e.V., Bundesarbeitsgemeinschaft der Freien Wohlfahrtspflege (BAGFW)
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Zusätzliches Feld für Nachweis von aus medizinischen Gründen nicht erfolgte Impfungen
-
Beschreibung
-
Ab dem 1. März 2020 ist in der Impfdokumentation über notwendige Folge- und Auffrischungsimpfungen mit Terminvorschlägen zu informieren, sodass die geimpfte Person sie rechtzeitig wahrnehmen kann. Gegen Masern wurde für definierte Gruppen eine gesetzliche Impfpflicht eingeführt. Gleichzeitig kann es aber auch Fälle geben, in denen Impfung oder eine Folge- oder Auffrischungsimpfung aus medizinischen Gründen nicht möglich ist. Das vorgesehene Feld kann daher nicht als Pflichtfeld ausgestaltet werden. Es sollte jedoch ein zusätzliches Feld geben, in dem der Arzt/die Ärztin bescheinigt, dass eine Impfung bzw. eine Folge- und Auffrischungsimpfung aus medizinischen Gründen nicht möglich ist.
-
-
-
Key
-
IM1X0-509
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Daten korrigieren oder löschen (nicht) möglich?
-
Beschreibung
-
So wie es sich aus den vorliegenden Anwendungsszenarien herausliest ist ein nachträgliches ändern oder gar löschen einer Impfung nicht vorgesehen. Aufgrund von Erfassungsfehlern kann es aber notwendig sein sowohl einen bestehenden Eintrag nachträglich ändern zu müssen als auch einen evtl. fälschlicherweise erfassten Eintrag löschen zu können. Wie soll damit umgegangen werden? Wenn technisch die Möglichkeit besteht Impfungen aus dem Impfpass zu löschen wie wird dann sichergestellt, dass es sich wirklich nur um eine Korrektur eines fehlerhaften Eintrags handelt und nicht um die Löschung eines korrekten und somit relevanten Eintrags? Da es sich bei einem Impfpass um ein kontinuierlich fortgeschriebenes Dokument handelt sollten sich diese Änderungen auch in einer lückenlosen Nachvollziehbarkeit von Neutragungen, Änderungen und Löschungen wiederspiegeln. Dies entspricht auch dem heutigen Papierprozess, bei dem auch nachträgliche Änderungen „erkennbar“ sind. Vom Gedanken her würde sich so etwas wie eine Blockchain aufdrängen.
Diese „lückenlose“ Nachvollziehbarkeit würde dabei helfen verarbeitende Systeme zu identifizieren bei denen, evtl. aufgrund von technischen Fehlern Impfungen „verschwinden“ und somit die Ergebnisse von, auf den verbleibenden Impfungen aufsetzenden, Impfstatus-Ermittlungen verfälschen würde.
-
-
-
Key
-
IM1X0-508
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Versichertennummer kann sich ändern
-
Beschreibung
-
Da sich „lebenslange“ Versichertennummer (eGK-Nummer) aus verschiedenen Gründen heraus doch ändern kann, wäre es sinnvoll hier eine Liste von Versichertennummern angeben zu können um den Patienten sicher identifizieren zu können. Es wäre daher sinnvoll die eGK-Nummer jeweils mit einem Zeitstempel oder Zeitraum zu versehen wann diese gesichert festgestellt bzw. zugeordnet wurde.
-
-
-
Key
-
IM1X0-507
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Einsatz von Snomed CT
-
Beschreibung
-
Der Einsatz von SNOMED CT-Codes ist im Sinne einer Interoperabilität natürlich sinnvoll. Es sollte aber berücksichtigt werden, dass die Codes möglichst einfach und kostengünstig für die Software-Hersteller zur Verfügung gestellt und es auch in damit zusammenhängen Katalogen, z.B. Arzneimitteldatenbanken nicht zu erhöhten Kosten für Hersteller oder Ärzten führt, da „teure“ Updates erworben werden müssen in denen Mappings (o.ä.) enthalten sind.
-
-
-
Key
-
IM1X0-506
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Titer-Werte angeben
-
Beschreibung
-
Zusätzlich zur Aussage ob eine Immunität vorliegt sollte auch der Wert und die Messmethode mit angegeben werden.
-
-
-
Key
-
IM1X0-505
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Schwierige Operationalisierung
-
Beschreibung
-
Je nach Datenlage des Impfpasses lässt sich diese Aussage nicht überprüfen. Daher sollte die Aussage, dass eine Grundimmunsierung vorliegt nur in Ausnahmefällen möglich sein und eine verpflichte Begründung vom Eintragenden angefordert werden in der die Grundlage der Einschätzung beschrieben ist.
-
-
-
Key
-
IM1X0-504
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Datum der Folegeimpfung
-
Beschreibung
-
Das Datum der Folgeimpfung sollte nicht zusammen mit der Impfung gespeichert werden, da sich dieses aufgrund regionaler Unterschiede ändern kann oder aufgrund anderer Erkenntnisse in der Zukunft neu bewertet werden kann.
-
-
-
Key
-
IM1X0-502
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Tina Olbrich
-
Organisation
-
Element44 GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ASK-Code fehlt
-
Beschreibung
-
Zur Vereinfachung der Verarbeitung sollte bei einer Impfung auch der ASK-Code angegeben werden können.
-
-
-
Key
-
IM1X0-501
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Zeitraum statt Datum
-
Beschreibung
-
Die Angabe eines fixen Folgedatums erscheint mir durchaus vermessen. Hier sollte man meines Erachtens eher auf ein Codesystem für einen Zeitraum zurückgreifen, der dann beispielsweise auch in Textbausteinen verwendet werden könnte.
Beispiel: "Die Impfkommission emphielt eine Folgeimpfung nach 8 - 12 Jahren, sofern dies der Gesundheitszustand und die körperliche Verfassung zu lassen. Sprechen Sie hierzu Ihren Arzt an."
-
-
-
Key
-
IM1X0-499
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Code
-
Beschreibung
-
Ich persönlich finde den Code nicht besonders selbstsprechend. Und was müsste Codiert werden, wenn der Eintrag digital, als Impfbescheinigung und im Impfausweis dokumentiert wurde.
Vorschlag:
D = Digital
B = Bescheinigung auf Papier
I = Impfausweis auf PapierDer Code ergibt sich dann aus der Kombination der vorkommenden Ausführungen.
-
-
-
Key
-
IM1X0-497
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Vage Datumsangaben
-
Beschreibung
-
Aus Sicht der Softwareentwicklung sollte für die Berechnung von Vorsorgemaßnahmen ein Leitfaden beigefügt werden, wie mit unpräzisen Angaben medizinisch sinnvoll umgegangen werden soll.
Diese Anforderung ist vor dem Hintergrund zu sehen, dass sich die digitale Unterstützung bei der Prophylaxe-Planung sehr nah, wenn nicht sogar darüber hinaus, sich am Medizinprodukt bewegt.
Je weniger Interpretationsmöglichkeiten durch Nicht-Mediziner bei der Implementierung und Bereitstellung von Algorithmen bestehen, desto sicherer ist die Anwendung!
-
-
-
Key
-
IM1X0-496
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Marcus Hettlage
-
Organisation
-
Element44 GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Geschlechtsangabe fehlt
-
Beschreibung
-
Die Angaben zum Patienten sollte auch das Geschlecht umfassen, da es auch geschlechtsspezifische Aspekte gibt die berücksichtigt wer-den müssen.
-
-
-
Key
-
IM1X0-495
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Goerke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Geschlechtsangabe und "Internationale Bescheinigung über Impfung oder Prophylaxe"
-
Beschreibung
-
Auf Seite 2 der weit verbreiteten "Internationalen Bescheinigungen über Impfungen oder Prophylaxemaßnahmen" (gelbes Impfbuch) befindet sich die Angabe zum Geschlecht.
Meine Erwartungshaltung an einen digitalen Impfpass besteht darin, dass aus einem solchen Dokument international anerkannte Impfbescheinigungen ohne Ergänzung weiterer externer Werte abgeleitet werden sollten.
Ich bin zwar kein Mediziner, aber wenn der digitale Impfpass auch als Grundlage für die Impfprophylaxe dient, so hat eine Impfung beispielsweise gegen Röteln für Frauen im gebährfähigen Alter eine gravierendere Bedeutung als bei Männern.
-
-
-
Key
-
IM1X0-494
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Anbieter oder Hersteller?
-
Beschreibung
-
In den meisten AVWG zertifizierten Systemen werden die Angaben zum Hersteller und zum Anbieter getrennt gehalten. Daher wäre eine Präzisierung notwendig, um Interpretationen und Nachfragen zu vermeiden. So gibt es immer einen Anbieter und nur in seltenen Fällen zusätzlich einen davon abweichenden Hersteller.
Damit sollte in die Operationalisierungsanweisung übernommen werden:
Es ist der Herstellername zu übertragen/anzugeben. Sofern nicht bekannt, ist der Anbietername zu verwenden.
-
-
-
Key
-
IM1X0-493
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Präzisere Festlegungen erwünscht
-
Beschreibung
-
Angesichts der weiten Verbreitung AVWG zertifizierter Systeme halte ich die Operationalisierungsempfehlung für falsch, da diese suggeriert, dass die Angaben an dieser Stelle manuell zu erfolgen haben.
In Regel werden die Angaben zum Handelsnamen, dem Hersteller, der PZN und dem ATC-Code aus einer AVWG zertifizierten Arzmitteldatenbank entnommen. Daher wäre es sehr hilfreich im Sinne einer intepretationsfreien Befüllung an dieser Stelle die AVWG Merkmalsziffern hier zu verlinken. Damit dürfte auch implizit klar sein, dass kein manueller Eingriff durch die verantwortliche Person zu erfolgen hat, sofern ein AVWG zertifiziertes System im Hintergrund arbeitet.
Für den Fall einer manuellen Veränderung des Handelsnamens (soll eigentlich der 26stellige Kurz- oder besser der 50stellige Langname verwendet werden?) dürfen ggf. ursprünglich voreingestellte Angaben zum ATC-Code und PZN auf keinen Fall mehr gespeichert werden. Dies könnte zu einer Patientengefährdung führen.
-
-
-
Key
-
IM1X0-492
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Umgang mit unbekannten Tages-, Monats- und Jahreszahlen
-
Beschreibung
-
Leider fehlt dem Element die notwendige Beschreibung. Da das Geburtsdatum für Impfungen von elementarer Bedeutung ist, stellt sich die Frage, wie bei der Altersberechnung mit den unbekannten Teilen eines Geburtsdatums zu verfahren ist. I
-
-
-
Key
-
IM1X0-491
-
Erstellt
-
25.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Geburtsort?
-
Beschreibung
-
Die "Impfbücher" des W.Bertelsmann Verlags (Nr. 13.07.101.80) aus den 50ger Jahren hatten neben dem Geburtsdatum auch den Geburtsort enthalten. Ich kann nicht beurteilen, ob dies medizinisch von Bedeutung ist, würde aber zumindest einen Kommentar/Hinweis erwarten, warum ein solches Datum für den digitalen Impfpass nicht von Bedeutung ist.
-
-
-
Key
-
IM1X0-487
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Profile
-
Beschreibung
-
Warum zwei Profile hierzu definieren
Record Prime + Practitionerrole_Addendum
-
-
-
Key
-
IM1X0-486
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Minimale Pflichtfelder
-
Beschreibung
-
Wenn es nur eine Practitioner Definition mit weniger Pflichtfeldern bei nicht ärztlichen Personen, warum nicht im Practioner Profil Contraints abhängig vom Role/Qualifikation hinzufügen und das eigentliche Profil entsprechend mit den minimalen Pflichtfeldern belassen?
-
-
-
Key
-
IM1X0-485
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
CodeSystem
-
Beschreibung
-
Wenn dies ein eigenes Codesystem ist, kann dies dann tatsächlich sich nicht auf Coding von HL7 oder IHE (Deutschland) beziehen und hier sollten maximal eine Übersetzung hinterlegt werden (ggf. auf HL7 Deutschland Ebene abbildbar) und maximal fehlende Codes erweitern. Eine Definition die sich nicht mit internationalen Codes deckt ist nicht sinnvoll. Hier sollte man sich auch an den IHE Deutschland Valuesets die bereits definiert wurden orientieren. Diese sind bereits sehr gut und umfangreich. Inhaltlich wäre auch Definitionen wie Taxifahrer als Qualifikation/Funktion eines Practitioner fraglich. Der Hintergrund ist hier unklar. Sollte dies dann nicht über Person oder ähnliches abgebildet werden.
-
-
-
Key
-
IM1X0-484
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Keine eigene Observation
-
Beschreibung
-
Wäre ggf. hier die Ressource ImmunizationEvaluation zu nutzen, da diese scheinbar dies wiederspiegelt und nicht eine eigene Observation profiliert werden muss?
-
-
-
Key
-
IM1X0-483
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Extension
-
Beschreibung
-
Keine Extension nötig -> es sollte eine ImmunizationRecommendation verwendet werden (wenn nicht passend auch mit CarePLan und ActivityDefinition Ressourcen ggf. abbildbar)
-
-
-
Key
-
IM1X0-482
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Extension
-
Beschreibung
-
Es wird Extension verwendet, obwohl es Konzepte für Person/Patient/Practitioner bereits gibt
-
-
-
Key
-
IM1X0-481
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Basisprofile
-
Beschreibung
-
Warum wird nur in Teilen auf das deutsche Basisprofil verwiesen und nicht vom Basisprofil von HL7-Deutschland ‚vererbt‘? Beispiel: doppelte Definition der GKV-Nummer als ID.
-
-
-
Key
-
IM1X0-480
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Datenfluss
-
Beschreibung
-
Der Datenfluss ist nicht transparent dargestellt. Wer ist z.B. Datensender oder -empfänger?
-
-
-
Key
-
IM1X0-479
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
LANR zusätzlich zu ANR
-
Beschreibung
-
Hier sollte nicht nur ANR stehen, sondern die tatsächliche LANR gemäß dem neuen Verzeichnis stehen und ggf. auch mit dem Verzeichnis abgeglichen werden (vgl. Diskussion um die LANR bei der Neuanlage von Ärzten in den IT-Systemen).
-
-
-
Key
-
IM1X0-478
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-477
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-476
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Geburtsname:
es fehlt die Angabe der Zeichenzahl
Vollständiger Name:
unnötiges Datenfeld, da lediglich Inhalt der anderen Felder dieses Bereiches zusammenkopiert sind
Vorname:
hier wird immer auf "Der Vorname des Versicherten wie in VSD (Versichertenstammdaten) definiert." Zurückgegriffen. In diesem Fall kann die verantwortliche Person aber nicht der Versicherte sein
-
-
-
Key
-
IM1X0-475
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Differenzierte Formatangabe fehlt/Angabe Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt eine differenzierte Formatangabe und die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-474
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Differenzierte Formatangabe fehlt
-
Beschreibung
-
Es fehlt eine differenzierte Formatangabe.
-
-
-
Key
-
IM1X0-473
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-472
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-471
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt/Count ist nicht Zahl
-
Beschreibung
-
Postfach:
count ist nicht gleich Zahl, die hier aber gemeint sein wird
Anzahl Stellen fehlt
Land:
welcher Ländercode soll verwendet werden?
Postleitzahl:
count ist nicht gleich Zahl, die hier aber gemeint sein wird
Hausnummer:
count ist nicht gleich Zahl, die hier aber gemeint sein wird
Stadt:
es fehlt die Angabe der Zeichenzahl
Straße:
es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-470
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unnötiges Datenfeld
-
Beschreibung
-
Unnötiges Datenfeld, da lediglich Inhalt der anderen Felder dieses Bereiches zusammenkopiert sind
-
-
-
Key
-
IM1X0-469
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-467
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Differenzierte Formatangabe fehlt
-
Beschreibung
-
Es fehlt eine differenzierte Formatangabe.
-
-
-
Key
-
IM1X0-466
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-465
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-464
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Vollständigkeit Zeitstempel
-
Beschreibung
-
Der Zeitstempel sollte immer vollständig sein (Datum und Uhrzeit).
Es muss klar sein, welche Zeitzone verwendet wird
-
-
-
Key
-
IM1X0-463
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Spezifizierung der Signatur fehlt
-
Beschreibung
-
Es fehlt die Spezifizierung der Signatur
-
-
-
Key
-
IM1X0-462
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt/Count ist nicht Zahl
-
Beschreibung
-
Postfach:
count ist nicht gleich Zahl, die hier aber gemeint sein wird
Anzahl Stellen fehlt
Land:
welcher Ländercode soll verwendet werden?
Postleitzahl:
count ist nicht gleich Zahl, die hier aber gemeint sein wird
-
-
-
Key
-
IM1X0-461
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-460
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-459
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Identifizierung einer Person
-
Beschreibung
-
Ich mache mir Gedanken über den Identifier da auch dieser neben den Impfeintragungen ständiger Aktualisierung unterworfen sein dürfte. Die Überlegung zum Identifier gilt eingeschränkt auch für den Namen.
Will man das Model schmal halten und ohne "Gültigkeitsgrenzen" und Listen auskommen, dann wäre es wichtig, an zentraler Stelle festzuhalten, dass alle Angaben zu einer Person den Stand der letzten Impfeintragung (oder aktueller) entsprechen müssen.
-
-
-
Key
-
IM1X0-458
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Und was ist mit der Nummer des Personalausweises?
-
Beschreibung
-
Auf dem gelben Impfbüchlein können auf der Titelseite die Reisepass-Nr oder die Nr. des Personalausweises angegeben werden. Daher plädiere ich dafür, dass es für die Angabe der Personalausweisnummer ein eigenes Feld gibt.
-
-
-
Key
-
IM1X0-457
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Versichertennummer vs VersichertenID
-
Beschreibung
-
Eine Versichertennummer ist eine 6-12stellige Ziffernfolge, deren Eindeutigkeit nur im Kontext einer IK der zugehörigen Krankenkasse eindeutig ist.
Wenn mit diesem Feld die eGK-VersichertenID gemeint ist, sollte man dies auch durch den Bezeichner zum Ausdruck bringen, wie beispielsweise "GKV_VersichertenID".
-
-
-
Key
-
IM1X0-456
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Görke, Hans-Joachim
-
Organisation
-
Cerner HS Deutschland GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
PID
-
Beschreibung
-
Mir ist an dieser Stelle nicht ganz klar, auf was sich die PID bezieht.
Soll die ID einen Patienten weltweit eindeutig repräsentieren oder ist es die Repräsentanz eines Impfpasses? Oder beides?
Ferner tue ich mich schwer mit Datenelementen, die mit "sollte" beschrieben werden. Was soll das Feld genau beinhalten?
-
-
-
Key
-
IM1X0-455
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Ergänzung um Angabe des Testreagenzes unter Nutzung der EUDAMED-Datenband
-
Beschreibung
-
Die Angabe der Laborergebnisse sollte auch die Codierung des verwendeten Testreagenzes, gewonnen aus der EUDAMED-Datenbank, beinhalten.
Dies erlaubt neben den bisherigen Angaben auch langfristig den Vergleich der Labortestresultate in eindeutiger Form
-
-
-
Key
-
IM1X0-449
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Kai U. Heitmann
-
Organisation
-
health innovation hub des Bundesministeriums für Gesundheit
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Undergone
-
Beschreibung
-
Ggf. lieber von "prior diseases" und "vorangegangenen Krankheiten" sprechen
-
-
-
Key
-
IM1X0-448
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Kai U. Heitmann
-
Organisation
-
health innovation hub des Bundesministeriums für Gesundheit
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Provenance auch für andere Komponenten
-
Beschreibung
-
Die Provenance sollte auch für andere Komponenten dieser MIO und auch anderer zukünftiger MIOs Verwendung finden können
-
-
-
Key
-
IM1X0-447
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Kai U. Heitmann
-
Organisation
-
health innovation hub des Bundesministeriums für Gesundheit
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Der deutsche Patient
-
Beschreibung
-
Es sollte an dieser Stelle diskutiert werden, insbesondere mit der Industrie, inwiefern man nun für jede MIO eine Variante der Definition zum Patienten zulässt oder nicht doch den "deutschen Patienten" als FHIR Definition festlegt und durchweg nutzt. Wenn die Notwendigkeit von anwendungsfall-spezifischen Sub-Profilierungen (zB weniger Informationen) gegeben ist, kann man sich auch die Abhängigkeit von einem "deutschen Patientenprofil" vorstellen, dass als Ausgangsprofil verwendet wird. All dies ist hier zunächst wohl nicht vorgesehen, würde aber der implementierenden Industrie maßlos helfen. Gleiches gilt auch für andere Profile wie Practitioner.
-
-
-
Key
-
IM1X0-446
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Kai U. Heitmann
-
Organisation
-
health innovation hub des Bundesministeriums für Gesundheit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Zahl der Extensions
-
Beschreibung
-
Die Zahl der hier entworfenen Extensions erscheint ungewöhnlich hoch. Insbesondere im Bereich der Aktoren könnte die Provenance Resource eine Alternative bieten.
z. B. gib es KBV_PR_MIO_Vaccination_Record_Prime.Extension (Verantwortliche Person) und KBV_PR_MIO_Vaccination_Record_Prime.Extension (Eintragende Person), aber bei Quelle der Information in „Impfrelevante Erkrankungen“ ist es modelliert als Provenance.
-
-
-
Key
-
IM1X0-445
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Kai U. Heitmann
-
Organisation
-
health innvoation hub des Bundesministerkums für Gesundheit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Datum der Folgeimpfung ist ein "Impfplan"
-
Beschreibung
-
Das Datum der Folgeimpfung sollte nicht im gleichen Block der Impfung selbst modelliert werden (und auch dort auch nicht technisch repräsentiert). Hintergründe:
Die Termine der Folgeimpfung(en) kann / können bei der eigentlichen Impfung vorliegen oder erst später festgelegt werden. Später können die Daten zur stattgefundenen Impfung dann aber nicht mehr angepasst werden. Auch muss das Folgedatum nicht durch den Impfenden festgelegt werden, das kann jemand anderes sein, oder gar eine App, die der Patient angestoßen hat, um Impfempfehlungen zu geben. Fazit: Folgeimpfungen sind Impfempfehlungen bzw. Bestandteil der Impfplans (Immunization Recommendation), gesonderte Aktivitäten neben der Impfung, können unterschiedliche Autoren haben und zeitlich nachgeordnet festgelegt werden und dürfen nicht Bestandteil der Informationen zur Impfung selbst sein.
-
-
-
Key
-
IM1X0-444
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Die Angabe des Titer-Codes sollte durch eine Codierung der Maßeinheiten nach UCUM egänzt werden
-
Beschreibung
-
Ableitend vom Kommentar zum Begriff des "Titers", angegeben meist diejenige Verdünnung, bei der das jeweilige Untersuchungsverfahren noch positive Reaktion zeigt, sollte man für die modernen Verfahren die Angabe von Konzentrationseinheiten nach dem UCUM-System ermöglichen
-
-
-
Key
-
IM1X0-443
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Die Angabe des Titer-Codes sollte durch eine Codierung der Maßeinheiten nach UCUM egänzt werden
-
Beschreibung
-
Ableitend vom Kommentar zum Begriff des "Titers", angegeben meist diejenige Verdünnung, bei der das jeweilige Untersuchungsverfahren noch positive Reaktion zeigt, sollte man für die modernen Verfahren die Angabe von Konzentrationseinheiten nach dem UCUM-System ermöglichen
-
-
-
Key
-
IM1X0-442
-
Erstellt
-
24.02.2020
-
Portallink
-
Name
-
Dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Überdenken des Begriffes Titer
-
Beschreibung
-
Guten Tag,
überdenken sollte man den Begriff des "Titers".
Beim Verfahren z.B. Röteln-Haemagglutinationstest oder polyvalenter IFT weist man hier sowohl Antikörper der IgM- wie der IgG-Klasse.
Als Impftiter (ein mehr oberdeutscher Sprachgebrauch) sollte es sich um die Darstellung schützender Antikörper, also IgG-Antikörper, handeln.
Moderne Verfahren weisen hier meist (Internationale) Einheiten je ml nach.
LOINC-Konzepten, die dies berücksichtigen, sollte der Vorzug gegeben werden
-
-
-
Key
-
IM1X0-441
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Fragwürdige Dokumentation
-
Beschreibung
-
Die Annahme einer Immunität anhand von Grenzwerten zur Entscheidungsfindung für die Durchführung einer Impfung ist in vielen Fällen obsolet.
-
-
-
Key
-
IM1X0-440
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Titerbestimmung
-
Beschreibung
-
Dieses Feld könnte generell für eine im besonderen Fall notwendige Titer-Kontrolle genutzt werden auf 4.1 und 4.2. sollte verzichtet werden
-
-
-
Key
-
IM1X0-439
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Dokumentation fragwürdig
-
Beschreibung
-
<span class="nobr"><a href="https://www.rki.de/SharedDocs/FAQ/Impfen/AllgFr_AllgemeineFragen/FAQ-Liste_AllgFr_Impfen.html#FAQId2407462" class="external-link" rel="nofollow">https://www.rki.de/SharedDocs/FAQ/Impfen/AllgFr_AllgemeineFragen/FAQ-Liste_AllgFr_Impfen.html#FAQId2407462<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
Titerbestimmungen als Entscheidungshilfe zur Durchführung einer Impfung sind sehr selten,
Titerbestimmungen zum Nachweis einer akuten Infektion müssen differenziert werden.
Die Sinnhaftigkeit dieses Punktes im e-Impfpass sollte überdacht werden.
Motiviert u.U. zu obsoleten Laboruntersuchungen
-
-
-
Key
-
IM1X0-438
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Facharztbezeichnung
-
Beschreibung
-
Die Fachgebietsbezeichnung sollte ausreichen-, auf Schwerpunkt-oder Teilgebietsbe-zeichnungen kann man verzichten, da es ohne Fachgebietsbezeichnung keine Untergruppen gibt.
-
-
-
Key
-
IM1X0-437
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Personen über 60 Jahre
-
Beschreibung
-
Es gibt explizit Stiko-Impfempfehlungen für " Senioren"
Die werden bei der Auflistung nicht berücksichtigt
-
-
-
Key
-
IM1X0-436
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Impfnebenwirkung von Impfschaden trennen
-
Beschreibung
-
Für den Punkt Impfschaden muss ein einzelner Unterpunkt eingerichtet werden.
Es fehlt der Hinweis auf online-Patientenmeldung für Nebenwirkungen
-
-
-
Key
-
IM1X0-435
-
Erstellt
-
23.02.2020
-
Portallink
-
Name
-
Doris Scharrel
-
Organisation
-
BVF
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Infektionsschutzgestz
-
Beschreibung
-
Gegen die Dokumentation durch Patienten spricht das Gesetz zur Verhütung und Bekämpfung von Infektionskrankheiten beim Menschen (Infektionsschutzgesetz - IfSG)
§ 22 Impfausweis
(1) Der impfende Arzt hat jede Schutzimpfung unverzüglich in einen Impfausweis nach Absatz 2 einzutragen oder, falls der Impfausweis nicht vorgelegt wird, eine Impfbescheinigung auszustellen. Der impfende Arzt hat den Inhalt der Impfbescheinigung auf Verlangen in den Impfausweis einzutragen. Im Falle seiner Verhinderung hat das Gesundheitsamt die Eintragung nach Satz 2 vorzunehmen.
(2) Der Impfausweis oder die Impfbescheinigung muss über jede Schutzimpfung enthalten:1.
Datum der Schutzimpfung
2.
Bezeichnung und Chargen-Bezeichnung des Impfstoffes
3.
Name der Krankheit, gegen die geimpft wird
4.
Namen und Anschrift des impfenden Arztes sowie
5.
Unterschrift des impfenden Arztes oder Bestätigung der Eintragung des Gesundheitsamtes.(3) Im Impfausweis ist in geeigneter Form auf das zweckmäßige Verhalten bei ungewöhnlichen Impfreaktionen und auf die sich gegebenenfalls aus den §§ 60 bis 64 ergebenden Ansprüche bei Eintritt eines Impfschadens sowie auf Stellen, bei denen diese geltend gemacht werden können, hinzuweisen. Der Impfausweis oder die Impfbescheinigung soll ein Textfeld enthalten, in dem der impfende Arzt einen Terminvorschlag für die nächste Auffrischungsimpfung eintragen kann.
-
-
-
Key
-
IM1X0-433
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
dr.bernhard.wiegel@t-online.de
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
zu ergänzende Berufsverbände
-
Beschreibung
-
Guten Morgen,
bitte ergänzen Sie diese Liste durch STIKO, DVV, BAEMI, DGHM, BDL, DGKL
-
-
-
Key
-
IM1X0-432
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BEDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
SNOMED CT
-
Beschreibung
-
Guten Morgen,
ich bitte bereits im Vorfeld hier für korrekte und einheitliche Codierungsvorschläge auf der Basis von SNOMED CT zu sorgen. SNOMED CT ist im Referentenentwurf zum PDSG bestätigt, Vorarbeiten also sinnvoll.
Ansprechpartner: Prof. Thun (SITIG)
-
-
-
Key
-
IM1X0-431
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Dr. Bernhard Wiegel
-
Organisation
-
KVB BAEMI BDL
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Noch offene Posten
-
Beschreibung
-
Sehr verehrte Frau Pantazoglou, herzlichen Dank für den Aufschlag.
In Abstimmung mit den befaßten Berufsverbänden bitte ich Sie,
1. bzgl. der korrekten Nomenklatur das DIMDI ins Boot zu holen
2. zu prüfen, inwieweit die vorstehenden Angaben den Vorgaben der WHO entsprechen
3. im Falle "Haemophilus influenzae" auch einen "Antikörper"-Nachweis zu kodieren
4. über das DIMDI eine einheitliche Codierung in Abstimmung mit den Lösungen zu diesem Thema mindestens zwischen den deutschsprachigen Anrainern (CH und A) zu suchen
5. für die korrekte Untersuchungsdarstellung die untersuchte Immunglobulinklasse und die verwendete Testmethodik zu kodieren (nur z.B. 40667-8 Rubella virus IgG Ab <span class="error">[Presence]</span> in Serum or Plasma by Immunoassay)
6. die Abstimmung mit den Codierungsvorschlägen aus der HL7-Welt zu sichen
7. weitere Ansprechpartner: BAEMI (Dr. Huzly) DIMDI (Dr.Haas) SITIG (Prof. Thun) ELGA/A (Dr.Sabutsch) und EHealth Suisse (Dr. Leichtle)
-
-
-
Key
-
IM1X0-430
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt/Unnötiges Datenfeld
-
Beschreibung
-
Geburtsname:
es fehlt die Angabe der Zeichenzahl
Vollständiger Name:
unnötiges Datenfeld, da lediglich Inhalt der anderen Felder dieses Bereiches zusammenkopiert sind
Vorname:
hier wird immer auf "Der Vorname des Versicherten wie in VSD (Versichertenstammdaten) definiert." Zurückgegriffen. In diesem Fall kann die verantwortliche Person aber nicht der Versicherte sein
-
-
-
Key
-
IM1X0-429
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-428
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Klarheit und Vollständigkeit
-
Beschreibung
-
Der Zeitstempel sollte immer vollständig sein (Datum und Uhrzeit).
Es muss klar sein, welche Zeitzone verwendet wird
-
-
-
Key
-
IM1X0-427
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Spezifizierung der Signatur fehlt
-
Beschreibung
-
Es fehlt die Spezifizierung der Signatur
-
-
-
Key
-
IM1X0-426
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der Zeichenzahl fehlt
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-425
-
Erstellt
-
22.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unnötiges Datenfeld
-
Beschreibung
-
Unnötiges Datenfeld, da lediglich Inhalt der anderen Felder dieses Bereiches zusammenkopiert sind
-
-
-
Key
-
IM1X0-424
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angaben Zeichenzahl
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl
-
-
-
Key
-
IM1X0-423
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Formatangabe
-
Beschreibung
-
Differenzierte Formatangabe fehlt
-
-
-
Key
-
IM1X0-422
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Formatierung
-
Beschreibung
-
Lediglich JJJJ ist angegeben, differenzierte Formatierung fehlt (TT.MM. oder JJJJ-MM-TT)
-
-
-
Key
-
IM1X0-421
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe Zeichenzahl
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
-
-
-
Key
-
IM1X0-420
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe Zeichenzahl
-
Beschreibung
-
Es fehlt die Angabe der Zeichenzahl.
Aufgeführte Beispiele gehören ins Namenskonzept (z.B. HumanName nickname)
-
-
-
Key
-
IM1X0-419
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe Format
-
Beschreibung
-
es fehlt eine Angabe des konkreten Formats
-
-
-
Key
-
IM1X0-418
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Überflüssig
-
Beschreibung
-
Vollständiger Name überflüssig, da lediglich Inhalt der anderen Felder dieses Bereiches zusammenkopiert sind.
-
-
-
Key
-
IM1X0-417
-
Erstellt
-
21.02.2020
-
Portallink
-
Name
-
Philipp Konhäuser
-
Organisation
-
Deutsche Hochschulmedizin e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Identifikation des Patienten nicht nachvollziehbar
-
Beschreibung
-
Die Identifikation des Patienten ist nicht nachvollziehbar. Welche PID soll gemeint sein? In jedem System wird die PID unterschiedlich erzeugt, eine lebenslang gültige Patienten-ID existiert derzeit nicht.
Die Reisepassnummer ist nicht zweckgebunden und somit nicht relevant; zudem besitzt nicht jeder Mensch einen Reisepass.
-
-
-
Key
-
IM1X0-415
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Johannes Neimann
-
Organisation
-
Praxis
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Identifikation muss auch ohne ANR oder BSNR möglich bleIben
-
Beschreibung
-
Impfung und Titerbestimmungen können unabhängig von einer kassenärztlichen Zulassung oder Ermächtigung erbracht werden. Im Sinne einer Interoperabilität über alle Versorgungsbereiche hinweg sollten diese Felder optional ausgestaltet werden. So erhalten beispielsweise private Labore und privatärztlich tätige Ärzte keine LANR bzw. BSNR.
-
-
-
Key
-
IM1X0-414
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unterschiedliche Klassifikationssysteme?
-
Beschreibung
-
Es gibt an drei Stellen im Entwurf Referenzen auf Krankheiten. An allen drei Stellen wird jeweils ein anderes Klassifikationssystem verwendet:
- Impfung gegen (Punkt 2.2) (ALPHA-ID)
- Vorerkrankung (Punkt 3.1) (ICD-10)
- Titer gegen (Punkt 4.1) (LOINC)
Aus dem Informationsmodell wird nicht ersichtlich, ob es Gründe für die Verwendung unterschiedlicher Systeme gibt. Ansonsten wäre zu prüfen, ob nicht eines der Systeme bevorzugt werden sollte.
-
-
-
Key
-
IM1X0-413
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Folgedatum einer Impfung
-
Beschreibung
-
Ein Folgedatum ist wichtig. Allerdings erscheint die Verknüpfung des Folgedatums mit der Impfung nicht optimal.
Uns stellen sich hier folgende Fragen.
1) Das Datum der Folgeimpfung ist in der Regel nicht fix, sondern hängt von Indikationen des Patienten ab, die sich jederzeit ändern können. Um das Folgedatum nachträglich anzupassen, müsste der Impfeintrag modifiziert werden. Damit würde die Verantwortlichkeit von Folgeeintrag und Impfeintrag vermischt.
2) Wie lassen sich Termine abbilden, die den Beginn einer Impfserie beschreiben. Beispielsweise wo würde man den Termin für die erste Zoster‐, oder HPV‐Impfung des Patienten vermerken?
3) Jede Impfung erhält einen Folgetermin. Wie lässt sich vermerken, dass ein Folgetermin stattgefunden hat und damit nicht mehr relevant ist. Verbleiben "alte" Folgetermine im Impfpass?
4) Wie ist bei Verwendung von Mehrfachimpfstoffen zu verfahren (z.B. Sechsfachimpfung) ? Müssen 6 Folgetermine eingetragen werden.
5) Wie ist zu verfahren, wenn die impfende Ärzt*in eine andere, vielleicht sogar fehlerhafte "Meinung" zum Mindestabstand hat, was häufig vorkommt, z.B. bei MMR/V. Sind die Einträge an "evidenzbasierte" Zeitintervalle (z.B. nach STIKO) gebunden?
6) Wie wird verfahren, wenn es regionale Unterschiede gibt? z.B. wird Pertussis nach SIKO regelmäßig aufgefrischt, nach STIKO nicht. Das führt zu Problemen bei Arztbesuchen in anderen Regionen. Regionale Unterschiede gibt es u.a. in Sachsen, Bayern, BW.
-
-
-
Key
-
IM1X0-412
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Grundimmunsierung vollständig muss validierbar sein
-
Beschreibung
-
Die Vollständigkeit einer Grundimmunisierung (GI) ist eine Option, einen schnellen Überblick über den Impfstatus zu erhalten. Ohne Kenntnis der Impfdaten ist die Information nicht auf Validität nachprüfbar, so dass bei fehlerhafter Einschätzung Haftungsprobleme entstehen können?
Vorschlag: Es müssen mindestens alle Vorimpfungen aufgenommen werden, die die Aussage „GI vollständig“ rechtfertigen. Also z.B. die letzten 3 Tetanusimpfungen. Es muss eine nachvollziehbare Bearbeitungsfunktion zur Einschätzung geben.
Wenn fehlerhafte Einträge bestehen, müssen diese editierbar sein.
Es sollte angestrebt werden, ein validiertes "Decision Support System" (DSS) zur Fehlerprüfung einzuschalten. Ein solches System könnte auch für ein Erinnerungssystem eingesetrzt werden.
-
-
-
Key
-
IM1X0-411
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Nachweis zur Vorlage in KITA oder Arbeitgeber
-
Beschreibung
-
Die KBV weist zurecht darauf hin: „...Die Dokumentationsmöglichkeit der impfrelevanten immunisierenden Erkrankungen ist vor allem im Kontext der zum Teil geltenden Masernimpfpflicht an dieser Stelle im elektronischen Impfpass aufgenommen worden....“ Daraus ergeben sich Fragen zur konkreten Durchführung: Wie soll der Nachweis konkret geführt werden:
- z.B. bei Schulen, die keinen Zugriff auf die die MIO der ePA haben?
- z.B. ein MIO‐Viewer wegen unzureichender Netzversorgung nicht aufgerufen werden kann?
Ist eine Druckoption für die Bescheinigung vorgesehen, wenn ja, wie wird sie signiert? Oder verbleibt die Verantwortlichkeit beim behandelnden Arzt, der den Nachweis papiergebunden austellen muss?
Es sollte möglich sein, digital signierte Dokumente vorzulegen, z.B. über eine App.
-
-
-
Key
-
IM1X0-410
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
MIO-Editor im PVS
-
Beschreibung
-
Die Durchführbarkeit wird im Praxisalltag erheblich erleichtert, wenn ein "MIO-Editor" bereitgestellt wird, der mit dem PVS verknüpft ist. Damit würden die Einträge auch gleichzeitig im PVS gespeichert und bei Bedarf von einer ePA in eine andere ePA transferiert werden können, wenn der Versicherte sich für eine andewre GKV bzw. ePA-anbieter entscheidet. Daneben wäre über einen MIO-Editor auch die Verknüpfung mit einer Impfpass-App möglich.
-
-
-
Key
-
IM1X0-409
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Titerhöhe und Methode angeben
-
Beschreibung
-
Aktuell wird vermerkt, ob der Titer ausreichend ist oder nicht. Es wäre sinnvoll darüber hinaus den Messwert und die Labormethode zu dokumentieren?
-
-
-
Key
-
IM1X0-408
-
Erstellt
-
18.02.2020
-
Portallink
-
Name
-
Hans-J. Schrörs
-
Organisation
-
GZIM und Hausarzt
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Dokumentation der Impfindikation sollte möglich sein
-
Beschreibung
-
Neben den Standardindikationen gibt es Indikationsimpfungen z.B. durch das persönliche Risiko bei Erkrankungen, Reisen oder Beruf. Impfschemas richten sich auch nach der Indikation. Eine Aussage über die Notwendigkeit von Wiederholungsimpfungen oder Impfabständen lässt sich in der Regel nicht immer korrekt treffen, wenn die Impfindikation unbekannt ist. Patienten wissen häufig nicht Bescheid oder die Angaben sind nicht validiert und damit nicht verwertbar.
Vorschlag: Die Impfindikation wird entsprechend den STIKO-Empfehlungen (z.B. mit S, I, R, B) gekennzeichnet, falls bekannt. Bei Übertragungen aus alten Dokumentationen ist die Indikation nicht immer bekannt. Bei Neuimpfungen ist die Indikation immer bekannt und würde durch Dokumentation das MIO-System zukünftig qualitätsmäßig ergänzen.
-
-
-
Key
-
IM1X0-406
-
Erstellt
-
17.02.2020
-
Portallink
-
Name
-
Elisabeth Pantazoglou
-
Organisation
-
Hochschule Niederrhein
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Spezifischere Kodierung
-
Beschreibung
-
Es ist u.U. notwendig eine Unterscheidung des Ak-Nachweises vorzunehmen.
-
-
-
Key
-
IM1X0-405
-
Erstellt
-
14.02.2020
-
Portallink
-
Name
-
Axel Biernat
-
Organisation
-
Cerner
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Use Case Internationalen Impfausweis erstellen/aktualisieren fehlt
-
Beschreibung
-
Ausserhalb Deutschlands wird in den nächsten Jahren der Internationale Impfausweis weiterhin bestand haben. Bitte den Use Case Internationalen Impfausweis erstellen/aktualiseren ergänzen.
Mit Sicherheit ist es an dieser Stelle hiflreich, diesen Prozess nachvollziehbar auch im MIO Impfausweis zur besseren Nachverfolgbarkeit zu dokumentieren.
-
-
-
Key
-
IM1X0-404
-
Erstellt
-
14.02.2020
-
Portallink
-
Name
-
Axel Biernat
-
Organisation
-
Cerner
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Betriebsärztlichen Dienst beteiligen
-
Beschreibung
-
Der Arbeitgeber muss im Rahmen seiner Fürsorgepflich auch sicherstellen, dass ggf. Impfungen durchgeführt werden, etwa bei Reisen seiner Mitarbeiter. Ich empfehle das neben der Bundesärztekammer auch die DGUV mit zu beteiligen.
-
-
-
Key
-
IM1X0-403
-
Erstellt
-
14.02.2020
-
Portallink
-
Name
-
Lars Treinat
-
Organisation
-
HÄVG Hausärztliche Vertragsgemeinschaft AG
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Prozessdarstellung und funktionale Anforderungen an die Implementierung
-
Beschreibung
-
Zu der hier vorliegenden Darstellung des Informationsobjekts und seiner Anwendungsszenarien fehlt aus unserer Sicht eine Darstellung des Prozesses für die beiden Anwendungsszenarien. Erst wenn ersichtlich ist, welche Akteure und Systeme bei der Befüllung des Informationsobjektes beteiligt sind und wie die Befüllung erfolgen soll, kann umfassend beurteilt werden, ob die im MIO eImpfpass enthaltenen granularen Informationen im Alltag praktikabel und sinnvoll gefüllt werden können. Auch wären funktionale Anforderungen für die Implementierung des MIO in Praxisverwaltungssystemen oder anderer Software wichtig, um einschätzen zu können, welche Auswirkungen auf die praktische Arbeit der Ärzte aus der Einführung des eImpfpass resultieren. Aus den vorliegenden Informationen ist nicht ersichtlich, wer für die Konzeption der Prozesse und die Festlegung der funktionalen Anforderungen einer Implementierung zuständig ist. Aus unserer Sicht ist es zwingend erforderlich, dass ggf. eine Klärung dieser Frage erfolgt.
Ebenfalls wäre u.E. eine User-Story sehr hilfreich, um zahlreiche Fragen beleuchten zu können, wie mit dem MIO eImpfpass in der Praxis umgegangen werden kann.
-
-
-
Key
-
IM1X0-402
-
Erstellt
-
14.02.2020
-
Portallink
-
Name
-
Lars Treinat
-
Organisation
-
HÄVG Hausärztliche Vertragsgemeinschaft AG
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Vormund/gesetzlicher Betreuer fehlt
-
Beschreibung
-
Diese Information ist u.E. erforderlich, um im Kontext der Impfung eine wirksame Einwilligung einholen zu können, ohne welche die Impfung ggf. eine Körperverletzung im Sinne des § 223 StGB darstellen könnte. Um ein zielgerichtetes Impfmanagement umsetzen zu können, ist diese Information wichtig bei Minderjährigen sowie Erwachsenen die aufgrund Behinderung oder Krankheit nicht in der Lage sind eine wirksame Einwilligung zu erteilen.
(vgl. Implementierungsleitfaden Arztbrief-Plus „hl7:guardian“)Die Informationen zu Vormund und Geschlecht werden Arztbrief-Plus verwendet, welcher auch im Bereich der elektronischen Arztvernetzung der hausarztzentrierten Versorgung bereits eingesetzt wird. Daher erscheint es aus unserer Sicht empfehlenswert, dass man die Konzepte in gleicher Weise im Informationsmodell des MIO abbildet.
(vgl. Implementierungsleitfaden Arztbrief-Plus <span class="nobr"><a href="https://www.vesta-gematik.de/standards/detail/standards/arztbrief-plus-auf-basis-der-hl7-clinical-document-architecture-release-2-fuer-das-deutsche-gesundhei/" class="external-link" rel="nofollow">https://www.vesta-gematik.de/standards/detail/standards/arztbrief-plus-auf-basis-der-hl7-clinical-document-architecture-release-2-fuer-das-deutsche-gesundhei/<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>)
-
-
-
Key
-
IM1X0-401
-
Erstellt
-
14.02.2020
-
Portallink
-
Name
-
Lars Treinat
-
Organisation
-
HÄVG Hausärztliche Vertragsgemeinschaft AG
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Geschlecht fehlt
-
Beschreibung
-
Diese Information ist aus unserer Sicht erforderlich, da es geschlechtsspezifische Unterschiede in den Impfschemata gibt und in diese Information somit zur zielgerichteten Umsetzung eines Impfmanagements benötigt wird.
(vgl. Implementierungsleitfaden Arztbrief-Plus „hl7:administrativeGenderCode“)
-
-
-
Key
-
IM1X0-400
-
Erstellt
-
13.02.2020
-
Portallink
-
Name
-
Christoph Wilhelm
-
Organisation
-
Bundesministerium für Gesundheit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
PKV / Versichertennummer
-
Beschreibung
-
Das Objekt Identifier besteht hier neben der PID und Reisepassnummer auch aus den Attributen PKV und Versichertennummer.
Was genau stellt der Wert PKV dar? Auch eine Nummer? Der Name der Versicherung? Die Eigenschaft, ob jemand gesetzlich versichert ist oder nicht?
Für eine natürliche Person in Deutschland gilt doch in der Regel eigentlich immer, dass sie zur gleichen Zeit entweder gesetzlich oder privat versichert ist. Auch wenn sich dies im Lauf des Lebens ändern kann. Tatsächlich werden beide Attribute PKV und Versichertennummer (KVNR?) immer beide abgespeichert, obwohl eigentlich immer nur eine zur selben Zeit notwendig wäre. Auch aus technischen Gründen wäre das keine optimale Lösung. Denkbar wäre ein eigenes Objekt z.B. "Versicherungszugehörigkeit" mit Angaben der Versichertennummer und Art (GKV, PKV oder ggf. weitere).
-
-
-
Key
-
IM1X0-399
-
Erstellt
-
13.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
mIC
-
Beschreibung
-
IHE hat in PCC ein Immunization Content (IC) Profile im Programm, das aber auf CDA basiert und nicht viel enthält.
Da es sich hier um eigentlich einen internationalen Impfpass der WHO handelt, der auf Basis von FHIR ausgearbeitet wird, sollte man überlegen, ob man nicht - zumindest zusammen mit A und CH - an einem mIC (mobile Immunization Content) Profile arbeitet und so dem Ganzen einen größeren Gültigkeitsbereich verschafft. Das erspart ggf. später notwendige Neujustierungen. (Dann müssten vermutlich auch weitere Profilebenen in die Hierarchie eingezogen, auch sollten die bisher vorhandenen Details abgeglichen werden.)
Ich weiß, dass das über den aktuell möglichen Zeitrahmen hinausgeht, die Erfahrung zeigt aber, dass das wiederum ein ganz wichtiger und auf keinen Fall zu vernachlässigender Aspekt ist.
-
-
-
Key
-
IM1X0-398
-
Erstellt
-
13.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Source of Truth?
-
Beschreibung
-
"Wenn man sich die Use Cases ansieht, dann tauchen Kardinalitäten und Optionalitäten auf. Da Informationsmodell und Use Cases ""nebeneinander"" stehen, ist unklar, was die ""source of truth"" ist. Normalerweise würde man das von einem Informationsmodell erwarten. Dann müssten sich aber Kardinalität und Optionalität darin finden, damit korrekte Ableitungen in die Use Cases verifiziert werden können.
Wenn Kardinalität und Optionalität in beiden Use Cases identisch sind, dann sollten diese nur im Informationsmodell aufgeführt werden, um Inkompatibilitäten zu vermeiden."
-
-
-
Key
-
IM1X0-397
-
Erstellt
-
13.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Profilhierarchien
-
Beschreibung
-
"Die Namenskonvention für die Profile finde ich gut, das erleichtert die Zuordnung und das Lesen.
Nur leider gehen darüber sämtliche Informationen über möglich Profilhierarchien verloren, so dass alle bisher erarbeiteten Profile nur als ""Sibblings"" aufzufassen sind. Zur Etablierung von Interoperabilität müssten aber Profilhierarchien aufgebaut werden, damit eine Wiederverwendung ermöglicht wird. Aufgrund der Struktur von FHIR wird das in einem größeren Netzwerk von Profilkomponenten enden, was eine KBV nicht alleine stemmen kann.
Ich schlage deshalb vor, genau das über das Interoperabilitätsforum übergreifend mit anderen Initiativen in einer gemeinsamen Aktion anzugehen und dazu alle einzuladen. Da das keine kurzfristige Aktion ist, sollte das als separater Handlungsstrang betrachtet werden, auf den man insgesamt einschwenkt."
-
-
-
Key
-
IM1X0-396
-
Erstellt
-
13.02.2020
-
Portallink
-
Name
-
Christoph Wilhelm
-
Organisation
-
Bundesministerium für Gesundheit
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Anpassung(en) Informationsmodell
-
Beschreibung
-
In diesem Informationsmodell fehlen die Kardinalitäten, also die Beziehungen der einzelnen Datenobjekte (MIOs) zueinander. Beispielsweise 1:n, 1:1 oder m:n Beziehungen wie etwa 1 Impfpass darf n Impfungen enthalten. Auch 0 bis 1 oder 0 bis unendlich wären als zusätzliche Angabe bei abhängigen MIOs denkbar.
Für eine spätere Umsetzung/Implementierung sind solche Angaben hiflreich um ein besseres Verständnis für das Gesamtkonzept zu erhalten.
Andernfalls läuft man Gefahr, dass ein entwickeltes System womöglich sogar medizinisch fachliche Fehler aufweist.Weiterhin sollte generell darüber nachgedacht werden, ob man die Modellierung übersichtlicher gestalten kann (z.B. durch bessere Anordnung der einzelnen Datenobjekte), damit es zumindest praktikabel ausgedruckt werden kann.
Kleine Randbemerkung: Das Vorschaubild auf dieser Seite (zum Klicken) schaut optisch anders aus, als das tatsächliche Modell welches auf dem PDF-Dokument zu sehen ist.
-
-
-
Key
-
IM1X0-395
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Dr. Christoph Bornhöft
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Validität der Angabe
-
Beschreibung
-
Wer darf das eintragen? Der Arzt, wenn er die Erkrankung dokumentiert hat? Darf er sich auf die Aussage des Patienten verlassen?
Bsp. Familie aus Berlin zugezogen, keine Masernimpfung beim Kind dokumentiert. Kind ist jetzt 6 Jahre alt. Mutter behauptet, das Kind sei erkrankt im Alter von zwei Jahren. Ist nicht zum Arzt gegangen. Berliner ehem. Kinder- und Jugendarzt weiss auch von keiner Erkrankung.
Ist dann erst zwingend eine Titerbestimmung erforderlich? Wer zahlt die? Wo wird dann vermerkt, dass die Titerbestimmung Grundlage des Eintrags an dieser Stelle war?
-
-
-
Key
-
IM1X0-394
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Dr. Christoph Bornhöft
-
Organisation
-
BVKJ
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
MIO setzt Detailkenntnis voraus, hat Fehlerpotential
-
Beschreibung
-
1. Bsp. : Meningokokken B-Impfungen sind je nach Alter des Impflings bei Beginn der Impfserie mal nach 4, nach 3 oder nach 2 Impfungen komplett. Der Eintragende muss das wissen und darf sich bei dem Errechnen des Alters bei Impfserienbeginn nicht verrechnen oder das falsche Schema anwenden.
2. Bsp.: Impfung mit HPV4 begonnen, mit HPV9 "abgeschlossen". Oder ist eine weitere HPV9 nötig?
-
-
-
Key
-
IM1X0-393
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Christoph Bornhöft
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Anzahl von gleicher Impfung
-
Beschreibung
-
Zur Grundimmunisierung sind oft zwei, drei oder vier Impfungen der selben Art in einer bestimmten zeitlichen Abfolge nötig. Daher ist es sinnvoll, eine Rangzahl (z.B. 2. FSME-Impfung oder 4. Pertussisimpfung) zu vergeben. Bei Auffrischungen kann das entfallen (z.B. "8. Auffrischung gegen Tetanus" ist nicht sinnvoll).
-
-
-
Key
-
IM1X0-392
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Metadaten zum Erkennen, ob bereits ein Impfpass vorliegt
-
Beschreibung
-
Ergänzend zu meinem vorherigen Kommentar (bisher nicht veröffentlicht), folgende weitere Frage zum angedachten Prozess.
Wenn es bereits einen Impfpass (als FHIR Dokument) in der epa gibt und ein Praxissystem einen neuen Eintrag (neue Impfung) schreiben will, dann müsste ja zunächst abgefragt werden, ob bereits ein Impfpass vorliegt, damit kein zweiter, komplett neuer Impfpass erstellt wird, sondern der bestehende aktualisiert wird. Welche Meta-Daten sind hierfür definiert, um zu erkennen, dass es bereits ein solches Dokument gibt?
-
-
-
Key
-
IM1X0-390
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
FHIR Mapping fehlt
-
Beschreibung
-
es fehlt an dieser Stelle (4.5 Eintragende Person) der Link zum Simplifier FHIR Mapping
-
-
-
Key
-
IM1X0-389
-
Erstellt
-
12.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Ableitung vom DE Basisprofil?
-
Beschreibung
-
Die Condition leitet nicht vom deutschen Basisprofil für eine condition ab. Ist dies mit Absicht so erfolgt oder aus Versehen? Ich hätte angenommen, dass es sinnvoll ist, eine Ableitung vom Basisprofil zu verwenden und dann für den MIO-Anwendungsfall weitere Einschränkungen zu treffen. Die Frage zielt auch auf perspektivisch kommende Anpassungen und Weiterentwicklungen ab und ob es da nicht sinnvoll wäre, hier bestehende Basisprofile als Grundlage zu verwenden?
-
-
-
Key
-
IM1X0-379
-
Erstellt
-
11.02.2020
-
Portallink
-
Name
-
Sylvia Thun
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
IG
-
Beschreibung
-
Ein Implementierungsguide gemäß FHIR-Richtlinien würde die Spezifikation mit wichtigen Informationen anreichern. Aber dieses ist sicher nach der Kommentierung geplant.
-
-
-
Key
-
IM1X0-378
-
Erstellt
-
11.02.2020
-
Portallink
-
Name
-
Sylvia Thun
-
Organisation
-
HL7
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
ALPHA-ID Brucellose
-
Beschreibung
-
Bitte ergänzen:
1|I13550|A23.9||||1304|BrucelloseEs existieren mehrere ICD und APLHA-ID zur Brucellose: Rücksprache mit DIMDI.
-
-
-
Key
-
IM1X0-377
-
Erstellt
-
11.02.2020
-
Portallink
-
Name
-
Sylvia Thun
-
Organisation
-
HL7
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Stoffbezeichnung nach IDMP / §31b SGB V
-
Beschreibung
-
Die Stoffbezeichnungen ASK des BfArM (Arzneistoffkennung) sollte mitgeführt werden. Eine Überführung in IDMP muss möglich sein.
-
-
-
Key
-
IM1X0-376
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Stefan Streit
-
Organisation
-
Hausarztpraxis Streit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Automatisierte Archivierung der Originaldaten und Details der Digitalisierung
-
Beschreibung
-
Es bedarf der automatisierten Dokumentation (Fotografieren?) der vielseitigen (2 bis 24 seitigen) analogen Impfpässe. Ein Scan fällt, wegen des erforderlichen Umblätterns der kleinen Heftchen, als praktikable Möglichkeit aus. Die Bilddatei muss so erstellt werden können, dass alle Seiten des Dokuments später mit dem Namen, der nur auf der ersten Seite des Papierdokuments steht, endgültig verknüpft sind. Nur so kann die analoge Ausgangsdatenlage valide dokumentiert werden. Impfpässe sind 30 bis 40 Jahre alt, mal mitgewaschen, haben herausgerissene Seiten, Eintrage können uneindeutig sein oder im Nachhinein vorgenommen. Es gibt viele verschiedene Papierformate, die eine automatisierte Archivierung erschweren. Dies gelingt nur bei den langen, weißen Stoffpässen, mit einem Einzugsscanner leicht. Diese sind aber heute selten. Die roten Bücher aus der ehemaligen DDR haben harte Pappcover. Am häufigsten sind die gelbe Impfhefte, von denen es verschiedene Varianten gibt, in denen sich die Impfeinträge an jeweils unterschiedlichen Seiten befinden. Viele Patienten haben zwei und mehr Impfausweise, teilweise mit widersprüchlichen Einträgen. Immer wieder finden sich abweichende Namen und Namesschreibweisen, gelegentlich gar keine Namenseinträge.
Gegenwärtig findet die Übertragung der Impfbucheinträge, in die digitale Arztakte, allenfalls im Format: Krankheit plus Jahreszahl, statt. Für Impfüberlegungen bedarf es deshalb zusätzlich des Papierimpfbuchs. Für viele Impfungen existieren mehrere Impfschemata, in der Regel ein Schnellimmunisierungsschema und ein Standardschema. Außerdem unterscheiden sich die Impfabstände für Kombinationsimpfstoffe, bei denen eine Komponente mit halbem Impfstoffgehalt verimpft wird, gegenüber denen der Einzelimpfstoffe mit vollem Wirkstoffgehalt. Liegt der analoge Papierimpfpass vor, dann reicht ein Blick auf Tag, Monat, Jahr der früheren Impfeinträge, für spätere Impfentscheidungen. Möchte man einen analogen Papierimpfpass vollständig digitalisieren dann erfordert das, für eine zukünftig-valide Entscheidungsbasis für jede Impfung, die händisch eingetippte Erfassung von Tag, Monat und Jahr, dem Klarname des Impfstoffs, der impfpräventablen Krankheit sowie ggf. der Chargennummer. So wie das digitale Impfbuch gegenwärtig kommuniziert wird, muss davon ausgegangen werden, dass die Patienten das Papierbuch nach der Digitalisierung entsorgen. Für die Standardimpfeinträge nach dem Regelimpfkalender kommt man so bereits auf ca. 50 Einzeleinträge, nach Reiseimpfungen und Auffrischungsimpfungen leicht auf 100 Einzeleinträge. Kombinationsimpfungen lösen 5-10 Einzeleinträge für einen einzigen Impftermin aus. Meist fehlt der Aufkleber und der Impfstoffname im Impfbuch, wie es eigentlich heute gefordert ist. Im Papierimpfausweis finden sich dann nur Kreuzchen bei den Erkrankungen, zwischen einem Datum und einer Unterschrift mit Stempel. Es muss pro Impfeintrag mit mindesten 30 Sekunden gerechnet werden, so dass die vollständige Digitalisierung eines Impfbuchs 25 bis 50 Minuten dauern kann.
-
-
-
Key
-
IM1X0-375
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Stefan Streit
-
Organisation
-
Hausarztpraxis Streit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Automatisierte Archivierung der Originaldaten
-
Beschreibung
-
Es bedarf der automatisierten Dokumentation (Fotografieren?) der vielseitigen (2 bis 24 seitigen) analogen Impfpässe. Ein Scan fällt, wegen des erforderlichen Umblätterns der kleinen Heftchen, als praktikable Möglichkeit aus. Die Bilddatei muss so erstellt werden können, dass alle Seiten des Dokuments später mit dem Namen, der nur auf der ersten Seite des Papierdokuments steht, endgültig verknüpft sind. Nur so kann die analoge Ausgangsdatenlage valide dokumentiert werden. Impfpässe sind 30 bis 40 Jahre alt, mal mitgewaschen, haben herausgerissene Seiten, Eintrage können uneindeutig sein oder im Nachhinein vorgenommen. Es gibt viele verschiedene Papierformate, die eine automatisierte Archivierung erschweren. Dies gelingt nur bei den langen, weißen Stoffpässen, mit einem Einzugsscanner leicht. Diese sind aber heute selten. Die roten Bücher aus der ehemaligen DDR haben harte Pappcover. Am häufigsten sind die gelbe Impfhefte, von denen es verschiedene Varianten gibt, in denen sich die Impfeinträge an jeweils unterschiedlichen Seiten befinden. Viele Patienten haben zwei und mehr Impfausweise, teilweise mit widersprüchlichen Einträgen. Immer wieder finden sich abweichende Namen und Namesschreibweisen, gelegentlich gar keine Namenseinträge.
-
-
-
Key
-
IM1X0-374
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Stefan Streit
-
Organisation
-
Hausarztpraxis Streit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Automatisierte Archivierung der Originaldaten
-
Beschreibung
-
Es bedarf der automatisierten Dokumentation (Fotografieren?) der vielseitigen (2 bis 24 seitigen) analogen Impfpässe. Ein Scan fällt, wegen des erforderlichen Umblätterns der kleinen Heftchen, als praktikable Möglichkeit aus. Die Bilddatei muss so erstellt werden können, dass alle Seiten des Dokuments später mit dem Namen, der nur auf der ersten Seite des Papierdokuments steht, endgültig verknüpft sind. Nur so kann die analoge Ausgangsdatenlage valide dokumentiert werden. Impfpässe sind 30 bis 40 Jahre alt, mal mitgewaschen, haben herausgerissene Seiten, Eintrage können uneindeutig sein oder im Nachhinein vorgenommen. Es gibt viele verschiedene Papierformate, die eine automatisierte Archivierung erschweren. Dies gelingt nur bei den langen, weißen Stoffpässen, mit einem Einzugsscanner leicht. Diese sind aber heute selten. Die roten Bücher aus der ehemaligen DDR haben harte Pappcover. Am häufigsten sind die gelbe Impfhefte, von denen es verschiedene Varianten gibt, in denen sich die Impfeinträge an jeweils unterschiedlichen Seiten befinden. Viele Patienten haben zwei und mehr Impfausweise, teilweise mit widersprüchlichen Einträgen. Immer wieder finden sich abweichende Namen und Namesschreibweisen, gelegentlich gar keine Namenseinträge.
-
-
-
Key
-
IM1X0-373
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Stefan Streit
-
Organisation
-
Hausarztpraxis Streit
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Digitalisierung des Dokumentationsprozesses bei der Impfung
-
Beschreibung
-
Eine digitale Impfstoffdokumentation für eine aktuelle Impfung erfordert einen kleinen QR-Code oder einen 2 D-Barcode auf der Impfstoffampulle, der automatisiert alle erforderlichen Dokumentationsschritte (Datum, Klarnameneintrag des Impfstoffs, Chargennummer, Namen der Krankheitheiten gegen die geimpft wurde (verschiedene Kombinationsimpfstoffe), Signatur, sowie die Ablage der Abrechnungsziffer im Praxisinformationssystem) automatisch auslöst und die entsprechenden Einträge automatisiert in die vorgesehenen Textfelder einfügt. Dafür bedarf es der Integration eines Handscanners. Üblicherweise finden Großpackungen mit 10 oder 20 Impfampullen pro Karton Anwendung, so das der vorgeschriebene 2 D-Barcode auf der Pappschachtel im Impfstoffkühlschrank liegt und für diesen Vorgang nicht geeignet ist.
-
-
-
Key
-
IM1X0-372
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Anschrift
-
Beschreibung
-
Postfach und PLZ sind kein "count", was für Zähler benutzt wird.
Bei der PLZ handelt es sich genaugenommen um einen Kode. Vermutlich ist die Verwendung eines Strings aber einfacher. Postfach ist definitiv ein String.
-
-
-
Key
-
IM1X0-371
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Pflicht- (M) vs. Optionales Feld (R)
-
Beschreibung
-
Unter "inhaltliche Darstellung" wird gesagt, dass es sich bei den Feldern um ein "Pflicht- (M) oder ein für die nutzende Person optionales Feld (R) handelt".
Hier könnte der Eindruck entstehen, dass "M" ein "MUSS"-Feld kennzeichnet, wobei sich für "R" keine direkte Äquivalenz aufdrängt.Die Kürzel stammen aus HL7 Version 3, was sich mit den Links deckt: Bei "M" handelt es sich um eine "Mandatory"-Angabe, also eine, die einen direkten Wert unter Ausschluss von Null-Werten verlangt, während das "R" für "Required" steht und somit nicht der Bedeutung optional entspricht. Für "optional" ist "O" vorgesehen.
Die verwendete technische Terminologie sollte auf einer separaten Seite erklärt sein und nicht auf ein Tool verweisen, dass nicht direkt sichtbar ist und auch nur indirekt verwendet wird.
Wenn eine spezielle technische Terminologie verwendet wird, dann sollte diese entweder abstrakt oder in direktem Zusammenhang mit der eingesetzten Repräsentationstechnologie, hier HL7 FHIR, stehen. FHIR benutzt aber andere Begriffe.
-
-
-
Key
-
IM1X0-370
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Kommentierungsformular scrollt weg
-
Beschreibung
-
Bei der Eingabe der Kommentare scrollt das Formular ständig weg. Damit wird die Eingabe eines Kommentars unnützt erschwert.
Es lässt sich in der Größe auch nicht verändern, um das ggf. so abzustellen.
-
-
-
Key
-
IM1X0-369
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
mehrere Identifikatoren
-
Beschreibung
-
Ein Impfpass kann über mehrere Identifikatoren für eine Person verfügen. Diese können sich über den Lauf der Zeit verändern. So wechselt bspw. nach 10 Jahren der Reisepass bzw. der Patient bekommt eine neue eGK. Deshalb sollten die Identifikatoren als Liste modelliert werden, die mit Zeitbereichen und ausgebenden Insitutionen versehen und dann mitunter auch "doppelt" vorkommen können.
-
-
-
Key
-
IM1X0-368
-
Erstellt
-
10.02.2020
-
Portallink
-
Name
-
Frank Oemig
-
Organisation
-
DTHS
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Datensammlung, kein Informationsmodell
-
Beschreibung
-
Bei der Darstellung handelt es sich nicht um ein klassisches Informationsmodell, sondern um eine strukturierte Datensammlung. Hier sollte auf eine korrekte Verwendung der Terminologie geachtet werden.
Informationsmodelle sollten die Zusammenhänge zwischen verschiedenen Artefakten beschreiben und darstellen. Die Nutzung einer Abstraktion im Sinne von logischen Datenstrukturen würde die Darstellung erheblich vereinfachen und somit leichter lesbar machen. So sollte ein Datentyp "Name" verwendet werden, der hier jedoch als eigene "Klasse" aufglistet ist und deshalb gleich mehrfach vorkommt. Diese Redundanzen lassen sich vermeiden.
In dieser Darstellung fehlen Angaben zur Kardinalität und Optonalität.
-
-
-
Key
-
IM1X0-366
-
Erstellt
-
07.02.2020
-
Portallink
-
Name
-
Schulze Christian
-
Organisation
-
Landkreis Oberhavel, Land Brandenburg
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Einbindung ÖGD
-
Beschreibung
-
Ich möchte die wichtigen Kommentare der Kollegin Teichert und Kollege Woltering ergänzen und darauf hinweisen, dass der ÖGD in vielen Bundeländern sogar eine gesetzliche Verpflichtung / Auftrag hat Impfdokumente zu kontrollieren, zu beraten und Impfungen durchzuführen.
Die Pädiater des ÖGD sind vielfach in Schulen und Kitas unterwegs und mobil.
Der technische Support zu Impfausweisen muss deshalb auch mobil sichergestellt sein.
-
-
-
Key
-
IM1X0-364
-
Erstellt
-
05.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Nachfrage zum Workflow / Prozess (zusätzlich zu den FHIR Ressourcen)
-
Beschreibung
-
Mir fehlt ein wenig die Prozessbeschreibung zusätzlich zu den FHIR Ressourcen. Das Bundle vom Typ=Dokument beinhaltet über die Composition und die weiteren (aus den Entries referenzierten) Ressourcen (wie Practitioner, Organization) das "Impfpass-Dokument", entweder aus dem Anwendungsfall "Daten eintragen" oder "Daten nach/übertragen". Soweit klar.
Was mir fehlt, ist eine Beschreibung wie genau diese Profile zu verwenden sind. Handelt es sich nur um die Strukturen zum Speichern (bzw. Anzeige des Dokuments Impfpass) oder auch zur Übertragung der Daten zwischen zwei Systemen (und damit dann auch die Validierung betreffend, ob das sendende System korrektes FHIR gemäß Profil sendet). Wie genau sind hier die Anwendungsfälle gedacht?
Z.B. Erfassung in einem System A und Speichern in einem System B unter Verwendung der genannten Profile, bzw. auch Nachtragen einer weiteren Impfung zu einer bestehenden Impfung. Was genau wird gesendet? Wird immer das gesamte Bundle (Dokument) übertragen oder z.B. nur auf die Composition, also beispielsweise das Addendum zu einem bestehenden Impfpass gesendet? Fügt das empfangene System diesen Eintrag dann dem bestehenden Impfpass hinzu?
Weiterer Hintergrund der Frage ist auch der angedachte Umgang mit den Practitioner-Ressourcen (z.B. Arzt mit LANR) und dem Fall, dass typischerweise solch eine Ressource bei jedem beteiligte Server bereits vorhanden sein wird (eigenes Provider Directory) und es also bereits eine Ärzte/Organisationsverwaltung geben wird. Welche Überlegungen gibt es an dieser Stelle, soll es ein zentrales Verzeichnis der Leistungserbringer geben, gegen die z.B. die LANRs ressolved werden?
-
-
-
Key
-
IM1X0-363
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Einträge des Patienten erlaubt?
-
Beschreibung
-
Als eintragende Person (und auch Verant. Person) sind gemäß des FHIR Profils nur Practitioner-Ressourcen vorgesehen. Dies würde bedeuten, dass der Anwendungsfall "Patient trägt Impfungen nach, z.B. in seiner EGA" nicht vorgesehen ist.
In den Hintergrundinformationen steht:
"...Auch elektronische Gesundheitsakten wie die Vivy bieten eine Sektion zur elektronischen Dokumentation von Impfungen an7. Zum Teil ist hier jedoch vorgesehen, wie auch beim Gesundheitskonto des online Portals vitabook, dass die Einträge von den zu behandelnden Personen selbst erfasst werden. Da die Einträge nicht durch eine ärztlich tätige Person gemäß Infektionsschutzgesetz erfolgen, ist die Verlässlichkeit der Informationen fraglich, wie auch die Qualität und Vollständigkeit der Einträge."Daraus lässt sich jetzt nicht explizit ablesen, ob der Impfpass das Szenario unterstützt oder nicht. Daher hier die konkrete Nachfrage, ob es auch möglich sein soll, dass ein Patient Daten (wenngleich weniger valide) übernimmt? Wenn ja, müsste das FHIR Profil angepasst werden, sodass die Referenz auch auf die Ressource Patient möglich ist.
-
-
-
Key
-
IM1X0-362
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Identifier System der BSNR
-
Beschreibung
-
Als Identifier System wird ein eigenes, neues verwendet:
BSNR = <span class="nobr"><a href="https://fhir.kbv.de/NamingSystem/KBV_NS_Base_BSNR" class="external-link" rel="nofollow">https://fhir.kbv.de/NamingSystem/KBV_NS_Base_BSNR<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>Die IK- Nummer hingegen verweist auf das DE Basisprofil. Wieso erfolgt dies nicht auch bei der BSNR, siehe Namensraum <span class="nobr"><a href="http://fhir.de/NamingSystem/kbv/bsnr" class="external-link" rel="nofollow">http://fhir.de/NamingSystem/kbv/bsnr<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> ?
-
-
-
Key
-
IM1X0-361
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Identifier System der ANR
-
Beschreibung
-
hier ist das System mit fixed value = <span class="nobr"><a href="https://fhir.kbv.de/NamingSystem/KBV_NS_Base_ANR" class="external-link" rel="nofollow">https://fhir.kbv.de/NamingSystem/KBV_NS_Base_ANR<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> angegeben.
An anderen Stellen werden die DE-Basisprofile referenziert, die in diesem Fall für die LANR aber <span class="nobr"><a href="http://fhir.de/NamingSystem/kbv/lanr" class="external-link" rel="nofollow">http://fhir.de/NamingSystem/kbv/lanr<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> verwenden.
Mir ist hier nicht ersichtlich, wieso es hier einen weiteren Namensraum gibt. Wenn ich es richtig verstanden habe, ist die ANR die LANR?
-
-
-
Key
-
IM1X0-360
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe der occurrence (Kardinalität)
-
Beschreibung
-
Mir scheint das Profil an dieser Stelle nicht korrekt. Die occurence ist verpflichtend anzugeben, aber (wenn ich es richtig verstanden habe) entweder als genaue Datumsangabe oder wenn diese nicht vorhanden ist, als string und ungefähre Angabe.
Im Profil ist jedoch die Datumsangabe als 1:1 (must support) hinterlegt, womit die Angabe als String nicht möglich ist? Mir scheint das so nicht korrekt.
-
-
-
Key
-
IM1X0-359
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Immunization.protocolApplied.doseNumber
-
Beschreibung
-
Die doseNumber finde ich nicht im Informationsmodel der Impfung wieder, ist im FHIR Profil aber vorhanden. Was genau ist der Anwendungsfall, bzw. müssten fehlende Informationen bitte ergänzend beschrieben werden.
-
-
-
Key
-
IM1X0-358
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
vaccineCode: Display verpflichtend
-
Beschreibung
-
Im vaccineCode ist u.a. für die PZN der Display mit der Kardinalität 1:1 definiert, also verpflichtend anzugeben. Um welchen Text handelt es sich hierbei genau?
Der Handelsname ist ja bereits über den coding.text definiert.
-
-
-
Key
-
IM1X0-357
-
Erstellt
-
04.02.2020
-
Portallink
-
Name
-
Christina Starfinger
-
Organisation
-
x-tention Informationstechnologie GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Geburtsdatum Extension
-
Beschreibung
-
Wozu gibt es die Extension beim Geburtsdatum?
Die Extension ist aktuell auch so definiert, dass alle Werte möglich sind, ist dies so beabsichtigt?
-
-
-
Key
-
IM1X0-356
-
Erstellt
-
03.02.2020
-
Portallink
-
Name
-
Christian Weitemeyer
-
Organisation
-
UMG
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Geschlecht fehlt
-
Beschreibung
-
Analog zu FHIR: Patient.gender
male | female | other | unknown
-
-
-
Key
-
IM1X0-353
-
Erstellt
-
02.02.2020
-
Portallink
-
Name
-
Prof. Sylvia Thun
-
Organisation
-
HL7 DE
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Gender
-
Beschreibung
-
Die Genderangabe ist für Impfungen relevant.
-
-
-
Key
-
IM1X0-352
-
Erstellt
-
02.02.2020
-
Portallink
-
Name
-
Birger Haarbrandt
-
Organisation
-
vitasystems GmbH
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Modellierung als wiederverwendbares Profil
-
Beschreibung
-
Der Ansatz, ein anwendungsfallspezifisches Profil zu erstellen, ist problematisch, da die Titer-Bestimmung ein Konzept ist, das auch außerhalb des Impfasses vorkommt. Daher sollte dieses Profil unabhängig vom Impfpass und unter Berücksichtigung verschiedener Anwendungsszenarien (und dem Zusammenhang zu Labor-Profilen) modelliert werden.
-
-
-
Key
-
IM1X0-351
-
Erstellt
-
02.02.2020
-
Portallink
-
Name
-
Birger Haarbrandt
-
Organisation
-
vitasystems GmbH
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Extension für Autor könnte Modelling-Antipattern sein
-
Beschreibung
-
Für solch generische Konzepte wie den Autor eines Eintrags sollte es nicht notwendig sein nicht-standardisierte Extensions zu definieren. Wenn es hier eine generelle Schwäche gibt, dieses in FHIR abzubilden, dann sollte die Extension so generisch und wiederverwendbar definiert sein, dass sie auch in anderen Anwendungsfällen (Mutterpass, U-Heft, Medizininformatik-Inititaitive) konsitent angewendet werden kann.
Gravierender ist, dass in der Beschreibung der Extension von der "Attestierenden (Verantwortliche Person)" gesprochen wird. Die Attestation (im Sinne einer Prüfung/Freigabe) ist ein anderes Konzept als der "Enterer". Hier ist zumindest mir nicht deutlich, ob das sauber dem Informationsmodell zugeordnet wurde.
-
-
-
Key
-
IM1X0-350
-
Erstellt
-
31.01.2020
-
Portallink
-
Name
-
André Sander
-
Organisation
-
ID Berlin GmbH&Co. KGaA
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
NIcht notwendig
-
Beschreibung
-
Alle Krankheiten sind auch mit der ICD abbildbar, die international vewendet wird. Damit wird eine bessere Interoperabilität erreicht.
-
-
-
Key
-
IM1X0-349
-
Erstellt
-
31.01.2020
-
Portallink
-
Name
-
André Sander
-
Organisation
-
ID Berlin GmbH&Co. KGaA
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
PID
-
Beschreibung
-
Da die PID abhängig vom Mandanten ist müsste in "System" ein Verweis auf die Institution bzw. sogar das verwendete Computersystem stehen.
-
-
-
Key
-
IM1X0-348
-
Erstellt
-
31.01.2020
-
Portallink
-
Name
-
André Sander
-
Organisation
-
ID Berlin GmbH&Co. KGaA
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ValueSet?
-
Beschreibung
-
Hier könnte man doch ein ValueSet mit Codes aus der ICD oder SNOMED verwenden!?
-
-
-
Key
-
IM1X0-347
-
Erstellt
-
31.01.2020
-
Portallink
-
Name
-
André Sander
-
Organisation
-
ID Berlin GmbH&Co. KGaA
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
Nicht einheitlich und ggf. techn. nicht interoperabel
-
Beschreibung
-
Die Codes enthalten eine Definition im Code selbst, die aber nicht einheitlich ist. Bei Säugling sind es Monate, bei Kleinkind Monate und Jahre und bei Erwachsener nur noch Jahre. Die Definition sollte in das Attribut "definition" aufgenommen werden.
Außerdem fehlt die Lebensphase ab 65 Jahre.
"Säugling" enthält zudem einen Umlaut, was auch heute noch durchaus zu Problemen führen kann.
-
-
-
Key
-
IM1X0-346
-
Erstellt
-
31.01.2020
-
Portallink
-
Name
-
André Sander
-
Organisation
-
ID Berlin GmbH&Co. KGaA
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Interval
-
Beschreibung
-
Wäre es nicht vorteilhaft an dieser Stelle noch ein optionales Intervall anzubieten, mit dem die Lebensphase algorithmisch verarbeitbar hinterlegt wird, falls die Terminologie das nicht zulässt?
Bsp. "Jugendlicher" ist für das Alter 14-18 definiert (zumindest im dt. Recht). In der Terminologie könnte das nun entsprechend modelliert sein. Ist das aber nicht möglich oder vorhanden, wäre es gut, das an dieser Stelle angeben zu können.
-
-
-
Key
-
IM1X0-345
-
Erstellt
-
28.01.2020
-
Portallink
-
Name
-
Heike Dewenter
-
Organisation
-
HL7 Deutschland e.V.
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
SNOMED CT Code
-
Beschreibung
-
Die Bezeichnung SNOMED CT Product Code ist nicht korrekt. Es handelt sich um SNOMED CT Concepts mit deren Concept Identifier - Codes.
Die Achse in SNOMED CT, bzw. der semantic tag, ist in diesem Fall "product". Darüber hinaus auch nur im Falle der Abbildung eines pharmazeutischen Produktes. Der Impfstoff als Substanz muss über die Achse "substance" annotiert werden.
-
-
-
Key
-
IM1X0-344
-
Erstellt
-
26.01.2020
-
Portallink
-
Name
-
Birger Haarbrandt
-
Organisation
-
vitasystems GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Benennung des Profils
-
Beschreibung
-
Der Name Observation_Immunization_Status ist schwierig zu unterscheiden vom (technischen) Element Immunization.status. Vielleicht kann man hier einen anderen Namen wählen (vielleicht sowas wie Antibody_Status, das fehlt mir aber der klinische Background), um die unterschiedlichen Bedeutungen deutlich zu machen.
-
-
-
Key
-
IM1X0-343
-
Erstellt
-
26.01.2020
-
Portallink
-
Name
-
Dominik Brammen
-
Organisation
-
Deutsche Interdisziplinäre Vereinigung für Intensiv- und Notfallmedizin DIVI e. V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Wichtige Informationen wie verabreichtes Volumen sollten explizit modeliert werden
-
Beschreibung
-
Wichtige Informationen, wie z. B. das verabreichte Volumen des Impfstoffes sollten nicht in einem Restinformationssammelfeld wie diesem modelliert werden. Sollte eine Dosisreduktion notwendig sein, dann sollte diese dann wichtige Information durch eigene Modellierung im Datenmodell im Sinne der Arzneimitteltherapiesicherheit nutzbar dokumentiert werden können.
-
-
-
Key
-
IM1X0-342
-
Erstellt
-
26.01.2020
-
Portallink
-
Name
-
Birger Haarbrandt
-
Organisation
-
vitasystems GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Immunization.primarySource Wert
-
Beschreibung
-
Im Addendum wird Immunization.primarySource mit "false" als Konstante gesetzt. In diesem Profil hingegen wurde das Element herausgenommen. Wenn ich die Defintion des Elements (und den Use-Case) richtig verstehe, sollte bei einem Eintrag doch entsprechend angenommen werden können, dass die Information von der Person stammt, die die Impfung durchgeführt hat. Daher frage ich mich, warum Immunization.primarySource nicht gesetzt werden kann.
-
-
-
Key
-
IM1X0-341
-
Erstellt
-
26.01.2020
-
Portallink
-
Name
-
Birger Haarbrandt
-
Organisation
-
vitasystems GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Kardinalität von Immunization.note
-
Beschreibung
-
Im Gegensatz zum Addendum exisitert hier ein Element "disclaimer", das als slice zusätzlich zu Immunization.note hinzugefügt wurde. Die Kardinalität von Immunization.note ist mit 1..2 angegeben (im Gegensatz zu 0..1 beim Record Addendum). Das sieht für mich nicht korrekt aus. Stattdessen sollte die Kardinalität so gesetzt werden, um doppelte Einträge und erzwungene "Anmerkungen" zu vermeiden:
Immunization.note auf 1..1
Immunization.note.text auf 0..1.
Immunization.note:disclaimer.text 1..1Zudem halte ich in diesem Anwendungsfall die Nutzung der Datenfelder Immunization.note.time und Immunization.note.author für wünschenswert (z.B. um das Hinzufügen eines Kommentars bei einem späteren Arztbesuch durch eine andere Person als jene, die die Impfung durchgeführt hat, adäquat abzubilden)
-
-
-
Key
-
IM1X0-340
-
Erstellt
-
23.01.2020
-
Portallink
-
Name
-
Ute Teichert
-
Organisation
-
BVÖGD
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
BVÖGD beteiligen
-
Beschreibung
-
Die Gesundheitsämter impfen nicht nur sondern sind auch bundesweit mit Impfbuchkontrollen unterwegs, so z.B. bei Einschulunteruntersuchungen, Begutachtungen oder Impfaktionen. Auch die Umsetzung des Masernschutzgesetzes läuft überwiegend über die Gesundheitsämtern. Daher müssen diese auch unbedingt mit in den elektronischen Impfpass einbezogen werden.
Als Vorsitzende de Bundesverbandes der Ärztinnen und Ärzte des Öffentlichen Gesundheitsdienstes (BVÖGD) rege ich an, auch unsern Verband in das Verfahren mit einzubeziehen.
-
-
-
Key
-
IM1X0-337
-
Erstellt
-
23.01.2020
-
Portallink
-
Name
-
Dr. Ronald Woltering
-
Organisation
-
Kreis Höxter - Gesundheitsamt
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Einbindung des Öffentlichen Gesundheitsdienstes (ÖGD) notwendig
-
Beschreibung
-
Der ÖGD ist in vielfältiger Hinsicht mit der Ausstellung, Auswertung und Kontrolle von Impfausweisen befasst.
Bei der Gefahrenabwehr impfpräventabler Erkrankungen ist die systematische Erfassung und Auswertung von Impfpässen ein wesentlicher Punkt der Maßnahmen.
Beim Vollzug des Masernschutzgesetzes wird zukünftig ein Zugriff auf die Daten im elektronischen Impfausweis notwendig werden.
Daneben werden (Reihen-) Impfungen durch den ÖGD selber durchgeführt und dokumentiert.
-
-
-
Key
-
IM1X0-336
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
Gefyra GmbH
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Übersetzungen
-
Beschreibung
-
Deutsche Übersetzungen für SNOMED Codes wäre technische betrachtet CodeSystem-Supplements, keine ConceptMaps, es sei denn, die Intention ist es, SNOMED Codes zunächst auf ein alternatives CodeSystem zu mappen, das dann deutsche Display-Werte hat.
Wegen der Lizenzproblematik denkbar, aber da die ConceptMaps alle leer sind, ist es schwer zu raten, welche Strategie hier verfolgt wird.Der Vollständigkeit halber sei jedoch darauf verwiesen, dass Deutsche Display-Values für ein Internationales CodeSystem als supplement abgebildet würden, siehe <span class="nobr"><a href="http://hl7.org/fhir/codesystem.html" class="external-link" rel="nofollow">http://hl7.org/fhir/codesystem.html<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-335
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ValueSetBinding statt Extension möglich
-
Beschreibung
-
Anstelle dieser Extension wäre es m.E. wesentlich einfacher und praktikabler, Condition.onsetString einfach an das gewünschte ValueSet zu binden
Also, die Altersgruppe wird direkt in onsetString geschrieben würden, z.B.:
<onsetString value="Jugendlicher"/>
...und das Binding prüft bei der Validierung, dass nur die gewünschten Codes "Erwachsener", "Jugendlicher", "Kleinkind" usw. verwendet werden dürfen...
-
-
-
Key
-
IM1X0-334
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Dummy-Code
-
Beschreibung
-
Bitte vergessen Sie nicht, den Dummy-Code zu ersetzen. Danke sehr
(Vergesse ich leider zu oft)
-
-
-
Key
-
IM1X0-333
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
verschiedene Profile für die beiden Use Cases
-
Beschreibung
-
Ich weiß, dass die Use Cases immer relevant sind. Aber ich frage mich auch, warum für ähnliche UseCases, denn letztendlich sind die beiden UseCases sich ähnlich, unterschiedliche Profile benötigt werden. Kann man nicht jeweils nur ein Profil erstellen und dann die Unterschiede bei den FHIR-Profilen über allgemeine Contraints festlegen und inhaltlich textuell beschreiben?
Kleines Anwendungsbeispiel: Wenn mein langjähriger Hausarzt (seit > 10 Jahren) die Impfungen einträgt, die ich bei ihm vor über ca. 10 Jahre bekommen habe, ist das Eintragen oder Nachtragen? Wenn es Eintragen ist, darf in der Immunization primarySource nicht enthalten sein, wenn es Nachtragen ist, muss in der Immunization primarySource = false enthalten sein. Hier würde ich mir Klärung wünschen.
-
-
-
Key
-
IM1X0-332
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Extension eventuell nicht erforderlich
-
Beschreibung
-
Laut Datenmodell:
"In diesem Feld können als Freitext ergänzende Angaben zur Person gemacht werden. Beispiele sind: Junior, III., Künstler- oder Ordensnamen."Für keine dieser beispielhaften Angaben ist diese Extension erforderlich.
"Junior" -> HumanName.suffix
"III."-> HumanName.suffix
Für die Qualifizierung von Künstler- und Ordensnamen gibt es eine Standard-Extension: <span class="nobr"><a href="http://hl7.org/fhir/extension-iso21090-en-use.html" class="external-link" rel="nofollow">http://hl7.org/fhir/extension-iso21090-en-use.html<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>Es bleibt unklar, wozu die Extension benötigt wird...
-
-
-
Key
-
IM1X0-331
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Unterschied mir nicht klar
-
Beschreibung
-
Ich sehe gerade nicht wirklich einen Unterschied zu <span class="nobr"><a href="https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Practitioner" class="external-link" rel="nofollow">https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Practitioner<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>. Vielleicht könnte dieser besser herausgearbeitet werden oder die beiden Profile miteinander verschmolzen.
-
-
-
Key
-
IM1X0-330
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints
-
Beschreibung
-
Hier könnte es sinnvoll sein, das active bei einem Practitioner zu belassen: Impfpässe enthalten oftmals Informationen, die älter sind. In der Zwischenzeit können sich ärztliche Personen aus dem Berufsleben zurückziehen. Vor diesem Hintergrund kann es im Zuge der Kontaktaufnahme relevant sein, dies zu hinterlegen. Auch könnte es für die Anrede der Person relevant sein, das Geschlecht zu hinterlegen (gerade vor dem Hintergrund der immer internationaler werdenden Vornamen) und für die Telekommunikation zu wissen, welches Medium bedient wird.
-
-
-
Key
-
IM1X0-329
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints
-
Beschreibung
-
Auch hier stellt sich mir die Frage, wie sinnvoll es ist, gewissen Informationen auf 0..0 zu constrainen, z.B. gender, telecom, address.
Das gender kann für Röteln relevant sein, da gerade Frauen im gebärfähigen Alter auf einen ausreichenden Impfschutz achten sollten.
Telecom und Address schaden meistens auch eher nicht.
-
-
-
Key
-
IM1X0-328
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints
-
Beschreibung
-
Ich frage mich, warum "active" und "type" sowie "telecom.use" auf 0..0 constraint sind. Diese Informationen können gerade bei dem Bedarf einer Kontaktaufnahme hilfreich sein. Oder werden sie im Zuge der TI-Identitäten nicht mehr benötigt, und diese werden bei den Identifiern hinzugefügt?
-
-
-
Key
-
IM1X0-327
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Simplifier - Dependency
-
Beschreibung
-
Im Simplifier-Projekt fehlt eine Dependency auf die deutschen Basisprofile, daher kommt bei <span class="nobr"><a href="https://simplifier.net/im1x0/kbvprmiovaccinationorganization" class="external-link" rel="nofollow">https://simplifier.net/im1x0/kbvprmiovaccinationorganization<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> die Fehlermeldung, dass diese nicht gefunden werden können.
-
-
-
Key
-
IM1X0-326
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Simplifier - Dependency
-
Beschreibung
-
Im Simplifier-Projekt fehlt eine Dependency auf die deutschen Basisprofile, daher kommt bei <span class="nobr"><a href="https://simplifier.net/im1x0/kbvprmiovaccinationorganization" class="external-link" rel="nofollow">https://simplifier.net/im1x0/kbvprmiovaccinationorganization<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span> die Fehlermeldung, dass diese nicht gefunden werden können.
-
-
-
Key
-
IM1X0-325
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints von u.a. category, language nicht notwendig
-
Beschreibung
-
In meinen Augen ist es nicht erforderlich, language und category auf 0..0 zu constrainen. Während ich bei anderen Fällen einsehe, dass die Informationen im Zuge des Impfpasses weggelassen werden können (z.B. value, method oder specimen, die ansonsten in diesem Kotext hochrelevant wären), sehe ich bei language und category keinen zwingenden Mehrwert, es wegzulassen. Die Sprache kann niemals schaden, und die category auf laboratory zu setzen, wenn es sich um einen Laborwert handelt, kann die weitere Verarbeitung und somit die Interoperabilität unterstützen.
-
-
-
Key
-
IM1X0-324
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints von u.a. category, language nicht notwendig
-
Beschreibung
-
In meinen Augen ist das Constrainen von language, category oder severity nicht zwingend erforderlich. Diese Informationen stören nicht, wenn sie nicht da sind.
-
-
-
Key
-
IM1X0-323
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Teilweise angenommen
-
Zusammenfassung
-
In der Description das Wort "übersetzen"
-
Beschreibung
-
Ich würde die description ändern. Da wir keine SNOMED-Lizenz haben, dürfen wir SNOMED nicht übersetzen, daher sollte hier eine rechtlich unbedenklichere Formulierung angedacht werden.
Außerdem sind ConceptMaps dazu gedacht, zwei unterschiedliche Systeme zu mappen, nicht dazu, Übersetzungen zu erstellen. Dazu gibt es CodeSystems mit content = supplement.
Dieser Kommentar bezieht sich auf alle ConceptMaps mit Quelle oder Ziel SNOMED CT.
-
-
-
Key
-
IM1X0-322
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mathias Aschhoff
-
Organisation
-
HL7 Deutschland e.V.
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Basisprofile
-
Beschreibung
-
Dieser Patient unterscheidet sich stark vom Basispatient.
Wird dieser oder der Patient aus den Basisprofilen entsprechend angepasst?
-
-
-
Key
-
IM1X0-321
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
ConceptMap kann nicht gerendert werden
-
Beschreibung
-
Ich weiß nicht, ob s am Profil liegt oder an Simplifier, aber die Ressource kann nicht gerendert werden.
-
-
-
Key
-
IM1X0-320
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
0..0-Constraints von u.a. category, language und confidentiality nicht notwendig
-
Beschreibung
-
In meinen Augen ist es nicht notwendig, einige der Punkte auf 0..0 zu constrainen. Statt dessen kann man an einigen Stellen einen fixen Wert vorschreiben.
Zu diesen Stellen gehören:- language: Hier könnte DE fest gesetzt sein, um klarzustellen, dass das Dokument in deutsch geschrieben sein soll
- category: Hier könnte der LOINC-Code 11369-6 - History of Immunization genutzt werden, um die Kategorie festzulegen.
- Die Confidentiality: Sofern nicht anders festgelegt, könnte hier z.B. "normal" stehen.
- section.title, section.text: In meinen Augen stört es nicht, wenn da etwas steht. Man muss es ja nicht verpflichtend machen.
-
-
-
Key
-
IM1X0-319
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mathias Aschhoff
-
Organisation
-
HL7 Deutschland e.V.
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Lob!
-
Beschreibung
-
Verwendung von IHE IC!
-
-
-
Key
-
IM1X0-318
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
NullFlavor bei vaccineCode
-
Beschreibung
-
Welcher Vorteil ergibt sich durch die Verwendung einer NullFlavor-Extension für vaccineCode gegenüber der Lösung, schlicht ein entsprechendes Coding zu erlauben?
-
-
-
Key
-
IM1X0-317
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mathias Aschhoff
-
Organisation
-
HL7 Deutschland e.V.
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
"durchgemachten"
-
Beschreibung
-
Anderes Wort wie erlebten, erfahrenen, überstandenen wäre treffender
-
-
-
Key
-
IM1X0-316
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mathias Aschhoff
-
Organisation
-
HL7 Deutschland e.V.
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ICD Codes?
-
Beschreibung
-
Die im ValueSet vorgesehenen Krankenheiten ließen sich auch über ICD abbilden.
-
-
-
Key
-
IM1X0-315
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Provenance erlaubt keine zusätzlichen Infos
-
Beschreibung
-
Da alle für das MIO nicht benötigten Komponenten von Provenance auf 0..0 constrained sind, können die Implementierer dort keine Informationen unterbringen, die z.B. für ein sinnvolles Debugging erforderlich sind, z.B. mit 'entity' auf Datenquellen verweisen oder durch die Angabe multipler 'agents' (derzeit nur 1..1 erlaubt) verschiedene Softwarekomponenten benennen, die bei der Erzeugung des Datensatzes beteiligt waren. Eigentlich sollte hier gelten: Je mehr Information, desto besser!
-
-
-
Key
-
IM1X0-314
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Provenance erlaubt nur Conditions als target
-
Beschreibung
-
Dies widerspricht der Formulierung "Ressourcen, die in diesem Projekt spezifiziert worden sind,". Ich nehme an, target soll auf alle Bestandteile des MIOs zeigen können...
-
-
-
Key
-
IM1X0-313
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
Package Dependency auf Basisprofile R4 fehlt
-
Beschreibung
-
Dem Simplifier Projekt fehlt die Deklaration einer Dependency auf die Basisprofile R4
(<span class="nobr"><a href="https://simplifier.net/Basisprofil-DE-R4/~packages" class="external-link" rel="nofollow">https://simplifier.net/Basisprofil-DE-R4/~packages<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>), daher können die Referenzen nicht aufgelöst werden...Wird vermutlich erst hinzugefügt, wenn die Basisprofile ballotiert wurden...
-
-
-
Key
-
IM1X0-312
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Später umsetzen
-
Zusammenfassung
-
SNOMED verpflichtend?
-
Beschreibung
-
Der Slice für das SNOMED coding ist 1..1 und MustSupport!
Ist das Absicht?...soll jetzt kein negativer Kommentar sein, ich frag nur. Wegen Lizenz und so...
-
-
-
Key
-
IM1X0-311
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
Gefyra GmbH
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Templates von CodeSystem und ConceptMap verwechselt...?
-
Beschreibung
-
Sieht so aus, als wären hier die Templates von CodeSystem und ConceptMap vertauscht worden. Die Überschriften "KURZBESCHREIBUNG - CODES ZUR ÜBERSETZUNG von..." gehören zu den ConceptMaps...
Wohingegen die Überschriften "KURZBESCHREIBUNG - CODES FÜR..." bei den ConceptMaps besser zu den CodeSystemen passen würden
-
-
-
Key
-
IM1X0-309
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ValueSet nicht definiert
-
Beschreibung
-
Das gebundene ValueSet enthält nur einen DUMMY-Code: <span class="nobr"><a href="https://simplifier.net/im1x0/KBVVSMIOVaccinationAgeGroups" class="external-link" rel="nofollow">https://simplifier.net/im1x0/KBVVSMIOVaccinationAgeGroups<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-307
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Extension eventuell nicht erforderlich
-
Beschreibung
-
Könnte man das nicht als protocolApplied abbilden?
Definition: "The protocol (set of recommendations) being followed by the provider who administered the dose."siehe: <span class="nobr"><a href="http://hl7.org/fhir/immunization-definitions.html#Immunization.protocolApplied" class="external-link" rel="nofollow">http://hl7.org/fhir/immunization-definitions.html#Immunization.protocolApplied<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
also so:
...
<protocolApplied>
<series value="Grundimpfung"/>
</protocolApplied>
-
-
-
Key
-
IM1X0-305
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Datentyp code für mode besser geeignet als CodeableConcept
-
Beschreibung
-
Die Verwendung des Datentyps CodeableConcept macht die mode-Extension unnötig kompliziert.
Da das Binding ohnehin fest vorgeschrieben ist (system=fixed), keine alternativen codings erlaubt sind (coding 1..1) und der code sprechend ist ("legal"), liefert die Verwendung von CodeableConcept hier keinen Vorteil.Der primitive Datentype "code" wäre hier funktionell gleichwertig und wesentlich einfacher.
-
-
-
Key
-
IM1X0-304
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Lösung
-
Vollständig angenommen
-
Zusammenfassung
-
Grammatik nicht ganz korrekt
-
Beschreibung
-
"Die ärztlich tätige Person"
"hat" => ersetzen durch "ist"
", wenn der Verdacht einer gesundheitlichen Schädigung besteht, die über das übliche Ausmaß einer Impfreaktion hinaus geht "
Komma ergänzen
" verpflichtet, den Verdacht dem zuständigen Gesundheitsamt namentlich zu melden (§ 6 Absatz 1 Nr 3 des lnfektionsschutzgesetzes • lfSG)"
Punkt ergänzen.
-
-
-
Key
-
IM1X0-303
-
Erstellt
-
21.01.2020
-
Portallink
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ADDITIONAL_COMMENT sollte den Datentyp Annotation verwenden
-
Beschreibung
-
Dieser erlaubt <strong>optiononal</strong> zusätzlich
- den Autor des Kommentars namentlich zu nennen
- den Zeitpunkt des Kommentars zu dokumentieren
- den Kommentar mittels Markdown zu strukturieren
siehe <span class="nobr"><a href="http://hl7.org/fhir/datatypes.html#Annotation" class="external-link" rel="nofollow">http://hl7.org/fhir/datatypes.html#Annotation<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>
-
-
-
Key
-
IM1X0-299
-
Erstellt
-
17.01.2020
-
Portallink
-
Name
-
Herbert Grundhewer
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Angabe eines Folgedatums obligatorisch
-
Beschreibung
-
Bei einer erfolgten Impfung X muss obligatorisch ein nächstes Impfdatum (kann sich auch auf andere Impfungen beziehen) angegeben werden, das Feld darf praktisch nie leer sein. Die Karte sollte dann beim Aufruf erinnern, wenn das Datum überschritten wurde.
-
-
-
Key
-
IM1X0-298
-
Erstellt
-
17.01.2020
-
Portallink
-
Name
-
Herbert Grundhewer
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Orientierung an STIKO-Vorgaben
-
Beschreibung
-
Hier wäre zu diskutieren, ob einige Vorgaben der STIKO mit einfliessen sollten: wichtig wäre zB der frühestmögliche Impfbeginn. So sollten Personen, bei denen dieser Zeitpunkt überschritten ist, automatisch eine Impferinnerung erhalten, zB beim Aufruf des Ausweises in der Praxis o.a. Das wäre also die 8. Lebenswoche, der 11. Lebensmonat und der 9. Geburtstag.
Insgesamt soll dieser Ausweis ja die Beteiligung verbessern, bei Aufruf muss also ein Hinweis auf fehlende Impfungen und auf noch nicht durchgeführte erscheinen.
-
-
-
Key
-
IM1X0-297
-
Erstellt
-
17.01.2020
-
Portallink
-
Name
-
Herbert Grundhewer
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Eintrag auch in Praxis-EDV
-
Beschreibung
-
Beim Eintrag einer Impfung in den e-Pass muss diese auch automatisch in die Praxis-EDV übertragen werden, um Doppelarbeit zu vermeiden.
-
-
-
Key
-
IM1X0-296
-
Erstellt
-
17.01.2020
-
Portallink
-
Name
-
Herbert Grundhewer
-
Organisation
-
BVKJ
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Nachtrag einfach
-
Beschreibung
-
Das Nachtragen muss möglichst einfach sein, da es meist händisch vorgenommen werden muss. Auch muss es möglich sein, bestehende Impf-Daten aus Praxis-EDV-Systemen direkt in den elektronischen Impfpass zu übernehmen.
-
-
-
Key
-
IM1X0-295
-
Erstellt
-
16.01.2020
-
Portallink
-
Name
-
Wolfgang Schneider-Rathert
-
Organisation
-
Sprecher AK Impfen der DEGAM
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
Akzeptanz eImpfpass erhöhen durch zeitsparende Dokumentation
-
Beschreibung
-
Alle relevanten Daten zum Impfstoff (Handelsname, Dosis (Kinder/Erwachsene), Zielerkrankung und Chargennummer) können mit dem mittlerweile weit verbreiteten BMP-Scanner direkt von der Impfspritze (Fehlervermeidung!) ins System übernommen werden.
-
-
-
Key
-
IM1X0-294
-
Erstellt
-
16.01.2020
-
Portallink
-
Name
-
Wolfgang Schneider-Rathert
-
Organisation
-
Arbeitskreissprecher Impfen Deutsche Gesellschaft für Allgemeinmedizin
-
Lösung
-
Keine Spezifikationsänderung
-
Zusammenfassung
-
ID Nr. statt Passnummer?
-
Beschreibung
-
Wäre die lebenslang bereits bei Geburt unveränderlich zugeteilte 11-stellige ID-Nummer nicht sinnvoller?
-
