FHIR®-Ressourcen, Version Benehmensherstellung, Phase II

Der Datenfluss ist nicht transparent dargestellt. Wer ist z.B. Datensender oder -empfänger?

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.

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.

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

Ein Implementierungsguide gemäß FHIR-Richtlinien würde die Spezifikation mit wichtigen Informationen anreichern. Aber dieses ist sicher nach der Kommentierung geplant.

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?