Project - FHIR Integration

Hello @rhausam Sir, Good to see you again :slight_smile: 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.


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.

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.

1 Like

That’d be great. I’ve modified and have run HAPI and Smart on Fhir local but a docker-compose would be great.

1 Like

@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.:slight_smile:

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)

  • HTTP Request and Response Headers Utilized
  • Will we allow clients to indicate if they would like an OperationOutcome result?
  • FHIR Service base class to ensure uniform service implementations.
  • Common FHIR request handling for uniform response and status codes
  • Document supported resources and search terms

@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.



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 :smiley:

It will better if @sjpadgett help us out in capturing the high level changes that are required.


1 Like

Hi @yashrajbothra

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.


And in the spirit of transparency here are the “semi organized notes” I shared with Yash :grinning:

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).



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” :grinning:, 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.



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.


14 posts were split to a new topic: LOINC Integration