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.
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
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.
Thanks Dixon,
Looks good especially the auto publish. This is inline with the original intent of publish and OpenEMR acting as a client for external FHIR servers. More so than anything else it is important in an institutional setting imo. Once you have patient setup it should be easier for us to help with others like encounters, medications etc.
For server credentials we can use globals for now but, I have plans to consolidate those in future. oeHttp client can provide for client grant type however, I donāt remember if iāve tested. Again, use what you want for client. I just find oeHttp easier to use.
The current utility aspects of Publish(demo resources) have served their purpose where I donāt care if they stay or go. Use what you can but, if they get in your way, throw away.
Remember also to allow for users capability to turn on/off auto publish etc.
Iām really looking forward to this and thank you for taking it on.
@dixonwhitmire I meant to ask. Are you going to stand up your FHIR server somewhere we all can access?
@sjpadgett - Excellent question!
I donāt believe we have a āsharedā public instance, but you can run the server locally using Docker Hub, or build it from source. I will be happy to help support either option.
Once things are looking good on the development front, I can also add a āsampleā docker-compose configuration to the project which will support a FHIR server, whether thatās HAPI or IBM FHIR.
Thatād be great. Iāve modified and have run HAPI and Smart on Fhir local but a docker-compose would be great.
@stephenwaite Can you help me figure out why I donāt get notifications for any activity on these topics?
Everywhere else I do.
hi @sjpadgett, think if you go to your preferences and select notfications->categories you can add your faves, I added the gsoc category so should be all set here
Thought I tried that but thank you. The famed Murphy of Murphyās Law has taken notice of late.
Good Morning!
I hope that everyone is doing well.
In regards to OpenEMRās FHIR implementation, it has been stated before that the goal for this effort is to implement FHIR as a means of integration/interoperability with other systems, rather than implementing a fully conformant server with all of the trimmings. Would it be helpful to do some additional design and capture the high level changes that are required?
For example, Iām thinking of things such as the following (this is a mixed bag between implementation ideas and the FHIR spec that I need to organize)
@yashrajbothra 's project proposal and the existing code in OpenEMR provide us with an excellent starting point. I would be happy to work with @yashrajbothra to update his documentation to provide additional detail, if that would be helpful. We can then post the document for review.
Of course if there is an effort underway, I certainly donāt want to be disruptive and am happy to assist with that if needed.
Regardless, @yashrajbothra it may be helpful if we connect to review some of the recent changes that have been merged.
Thanks!
Dixon
Hello @dixonwhitmire
I will create a revised version of my proposal so that it will easy to read and review then we can add all the additional details and plan things out. Also, I am ready to connect and review all the merged changes 
It will better if @sjpadgett help us out in capturing the high level changes that are required.
Thanks
Yash
That sounds like a plan. Thank you very much! I will follow up with you via email. Feel free to message me on Slack as well.
Thanks!
Dixon
And in the spirit of transparency here are the āsemi organized notesā I shared with Yash 
At a high level Iām asking if we can incorporate some of my recent API related commits into his project in addition to asking for additional detail regarding REST messaging headers and global unique identifiers.
Note: The hyperlinks in the PDF wonāt work. If anyone is interested in seeing the Google Doc, just drop me a line and I will be happy to provide you with access.
OpenEMR FHIR Notes.pdf (92.6 KB)
Hi @dixonwhitmire,
Those plans looks great. Maybe a good starter mini project for @yashrajbothra to work on would be to convert the encounter api endpoints to use your rest helper function methodology in addition to applicable automated testing (ie. mimick the work you did on the patient api endpoints).
-brady
Sounds great! I just reviewed some notes with Yash to clarify the current validator implementation.
Hi @brady.miller and @yashrajbothra - I am still chipping away at integrating the FHIR Patient Service with the recently merged API related changes. My intention here isnāt to āsteal Yashās thunderā 
, but to deliver an example of how the services (FHIR + API) can be integrated, just to to serve as a starting point.
Depending on my schedule, I should be able to post a PR for the FhirPatientService by the end of this week/weekend.
Update: Iām also tracking this issue - `fhir/Patient` FHIR endpoint not working Ā· Issue #3510 Ā· openemr/openemr Ā· GitHub and will submit my PRs against it.
Thanks!
MS recently announced their cloud integration, and the workflow contains FHIR EMR, Iām guessing the OpenEMR FHIR integration will play an important role in the future. https://www.microsoft.com/en-us/industry/health/microsoft-cloud-for-healthcare
14 posts were split to a new topic: LOINC Integration