Stream: german (d-a-ch)
Topic: UKF Format Medikationsplan
Patrick Werner (Mar 23 2016 at 09:46):
Ich würde mich gerne auch in das UKF des Medikationsplans einbringen. Gibt es schon fertige Profile für die Ausgangsresourcen? Auf http://wiki.hl7.de/index.php?title=IG:Ultrakurzformat_Patientenbezogener_Medikationsplan wird von Konversionsskripts gesprochen welche aber noch nicht verlinkt sind.
Gibt es schon Kontakt mit der internationalen Community ob das UKF generell verwendet werden soll? Ich würde gerne das Mapping auf das UKF in das Ausgangsprofil mit einbetten, mit Extensions wäre dies aber nur relativ umständlich möglich.
dr Kai U. Heitmann (Mar 24 2016 at 17:37):
Patrick, hervorragend wenn du dich einbringen willst. Die Konversionskripts sind sicher noch verbesserungswürdig, wir sollten hierzu nach oOOoOo telefonieren. Was meist du mit "Kontakt zur internationalen Community"? Das UFK soll sicher nicht generell angewendet werden, wir müssen uns im Klaren sein, dass die Nutzung dieses Formats eher peinlich ist für das ach so digitalisierte Deutschland. Das Mapping folgt meist strikten Regeln, eine "Einbringung" in ein Ausgangsprofil ist wünschenswert (und geht nur über Extensions) aber eben auch eine Herausforderung. Hier muss man abwägen, ob das der effizienteste Weg ist.
Stefan Lang (Mar 25 2016 at 18:27):
Hier im Zulip gibt es diesen Thread: https://chat.fhir.org/#narrow/stream/implementers/topic/Low.20bandwith.20serialisation
Stefan Lang (Mar 25 2016 at 18:29):
Da hatte Simone das Format des Medikationsplans schon einmal reingeworfen. Low Bandwidth/Low Storage gibt es ja nicht nur auf der eGK
Stefan Lang (Mar 25 2016 at 18:33):
Den einen oder anderen (für mich schon relativ konkreten) Anwendungsfall im Device-Bereich sehe ich auch, insofern würde ich mich da auch gern für einen Kontext über den Medikationsplan hinaus einbringen
Simone Heckmann (Mar 29 2016 at 09:39):
Der Standard bringt eigentlich alles mit, was man für unser UKF braucht. Beim erstellen von Profilen kann ich jedem Attribut ein Mapping auf einen anderen Namensraum zuweisen. Alternativ könnte man auch das Feld "Alias" verwenden, um den UKF-Attributsnamen im Profil zu definieren. Allerdings müsste das Komprimierungsskript noch mehr tun, z.B.:
- alle Narratives entfernen
- alle Attribute mit "fixed" values (ebenfalls im Profil festgelegt) entfernen
- alle nicht verwendeten Felder entfernen (im Profil wäre da die Kardinalität auf 0..0 gesetzt)
- und schließlich: die Attributnamen durch die Aliase ersetzen
Meines erachtens lassen sich aber alle anzuwendenden Regeln mit den Mechanismen der Standard-Profile ausdrücken. EIne Notwendigkeit für Extensions sehe ich nicht.
Simone Heckmann (Mar 29 2016 at 09:42):
Etwas komplizierter wäre die Dekomprimierung. Da müssten dann die Feldnamen zurückgemapped, aber auch alle fehlenden Felder mit fixed Values ergänzt werden. Den Narrativ neu zu generieren wäre dann noch das einfachste...
Simone Heckmann (Mar 29 2016 at 09:55):
Genial wird der Coup dann, wenn wir die (De-)Kompression als online-Dienst über das FHIR Operations Framework anbieten können, z.B. http://offiziellerUKFKompressor.de/Bundle/$compress
Simone Heckmann (Mar 29 2016 at 09:56):
Als Parameter wäre dann die URL des Profils anzugeben, das die Regeln definiert, sowie das zu komprimierende Bundle.
Patrick Werner (Mar 29 2016 at 09:56):
Ja genau sowas in der Art würde ich gerne bauen
Simone Heckmann (Mar 29 2016 at 09:56):
Das Framework wäre dann für beliebige Profile nutzbar
Simone Heckmann (Mar 29 2016 at 09:57):
Glückwunsch, du hast den Job! :D
Simone Heckmann (Mar 29 2016 at 09:58):
Ich hatte mit Forge schon mal angefangen Profile zu definieren, hauptsächlich um mich mit dem Slicing vertraut zu machen, das wir für die Sektionen des Dokumentes benötigen. Können wir uns am Freitag ja mal anschauen.
Simone Heckmann (Mar 29 2016 at 10:00):
Das Nette ist, dass ich für jeden Slice einen anderen Alias angeben kann, so dass beim Komprimieren nicht die Info verloren geht, um was für eine Section es sich handelt. Da die LOINC-Codes, die die Sections identifizieren nämlich fixed values sind, würden diese beim Komprimieren abgeschnitten. Statt dessen kann man aber einfach jedem Slice/jeder Section einfach einen anderen Alias (z.B. s1, s2 usw. zuweisen).
Patrick Werner (Mar 29 2016 at 10:00):
ich war am überlegen ob man dazu 2 profile erstellt oder nur eins. Also einmal Profil für das Bundle unkomprimiert + Profile für die Transformation - oder ob man das lieber gleich in 1 Profil packt. Kurz und Langversion. Ich favorisiere aktuell Option2.
Simone Heckmann (Mar 29 2016 at 10:08):
Ich denke, dass ein Profil ausreicht. Das müsste dann in dritter Aufgabe auch noch zur Validierung der übermittelten Langformate dienen. Was nicht validiert dürfte dann auch nicht komprimiert werden, da es potentiell ungültige Codes enthält, verbotene Attribute, für die es keine Entsprechung im UKF gibt oder zusätzliche Informationen, die beim komprimieren verloren gehen würden. Kurz gesagt, das Profil wäre hier der Dreh- und Angelpunkt des Ganzen. Ich würde vorschlagen, das von Kai definierte Dokument nochmals extrem zu verschlanken (z.B. zu einem Dokument, das nur eine Section und nur MedicationStatements enthält) und damit einen Proof-of-Concept zu implementieren...
Patrick Werner (Mar 29 2016 at 10:11):
sehr guter Vorschlag, können wir gerne am Freitag weiter besprechen (falls du kommst, aktuelle sind nur 2 Studenten im Schwerpunkt, Christian wollte sich noch bei dir melden deswegen) Ich ziehe mir mal weiter Slicing rein .. :)
Oliver Egger (Mar 29 2016 at 13:29):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
