Hi @MatthewVita ,
There is a “preliminary plan” to use a node.js library for FHIR (akin to what is done in OpenEMR 5.0.1 for CCDA). For your fake-patient-web, would be very cool if used the a node.js library for FHIR (then can basically do the same thing for the FHIR within OpenEMR).
-brady
Great idea! I have big plans for this repo. I’d like to keep it system-agnostic so that OpenEMR has to support inbound FHIR processing. Also, researchers and other systems can take advantage of my system.
-m
Hello All,
Good to see views on FHIR implementation. ViSolve did a little bit of
research last year for FHIR implementation for OpenEMR and our findings
have shown HAPI may be a better choice. So, ViSolve started using HAPI for
their FHIR implementation.
ViSolve is NOT religious on HAPI but if there are good reasons to go with
node.js, we will consider that
Thought of sharing our findings here:
There is no clear explanation or feature that says HAPI is better than
Node.JS library for FHIR.
Both has schemas defined for all the resources and ability to convert them
to JSON/ XML.
We choose HAPI because:
- HAPI has a strong community support which releases for all updates of
FHIR - HAPI organizations has been a valuable contributor in HL7 concepts
also, they have provided the API for HL7. - Its developed based on the JAVA Spring framework.
Here is a link - that states 2 disadvantage of using Node.js library -
But since we have not tried this package, we are not sure of its real
difficulties.
There are no many examples or resources available that explains how to use
node package like HAPI.
ViSolve has implemented at high level some FHIR resources for OpenEMR as a
prototype to get ourselves familiar with FHIR.
Regards,
Sena
2 Likes
Sena,
It’s funny you bring up HAPI because I actually run the GitHub - MatthewVita/node-hl7-complete: Node module that is bridged with the Java Hapi HL7 library. project which is a production-ready library that allows Node.JS users to easily work with HL7. HAPI is used under the hood via a specially embedded JVM bridge!
Anyways, I will report back on the capabilities of the current offerings in the node world as well as look into HAPI FHIR. I am new to FHIR but really like the concept!
EDIT: Wanted to thank you for sharing your research findings as well
Thanks,
Matthew
1 Like
Would be good to avoid java if possible (complicated installation etc.), however, generally the person(or group) whom does the work gets to decide. Looking forward to see what transpires on this.
-brady
1 Like
Okay everyone. I have spent some time looking into this and it appears that the FHIR JavaScript libraries that have been discussed are mainly clients. In other words, if you are Foobar Hospital and wish to consume data from your Acme EHR’s FHIR endpoints, you will want to use one of the clients. If you look at the HL7 site, they reference “Publicly Available FHIR Servers for testing”… I will take this as a sign that most folks are focused on getting clients hooked up rather than implementing the servers themselves.
As for our needs, I believe we need to take a step-by-step approach. To start, it is best to create a C_FastHealthcareInteroperabilityResources.class.php controller to accept queries and CRUD operations. If the base Controller class doesn’t allow for complex variable URI paths (i.e.: /Patient/32/_history/4), I suppose we can use a query string for that as a workaround. Getting this code in place will put pressure on the existing codebase modernization work because the controller layer should really be “talking” with various service classes to get at the data, all while following known OpenEMR domain rules. We definitely don’t want duplicate code!
Once a request comes in, we can use a FHIR parser that PHP calls. We may need to be clever here… the PHP FHIR parser doesn’t appear to be very mature so we may need to think of a way for PHP to make a call to a Node.js script. Like Brady mentioned, the Java solution will most likely have an impact on user installs so it’s best to stick with something simple like PHP/Python/Node from a dependencies perspective.
Once we get a good amount of the FHIR spec covered, the final step will be a good time to look into SMART-compliance and, perhaps, move away from the basic C_FastHealthcareInteroperabilityResources.class.php controller (may need to use a separate Node server) to ensure we are fully compliant with SMART. I don’t think it is a good idea to do this right out of the gate because this is very complex and I have a feeling the auth piece will be difficult.
As far as my GitHub - MatthewVita/fake-patient-web: FakePatientWeb shows a realistic fake patient record in a nice UI as well as in JSON form. 300,000 NAMCS records are used as the data source. TODO: FHIR integration project goes. I am very interested in pivoting the solution so that it’s essentially a fork of GitHub - smart-on-fhir/sample-patients: Utilities to generate sample data as FHIR Resources but uses NAMCS data. As a bonus, I’d like to incorporate it all with the existing GitHub - smart-on-fhir/smart-stub: Node / Express server to stub SMART Auth server. Elements from this dataset can then be used for the CRUD operations of our FHIR server for proper testing.
-m
1 Like
I guess now would be a good time to mention my involvement after having dug into this subject quite a bit. I’m totally focused on the OpenEMR Cloud project at the moment. “In my free time” I’ll be working on getting the NAMCS dataset in a friendly FHIR format. That should be helpful for this project from a CRUD operations and data validation perspective.
Once the OpenEMR Cloud project is done, I can make time for this!
-m
Hi @MatthewVita ,
That sounds great. To clarify regarding FHIR server/client. Goal is to have OpenEMR allow client applications connect to it to collect data (for example, patient data to support the MU3 API requirements). I think this is what you mean with “once a request comes in, we can use a FHIR parser that PHP calls”.
-brady
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