Do we also want to allow for write/update operations?
thanks for the link Matthew
1 Like
@Matthew_Vita ,
Except for logging, I canāt think of any reasons to support write/update operations at the onset (ie. keeping simple seems best), although good to keep this in mind while building a solution, since there will likely be reasons to support this in the future.
Hello Matthew
From my view implementing FHIR ability to OpenEMR in PHP from scratch will be a laborious task. Also, the gain may not be proportional to the effort as there are platforms that can be leveraged for this task. So not to reinvent the wheel, ViSolve customized HAPI FHIR to work with OpenEMR database.
To Implement FHIR from scratch in PHP, we see some challenges like:
-
FHIR has 93 resources, each resource has its own definition and parameters that need to analyzed and implemented based on the standard
-
Implementing FHIR standard in PHP from scratch - required to change the OpenEMR existing features to support the implementation
-
Need to convert to JSON / XML format according to the required standard & definition
HAPI is a opensource FHIR API - it has the resources schema classes defined and functions to convert into JSON/XML. We have used those to do CRUD operations with OpenEMR database. It is noteworthy, to mention that HAPI has contributed significantly to the HL7 standard.
As a POC project, ViSolve has already implemented some of the basic primary resources with OpenEMR database to give the FHIR server ability to OpenEMR.
ViSolve has tested the OpenEMR FHIR enabled server with postman application and we have focused on all the operations like:
-
Read the particular entry of resource (given ID) -
Create a new entry in the resource -
Update the entry in the resource (given ID) -
Delete the entry in the resource (given ID) -
Full Search of a resource (will retrieve all the values in a Resource)
Thanks & Regards,
Tech Lead - Solutions & Services
ViSolve Inc
Hello Matthew / Brady
The write/ update operations are needed for any resource in FHIR server. For example, let us consider that there is a FHIR Client app to schedule appointments for the patients.
If FHIR Client need to communicate and work with FHIR Server (OpenEMR), we need to support all the CRUD operations in Appointment Resource.
If a new appointment is created in FHIR client - that need to be inserted into FHIR server. If an appointment is updated - that need to be updated in FHIR server.
We need to concentrate on authentication or authorization of the FHIR client for securing the access. For web applications, FHIR recommends to use OAUTH for authentication of clients/users.
Thanks & Regards,
Tech Lead - Solutions & Services
ViSolve Inc
Update is a MUST to make the solution competitive so IoT devices can access
and update the data!
I have requested the team to share the PoC that ViSolve has done on this
topic and hopefully VISolve can do that
in the next few days.
-Sena
ViSolve
1 Like
Hi Sena and others at ViSolve,
Thanks for the feedback.
I want to clarify something. Iām not suggesting we develop a FHIR library ourselves in PHP. Iām saying that we should create C_FastHealthcareInteroperabilityResources.class.php controller that receives the FHIR resources and sends it to a library for parsing/validation. Calling a mature FHIR.js Node library from PHP may be a great solution. Not sure about HAPI because itās hard to distribute an embedded JVM with our software (i.e.: with our XAMPP package).
We could have our end users āopt inā to the HAPI solution by installing the required dependencies themselves. Still, I think that PHP being the server that simply calls the FHIR library and database may be a good option. May even work for SMART on FHIR.
Does this make sense? Moreover, is it a good approach?
Thanks,
Matthew Vita
an embedded JVM with our software
āI guess each approach has its pros and cons and I dont dare to get into
the āflameā war here.
Based on my years of experience on the system side, my vote is for Java
based simply at hi level it gives a warm feeling that
it is more secured and more āover want to leverage what others have done
like HAPI!
But one could go with PHP also and as I said my vote is for Java!
Thanks,
Sena
Sena,
I agree with your assessment (Iām a full time Java programmer and like the ecosystem 
). Iām just not sure how weāre going to easily distribute Java to our end users (e.g.: how can it be packaged into XAMPP?). If this can be figured out, I believe the OpenEMR PHP controller calling to HAPI would be a wonderful approach for FHIR!
Iām at work, but it looks like thereās a discussion about how to do this here: https://www.codeproject.com/Questions/890920/How-can-we-execute-java-programs-in-xampp
The worst case scenario is that we have our end users install one additional program manually. I donāt think this is a bad thing at the end of the day.
Thanks,
Matthew Vita
Hi Sena and Matthew,
The nice thing is that these decisions get to be decided by who does the work
I like Matthews approach of keeping the connector class generic. Then could support HAPI mechanism if that is the route that the folks who do the work choose(and guessing a instruction set on installing/configuring HAPI should suffice). And if a developer decides to build a node.js solution in the future, then could just build it into the connector (note this was what Jerry did on CCDA stuff; rather than the ccda connector using the offsite mirth server, he redirected it to a local node.js instance).
-brady
Brady,
Good thoughts!
Iām happy this conversation has started and whoever picks up the work has an idea to go about it.
Maybe Iāll be able to contribute to this once the cloud project is done!
-m
For anyone interested in participating or watching, Iām working on generating realistic FHIR data from the NAMCS dataset. Once this is done, I am going to create a SMART on FHIR server and a simple API to export the data.
Although I am very focused on the cloud project (which is almost done!), I will be working on this here a few times a week: NAMCS FHIR Solution Ā· Issue #1 Ā· MatthewVita/fake-patient-web Ā· GitHub
EDIT: I should mention that this data can be useful for testing when the OpenEMR FHIR integration project starts (mainly useful for the create and update operations because it has the relationships resolved).
-m
1 Like
I am certainly learning a LOT about the defacto FHIR viewer from HAPI FHIR. Iām using a Docker solution to run it locally:
Solution is hapi-fhir/hapi-fhir-jpaserver-example at master Ā· jamesagnew/hapi-fhir Ā· GitHub
Next step is to hook it up to a mock data providerā¦
1 Like
Just so you all know, this thread/project is linked in the core roadmap: http://open-emr.org/wiki/index.php/Roadmaps#OpenEMR_Project_Roadmap
If youād like to, you can adjust the top post in the thread to be similar to the other linked projects. This is a great example: Intelligent Chart Summarization
-m
Just thought Iād do a fyi here about a HAPI FHIR project iāve been slowly creating and testing consisting of the following:
- Stu3
- Mysql
- Several Daoās with entities.(too lazy to list)
There are many resources out there that building up a solution is more project management than coding. This points out how well the HAPI FHIR is done.
I had original intention to populate resources from live clinical data(seems so logical) but have since been reconsidering to maintaining server repository as separate mysql database with the user publishing from OpenEMR. With the ability to read/write to server database from OpenEMR it would be natural to create some php classes for handling data that is authorized to be public on the server. Could be as simple as a publish button in demographics where select items to be published would be written out to server database.
Though I am a rusty Java developer and am far more comfortable in node/web apps, I think it would be a disservice to support any way other than the Java solution for many reason iām sure most of you already know. The more I work with HAPI FHIR the more convinced I am it will be the fastest and easiest way to get going with FHIR.
Soon I hope to publish a project core somewhere(prob OpenEMR repositories) once I trim the unnecessary and thin down to something closer to production server. The way HAPI has been developed where possible configurations are many the real challenge is not hitting endpoints but getting to the EMR data. So far the database now totals around 40-50 tables.
3 Likes
Awesome! Thanks for the update
Well, iāve spent many hour looking at all the various ways to implement. I have been able to set up several Java based production servers of HAPI JPA and SMART on FHIR. Iāve also developed/tested a Nodejs server with oauth2 and a couple profiles to companion with my ccda-server and I finally have convinced myself that a server to support OpenEMR is not a hindrance and just comes down to how we want to integrate to our work flows.
So I have begun to developed a Php solution with the idea that provider/user have a dashboard to manage FHIR. First phase is this PR: Phase 1 FHIR on PHP- Provider Client and implement classes. by sjpadgett Ā· Pull Request #1422 Ā· openemr/openemr Ā· GitHub
All the necessary Stu3 schema are implemented by generated classes which I wrapper into classes for creation and parsing server resource responses with a companion class for collecting OpenEMR live data. A needed HTTP client class to speak to our/public server is included. Also, A good start of a dashboard app with a client controller class in integrated into demographics in this initial P.R.
Certainly need to get feedback on this start and please jump in and maybe pick up one or two resources to add to the resource class. Really, I see the development of the dashboard driving resource capabilities needed. Iām starting to get an oauth integrated but if someone were to develop a search method to search various FHIR servers and compile to serve up to dashboard then that would be a backbone issue gone.
Iām eager to get some help and feedback to continue on or not.
Thanks.
3 Likes
I am a true noobie and I am just beginning to get clarity re: FHIR and oauth2. It looks like it will be the direction MedEx heads towards also. If the community finds MedEx useful, it will be a nice way to fuel FHIR/oath2 development. Am I wrong to think that FHIR will really be a requirement to ensure openEMR can coexist in the future ecosystem of interconnected EHRs? If thatās true, how could FHIR development not be important?