Modeling OpenMRS encounters as allergies, conditions, diagnosis etc

This post is a continuation of the conversation I initiated on:!topic/dev/bwPjAw0zeh0

Basically, i’m trying to list down our plans for representing OpenMRS encounters using FHIR. In the previous email (see link) we discussed how to manage requests for Encounters and visits, and what gets returned each time. Now, lets try to build on that to see how different observations will be grouped together under encounters.

Lets say someone is using OpenMRS, and wants to return a bunch of obs grouped together under an encounter. How will we represent these Obs ? Some of them might be allergies, others may be conditions or diagnosis etc. Basically, what we could do is,

A. Figure out which obs can be categorized as an allergy (recommend using concept class, or if that’s missing, then maybe a concept defined as a global property)

B. Next, check which other obs can be grouped under whatever other FHIR resources (such as diagnosis or condition). If any obs that the OpenMRS FHIR module can support exists, then they would be identified based on concept class or a global property, and new FHIR resources created.

C. In each case, we have different strategies on how to model allergies, diagnosis or conditions etc. based on the underlying data model. Each of these resources will be built based on the appropriate strategy selected based on the underlying OpenMRS data model.

D. All other obs that didn’t fall into any of the FHIR categories supported by OpenMRS be represented as plain old FHIR observations

Thoughts ? comments ? glaring mistakes ? :slight_smile:

The steps needed would vary depending on the version of OpenMRS being used. Assuming OpenMRS 2.2+, allergies and conditions are first-class citizens, so there’s no need to worry about converting from obs. If the FHIR module needs to support older versions, then you may need to convert obs into conditions and/or allergies for the appropriate FHIR representation.

Hi @burke, @darius et. al.

To resume this thread, we’re about to begin work on implementing allergies and conditions using FHIR :smile: We had a conversation on the dev list regarding this, and @darius advises that the best way to identify generic obs as allergies is to identify which concept id’s denote allergies using a global property.

Now, we’re thinking about conditions. I see that we’re implementing condition objects for OpenMRS 2.2, and that its already been done at

But how would we identify generic obs as specific conditions? Would you foresee any reasons that we should NOT do this by identifying conditions using a global property?

Also CC’ing @harsha89, who should be aware of these plans :smile: