Stream: german (d-a-ch)
Topic: mysql & hapi
Don (May 03 2017 at 15:38):
Hallo zusammen!
Mir steht bevor vorhandene Patienten-Daten aus einer MySQL-DB über FHIR-API verfügbar zu machen, ich habe mir HAPI-FHIR angeschaut, blicke jedoch noch nicht durch, wie ich es angehen sollte. Hat vielleicht jemand einen Tip für mich? :)
Patrick Werner (May 03 2017 at 15:40):
was ist genau die Frage?
Ist hier gut beschrieben: http://hapifhir.io/doc_rest_server.html
Patrick Werner (May 03 2017 at 15:42):
damit Baut man sich die nötigen Resourcenprovider und triggert daraus seine ServiceKlassen welche sich wiederum die Infos aus der MySQL DAtenbank zusammensuchen
Don (May 03 2017 at 15:53):
Danke für Deine Antwort Patrick! Mir ist unklar, wo und wie die DB-Daten in die DataObjects gemappt werden.
Patrick Werner (May 03 2017 at 15:55):
das muss man selber machen, die Beispiele deuten das ja an. Dort werden neue Resourcen erstellt und returnt, beim Erstellen der Resourcen befüllt man dann statt mit Beispieldaten mit den Daten welche man aus der MySQL DB queried
Patrick Werner (May 03 2017 at 15:56):
wie komplex soll das denn werden? Es sollen nur die Daten des Patienten gesucht werden?
Patrick Werner (May 03 2017 at 15:57):
also z.B. "gib mir alle Patienten mit Geburtsdatum = X, oder mit Namen = foo?
Patrick Werner (May 03 2017 at 15:58):
ein kompletteres Beispiel findet sich hier:
https://github.com/jamesagnew/hapi-fhir/tree/master/restful-server-example
Don (May 03 2017 at 15:58):
Es sind schon viele Daten, darunter Laborwerte etc., also ist es eine recht aufwendige Angelegenheit, nicht einfach mal schnell zu einer bestehenden API eine FHIR hinzuzufügen :(
Stefan Lang (May 03 2017 at 16:14):
Das ist dann in der Tat ein bisschen komplexer. Zumal ein bereits existierendes Datenbank-Backend ja in der Regel nicht exakt so strukturiert sein dürfte wie die FHIR-Ressourcen. Ein 08/15-autogeneriertes ORM wird typischerweise nicht reichen, wenn nennenswert medizinische Daten in der MySQL-DB enthalten sind.
Das Mapping musst Du also selbst erstellen, unter Berücksichtigung aller CRUD-Operationen (soweit für den Use Case relevant) bzw. deren Implikationen. Besonders, wenn womöglich sowohl über eine angebundene Applikation als auch über FHIR gelesen und geschrieben werden soll. Aber um das zu diskutieren, müsste man deutlich mehr Hintergrund-Infos haben.
Don (May 04 2017 at 09:26):
Vielen Dank Stefan, gibt es vielleicht ein Migrationstool, mit dem ich die Daten aus einer vorhandenen DB in eine leere FHIR konform übertragen kann? Daten-Mapping muss natürlich weiterhin selbst erstellen, aber kann mir evtl. die DB-Backend generieren lassen?
Ich muss nicht die vorhandene DB oder Backend mit dem neuen FHIR-Backend synchron halten.
Patrick Werner (May 04 2017 at 09:33):
Hi Don, DB Backend für HAPI gibt es auch schon als Example: https://github.com/jamesagnew/hapi-fhir/tree/master/hapi-fhir-jpaserver-example
Patrick Werner (May 04 2017 at 09:35):
Ein Migrationstool um die Daten hier rein zu bekommen existiert nicht. Aber hiermit hat man einen FHIR Server mit JPA Backend. Zur Daten Migration würde ich wahrscheinlich den Weg über die REST Schnittstellen des HAPI Servers gehen. Ist zwar langsamer aber man kann auf diesem Weg seine Daten gleich validieren. Direkt auf die DB von HAPI zu migrieren ist riskanter - da ohne validierung
Stefan Lang (May 04 2017 at 10:37):
Da stimme ich Patrick in beiden Punkten zu.
Die Migration muss man zwangsläufig manuell mappen. Ein Tool dafür könnte bestenfalls eine sehr geringe Zahl eigener Codezeilen ersetzen.
Und ich würde auf jeden Fall anhand dieses Mappings die MySQL-DB direkt in FHIR-Ressourcen umsetzen, aus den genannten Gründen. Dann erkennt man auch gleich, wo eventuell im Mapping noch Unvollständigkeiten enthalten sind.
Simone Heckmann (May 07 2017 at 12:56):
Hallo @Don
schau mal hier: http://www.openmapsw.com/FHIR/FHIR.htm
Vielleicht geht das in die Richtung, nach der Du suchst?
Simone Heckmann (May 07 2017 at 12:58):
Das eigentliche Mapping muss man natürlich auch hier selbst erstellen, aber es gibt immerhin ein Framework dafür...
Last updated: Apr 12 2022 at 19:14 UTC
