Stream: german (d-a-ch)
Topic: Sender und Empfänger von Compositions / Bundles in FHIR?
Mareike Przysucha (Jul 22 2021 at 12:53):
Hallo in die Runde.
Ich wurde im Rahmen eines Projekts in Süddeutschland auf Probleme beim ePflegebericht-IG hingewiesen: Sender und Empfänger. Momentan verweisen wir entsprechend der deutschen Basisprofile auf IHE MHD. Gibt es da Sender und Empfänger? Wenn nicht, würde ich die Seite verwerfen, wenn es welche gibt, würde ich die Links entsprechend anpassen.
Hat da jemand Informationen für mich?
Danke im Voraus und herzliche Grüße
Simone Heckmann (Jul 22 2021 at 15:42):
Ich hatte kürzlich ein ähnliches Problem:
Eigentlich sind "Sender/Empfänger" keine Eigenschaft des Dokumentes sondern des Transportes, also in diesem Falle offenbar ein gerichteter Versand. In FHIR wäre das ein MessageBundle. Da können im MessgeHeader solche Dinge wie sender/recipient und auch Datum des Versandes etc. abgebildet werden.
In meinem Fall war es dann aber so, dass der Transport gar nicht per FHIR Messgaging erfolgen sollte, sondern per KIM (wo ja Sender und Empfänger ebenfalls im Transportprotokoll (=eMail) bereits benannt sind). Man wollte aber unbedingt die Info über Sender und Empfänger im Dokument persistiert haben, was wir dann mit Hilfe einer Extension gemacht haben. Wenn das öfter Vorkommen sollte, müssten wir dazu vll. ein bisschen Best Practice formulieren, bzw. abgestimmte Extensions publizieren.
Simone Heckmann (Jul 22 2021 at 16:01):
Es ist ja im Prinzip wie in der Papierwelt: Das Dokument hat lediglich einen Autor, der's unterschreibt. Absender und Empfänger hingegen stehen auf dem Briefkuvert und dienen nur dem Versand, sind aber vom Dokument losgelöst.
Ich schätze, der Bedarf der hier aufkommt entspricht dem eines "Fensterkuverts", wo man den Absender/Empfänger direkt auf's Dokument mit draufschreibt, und für den Versand wiederverwendet.
Dazu gibt's aber meines Wissens in FHIR keine Entsprechung. Das müsste ja irgendein Zwitterwesen aus document- und message-type Bundle sein, in dem sowohl eine Composition als auch ein MessageHeader drinsteckt und der MessageHeader von der Composition referenziert wird, aber das macht mir ehrlich gesagt ein bisschen Angst :fear:
Christof Gessner (Jul 22 2021 at 17:31):
Könnte DocumentManifest helfen? Aber die C-CDA-Kollegen haben sich wohl auch auf eine extension verlegt: http://hl7.org/fhir/us/ccda/STU1/StructureDefinition-CCDA-on-FHIR-Information-Recipient.html
Mareike Przysucha (Jul 22 2021 at 17:32):
Danke für die umfangreiche Information. Ich habe mich unglücklich ausgedrückt.
Ich meine konkret:
informationRecipient, also die Person, für die das Dokument in erster Linie intendiert war. Hier kann die Extension, die @Christof Gessner referenziert hat, genutzt werden.author: Passt nachauthorlegalAuthenticator: Dies kann lt. https://www.hl7.org/FHIR/composition-mappings.html#cda aufattestergemappt werden.
Christof Gessner (Jul 22 2021 at 17:34):
Sorry, Link zur wohl aktuellsten Version hier: http://hl7.org/fhir/us/ccda/StructureDefinition-InformationRecipientExtension.html
Simone Heckmann (Jul 23 2021 at 10:14):
Uff. US-Realm-Extension für ein Standard-CDA-Element :oh_no:
Simone Heckmann (Jul 23 2021 at 10:16):
@Oliver Egger Wie gehst du damit in deinen CDA-> FHIR Mappings um?
Simone Heckmann (Jul 23 2021 at 10:18):
Mareike Przysucha said:
informationRecipient, also die Person, für die das Dokument in erster Linie intendiert war. Hier kann die Extension, die Christof Gessner referenziert hat, genutzt werden.
Leider nicht, da die Reference-Targets a little bit zu spezifisch sind: Reference(US Core Practitioner Profile | US Core PractitionerRole Profile | US Core Patient Profile)
Oliver Egger (Jul 23 2021 at 10:29):
Wir haben äquivalent zu US Core eine CH Core InformationRecipient Extension erstellt: http://fhir.ch/ig/ch-core/StructureDefinition-ch-ext-epr-informationrecipient.html . Habe irgendwo in Erinnerung dass es ein Ticket gab eine Universal Realm Extension zu machen, finde es aber nicht mehr ...
Simone Heckmann (Jul 23 2021 at 13:59):
Oliver Egger said:
Wir haben äquivalent zu US Core eine CH Core InformationRecipient Extension erstellt: http://fhir.ch/ig/ch-core/StructureDefinition-ch-ext-epr-informationrecipient.html . Habe irgendwo in Erinnerung dass es ein Ticket gab eine Universal Realm Extension zu machen, finde es aber nicht mehr ...
Super, danke für die Info. Kannst du mir das Ticket noch nachreichen, falls du es findest? Ich eskaliere das mal an FMG. Irgendwie kann es nicht die Lösung sein, dass jedes Land eine eigene Extension erstellen muss um ein Element aus einer universellen HL7 Spezifikation abzubilden...
Simone Heckmann (Jul 23 2021 at 15:12):
Update: Brett sagt, dass Rick meint, dass SD gendwann gevoted hätte, die Extensions in R5 Core zu portieren... Wir bleiben dran...
Simone Heckmann (Sep 23 2021 at 18:51):
Fundstück der Woche:
IHE-MHD hat eine "intended recipient"-Extension auf einer List Ressource, die das SubmissionSet repräsentiert.
Das SubmissionSet ist Pflicht bei jeder DocumentProvide interaction und muss vom Empfänger auch immer persistiert werden.
Zumindest wenn das dokument also im Kontext von MHD/XDS versendet würde, wäre das Problem gelöst.
ich finde das SubmissionSet ja so überflüssig wie nen Kropf, wenn man davon ausgeht, dass die meisten Dokument einzeln versendet werden
Simone Heckmann (Sep 23 2021 at 18:52):
https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Minimal.SubmissionSet.html
Last updated: Apr 12 2022 at 19:14 UTC
