Consuming FHIR Resources for OpenMRS

Hi everyone,

I’m mentoring a GSoC project to build support to consume FHIR resources for OpenMRS. A number of students have tried to reach out to me on IRC / wiki, but I haven’t been able to respond in a timely manner because i’m never in the same place for too long.

I started this post as a way of keeping track of everyones questions. Feel free to reach out to us on this thread, and discuss your ideas further :smile:


Hi Suranga, One of the project objective as listed in the project page is,

  • Build support for the FHIR module to accept a subset of FHIR
    resources sent from third party applications. At minimum, the student should complete support for FHIR patient, practitioner, Observation, location and encounter resources

The resources mentioned above are already implemented in the module. What else expected to complete under this objective? I see some of the search parameters are not implemented as mentioned in . Also update and create resource services are not implemented. Is that the tasks which is expected to complete under this objective?

Hi @sashrika, happy to see your interest, and thank you for the work that you’ve already done.

The GSoC project will focus on consuming FHIR resources - that is, accepting FHIR resources someone sends to OpenMRS, and storing them as discrete data in the OpenMRS DB. Work to date deals only with exporting FHIR, and we’re yet to support the reverse of this.

We currently have two tickets that will explore the possibility of doing this with the FHIR Person resource. (FM-40 and FM-41) we will not be creating any more tickets that deal with consuming FHIR - the rest will be done via GSoC :smile:

Hi @surangak: What is the username and password for the FHIR demo server? The one you sent via email did not work.

Thanks @surangak , that is kind of a joing work rather than an individual job :smile: .

I learned that there is some distance between OpenMRS resources and FHIR Resources, since because OpenMRS data model is highly generalized. I saw a one Objective of the project as “Make appropriate modifications to the OpenMRS database in order to support FHIR resources appropriately”. I am sure we are not going to make direct changes to the underlying OpenMRS data model. So are we going to create new intermediate objects which keeps the matching between OpenMRS resources and FHIR Resources?

I did some reading on fhir site, how do they implement post/put requests. I got to know that we can use @create and @update annotations. I hope to put some effort towards that and let you know the progress.


I want to introduce @vaibhavhp, who’ll be working as backup mentor of this project. Vaibhav is a former GSoC student of mine, and an all around nice guy to work with. He’ll be helping me and @harsha89 figure out our FHIR efforts :smile:


@sashrika, in response to your question, the statement “Make appropriate modifications to the OpenMRS database in order to support FHIR resources appropriately” was made in view of the potential for distance between the OpenMRS data model and the FHIR model. But you’re right, this is not really going to be necessary, and we don’t anticipate any need to make such a change at this point :slight_smile:

Hello everyone,

@surangak Thanks for introducing me. I’m glad to be part of this project. The GSoC 2014 was a great experience. @surangak and @harsha89 I’ll give all my best to our FHIR efforts.

Looking forward to have yet another great summer!

Excited like a student again!! :smile: :smile:

1 Like

Thanks @surangak , That was I also thinking.
Hi @vaibhavhp , Happy to see you as a backup mentor in this project :smile: .

I have few questions to raise here.

  1. Bad repercussions of changing the OpenMRS data model is clear. But can’t we add new Table/Object to the already existing model to support FHIR resources like Practitioner? Or new Composition table to keep the mapping between Encounters and various other related resources to it? I understand this modifications will heavily cost though, because then we need to touch several OpenMRS modules and files to keep the consistency across the system.

  2. Since a major objective of this project is to support create/update operations to existing resources, I went through There I found in addition to typical create/update operations, FHIR supports conditional create and updates. Is there any use cases where implementing these operations could be beneficial for the FHIR consumers? (eg : the simple idea of conditional create is we tell the server that create this resource , if there is no matching resource found in the database for the “given” condition. In HTTP headers we have to mention what is our condition. One condition would be create this person, if there is no any person with the name “xyz” )

@sashrika the approach is we should only figure out ways of mapping our existing openmrs objects to fhir resource. OpenMRS provider is equivalent to practitioner.So many of fhir resources has equivalent representation in OpenMRS model. I agree that there are some mismatches.

Your last concerns on the conditional implementation. Yeap it definitely need to implemented. Shouldn’t be hard but we need to look at how HAPI library provide us flexibility on that.

1 Like

@harsha89, yes according to the conditional update behavior, its implementation should not be hard, if we have already implemented the relevant search and create operations. We have to perform the search operation and based on the result we get(no matches, one match, multiple matches) we perform the correct operation.

one more concern :smile:

According to the FHIR specifications, many operations rely on the “version-id” of each resources. But AFAIK we don’t maintain a version-id for resources. So are we going to not consider this attribute in this project scope?

I think implementing support for versions is not something that we can do easily. @surangak we can do quick background search on this. But according to my knowledge, it’s something that associate with work. We no need to put up that much of concern to versioning. :slight_smile:

1 Like

So I think for the time being, I can omit the versioning of resources :smile:

@surangak , @harsha89 , @vaibhavhp , In the project page there is a extra credit task as “Add security features to manage transactions”. What are the objectives of this task?

We have basic authentication security for the FHIR web services. There is another project for implement Oauth2.0 security for OpenMRS. If the infrastructure built by that project, we can modify the FHIR module to work with OAuth2.0.

In addition to that I found on page, that base on the access permissions, the results of a query can be vary. I am not aware of such Authorization framework in OpenMRS(I never noticed it because I always login as admin :smile: ). If there is such mechanism we can restrict the search results based on the authorization level of the Requester.

@surangak , @vaibhavhp , @harsha89 According to the project page one of the extra credit task is “Build an audit mechanism to track transactions and their outcome”.

I found few resources on how we can implement audit records in FHIR. According to , FHIR defines “provenance” and “audit event” resources suitable for tracking the origins, authorship, history, status and access of resources. These audit events can be then further processed by properly authorized application. blog post discuss about tamper resisted auditing in FHIR. We use “audit event” resource for the actual auditing and use “provenance” resource to check the integrity of the “audit event” resource. This process involves public key infrastructure. Not sure whether this heavy process fits into a three month project along with the other project objectives, but running a background checking and implementing at least a proof of concept would be an interesting thing :slight_smile: .

What is your suggestion?

Great findings and thoughts @sashrika.

OAuth2 integration also a one of task in this module which depends the implementation of OAuth module. So there is a dependency, but we should be able to do with the OAuth module progress.

Also we can think of implement some restrictions based on the incoming request. We can refuse the request coming from special IP addresses and also we can limit the bad incoming request which try to get data from the FHIR api without security headers multiple times. Also some kind of throttling.

For the auditing purposes I think @surangak is expecting a initial version of auditing capabilities. We can write a intecepter for fhir request and do the auditing there. Audit details may associate, number of requests comes from origin, number of fail attempts for a API and etc.

Thanks, Harsha

1 Like

Thanks Harhsa :smile: So some of the Security and Auditing features we are interested now is

  1. Modifying the module to work with Oauth2.0
  2. Restrict special IP addresses
  3. API throttling
  4. Auditing with using an inteceptor. I’ll look into more details on this areas.

@surangak , @vaibhavhp , @harsha89 I submitted a project proposal to melange on this project. I would like to hear any comments and feedback from you in order to improve my proposal :smile: .

Thank You!

Thanks @sashrika, great work! :grinning:

1 Like

Thank you @vaibhavhp :smile:

1 Like

@surangak @harsha89 @vaibhavhp I am very much happy to see that I’ve been selected for GSOC - 2015 under this project :smile: :smiley: . Without your generous support this would be an impossible task. I will contribute to this project and OpenMRS at my best and I wish I’ll get you support and direction in future as well.

Thank you! Regards! Sashrika.

1 Like

Hi @sashrika, @harsha89,

I’ve just had a conversation with @wyclif around conditional creates and updates.

So the problem we have is that basically, OpenMRS needs to be the deciding factor here. For example, if a conditional create says “do X”, and the OpenMRS db says “sorry, we don’t allow that”, then OpenMRS gets priority, and we have to go with what OpenMRS says.

But if OpenMRS has no issue with what the conditional create / update asks, then we can go ahead.

So basically, conditional creates are ok, but they are restricted by the internal validations built into the OpenMRS core :smile:

And also, it might make sense to re-think our use case around conditional creates.

In our case, if someone sends OpenMRS a new resources with a unique UUID, then it doesn’t matter what conditions we try to specify… I mean. Should someone be allowed to say, “we’re sending you a brand new Patient resource, but only create it if the OpenMRS db doesn’t already have a patient with a patient identifier.type = xyz and patient identifier.value=123” ?