Stream: german (d-a-ch)
Topic: RI für deutsche profile
Dmitri Ilyin (Jan 23 2019 at 15:32):
Hallo verehrte Kollegen,
wir arbeiten an der FHIR Schnittstelle die von der KBV definiert ist und auf dem "FHIR deutschem basis profile" basiert ist/sein wird. Wir haben vor ein Paar Tagen angefangen uns mit dem FHIR zu beschäftigen, sind also ganz neu. Ich suche momentan alle Anhangspunkte womit ich sinnvollerweise anfangen kann.
Wir entwickeln in Java, somit wollte ich fragen ob es bereits eine Open Source Java Implementierung des Profiles gäbe? Bzw Beispiele, wie mann so ein Profile in Java implementiert.
für jeden Hinweis vielen Dank und Grüße
Dmitri Ilyin
Morten Ernebjerg (Jan 24 2019 at 09:17):
Hallo und wilkommen zu FHIR!
Es gibt schon eine zeimlich ausgereifte Java-Implementierung von FHIR (Servers und Clients), HAPI FHIR (http://hapifhir.io/). Damit kann man auch gegen beliebige Profile validieren und so ein- und ausgegehende Daten entsprechend kontrollieren - siehe hier. Je nach Usecase reicht das vielleicht aus. Wenn es um eine "tiefere einbettung" von den Profilen gehen sollte kenne ich mich leider nicht so gut aus, aber mit HAPI kann einzelne Module zusammengesetzt und Angepasst werden.
Dmitri Ilyin (Jan 24 2019 at 10:17):
Hallo Morten,
danke! Ja, wir haben die bereits entdeckt und aufgesetzt. Uns fehlen die Beispiele wie man ein Profil implementiert.
Da das deutsche profile nicht seit Gestern gibt, würde es mich interessieren ob es eben eine Implementierung bereits gibt.
Die KBV Profile unterscheiden sich nur geringfügig von den deutschen Profilen. So wir können uns viel Arbeit sparen.
So ist mein Verständnis vom ganzen bisher.
viele Grüße
Dmitri
Morten Ernebjerg (Jan 24 2019 at 12:07):
Hallo Dimitri,
ah, OK. Ich denke, ich habe misverstanden, was mit "implementieren" gemeint war, vielleicht könntest Du etwas mehr dazu sagen? Z.B. welche konkrete Funktionalitäten sollen unterstütz werden (serverseitig und/oder clientseitig)?
Dmitri Ilyin (Jan 24 2019 at 13:04):
nun es muss eine REST Schnittstelle implementiert werden (für uns die Client Seite interessant), die mehrere Resourcen zum lesen anbietet. Die Resourcen sind als Profile definiert. Darunter sind z.B. Patient, Kostentraeger usw. Die Profile sind von deutschen basis profile abgeleitet. Ich habe es soweit so verstanden, das wir zuerst die Resourcen die in Profilen festgelegt worden sind in Java Klassen (so primitiv gedacht) ausformulieren. Dann können wir diese Resourcen mit HAPI API lesen. Gehe ich da in richtige Richtung??
Morten Ernebjerg (Jan 24 2019 at 16:39):
HAPI unterstützt automatisch die Basis-Resourcen (bzw. einige von den HAPI Beispiel-Server-Projekte im HAPI GitHub Repo haben schon die nötige Klassen). Da die Profile von den Basis-Resourcen abgeleitet sind, kann HAPI auch Resource-Instanzen lesen und schreiben, die beliebige Profile entsprechen. Für Validierung mit Profile
Morten Ernebjerg (Jan 24 2019 at 16:46):
(Oops, aus Versehen zu früh abgeschickt! ) Für Validierung mit Profilen muss man selber etwas implementieren (s.O.). Für Extensions kann man ggf. die entsprechende Resource-Klassen anpassen, damit die Extensions als normale Felder erscheinen. Aber meines Wissens ist das nicht nötig, man kann auch so mit Extensions arbeiten. (@Patrick Werner lege ich da richtig?)
Kommt das eine Antwort auf Deiner Frage näher?
Patrick Werner (Jan 24 2019 at 17:20):
Hallo @Dmitri Ilyin du musst in Hapi gar nichts implementieren, ist alles schon da. Profile sind Bestandteile des FHIR Standards, werden als StructureDefinition Ressourcen modelliert/erfasst.
HAPI bringt bereits alles mit um mit profilierten Ressourcen umzugehen.
Eine profilierter Patient ist auch ein Patienten Ressource + Profil.
Um die angesprochene read-only FHIR Schnittstelle zu implementieren, würde auf Java Object Seite (Objekte der FHIR Ressourcen) ein Patient erstellt & entsprechend befüllt werden. Das Einzige was man noch hinzufügt ist im meta tag die profile URI
Patrick Werner (Jan 24 2019 at 17:21):
Man kann sich (wie Grahame auch schon im hapi stream anmerkte) eine Facade dafür bauen wenn man mag, muss man aber nicht.
Dmitri Ilyin (Jan 28 2019 at 10:19):
Hi @Patrick Werner ,
"eine profilierte Resource eine FHIR Resource + Profile". Heisst es das das Profile (StructureDefinition) in dem Server/Client mit deployed werden muss? Das Profil, das wir zu implementieren haben, gibt es nur in Form von XML Dateien, also nicht online vorhanden.
Danke!
Dmitri Ilyin (Jan 28 2019 at 10:22):
Noch eine allgemeine Verständnis Frage. Muss bei der Implementierung der profilierten Resource berücksichtigt werden das die von FHIR Clients, die das Profile nicht implementieren, diese Resource trotzdem lesen können? Z.B. der Patient bekommt neue Elemente, diese sind als Properties realisiert. Der Client kennt aber das Profile nicht und kann mit diesen neuen Elementen nichts anfangen. Kann HAPI damit umgehen? werden die neue Elemente dann einfach ignoriert?
Was ist wenn sich der Type eines Elementen in dem Profil ändert, der Name aber gleich bleibt?
Danke und Grüße
Stefan Lang (Jan 28 2019 at 10:22):
Diese XML-Dateien kann man i.d.R. auf einen FHIR-Server hochladen, so dass dieser sie verwenden kann. Auf den Testserver meist einfach über den [base]/StructureDefinition Endpoint, ansonsten über entsprechende Admin-Backends.
Stefan Lang (Jan 28 2019 at 10:25):
Ressourcen bekommen technisch betrachtet niemals neue Elemente, bestenfalls Extensions (die inhärenter Bestandteil von FHIR-Profilen sind).
Grundsätzlich sollen Ressourcen auch ohne das Verständnis der Extensions verarbeitbar sein, weswegen z.B. im Patientenprofil Constraints sind, die trotz getrennter Angabe von Vorsatzwort/Namenszusatz/(Detail-)Nachname auch die Angabe des name.family-Elements mit dem vollständigen Nachnamen erzwingen.
Stefan Lang (Jan 28 2019 at 10:27):
Unbekannte Extensions werden gespeichert, aber (im Produktivsystem) nicht verarbeitet.
Eine Ausnahme sind Modifier-Extensions, die die Aussage der komplette Ressource verändern würden (z.B. eine Negations-Extension). Deswegen sollten diese extrem sparsam eingesetzt werden und kommen z.B. bei den KBV-Profilen auch nicht vor.
Stefan Lang (Jan 28 2019 at 10:29):
Profile können prinzipiell auch nicht den grundsätzlichen Typ von Elementen verändern. Sie können lediglich auf Profile des ursprünglichen Datentyps beziehen.
Stefan Lang (Jan 28 2019 at 10:30):
Oder eben aus einer erlaubten Auswahl von Typen einen bestimmten festlegen (z.B. Observation.value[x] => Observation.valueQuantity)
Stefan Lang (Jan 28 2019 at 10:37):
Zum Verhalten bei unbekannten Extensions hilft auch die Spec weiter:
https://www.hl7.org/fhir/extensibility.html#exchange
Dmitri Ilyin (Jan 28 2019 at 11:52):
vielen Dank! Jetzt habe ich erstmals genug Info zum "verdauen".
Dmitri Ilyin (Jan 29 2019 at 16:36):
Hallo zusammen,
HumanName DataType ist im deuschen profile abgeleitet und die abgeleitete Variante ist in Patient und Practitioner als Element Type verwendet. Ich will HumanName als CustomDataType implementieren um es in diesen Resourcen zu (wieder)verwenden. Ich rede von der Implementierung in HAPI.
Wäre es richtiger Einsatz?
Das KBV Profil beschränkt HumanName bei Verwendung in Practitioner (und in Patient) nochmal zusätzlich. Und hier ist mir nicht klar wie ich vorgehen muss. CustomDatatype nochmals beschränken? Nochmals von Customdatatype ableiten?
danke für die Hinweise und Grüße
Patrick Werner (Jan 29 2019 at 17:28):
der profilierte "deutsche" HumanName ist immer noch ein HumanName. Somit muss auch hier in hapi nichts verändert werden. Man muss beim Bauen von compliant HumanNames darauf achten, dass man der Struktur des HumanName Profiles folgt. Überprüft werden kann dies dann mittels validate gegen das HumanName Profil bzw. Profile welches den deutschen Basis HumanName enthält.
Patrick Werner (Jan 29 2019 at 17:30):
Als Faustregel gilt: der komplette FHIR Standard ist mittels hapi nutzbar ohne hapi anpassen zu müssen.
Last updated: Apr 12 2022 at 19:14 UTC
