With the plan to rollout dispensing into implementations, a new requirement came up with the UgandaEMR team to be able to attach a dispense location to the Medication Request for example a hospital that has more than one pharmacy. This will also in effect be used to filter dispense requests by location. This location can further be used to allocate the pharmacy location based on stock availability.
Taking a look at the current MedicationDispense we have the performer mapped directly from the MedicationRequest FHIR resource. We have the option to use HealthCareService. This change would ofcourse require changes to the typing within the dispensing esm.
@pirupius so it sounds like this is something that the person ordering the prescription would specify? Are you planning on modelling these locations as OpenMRS Locations?
I think the closest thing to a “right” place to store this (interested in @ibacher 's thoughts though) would be the “dispenseRequest.performer” on Medication Request, not the top-level “performer”. This is supposed to be an “Organization”, but I think we’d want to model this as a Location in OpenMRS.
Then, on the Medication Dispense, we’d store this in the “location” field (which we already have in FHIR and in the OpenMRS data model).
I think this would be (relatively) easy to handle on the Dispensing side… it’s the Medication Request side that is trickier, because once we decided where in the Medication Request model we’d want to store this, we’d likely need to expand the OpenMRS Order object (which is where Medication Requests are stored in OpenMRS). And assumedly if this is collected at order time, the O3 order basket would need to be expanded to support collecting this (on a configurable basis).
This also seems like something that could be good to discuss on a TAC. fyi @burke
I assume you mean dispenseRequest.dispenser? But that seems like the right field to me. Organization is probably more correct than HealthCareService. We’ve had a couple of use-cases where mapping OMRS Locations to Organizations seems to make sense, but I think we need some agreed-on protocol for how we model those locations in the backend. My inclination is to just add a location tag, but it probably needs to be a slightly longer discussion to work out how much detail we would ideally like to capture (technically orgs, like locations, can be nested, so we’d want to think about how the hierarchy of locations corresponds to the hierarchy of organizations)
@pirupius thanks for this. It’s something I think we will need eventually also. I’m curious how you will be handling it on the ordering UI. Would the ordering provider specify the location? I could imagine the location being defaulted based on either the form (if it is from a form) or the logged-in location. E.g. if it is being ordered from the Women’s Health ward it defaults to the Women’s Health pharmacy.
I don’t think 6 is stable enough given that it’s a new release. Also, I am wondering if we support FHIR 6 in the FHIR2 Module.
My thoughts would be to include a fulfillerLocation in the Order object which can then map to supportingInformation which is a reference of (Any). Idealy this is supportive info for a fullfilfer to determine where to fulfill the order from. That way was could avoid lots of changes.
@slubwama we definitely don’t support FHIR 6, but could go with the FHIR 4 field, which is “dispenseRequest.performer”, to store this.
The idea of creating a new “fulfillerLocation” sounds reasonable to me, and makes it consistent naming with “fulfillerStatus” but worth discussing.
I’m definitely happier with fulfillerLocation than fulfillerStatus as a concept for orders. We should probably discuss this on the TAC this week before any implementation.
As I indicated above, I’d really prefer we had an opportunity to work through this a bit before just making a core data model change. While I don’t think there’s anything per se wrong with it, some of the things we’ve rushed to implement in core in the past are a little limiting (fulfillerStatus is kind of an example of that; it’s fine, but only for very limited use-cases). Changes that we make to core are generally less easy to undo if we decide there’s a better way to handle something, so it’s kind of important to get things right.
@dkayiwa On exploring Order Attributes, there were no webrest APi’s associated orderattributes or orderattributetypes. I have gone ahead to raise a ticket to and also created a PR that introduces webrestapi for these.
@here We will also need to discuss strategy on how we will be mapping orderattributes to fhir elements. We might need to agree on orderattributes to use and possibly add them to a core module that distributes metadata across all distributions. This is to make sure that those attributes are reserved just like DrugOrder and TestOrder are known across all distributions. Suggestions are welcome