In diesem Teilabschnitt wird der grundlegende Impfeintrag definiert.
Kurzbeschreibung:
In diesem Profil werden die grundlegenden Inhalte zum Impfeintrag, also einer Impfzeile definiert. Diese besteht unter Anderem aus dem Impfstoff, dem Impfdatum u.s.w.
Weiterhin ist dieses Profil mit dem Szenario Daten nach- oder übertragen verknüpft und hat daher weniger Zwänge als das Profil Record_Prime.
Bezeichnung der FHIR®-Ressource:
Der FHIR®-Identifikator (StructureDefinition.URL) der FHIR®-Ressource lautet:
https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_Vaccination_Record_Addendum
Übersichtsabbildung des Profils
Kommentierungen
-
-
Key
-
IM1X0-333
-
Erstellt
-
21.01.2020
-
Name
-
Mareike Przysucha
-
Organisation
-
Hochschule Osnabrück
-
Kommentierungsart
-
Inhalt
-
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-318
-
Erstellt
-
21.01.2020
-
Name
-
Simone Heckmann
-
Organisation
-
HL7 DE
-
Kommentierungsart
-
Technische Repräsentation
-
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?
-