Stream: german (d-a-ch)
Topic: Extension in DocumentReference für beteiligte Personen
Heiko Lemke (Oct 18 2017 at 15:34):
Hallo FHIR-Experten,
ich habe die Herausforderung, in einer DocumentReference (Suche/Abfrage von archivierten Dokumenten) auch einige Personen(Ärtze, med. Personal) mitzugeben, die bei einer HL7v2 MDM Message in den Feldern TXA-5,TXA-9,TXA-11 (ggf. weitere) übertragen werden. In der Ressource DocumentReference gibt es aber nur die Elemente "author" (was TXA-9 entsprechen würde) und "authenticator".
Wir nehmen an, dass wir dafür eine Extension benötigen würden mit einem Attrut "role" und einem referenzierten Personen (Practioner?) Objekt benötigen.
Kann jemand sagen, wie so eine Extension im XML-Schema korrekt aussehen würde oder gibt es eine bessere Lösung?
Vielen Dank im voraus!
Simone Heckmann (Oct 18 2017 at 17:08):
Für alle zum mitdenken: hier die Spezifikation aus V2 für das TXA-Segment:
pasted image
Stefan Lang (Oct 18 2017 at 17:10):
Erster Aufschlag: ein separates Attribut für die Rolle würde mindestens eine komplexe Extension benötigen.
Bei einer begrenzten Anzahl Rollen (hier: 2, für TXA-5 und TXA-11) wäre es wahrscheinlich sinnvoller, für jede Rolle eine eigene Extension zu definieren.
Extensions werden als StructureDefinition profiliert. Ein analoges Beispiel findet sich hier:
https://www.hl7.org/fhir/extension-medicationstatement-prescriber.html
Stefan Lang (Oct 18 2017 at 17:12):
Darauf aufbauend müssen also zwei Namen (aka URLs) für "Verantwortlicher" und "Schreibkraft" definiert werden.
Diese Extensions sollte dann in einem Profil auf DocumentReference verwendet werden.
Simone Heckmann (Oct 18 2017 at 17:13):
TXA.#10 würde ich als DocumentReference.agent mit DocumentReference.agent.type= TRANS ("An entity entering the data into the originating system. This includes the transcriptionist for dictated text transcribed into electronic form.") sehen und DocumentReference.agent.who.reference = Link auf eine RelatedPerson, wobei in den meisten Fällen vermutlich eine logische Referenz mit identifier/display ausreichen würde.
Stefan Lang (Oct 18 2017 at 17:13):
Die Einbindung von Extensions in Profile kann man sich exemplarisch hier abschauen:
https://simplifier.net/BasisprofilDE/humanname-de-basis/~xml (ganz unten, im Bereich "<differential>")
Simone Heckmann (Oct 18 2017 at 17:14):
@Heiko: Hast du eine Beispiel-Nachricht, an Hand derer wir das durch-excerzieren könnten?
Stefan Lang (Oct 18 2017 at 17:15):
Und es wäre zu recherchieren, ob da möglicherweise schon mal jemand das analoge Mapping gemacht hat.
Das ist ja keine D-spezifische Fragestellung.
Simone Heckmann (Oct 18 2017 at 17:15):
TXA.#9 wird ja im V2-Mapping schon auf agent gemapped: http://build.fhir.org/documentreference-mappings.html#v2
Stefan Lang (Oct 18 2017 at 17:16):
@Simone Heckmann Daher geht es wohl auch nur noch um TXA-5 und TXA-11
Stefan Lang (Oct 18 2017 at 17:24):
@Heiko Lemke Ergänzend/allgemein: XML-Schema wird im FHIR-Kontext eigentlich nicht verwendet. Dafür verwendet man StructureDefinition, mit dem man Profile auf Ressourcen und auf Datentypen definiert, sowie Extension zur Definition von (sic!) Extensions.
Alles andere macht der FHIR-Server.
Stefan Lang (Oct 18 2017 at 17:26):
Hilfreiches Tool zum Profilieren: https://simplifier.net/Forge
Extensions muss man derzeit von Hand schreiben, aber das ist ja überschaubar.
Simone Heckmann (Oct 18 2017 at 17:27):
TXA.#5 ist ja eigentlich gar kein Attribut des Dokumentes, sondern der Maßnahme, die dieses Dokument hervorgebracht hat.
Da würde ich davon ausgehen, dass abhängig vom konkreten UseCase, das Profil die Verwendung von context.related genauer spezifiziert.
Beispiel: In einem Profil für "Befundbrief" würde context.related auf eine Procedure oder Observation verweisen (http://build.fhir.org/servicerequest.html)
Der PrimaryActivityProvider wäre dann Procedure.performer oder Observation.performer
Simone Heckmann (Oct 18 2017 at 17:29):
@Stefan Lang Extensions kann man mit Forge bauen:
pasted image
Eigentlich muss man nur die Metadaten ausfüllen (eindeutige URL, wer/was/wann/wieso) und die Kardinalität und den Datentyp der Extension festlegen.
Simone Heckmann (Oct 18 2017 at 17:30):
Dessen ungeachtet bin ich aber noch nicht überzeugt, dass man hier überhaupt eine Extension benötigt.
Stefan Lang (Oct 18 2017 at 17:32):
ad TXA-5: Sofern diese Informationen (also die Procedure oder Observation) bekannt sind: d'accord.
Ob sie das im Kontext von Dokumentenmanagement immer sind, würde ich bezweifeln. Und eine blanke Procedure/Observation mit einzigem Inhalt Performer wäre ziemlich suboptimal.
Stefan Lang (Oct 18 2017 at 17:33):
ad Forge/Extension: hoppla, das habe ich wohl bisher immer ignoriert ;-)
Simone Heckmann (Oct 18 2017 at 17:34):
Dann würde ich aber eher noch das extensible(!) ValueSet für ParticipationRoleType extenden, als die Resource....
Simone Heckmann (Oct 18 2017 at 17:42):
Die Erweiterung des Standard-ValueSets um einen geeigneten Code für TXA.#5 wäre mir sogar einen ChangeRequest wert. Das Argument, dass man's für das Mapping von TXA.#5 braucht, sollte genügen. Du hast recht: Procedure/Observation-Resourcen erzeugen wird in den meisten Fällen nicht funktionieren, da diese Pflichtfelder haben (status/code), die man mit den Infos aus TXA nicht bedienen kann.
Simone Heckmann (Oct 18 2017 at 17:44):
Oh ja! Wichtiger Hinweis: DocumentReference wurde seit STU3 nochmal geändert.
Die "current" Version hat das "agent"-Attribut, das es in STU3 noch nicht gab:http://build.fhir.org/documentreference.html
Stefan Lang (Oct 18 2017 at 17:44):
Und ParticipationRoleType extended macht sicher mehr Sinn als Extensions. Hatte sich mir nur entzogen, da ich auf STU3 geschaut hatte und DocumentReference.agent dort noch nicht existiert.
Stefan Lang (Oct 18 2017 at 17:45):
Genau
Simone Heckmann (Oct 18 2017 at 17:45):
Das Manko ist wohl anderen vor uns schon aufgefallen :-)
Simone Heckmann (Oct 18 2017 at 17:46):
Ich muss aber auch gestehen, dass mir "im echten Leben" noch nicht viele MDM-Nachrichten untergekommen sind, bei denen in TXA.#5 etwas drin stand :)
Stefan Lang (Oct 18 2017 at 17:47):
Eventuell fehlt der Code deswegen im ValueSet?
Simone Heckmann (Oct 18 2017 at 17:49):
Ich kann mir auch gerade nur schwer ein Szenario vorstellen, unter dem der Autor des Dokumentes nicht auch der für die Maßnahme Verantwortliche ist.
Stefan Lang (Oct 18 2017 at 17:50):
Im Prinzip ja - ich denke, da wäre es nochmal sinnvoll, den Use Case zu kennen @Heiko Lemke
Stefan Lang (Oct 18 2017 at 17:51):
Also, zusammenfassend aktueller Diskussionsstand (auf Basis FHIR current Build):
- Change Request in den Standard packen, um TXA-5 abbilden zu können
- bei Dringlichkeit (oder Ablehnung des Change Requests) vorher selbst ein erweitertes ValueSet erstellen
- entsprechendes Profil auf DocumentReferece definieren
Simone Heckmann (Oct 18 2017 at 17:52):
Soweit ich weiß, orientiert sich DocumentReference recht eng an den Metadaten von IHE XDS. Daher liegt die Vermutung nahe, dass es auch dort schon kein Äquivalent für TXA.#5 gibt. Aber da lasse ich mich gerne widerlegen...
Heiko Lemke (Oct 18 2017 at 19:33):
Vielen Dank erstmal für die intensiven Überlegungen zu dem Thema. Also das TXA-5 ist vielleicht erstmal nicht ganz so wichtig, da es ggf. etwas missbräuchlich verwendet wird (soll eigentlich den letzten Bearbeiter des Dokuments benennen). Wichtig ist das TXA-11. Was wäre nun hierfür der Vorschlag? Ein Attribut DocumentReference.agent gibt es ja in STU3 nicht. Wie könnte eine äquivalente Extension dazu aussehen?
(BTW: für TXA-10 würde wohl DocumentReference.authenticator passen, oder?)
Simone Heckmann (Oct 18 2017 at 22:16):
Geht es um eine Implementierung die vor der Veröffentlichung von R4 (Ende 2018) in Produktion gehen soll?
Thorsten Conrad (Oct 19 2017 at 09:06):
Hallo zusammen,
das IHE MHD Profil definiert ja eigentlich was wie zu mappen ist.
Die Maßnahme aus TXA-5 ist laut Profil in DocumentReference.context.event zu kodieren. Da kann man auch noch TXA-4 ablegen.
Der Autor aus TXA-9 sollte in DocumentReference.author und die verantwortliche Person aus TXA-10 soll als "Contained Resource" in DocumentReference.authenticator hinterlegt werden.
Die Schreibkraft aus TXA-11 wird unterschlagen oder kann als "RelatedPerson" ebenfalls in DocumentReference.author abgelegt werden.
Wir haben alle aber ein Problem, das die Rolle des Autors in STU3 "optimiert" wurde und John Moehrke hatte dazu am 2017-04-26 das Ticket #13266 angelegt.
Gruß,
Thorsten
Simone Heckmann (Oct 19 2017 at 14:37):
Hallo, @Thorsten Conrad
Danke für den Hinweis auf MHD!
Der Code der Maßnahme kann in Document.reference.context.event codiert werden, (und der Zeitpunkt der Maßnahme (TXA.#4) in context.period.
D'accord.
Aber zu TXA.#5 (Verantwortlicher der Maßnahme) finde ich in MHD keinen Hinweis.
Schreibkraft als "author" zu modellieren halte ich für keine gute Idee, da man dann den tatsächlichen Autor und die Schreibkraft nicht unterscheiden könnte!
Die "Optimierung" im current build, mit der Einführung des "agent" mit type unf who.reference löst jedoch unsere Probleme.
Thorsten Conrad (Oct 19 2017 at 16:04):
Mhmm. Danke für die Info. Was habe ich denn da wieder gelesen?
Also, nochmal:
OBR-4 -> DocumentReference.context.event
TXA-4 oder OBR-7/OBR-8 -> DocumentReference.context.period
TXA-9 -> DocumentReference.author
TXA-10 oder TXA-22 -> DocumentReference.authenticator
Die Schreibkraft als RelatedPerson zu hinterlegen geht tatsächlich nicht, da diese einen Bezug zum Patienten haben muss.
Erst ab R4 geht es mit agent.type. Dann kann man auch wieder die Rolle des Autors hinterlegen.
Simone Heckmann (Oct 21 2017 at 19:58):
Hallo,
da ich gerade zufällig den richtigen Knopf für komplexe Extensions bei Forge gefunden habe, habe ich mal die agent-ersatz-extension zusammen-
und dann auf Simplifier in meine Sandbox geworfen: https://simplifier.net/Sandbox/agent
Kann man natürlich noch schöner machen ... Referenzen auf die konkreten Resourcentypen begrenzen usw.
Simone Heckmann (Oct 21 2017 at 20:06):
...und das DocumentReference-Profil mit der Extension: https://simplifier.net/Sandbox/document-reference-with-agent
Simone Heckmann (Oct 21 2017 at 20:18):
Das würde in der Instanz dann so aussehen:
STU3 mit Extension:
<extension url="http://gefyra.de/StructureDefinition/agent"> <extension url="type"> <coding> <system value="http://hl7.org/fhir/v3/ParticipationType"/> <code value="AUT"/> <display value="author (originator)"/> </coding> </extension> <extension url="who"> <reference value="Practitioner/xcda1"/> </extension> </extension>
R4 mit backbone-element "agent":
<agent> <type> <coding> <system value="http://hl7.org/fhir/v3/ParticipationType"/> <code value="AUT"/> <display value="author (originator)"/> </coding> </type> <who> <reference value="Practitioner/xcda1"/> </who> </agent>
Simone Heckmann (Oct 21 2017 at 20:20):
Die Frage wäre, ob wir das in die Basisprofile mit aufnehmen wollen...
Simone Heckmann (Oct 21 2017 at 21:01):
Politisch betrachtet wäre es natürlich zielführender, das Attribut (wenn es nicht gerade kriegsentscheident ist) vor R4 gar nicht zu implementieren und dem Kunden/Auftraggeber statt dessen R4 als Mohrrübe vor die Nase zu hängen. Wenn R4 neue/zusätzliche Funktionen bringt, ist es sicher leichter, die erforderlichen Resourcen (hic: Zeit + Geld) zu bekommen, um die Implementierung auf R4 zu aktualisieren.
Wenn hingegen die Funktionen in STU3 schon alle implementiert sind, wird man bei der Frage nach den Mitteln für das Update erfahrungsgemäß mit "Wieso? Es funktioniert doch!" abgespeist - auf Kosten der Interoperabilität.
Aber wenn die Extension implementiert wird, dann besser deutschlandweit einheitlich, als jeder mit einer eigenen Extension.
Daher wäre mein Vorschlag, die Extensions und das Profil in unseren Leitfaden aufzunehmen, jedoch zum Stichtag des R4 Releases auf "deprecated" zu setzen.
Heiko Lemke (Oct 23 2017 at 08:46):
Hallo Simone, super, dass Du das gemacht hast. Aber kannst Du noch einen Hinweis "zum richtigen Knopf für komplexe Extensions" geben? Ich habe das selbst auch rudimentär versucht. Nach dem Abspeichern hat Forge das ganze aber nicht mehr richtig darstellen können.
Simone Heckmann (Oct 23 2017 at 15:14):
pasted image
ich habe das mit Add > Add a complex extension gemacht. Ich kann die Datei so auch wieder öffnen.
Aber Forge ist - wie alle FHIR-Tools beta, daher kann es schon mal sein, dass nicht alles so einwandfrei funktioniert, wie man das gerne hätte ;-)
Simone Heckmann (Oct 30 2017 at 10:38):
Also, da sich bisher niemand dagegen gewehrt hat, würde ich dieser Extension nun eine http://fhir.de/-url verpassen und sie in das Basisprofil aufnehmen, mit Verfallsdatum Ende 2018....
Simone Heckmann (Nov 07 2017 at 09:37):
https://simplifier.net/BasisprofilDE/agent
ping @Heiko Lemke
Heiko Lemke (Nov 07 2017 at 21:30):
Die Extension ist für meinen Zweck gut nutzbar.
Eine Frage zum who-value: Sollte der nicht besser als Extension.extension:who.valueReference definiert sein (derzeit Extension.extension:who.value[x]:valueReference)?
Simone Heckmann (Nov 07 2017 at 21:42):
Auf Simplifier stimmt's:
pasted image
Simone Heckmann (Nov 07 2017 at 21:43):
Allerdings ist mir heute morgen schon aufgefallen, dass beim Download+ Import nach Forge dann ein value[x] draus wird, daher:
https://chat.fhir.org/#narrow/stream/conformance/topic/Forge.3A.20Reference.20to.20a.20set.20of.20Resources
Last updated: Apr 12 2022 at 19:14 UTC
