How can get the Link to FHIR Encounter resource and Link to FHIR Provider from OpenMRs Obs to be assigned to FHIR Condition encounter and asserter. I found this topic, but still unclear of the correct way to get these:
I tried searching but couldn’t find a document that descibes Obs to be represented as conditions. [FM-66] - OpenMRS Issues specifies that these can be identified as those with Problem Added and Problem Removed concepts from the original 2005 AMPATH concept dictionary. Can someone please provide any link to this resource.
This is something we need to figure out the best approach to do. AFAIR there is no clear distinct way we can map Obs to a FHIR Condition we might need some brainstorming session.
Your initial attempt is good. Also not everything is possible to map with OpenMRS Obs to FHIR Condition and vice versa.
Can post some details on FHIR Condition resource and it’s representation and challenges that we have?
@tharaka, for this specific ticket, you’re trying to determine how to only represent conditions that are stored as Observations. Initially, I think that the way to do this would be to have a global property where users can specify which concepts represent ‘conditions’, meaning that this strategy would take all Obs linked to any concept identified via that global props, and represent them as conditions.
In FM-66, I said that the concepts ‘problem added’, and ‘problem removed’ may be the concepts that represent conditions.
What if you create a global property that can be used to store whatever concept id’s that are meant to be conditions, and set its default value with the concept id’s of ‘problem added’ and ‘problem removed’? that way, this global props can be used to indicate whatever concepts users think are conditions.
That makes a lot of sense. And that kind of method would also best fit in ObsConditionStrategy.
But there we will get the whole set i.e a list of Conditions. Is that what we need finally in the FHIR condition resource web layer. Or should we have both @Read and @Search methods.
That unclearness is hopefully cleared by the @surangak’s suggestion of using a global property. Still the problem added and problem removed concepts are bit unclear to me. Are there any documentation on these. I found following two wikis. Are there any other documentation or an example to look at regarding this?
What will be the final result of calling to the FHIR Condition web layer? Will it be a list of conditions? Or will it be the Obs with a given id, like what is done currently:
What I have in mind is to return the Observation with the provided ID. When mapping is done we would only match if the Observation is linked to one of the concept identified via the global prop. Is that what you exactly meant?
I hope this is about implementing the method getConditionById(String uuid) in ObsConditionStrategy class.
Can you please have a look and let me know whether I am moving in the right direction.
What will be a good key for global property. I thought of giving the IDs of concepts which can represent conditions as a comma separated string. At the moment I have used “fhir.concepts.conditions”. Will that be a good choice?
In web layer, there can be multiple search options. The main straight forward seach is get condition by uuid or id. Based on the strategy, it may return a observation or related object mapped to a FHIR Condition object.
@surangak when we asked for a getConditionByUuid, it means the Obs uuid where we should mapped Obs to a Condition right?
@harsha89, I have added test case for the getConditionByObsId method in ConditionService class. I will also add test cases for the previous methods also. Can you please review it.
I have addressed the review comments at PR. Still I need to find out how to map the asserter. In mapping the FHIR condition encounter I used FHIREncounterUtil private method, buildPatientReference() mehtod. If this mapping is correct I hope we can change the access level to public in FHIREncounterUtil. I didn’t do that as I was worried about API changes. Please let me know if it is ok to change the access level.
Yes those concepts are coming from global properties as @surangak said. We need to verify the mapping of encounter and have to find out mapping of asserter. @surangak What do you think?
