Stream: german/mi-initiative
Topic: MII-Reference mii-reference-1 constraint
Christian Gulden (Sep 07 2020 at 15:07):
In der MII-Reference sorgt momentan constraint mii-reference-1 dafür, dass entweder Reference.identifier oder Reference.reference gesetzt sind, nicht jedoch beide.
Was ist die Motivation dahinter?
Es gibt Szenarien in denen ich aus dem Quellsystem beispielsweise nur die Diagnose und die Patientennumer kenne. Intuitiv würde ich dann eine Condition resource erzeugen und Condition.subject.identifier.type auf Medical Record und identifier.value auf diese Patientennummer setzen. Wenn ich diese Resource dann aber auch noch an einen FHIR-Server schicken will, bei dem ich weiß das früher oder später eine Patient-Resource mit dieser Nummer angelegt wird, dann will ich eigentlich eine "saubere" Referenz auf den Patient haben. Dazu kann ich den update-as-create Mechanismus nutzen und diese "saubere" Referenz selber vergeben indem ich Patient.id und Condition.subject.reference auf die selbe technische ID setze. Hier hätte ich also gerne beide Möglichkeiten Referenzen zu definieren.
Workaround: da ich mit der Patientennummer im identifier alle Informationen habe um selber einen "Dummy" Patienten anzulegen könnte man statt nur die Condition zu befüllen immer Bundles mit Condition + Patient (+Encounter) erzeugen. Die Dummy resourcen sind dann (temporär) nicht MII-konform.
Alexander Zautke (Sep 07 2020 at 17:40):
Die Motivation dahinter war, dass wir so sicherstellen können, dass wir möglichst wenig Inkontinenzen ermöglichen. Wir wollten nicht, dass Reference.identifier mit dem Identifier aus dem Target der Referenz auseinander laufen. Dann wüsste der FHIR Server nicht mehr wonach diese Referenz aufgelöst werden sollte. Generell sollte jedoch für alle Use Cases einer der beiden Werte ausreichen (wobei ich immer ein Freund von Reference.identifier bin). Chaining und Suchen sollten (wenn ordentlich implementiert) in beiden Fällen gleich funktionieren.
Christian Gulden (Sep 09 2020 at 12:19):
Alles klar, danke! Ich muss das mit suchen/chaining dann nochmal austesten.
Christian Gulden (Nov 30 2020 at 15:14):
ich habs jetzt nochmal ausgetestet und bin auf
Chaining is not supported when using the :identifier modifier, nor are chaining, includes or reverse includes supported for reference elements that do not have a reference element. (https://www.hl7.org/fhir/search.html#reference)
gestoßen. In dem Server mit dem ich es getestet habe ging das dann auch nicht.
Wir können bei uns als "workaround" bevor die Resourcen an den FHIR-Server geschickt werden die identifier-Referenzen zu logischen Referenzen konvertieren, da wir die Resource.id als Hash über dem identifier berechnen.
Christian Gulden (Dec 04 2020 at 16:34):
Kann man an dem Constraint vielleicht doch nochmal rütteln und sowohl logische als auch literale Referenzen zulassen? Wir haben den Anwendungsfall dass wir auch andere Forschungsrepositories inkrementell beladen wollen, hier "FHIR-unabhängige" Fall- und Patientennummern an jeder Resource zu haben (als logische Referenz) und gleichzeitig in der Lage zu sein mit den selben Resourcen FHIR-Server abfragbar zu beladen wäre ideal. Im besten Fall würden wir uns den Workaround sparen wollen.
Alexander Zautke (Dec 04 2020 at 21:42):
Ja :) Wir haben in der letzten Woche in verschiedenen Kontexten über diesen Constraint diskutiert, ich werde das zeitnah im Kümmererteam ansprechen. Mein Präferenz ist zunehmend aus dem XOR ein OR zumachen, sodass wir Display-Only Referenzen ausschließen.
Alexander Zautke (Dec 17 2020 at 16:11):
Im Meta Package ist es nun gefixt. Siehe Version 1.0.2, dieses Update müssen wir nun in allen anderen Packages nachziehen.
Alexander Zautke (Dec 17 2020 at 16:12):
@Christian Gulden Würde es erstmal ausreichen, wenn wir ein neues Update für das Modul Person veröffentlichen?
Noemi Deppenwiese (Dec 18 2020 at 09:23):
In MIRACUM Erlangen würden wir uns ein neues Labor-Release wünschen mit 1.0.2 Referece-Profil... (Dafür wäre Person erstmal nicht so wichtig)
Christian Gulden (Jan 12 2021 at 14:54):
Alexander Zautke said:
Christian Gulden Würde es erstmal ausreichen, wenn wir ein neues Update für das Modul Person veröffentlichen?
Klingt gut! Es müssten aber doch primär die Profile aktualisiert werden, die noch das alte Profil nutzen bzw. auf einen Patienten/Encounter referenzieren, oder?
Christian Gulden (Jan 12 2021 at 14:57):
BTW, ich bin ein riesen Fan von https://github.com/renovatebot/renovate - da die Paket-Abhängigkeiten in https://github.com/medizininformatik-initiative/kerndatensatzmodul-person/blob/master/package.json standard npm format sind könnte man damit ggf. automatisch PRs erzeugen, wenn sich eines der Abhängigkeiten aktualisiert hat.
Noemi Deppenwiese (Jan 13 2021 at 08:41):
Darf ich mir an dieser Stelle ein Modul Prozedur mit upgedateder Dependency auf Meta wünschen? :)
Alexander Zautke (Jan 19 2021 at 15:37):
Natürlich darfst du das :) Done.
Last updated: Apr 12 2022 at 19:14 UTC
