Stream: german (d-a-ch)
Topic: German Beginner's ;)
Klaus Urban (Apr 06 2016 at 13:01):
Test
Simone Heckmann (Apr 06 2016 at 13:01):
Funktioniert :)
Patrick Werner (Apr 06 2016 at 13:02):
reTest :)
Torsten Schmale (Nov 11 2018 at 15:22):
Hi,
mangels besseren Wissens schreibe ich einfach mal in diesem Topic hier, ich hoffe das passt.
Bin ein "German Beginner" in Sachen FHIR und tue mich etwas schwer den richtigen Zugang zu finden. Vielleicht kann mir ja mal jemand etwas auf die Sprünge helfen.
Mein Ziel ist mit Forge zu modellieren und dabei auf bereits vorhandene Modelle in der offiziellen HL7 FHIR Registry zuzugreifen, um passendes zu verwenden, statt es neu anzulegen. Ergebnisse dann in einem Simplifier-Projekt zu speichern und dann in einen Testserver wie HAPI FHIR einzuspielen um Instanzen der modellierten Ressourcen via REST anzulegen, zu validieren etc.
Ein passendes Tutorial dazu habe ich nicht gefunden und andere Tools mit denen man das machen kann, habe ich auch nicht gefunden.
btw, als Mac User frage ich mich auch ob es neben Forge auch noch was für Mac gibt... (bis dahin Virtual Box).
Ich habe Forge nun installiert und ein eigenes Projekt in Simplifier.net angelegt, Export von Forge in dieses Projekt funktioniert.
Würde nun gerne in Forge auf die offiziellen Modelle zugreifen, diese importieren und wo nötig profilieren aber unklar wie das geht.
Dachte dann, man müsse vielleicht erst in sein eigenes Simplifier Projekt was importieren oder "forken" (github grüßt), um es danach nutzen zu können. Scheint aber auch nicht zu gehen.
Konkrete Frage daher: wie kann man z.B. die Patient Ressource http://hl7.org/fhir/patient.html in Forge importieren, um sie dann anzupassen?
VG Torsten
Simone Heckmann (Nov 11 2018 at 18:03):
Hallo Torsten,
hier bist du genau richtig, Willkommen in der Community :)
Was mir noch nicht ganz klar ist aus Deiner Fragestellung:
Möchtest du Profile basierend auf anderen Profilen (z.B. Basisprofile-DE oder IHE-MHD) erstellen oder basierend auf den Ressourcen der FHIR-Spezifikation?
In letzterem Falle brauchst du gar nichts zu Importieren, denn die Ressourcen sind in Forge bereits "eingebaut".
Geh einfach auf File > new Profile und wähle die Ressource aus, die du profilieren möchtest.
Wenn du bspw. auf den Deutschen Basisprofilen aufsetzen möchtest, müsstest du am einfachsten das gesamte Projekt herunterladen (auf der Startseite des Projektes https://simplifier.net/BasisprofilDE über den Link "download > ZIP valid resources as XML"), in einem Unterordner deines Forge-Projektes speichern und dann mit File > new derived Profile darauf ein abgeleitetes Profil erstellen.
...kennst du schon die Profiling Academy? https://simplifier.net/guide/profilingacademy/modules
Hier kann man Profiling Erklär-Bären mieten:
https://www.gefyra.de/p/unser-schulungsangebot.html
(FHIR für Spezifizierer)
...oder einfach hier weiterfragen ;-)
Torsten Schmale (Nov 11 2018 at 21:21):
Hallo Simone,
Danke für doe freundliche Aufnahme und die Infos.
Hat mir insofern schon mal geholfen, dass mir jetzt klar ist wo man die Modelle her bekommt und wie man sie in Forge importiert.
Kann man die Modell nur im Simplifier downloaden oder auch direkt von h7.org/fhir ?
Hintergrund:
wir überlegen ob wir die Business Objekte für ein neues Facharztmodul direkt in der FHIR-Welt modellieren. Wenn die FHIR-Tools brauchbar sind (wovon ich ausgehe), dann hat das Vorteile für die spätere Integration und Mapping. Insofern geht es weniger um Profiling im engeren Sinne, sondern um Modeling mit Rückgriff auf bereits vorhandene Datentypen und Value Sets.
Profiling Academy hatte ich gesehen. Hänge momentan aber noch am Grundverständnis: StructureDefinition, Snapshots, Slices etc.
Gibt es ein Tutorial dafür? Also quasi die "Grundschule" bevor man sich mit der "Academy" beschäftigt?
FHIR Einführung hatten wir zuletzt auf dem DIT ja gehabt. Sollte zunächst mal reichen, um die ersten Schritte hier zu machen (hoffe ich jedenfalls). Die Erklär-Bären werden wir auch noch brauchen, wenn wir das VO-Modul umsetzen.
VG Torsten
Marco Rudolph (Nov 21 2018 at 11:05):
Ich würde meine Kollegen gerne davon überzeugen, dass die eigene Implementierung eines FHIR-Servers unwirtschaftlich ist.
Das ist zur Zeit meine Überzeugung :) ..kenne mich aber leider nicht gut genug aus.
Mein Vorschlag einen Hapi bzw. Vonk - Server zu nutzen, der via Facade unsere Daten in FHIR dupliziert stößt auf Unverständnis.
Bisher habe ich angeführt, dass Search, FHIR-Versionierung und Historisierung große Baustellen sind, die man als PVS-Hersteller eher abgeben sollte. Zudem ist der zukünftige Pflegeaufwand garnicht einzuschätzen. Mapping der bestehenden Datenstruktur zu KBV Profilen (ValueSets, etc) muss bei beiden Varianten geschehen, denke ich.
Ich bin für weitere Gründe/Argumentationen pro/contra eigener Implementierung eines FHIR Servers sehr dankbar.
Patrick Werner (Nov 21 2018 at 11:39):
Willkommen Marco,
ich bin deiner Meinung. Search API, Operations, Versioning, Validierung sowie Valueset bzw Codesystem Handling sind alles keine trivialen Aspekte, die in der Implementierung ordentlich Zeit kosten werden.
Nächster Punkt wäre Standardkompatibilität: nutzt man vorhandene Server oder Facades wurden diese bereits eingehend auf Standardkompatibilität getestet, den eigenen Server müsste man hier kontinuierlich integration testen um zu merken ob man einen Aspekt des Standards etwas anders interpretiert hat als vorgesehen.
Ebenso bezweifle ich, dass es sich unter dem Aspekt: Kosten lohnt hier selbst zu entwickeln.
Simone Heckmann (Nov 21 2018 at 12:10):
Hallo Marco, ich teile ebenfalls Deine Auffassung und möchte noch zwei Aspekte hinzufügen: mit gereiften Fassaden, die bereits von verschiedenen Herstellern in verschiedenen Kontexten genutzt werden, erhält man wesentlich bessere Softwarequalität, als wenn man nochmal ganz von vorne anfängt. Außerdem: die Wechselschnittstelle wird nicht die einzige FHIR Schnittstelle bleiben. Würde man selbst implementieren, konzentriert man sich vermutlich zunächst auf die dort geforderten Funktionen und merkt vielleicht später erst, dass man zu kurz gedacht hat. Fassaden sind deutlich Zukunftssicherer, da dort bereits alle Funktionen, auch die, die nicht Bestandteil der KBV-Spezifikation sind, bedacht wurden.
Simone Heckmann (Nov 21 2018 at 13:34):
Weiterhin: Wenn mehrere Entwickler mit den gleichen Werkzeugen versuchen, die gleichen Probleme zu lösen, dann besteht die Chance, eine Community zu entwickeln, in der man sich gegenseitig unterstützt. (Ich weiß, das ist in der Deutschen Unternehmenskultur so nicht üblich, aber wir können uns ja mal eine Scheibe Mut vom Argonaut-Projekt abschneiden ;-) ) Je mehr wir zusammenarbeiten, um so schneller geht's und um so kostengünstiger wird die Umsetzung der Schnittstellen. Das sollte eigentlich im Interesse Aller sein :)
Ich denke, dass viele den Fehler machen, auf den ersten Blick anzunehmen, dass die Implementierung von FHIR einfach wäre. Natürlich ist das auch eines der "Verkaufsargumente" für FHIR, aber es gilt im konkreten Fall der KBV-Spezifikation leider nur bedingt.
FHIR ist in so fern einfach, dass es gut skaliert und einfache Probleme einfach gelöst werden können. Aber um's mit den Worten unseres Meister Yoda zu sagen: "You can move complexity around but you can't make it go away".
Für FHIR bedeutet das, dass man versucht, Komplexitäten von den i.d.R. einfach gestrickten Client-Anwendungen fernzuhalten und auf die Server-Seite zu verlagern. Nun fordert die KBV-Schnittstelle aber leider die PVS-Systeme in die Server-Rolle.
Ein weiterer Punkt, der FHIR einfach macht ist, dass es eine engagierte Entwicklercommunity und zahlreiche Tools, Bibliotheken und Frameworks gibt, die verwendet werden können, um die Implementierung zu vereinfachen und zu beschleunigen. Wer diese jedoch verschmäht, muss sich darauf gefasst machen, dass FHIR weder einfach noch schnell zu implementieren ist. Also nur noch "HIR", genau genommen....
Luise Oeppert (May 15 2020 at 09:18):
Hallo, ich gehöre dann wohl auch zu den German Beginners.
Ich schreibe gerade meine Masterarbeit. In dieser dreht sich alles um die Datenübertragung zwischen den Klinischen Krebsregistern und der Bundeauswertungsstelle (IQTIG). Übertragen werden sollen ausgewählte Daten des ADT/GEKID-Basisdatensatzes und des organspezifischen Moduls Prostatakarzinom. Realisiert wird das Ganze mit FHIR.
Für die Modellierung meiner Ressourcen habe ich Forge verwendet, dazu habe ich mir Projekte angesehen, die ähnliche Ansätze haben bzw. sich mit ähnlichen Themen auseinandersetzen (Care Cancer Record on FHIR, oncology der DKTK). Mittlerweile bin ich mit der Modellierung meiner Ressourcen fast fertig und habe soweit alles verstanden. Eine wichtige Frage konnte ich mir jedoch noch nicht beantworten, dabei geht es um die Resource Observation. Warum muss bei Observation.code bspw. auf LOINC und einen entsprechenden Code verwiesen werden? Welchen Hintergrund und Zweck hat dies?
Aufgefallen ist mir dies vor allem auch bei der TNM-Klassifikation. Dort werden die jeweiligen Werte (T,N,M, etc.) mit Hilfe von slicing als component einer Observation angelegt. Auch dort sollte bspw. unter Observation.component:TMT-T.code ein Verweis auf LOINC und einen entsprechenden Code erfolgen. Warum dieser erfolgen sollte ist mir leider noch unklar.
Nun hoffe ich auf eine einfache Erklärung. Danke :blush:
Viele Grüße, Luise
Mareike Przysucha (May 15 2020 at 09:33):
Hallo @Luise Oeppert, herzlich willkommen im Chat.
Um Deine Frage zu beantworten, muss man sich überlegen, wie die einzelnen Ressourcen, die tatsächlich übermittelt werden, aussehen.
Ich habe dazu einmal zwei Beispiele:
- Pflegegrad nach den deutschen Basisprofilen: https://simplifier.net/basisprofil-de-r4/observation-pflegegrad
- Gesamtergebnis Braden-Skala: https://simplifier.net/germanenursingsummary/observation-braden
Wenn man die beiden nebeneinander legt, wird man feststellen, dass diese sich primär im Code und ggf. noch im Value unterscheiden.
Um nun entscheiden zu können, was genau in der Observation transportiert werden soll, wird der Code verwendet. So sagt im ersten Beispiel der Code, dass es sich um einen Pflegegrad handeln soll, im zweiten Fall, dass es sich um einen Wert für die Braden-Skala handelt.
Nun könnte man natürlich sagen: Da reicht ein Text aus für den Menschen. Da aber die Ressourcen auch von einem PC verstanden werden sollen, ist ein internationaler Code besser, da dieser international verständlich ist (auch in China oder den USA) und der Code unabhängig vom Text auch immer gleich ist.
Kurz zusammengefasst: Der Code ermöglicht es den empfangenden Systemen, zu verstehen, worum es in der Observation geht.
Dies gilt auch bei Observations, die primär aus Components bestehen, da auch hier gesagt werden muss, worum es geht. Die Components liefern dann aufgesplittet die Einzelinformationen, aus denen sich die Observation zusammensetzt.
Anderes Beispiel dazu aus dem Bereich Wundversorgung: Die Wundgröße besteht aus Länge, Breite, Fläche und ggf. Wundtiefe. Die Observation bekommt den Code für die Wundgröße, damit die Systeme wissen: "Okay, hier kommt eine Wundgröße". Die Components enthalten dann den Code für Länge, Breite, Fläche bzw. Tiefe und die entsprechenden Angaben.
Ich hoffe, ich konnte Dir helfen. Wenn nicht: Trau Dich, mache einen Thread auf und frage dezidierter nach.
Simone Heckmann (May 15 2020 at 09:38):
Hallo @Luise Oeppert ,
auch von mir ein fröhliches "Willkommen"!
Da in DE momentan einige Projekte parallel am Thema Onkologie arbeiten, haben wir kürzlich dafür einen separaten Stream eröffnet: https://chat.fhir.org/#narrow/stream/224719-german.2Foncology
Da ist zwar noch nicht allzuviel Aktivität, aber vielleicht gelingt es Dir etwas Schwung hinein zu bringen :smirk:
@Stefan Lang in Bezug auf "ADT/GEKID on FHIR" läuft doch auch schon was, oder...?
Stefan Lang (May 15 2020 at 09:54):
ADT-GEKID ist im Grunde Bestandteil unserer Onkologie-Arbeitsgruppe, die unter anderem auch die Cancer Care- und DKTK-Profile vereinen möchte.
Da sind auch Vertreter der Krebsregister und der ADT beteiligt, von daher: ja, ganz sicher ;)
Stefan Lang (May 15 2020 at 10:03):
Mappings von ADT-GEKID auf FHIR (CCR) sind auch in Arbeit -> @Alexander Zautke
Patrick Werner (May 15 2020 at 10:05):
Das erste Mapping hatte @Stefan Sigle bei uns begonnen: https://docs.google.com/spreadsheets/d/1-_mr3Jd_buxEt-xsnHwoWcPYhRkSfie7sE91H-aWZ8o/edit#gid=0
Patrick Werner (May 15 2020 at 10:05):
ist aber noch sehr sehr WIP
Luise Oeppert (May 15 2020 at 11:18):
Danke für die Antworten.
@Mareike Przysucha Deine Antwort war sehr hilfreich. Danke dafür, das hilft mir auf jeden Fall weiter.
Den anderen Strem kenne ich bereits, war mir aber unsicher wo ich das Thema anbringen soll. Deshalb ist es hier gelandet.
Simone Heckmann (May 15 2020 at 11:34):
Das war auf keinen Fall falsch! Erhöht die allgemeine Aufmerksamkeit für den neuen Stream :)
Armin Griebler (May 18 2020 at 12:01):
Hallo, ich bin mir nicht sicher in welchen Stream meine Frage am besten passen könnte, deshalb stelle ich sie einfach mal hier. Und zwar möchte ich ein Medizinprodukt mit der Device Resource abbilden. Da jedes Medizinprodukt eine eigene Klassifizierung laut Medizinproduktegesetz hat, möchte ich diese auch angeben. Gibt es hierfür schon ein eigenes CodeSystem, bzw. welches Element der Resource wäre dafür am besten geeignet?
Last updated: Apr 12 2022 at 19:14 UTC
