Stream: german (d-a-ch)
Topic: E-Rezept
Gollenbeck (Oct 13 2020 at 12:09):
Guten Tag , gibt es hier jemand welcher sich mit den Signaturen in den unterschiedlichen Objekten Verordnung, Quittungsdatensatz etc. auskennt in Bezug auf FHIR Formaten ?
Simone Heckmann (Oct 13 2020 at 12:38):
@Hendrik J. ...?
Hendrik Jablonski (Jan 18 2021 at 15:55):
Hallo DACH-Community. Ich habe mal zwei Anliegen für unsere Spezifikationen zum E-Rezept.
-
Wir brauchen einen Exit aus der E-Rezept-App, um auf den Warenkorb einer Apotheke mit Versandoption verlinken zu können. Das betrifft nicht nur, aber auch Versandapotheken mit eigener App. Wir dachten da an eine URL mit reichlich Entropie auf einen Warenkorb, der anschließend in einer separaten App oder auch einem Online-Portal geöffnet werden kann. Meine Frage, kann man diese URL in Communication.instantiatesUri transportieren? Eine sinngemäße Übersetzung der Definition dieses Felds verweist auf ein ORDERSET das von dieser Bestell-Communication ADHERED ist... Wie ist eure Meinung, passt das oder eher ist das fachlich zu weit weg?
-
Die E-Rezept-App soll in einem Apothekenverzeichnis nach "relevanten" Apotheken im Umkreis des Users suchen. Zusätzliche, verschiedene Filteroptionen sind alle sinnvoll aber die initiale Abfrage könnte fast immer lauten:
"Gib mir alle Organizations, deren Location in einem 5km-Radius liegen und deren HealthcareService einen Notdienst bereitstellt."
Das hab ich mit meinen bescheidenen FHIR-Kenntnissen mal versucht in eine Abfrage zu verfassen, die aber nicht richtig funktioniert:
http://hapi.fhir.org/baseR4/Organization?_revinclude=Location:organization.near=52.454755|13.394500|5|km&_revinclude=HealthcareService:organization.service-type=http://terminology.hl7.org/CodeSystem/service-type|117
Was mache ich hier falsch?
René Spronk (Jan 18 2021 at 16:48):
on a _(rev)include one can't specify any conditionalities. That only works on _has , and on the standard parameters that apply to the focal resource of your search. GET HealthcareService?location.near=xxx&organization.type=zzz&_include=HealthcareService.organization may do the trick, filter the result bundle for organizations. Does your server support 'near' ? Seems complex in its implementation, so servers may not support it.
Hendrik Jablonski (Jan 19 2021 at 07:46):
Thanks Rene, very helpful answer. For the moment we go with a HAPI standard server, that does support "near"-search. For productie use we are still examing.
So, for my Organization-Search I need to query that resource with most significant (difficult = token)-search and make use of both references to Location and Organization. In my sample data I only used references pointing to the Organization. I will have a try, thanks for now.
Hendrik Jablonski (Jan 19 2021 at 14:25):
Once again, great help Rene, thanks a lot.
I gave it a try with the HAPI reference system and some sample data: http://hapi.fhir.org/baseR5/HealthcareService?location.near=52.50892873|13.371629331|3|km&service-type=http://terminology.hl7.org/CodeSystem/service-type|117&_include=HealthcareService:organization
My problem was asking to "give me all Organizations that have a Location nearby and also a HealthcareService of special type".
I see the point asking directly for "some special HealthcareServices nearby and please include the Organization".
I love this FHIR Community.
Hendrik Jablonski (Jan 20 2021 at 15:32):
does anyone have an idea for my other question regarding: Communication.instantiatesUri ?
We want to communicate a shopping cart-URL to a client. Is instantiatesUri the appropriate field?
Simone Heckmann (Jan 20 2021 at 15:38):
Meine Tendenz wäre hier eher Communication.payload.contentAttachment.url
Die URL ist ja der Inhalt, der hier kommuniziert werden soll...
Simone Heckmann (Jan 20 2021 at 15:41):
Communication.instantiatesURI bedeutet nach meiner Interpretation eher „wir senden diese Nachricht, weil das verlinkte Protokoll das so vorschreibt“, speziell bei automatisch versendeten Nachrichten....
Hendrik Jablonski (Jan 21 2021 at 15:49):
Danke @Simone Heckmann klingt super.
Thomas Zacher (Apr 08 2021 at 13:53):
https://simplifier.net/erezept-workflow/gemerxcommunicationinforeq
Communication.about referenziert das Medikationsprofil. Aber warum ist es möglich, Communication.about mehrmals einzufügen? Jede Verordnung enthält doch nur eine Medikation? Und nach meinem Verständnis macht es auch nur Sinn, wenn in Communication auf eine Medikation referenziert wird, weil Communication.payload auch nur einmal eingefügt werden kann. Sonst würden sich die payload-Infos auf alle about-Medikationen beziehen. Die Frage lautet also, warum kann about mehrfach eingefügt werden?
Danke euch!
Johannes Höhn (Apr 08 2021 at 14:35):
Ich kann zwar zu dem Problem leider nichts beitragen, möchte aber ein bisschen Verwirrung durch die Terminologie vorbeugen: Ein FHIR Medication-Objekt entspricht einem Medikament, also einem Arzneimittel. Eine Medikation ist eine Behandlung mit einem Medikament und wird in FHIR in einem MedicationStatement abgebildet.
Thomas Zacher (Apr 08 2021 at 14:58):
Vielen Dank für die Klarstellung, Johannes. Ich meinte schon ein FHIR Medication Objekt, das in diesem Kontext ein verschriebenes Arzneimittel repräsentiert. Die Verfügbarkeit (z.B.) dieses Arzneimittels möchte der anfragende Versicherte bei der ausgewählten Apotheke klären. Allerdings enthält eine eRezept-Verordnung nur ein Arzneimittel. Deshalb verstehe ich die 1..* Kardinalität von Communication.about nicht.
Simone Heckmann (Apr 08 2021 at 17:27):
@Theodor Szymkowiak
Frank Oemig (Apr 08 2021 at 19:10):
Elektronisch sollte jedes Medikament ein einzelnes Rezept darstellen. Es gibt aber Ausnahmen, wenn Medikamente nur zusammen abgegeben bzw. eingenommen werden sollen. Deshalb 1..*
Timo Rosenblatt (Apr 09 2021 at 06:39):
Wir müssen also beim Empfang der Anfragen vorsehen, dass eine Anfrage mehrere Artikel beinhalten kann, korrekt?
Simone Heckmann (Apr 09 2021 at 06:49):
IIRC war die Überlegung die, dass der Patient beim einlösen eines Rezeptes eventuell zusätzlich noch ein OTC Medikament benötigt und beides in der selben Apotheke holen will. Folglich soll auch die Verfügbarkeit von mehreren Medikamenten in einer Communication abgefragt werden können.
(bitte bestätigen oder widersprechen, @Theodor Szymkowiak :wink: )
Thomas Zacher (Apr 09 2021 at 10:55):
D.h., dass der Versicherte im FdV mehrere Medikamente (aus verschiedenen eRezepten) für eine Nachricht bündeln kann? Denn wenn ich es richtig verstehe, ist ein OTC Medikament letztlich ja auch nur ein Medikament, das in einem eRezept verordnet wird.
Frank Oemig (Apr 09 2021 at 14:43):
OTC = over the counter, d.h. ohne Rezept?!
Thomas Zacher (Apr 11 2021 at 10:07):
Sehr interessant. Für ein Medikament ohne Rezept gibt es folglich auch kein Task-Objekt, kein Verordnungs-Bundle, etc. D.h. der Versicherte müsste dann im FdV in der Lage sein, ein FHIR Medication-Objekt zu erstellen, um dieses zusätzlich über Communication.about bei einer Anfrage einzubeziehen. Z.B. er gibt einen Text ein und das FdV macht ein Medication_Freetext-Objekt daraus. Oder er wählt aus einer Liste von OTC-Medikamenten aus und das FdV erstellt daraus ein Medication_PZN-Objekt. Dann wird für mich ein Schuh draus. Hab mir die Spec vom FdV nicht angesehen, da müsste das ja drin sein. Klingt aber schwer vorstellbar.
Naja, anyway. Offenbar muss man für irgendeinen exotischen Fall die Möglichkeit mehrerer Medication-Objekte in einer Anfrage einbeziehen, für die dann sinngemäß der gleiche Communication.payload gilt.
Vielen Dank an Euch! :+1:
Timo Rosenblatt (Apr 12 2021 at 05:54):
In Kombination mit bestimmten Rx Fertigarzneimitteln können OTC auch bei der Kasse abgerechnet werden und wären dann auch wieder auf einem Rezept. Ich denke also, dass wir nur von dieser Kombination sprechen, in der es auch ein E-Rezept zu dem OTC FAM gibt.
Theodor Szymkowiak (Apr 12 2021 at 08:53):
Im About soll zurzeit nur das Medikament eingetragen werden, welches im E-Rezept Bundle angegeben ist (siehe gemSpec_eRp_FdV A_19194-2). In Zukunft könnte sich das aber ändern, sodass wir bei der FHIR-Profilierung auf die Kardinatität 1..* setzen. Die Durchsetzung, dass nur ein Medikament angegeben wird erfolgt dann über die Spezifikation und die von uns erstellte App. OTC Medikamente sollen im Payload der Communication als Freitext angegeben werden.
Thomas Zacher (Apr 13 2021 at 06:38):
Vielen Dank für die Klarstellung! :smile:
Frank Oemig (Apr 13 2021 at 08:57):
Frei erhältliche Dokumente, wie bspw. Aspirin, sind in der Dokumentation mitunter zu berücksichtigen. Aktuell ist es aber so, dass jeder Arzt nur "seine" Medikamente berücksichtigt, obwohl ein BMP eigentlich genau das angehen sollte. Insofern ist ein Rezept eine Sache, die Dokumentation eine ganz andere.
Last updated: Apr 12 2022 at 19:14 UTC
