Hey @sjpadgett Sir, Should we do something like this
Like we can take json of valueset and then convert it into code to ENUMS or we can add new table in our DB for Valuesets.
1 Like
Hi @yashrajbothra
Glad you are taking this on. I personally dread this type of development!
I think a table is easier to maintain. However, Iāll leave it with you as to what you come up with as the best approach.
AFAIK ValueSets and code are very important part of FHIR and we will use it in most area. So it will be better if we implement best approach. I am currently trying to implement in local and will discuss more as i reach to proper approach.
Thanks
Yash Bothra
1 Like
Wisdom, here is issue for FHIREncounter put/post #3226
The ārightā or best approach for the value sets will vary depending on the data type and the value set definitions and binding strengths. Essentially, the enumerated (extensionally defined) value sets (which are typically on the smaller side) that are used with the ācodeā data type elements and required bindings are expected typically to be handled directly in code (e.g. enums and switch statements). But the CodeableConcept elements with extensible or lesser strength bindings to often larger and more ādynamicā (intensionally defined) value sets probably need a different approach. Thatās where terminology services (or their internally hosted equivalents, in database tables or otherwise) particularly come into play. We should look at the uses and determine what approach will fit best where.
2 Likes
Hello everyone and thank you for interest in OpenEMR and especially our implementation of FHIR.
First, we have brought on Robert @rhausam as a mentor for FHIR. This s a welcomed and tremendous boost for the project. He brings a more in depth knowledge of FHIR to the project so, look to him for guidance for FHIR structure and guidelines. So welcome Robert and thanks.
I do want to interrate again our goal here. We are not trying to develop a fully implemented FHIR server. Others have done that very well. We want to implement an API that will meet ONC requirements for the EHR setting. This means economy of scale.
Also for those of you newly trying to get a handle on FHIR. The spec can appear very daunting. As with any specification written by committee, it becomes all encompassing making trying to figure out what does or doesnāt pertain to your implementation, difficult. Please donāt be discouraged because, youāre not the only one to face this.
Read up on what the spec is trying to accomplish and the reasons it exist. Look at provided examples and you will quickly have an awakening to getting a handle on how to start. Bottom line, itās not as difficult as it first appears.
3 Likes
Thatās a great comment, Jerry, that frames the scope and direction for the work. And Iām happy to be part of it and help in any way that I can.
3 Likes
Hi Folks,
My name is Dixon Whitmire. Iām a Software Developer/Architect that works in IBMās Watson Health divison. We recently open sourced our FHIR Server, and are interested in updating OpenEMR to support the automated publishing of patient records/resources when a record is changed.
I can see that work is underway to support FHIR R4 in a meaningful way, and have taken a look at the current publishing mechanism and its configuration.
Would the community be open to additional changes at this time? If so I can type up an overview of what weāre planning and send it over for review.
Thanks!
Dixon Whitmire
3 Likes
Hello,
In regards to my comment above regarding the FHIR publishing service, I can see that there is an effort underway as part of the GSoC and that there was a proposal process. I certainly want to be and helpful if possible, and not present conflicting efforts/PRs. Worst case scenario I can make updates and my team can run out of my forked repository.
@sjpadgett, @rhausam, or @yashrajbothra Are there documents, forum posts, or GitHub issue(s) which are tracking the current FHIR work that is underway?
Thanks!
Dixon Whitmire
1 Like
Hello @dixonwhitmire Sir, Thanks for showing interest. AFAIK we havenāt documented anything for FHIR yet but you can find some ongoing Issues which we are working on. I am giving reference to the one I am currently working on.
Thanks
Yash Bothra
1 Like
Thanks for the feedback @yashrajbothra!
Iām currently reviewing the FHIR responses OpenEMR returns for the patient resource. If I find an issue I will create a GitHub issue, if I donāt find an existing one and take it from there.
Hi Dixon,
The publish plugin will be removed soon from v5.0.3 (insecure) and reworked once we finish our core resources. The initial was more a testing jig with the idea to build a provider client for public/private FHIR server interactions. I see it heading toward a search/import type client.
The thought was that OpenEMR could stand up a custom world facing open sourced FHIR server configured to OpenEMR mission. Then use our API for interaction with this server. The server would give us full conformance while providing a repository. OpenEMR could then push and pull data as needed.
Still, in many of our settings, this is overkill.
Notable is there are not many tools available for a PHP implementation of a FHIR API. Our best hope for now while folks are currently interested, is getting the core resources finished.
However you want to contribute, just let us know. We can use the expertise.
Iām bit late to the discussion, but stupid question what would FHIR bring to OpenEMR? Iām trying to understand it, will it be able to use to share patient data between OpenEMRs?
Hi Jerry,
Iām finishing up a document that outlines my proposed changes. Well . . ādocumentā may be too strong of a word It collects the high level changes I would like to make as well as I can iterate towards that so itās not a huge PR! I will wrap that up and post it on Monday for review.
Thanks!
Dixon
1 Like
Hi Cyril,
Iām new to OpenEMR, but Iāll give this one a shot . . .
FHIR is a standard which describes how to model clinical/adminstrative data as āresourcesā and utilize those āresourcesā within an application or as an integration interface between systems. FHIR supports several messaging formats, including a REST based JSON API. The optimistic view is that FHIR may be utilized to provide a common standard for developing clinical applications, to speed development and innovation.
The executive summary from the FHIR site is a great place to start, if you would like to learn more.
While Iām not a core contributor to OpenEMR, FHIR could be used to provide a common means of integrating with an OpenEMR installation, and integrating with other FHIR based systems.
Hope this helps!
Dixon
1 Like
Hi Dixon, glad you have on board with the OpenEMR contributions (I was reading through the posts).Thank you for the answer and clarifying it. It helps to understand the idea of FHIR. It actually makes sense and FHIR can also be used in OpenEMR to talk to other OpenEMRās as well. Iām part of a project in which we are planning to deploy multiple OpenEMRs in our area and was looking at a way to share patient data. FHIR makes a lot of sense (correct me if Iām wrong), I honestly didnāt know a standard existed for this. Will be following this project.
1 Like
And yet I feel like iāve known you forever! Glad to have you.
Just to also note that interop of patient data in the past was attempted though passing structured documents such as CCD, CCR and recently CCDA(or patient carried around a box of print outs!). For anyone having to build CCDA in all the various types, FHIR is a saviour. Especially with the addition of Json as opposed to XML(yuck).
FHIR is rapidly being adopted by more concerned parties every day. Where folks developing client applications out pacing those who need to serve those applications. This is another reason OpenEMR needs to support quickly.
2 Likes
Hi again, everyone. Itās really good to see the level of activity and progress thatās happening with FHIR. I havenāt been able to engage much in the past couple of weeks, as I started a new contract last week and Iāve had to focus there and elsewhere. Iām going to try to keep up a little better going forward. As I think I mentioned before, Iām very active in HL7 and working on aspects of the FHIR core specification development and on a few FHIR Implementation Guides.
I also am a lead on some of the HL7 FHIR Connectathon tracks, and that leads me to a question. Have any of you who are in the OpenEMR FHIR contributors group participated in or has OpenEMR itself been included in any of the previous FHIR Connectathon tracks? Iām not aware of that having happened, but Iām asking because with the number of people and activities occurring during a Connectathon it is certainly possible that I could have missed it. So, whatever the answer for previous Connectathons, itās occurring to me that the upcoming Connectathon being planned for next month might be a great time to get OpenEMR and the community here involved. Several things will be different this time, the main one being that this Connectathon for the first time will be entirely virtual (obviously, due to COVID-19). And mostly because of that, the cost to participate is also significantly lower - it will be 100 USD (compared to > 400 USD previously). I also realize that 100 USD may still be prohibitive, but if thatās the case then I expect that we can find a way to manage that (or even arrange to have the fee waived).
The Connectathon is going to be held over a continuous 48 hour period on May 13-15 (the starting and ending times are still being decided), to provide an opportunity for participants in all time zones to be able to engage. This is the description, including the current list of tracks:
https://confluence.hl7.org/display/FHIR/2020-05+Connectathon+24
The work on FHIR in OpenEMR might fit into one or more of those tracks (if so, it would probably be best to choose one), or it may be that some of us would just want to join a track without specifically bringing OpenEMR into it. Or, if we would want to be somewhat more ambitious, it likely is still possible to propose a new track that would involve or focus on one or more aspects of FHIR in OpenEMR (even though technically the deadline for track proposals has passed, Iām pretty sure that if we would propose something within the next few days it wouldnāt be problem).
Some things particularly that Iām thinking of that could be useful to accomplish with OpenEMR in a Connectathon are: (1) more formal testing of the OpenEMR FHIR capabilities (as client or server) - leveraging the Touchstone and potentially Crucible or other platforms for that; and (2) providing an opportunity to explore data exchange (and any issues that are encountered with that) with other EHRs and systems.
What are your thoughts?
Rob
2 Likes