Das Informationsmodell stellt die Inhalte hierarchisch dar.

Das als PDF aufrufbare Bild (bitte anklicken, dann auch auf eine lesbare Größe vergrößerbar) zeigt einen Überblick zum fachlichen Informationsmodell des Impfpasses. Die einzelnen Bestandteile des Informationsmodells werden in den entsprechenden Unterabschnitten separat erläutert und zur Kommentierung gestellt.


Kommentierungen

    • Key

    • IM1X0-652

    • Erstellt

    • 28.02.2020

    • Name

    • Frank Oemig

    • Organisation

    • DTHS

    • Kommentierungsart

    • Inhalt

    • 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

    • Name

    • Sven Lüttmann

    • Organisation

    • VISUS Health IT GmbH

    • Kommentierungsart

    • Technische Repräsentation

    • 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-643

    • Erstellt

    • 27.02.2020

    • Name

    • Sven Lüttmann

    • Organisation

    • VISUS Health IT GmbH

    • Kommentierungsart

    • Technische Repräsentation

    • 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-616

    • Erstellt

    • 27.02.2020

    • Name

    • Ralf Franke

    • Organisation

    • gevko GmbH

    • Kommentierungsart

    • Inhalt

    • Zusammenfassung

    • Ergänzung Immunglobulinen

    • Beschreibung

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

    • Key

    • IM1X0-507

    • Erstellt

    • 25.02.2020

    • Name

    • Tina Olbrich

    • Organisation

    • Element44 GmbH

    • Kommentierungsart

    • Codierung

    • 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-414

    • Erstellt

    • 18.02.2020

    • Name

    • Hans-J. Schrörs

    • Organisation

    • GZIM und Hausarzt

    • Kommentierungsart

    • Inhalt

    • 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-398

    • Erstellt

    • 13.02.2020

    • Name

    • Frank Oemig

    • Organisation

    • DTHS

    • Kommentierungsart

    • Inhalt

    • 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-396

    • Erstellt

    • 13.02.2020

    • Name

    • Christoph Wilhelm

    • Organisation

    • Bundesministerium für Gesundheit

    • Kommentierungsart

    • Inhalt

    • 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-393

    • Erstellt

    • 12.02.2020

    • Name

    • Christoph Bornhöft

    • Organisation

    • BVKJ

    • Kommentierungsart

    • Inhalt

    • 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-370

    • Erstellt

    • 10.02.2020

    • Name

    • Frank Oemig

    • Organisation

    • DTHS

    • Kommentierungsart

    • Redaktionell

    • 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-368

    • Erstellt

    • 10.02.2020

    • Name

    • Frank Oemig

    • Organisation

    • DTHS

    • Kommentierungsart

    • Inhalt

    • 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.