Representing FHIR specific value sets in OpenMRS

Hi @burke and @akanter,

As we work on implementing support to consume FHIR resources, we’ve discovered that there are a number of FHIR specific value sets that we must deal with.

For example, The DiagnosticReport Resource: contains service category and status fields that can contain one of the value set values listed in and respectively.

These are FHIR specific value sets, and may be posted into OpenMRS by a third party client. Given that there are so many, and that they can be so diverse, I believe that the best way to support these would be via the concept dictionary?

CC @harsha89 and @milan

I think we should incorporate these, although when some require 1000’s of codes, my guess would be to only include those relevant to the particular use case. We need to decide how to capture the information which links them to the value set (such as the OIDs) and include a process for updating them. Traditionally, we have used an interface terminology map so that the main concepts don’t change, but the reference maps to the value set entries might. What about using something like a reference source of OID followed by the code (OID:code)?

Agree that mappings (reference terms) would be a better fit for these value sets than putting them in the local concept dictionary.

Thanks! so I we’ll be adding mappings, but only relevant ones that are truly needed.

I think that the best place to start off would be the DiagnosticReport resource: The first field to introduce FHIR specific value sets is ‘names’, but we shouldn’t add those by default because there can be tens of thousands: On the other hand, status: should be added because they’re so few, and all relevant. I also think we should incorporate service category:


@akanter, sorry just wanted to confirm; did we reach a conclusion on this topic? as I understood, you are ok with adding the “essentials” as listed above? :sunny:

Yes, but I would need a JIRA with specific entries listed and included in the new terminology and metadata project. Thanks, Suranga!

Hi, thanks! I just created the following ticket:

It seems that I don’t have rights to edit ticket descriptions or create epic tickets under the TERM project, but I tried to do the best with the permissions that I have. Is the information listed here enough for your needs?

@milan, please note, this is the process you’ll have to follow as you identify new mappings that are required by FHIR :sun_with_face:

@surangak Noted down it!. :smiley:

Basically, the fields like status, serviceCategory are going to be stored as Concepts. But there isn’t any filed in OpenMRS Encounter to store them. Anyway, OpenMRS Obs have a filed to store them.

Are we going to store these Concept values in Obs and then store them inside Encounter? This is the idea now I have in my mind after draft reading through these references: