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
Hello @rhausam Sir, Good to see you again I have been trying to mingle with FHIR for a few weeks now. And the experience so far was quite good. Taking Connectathons I have never heard that jargon before will try to gather more info about that. BTW Some of the things which you mentioned below matches with my proposed project. If u can help in any particular thing that will be great.
Link to Proposal (Please Comment if U have any Suggestion)
Hi, @yashrajbothra. I’ve taken a first look at your proposal. I probably need to spend more time going through it, but I think it looks really good and I believe it should be a really valuable contribution to OpenEMR, and also to the FHIR community. I’m completely new to GSOC myself, so I’m not sure about specific aspects in that regard, but, as I said, I think this looks good.
1 Like
Edit: Apparently I’m responding to myself for some reason. Oops. @sjpadgett
Hi Jerry,
My high level punch-list is attached. I’ll get started on this today, after I’ve reviewed your “fhir” related changes.
openemr-fhir-publishing.pdf (66.6 KB)
Please let me know if you have any suggestions or there are other things I should consider.
Thanks!
Dixon Whitmire
1 Like
Dealing with external standards-based interfaces is easier if the source system has data dictionary structures. We currently have none. Implicit X12 mappings and related business logic is in billing code. Some hl7v2 mapping is in lab results and some in ccd/ccr code. Another challenge to consider is ability of each installation to create forms specific to their needs. Although it is extremely useful for the practices, in interoperable world users will need to map every relevant field.