Hi everybody,
It’s time to begin working out the direction to go to support FHIR. Anybody have thoughts on this?
thanks,
OpenEMR
1 Like
Just in brainstorming phase here:
- One option is to leverage the node.js that Jerry is working on (currently working on this to build ccda’s locally without needing a external mirth server). There appears to be a fhir package for node.js here: https://www.npmjs.com/package/fhir
- Another option is a php based package, such as this: https://packagist.org/packages/dcarbone/php-fhir
- And guessing other options
Please feel free to weigh in.
-brady
OpenEMR
First I’ve seen these libraries. The fhir.js looks to be very up to date with the specification. Have you a use case in mind for OpenEMR? I get serving up an available resource from OpenEMR but what about from the client side. What would that interface look like to say, provider? For portal, I’d like to see an interface that would show all available resources whether from OpenEMR or other repositories where patient could maintain a personal master health record along with a self maintained health journal for things like tracking glucose, diet, over the counters and so on. Crazy I know, but; I’m a pie in the sky kind of guy.
Hi @sjpadgett ,
I think a good starting point will be to serve to allow patients to collect the required MU3 items via api calls (so could leverage the patient portal credentials for that). (I plan to do more research into the MU3 required elements in the near future, so will have more specifics on that soon)
Then can grow from there (ie. server/client for interoperability support and the patient personal master health record 
)
-brady
You can check me but from what I gather for MU 3, the api’s are not
required to meet any standard (FHIR/HL7/whatever one picks) necessarily,
but instead that the api is available to some client/resource whether
proprietary or not. For example you could have a mobile app that accesses
the api for medications or account information using your own secure
messaging protocol. I think stage 3 only requires that to be demonstrated.
Not sure why anyone would not want to get on board with what is trending to
be the standard but it is possible.
Do I understand correctly that a MU3 certification will be required this year? I’m wondering what the current thinking is as to how we’ll get there.
Hi @sunsetsystems and @sjpadgett and everybody,
Don’t mean to hijack this thread (but I just did ). Will plan to
separate this into a separate forum thread later if can figure that out.
Plan to work towards MU3, which is still in the analysis phase:
http://www.open-emr.org/wiki/index.php/OpenEMR_Certification_Stage_III_Meaningful_Use#Completion_Barometer
It appears things are becoming a bit unhinged in the MU world though; for
example, I just received an email today from ICSA that they are not
starting any new certification contracts (I think this means they are
dropping out of certification). Sounds like the possible new “thing” may be
what was discussed at the OEMR board meeting yesterday evening by Roger
Maduro; even though it’s 90 minutes, recommend listening to it to see where
things appear to be heading:
On this note, we need to prepare for this possibility, and we are
attempting to produce articles and material over the next week to begin to
convince CMS that OpenEMR is the real deal. What we need from all
vendors/professionals supporting OpenEMR is at least a quick blurb
regarding any services offered regarding OpenEMR, which will go on Open
Health News where Roger Maduro will be creating a marketplace in order to
give open source projects real footing for the future. If you are willing
to do this (is basically free marketing for vendors if less than 100 words
and have option to pay for more words/bells/whistles), just let me know and
I’ll bring you into the collaborative google doc where we are working on
this. The more vendors/professional we have, the more chance we have of
making a significant impact.
thanks,
-brady
That barometer and Visolve’s estimate make it look like a lot of work. Are you thinking those requirements may go away?
Hi,
MU3 (ONC 2015) is required starting in 2018, which I assume will likely be
a 90 day reporting period, thus last quarter of 2018 (so, there is still
some time). It appears to be up in the air what’s going to happen; I don’t
think anybody really knows. Plan is to analyze and pursue development for
MU3, but not start actual certification testing (ie. start paying for
testing) until things are more clear. And in the meantime, need to asap get
OpenEMR in the running so applicable facilities can apply for large amounts
of moneys that is available, per the board meeting yesterday.
-brady
I have been working on tools for FHIR for the last few years. I have a sandbox FHIR database on my website for testing (not running at moment, converting to SMART authorization, up this weekend) and have several conversion apps that convert from OpenEMR to FHIR. Pick a patient in OEMR and the whole record is converted to FHIR, demographics, encounters, vitals, etc… I have most of the stock forms done in C#. I have looked at some of the java code from David Hay at Orion Health in New Zealand, who is Chair of the FHIR Management Group and the lib’s and utilities are becoming very robust and easy to work with. I think the whole industry is going to pick up on FHIR especially since the ONC and CMS are actively looking at it. Whatever it is we have to find a way to exchange records that works for everyone and it looks like this is going to be it for now.
2 Likes
Hi @Kim_Weesner,
Would you be interested in working on putting together a FHIR endpoint in OpenEMR? A potential first step is to improve upon my recently created 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 to export FHIR.
As a bonus, it would be great to have realistic fake FHIR data for educational setting of OpenEMR.
Thanks,
Matthew
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