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.
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?
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)?
@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?
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
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:
