Referrals in OpenMRS

[ibacher (Ian Bacher)]

@pmanko @mozzy Re: our conversation on this very value set.

[ibacher (Ian Bacher)]

@burke

But these abstract locations could also be accomplished with location_id if one defined locations for the abstract locations

What about pursuing the idea of having multiple possible location values, like we do for Obs values? E.g.,

• location_id
• location_concept

This complexity could be hidden from the user in much the same way that the Obs value is (thus if you say “the hospital lab” it might be a location_id, but “home” might be a location_concept)?

[burke (Burke Mamlin)]

@ibacher

• location_id
• location_concept

This complexity could be hidden from the user in much the same way that the Obs value is (thus if you say “the hospital lab” it might be a location_id, but “home” might be a location_concept)?

I considered this approach, but didn’t think the complexity for API usage might not justify the benefits. That is, if abstract locations (like “Home”) can be created as locations, then we’d avoid making location-specific concepts and avoid the complexity – e.g., if both location_id and location_concept are populated which takes precedence, clients don’t know if they’re going to get a Location or a Concept, etc. The benefit of this approach (use just using concepts instead of locations) would be localization support of concepts.

Given all this, perhaps a slight tweak of your suggestion might work, e.g.,

• location_concept (FK to Concept)
• specific_location_id (FK to Location)

Meaning we anchor on collecting location as a concept, using a value set as FHIR suggests & benefiting from localization. In those cases where someone needs to provide a specific (non-abstract) location, they could choose from locations and we’d store that as additional location info. Both of these would be optional fields.

[angshuonline (Angshuman Sarkar)]

@burke

Does anyone see a potential problem with allowing implementations to define abstract locations (like FHIR’s list of location roles) within their OpenMRS locations table when/if they want to order tests or referral to be performed at one of these abstract locations (e.g., “Home”, “Extended Care Facility”, “Outside Hospital”, etc.)?

Makes sense. In that case, we will prob need 1 additional attribute “locationCode” which can have codes from the FHIR valueset, although I do not assume such details are needed. Another option is to use the “location tags” - and once you select. that, only the locations tagged with a specific tag can be shown.

this imo, will be closer to OMRS ref model.

If you would use concepts to indicate the locationCode, then we will have to have some other mapping or convention to show the list of locations that can entered in “servicerequest.locationreference”

[angshuonline (Angshuman Sarkar)]

at the same time, having ref to concept for codes is also ok as it provides means of mapping to different code systems.

[burke (Burke Mamlin)]

After discussion on today’s Platform team call, we decided to implement service order (and thereby referral orders) location as a concept. Having a specific location (pointing to OpenMRS Location) can be added in the future if/when the implementation need arises.