When integrating OpenMRS with other systems, sometimes there is a need to be able to create a FHIR resource originating from another system with an externally generated id by which it can be referenced, this enables a workflow where a client can first perform a look up before creating any new resource to avoid creating similar resources with different ids.
Currently, the FHIR2 module does not support a client to provide an id when creating a new resource however, from the FHIR specification a server can support it.
When this feature is added, it can be implemented such that it can be disabled or enabled, where by default it is disabled.
I’m less open to this particular request. For the most part, there’s no consistent mechanism to mapped “voided“ data to FHIR. For operations that need to happen at that level, it’s best to just use the OpenMRS API. Note, though, that I think you should be able to do a GET request for a voided object via UUID; they’re just filtered from the search results.
I don’t necessarily have an issue with implementing FHIR’s update-as-create mechanism for certain domains, though I think we need to be selective here as, e.g., update-as-create for orders or obs is likely a non-starter as they are “immutable“ from OpenMRS’s perspective or at the very least would need very special handling.
@sharif I’ve closed that ticket. Let’s work out what’s being implemented first before we create a ticket for it.
I’m fine with supporting upsert operations for specific resources, this sort of aligns with making the feature configurable i.e. admin configures the operation for specific resources, when no resource is configured, it is equivalent to being disabled.
As for retired/voided data, I’m aware that the REST API has support to return retired/voided data and it’s what we’re currently using, we were just hoping to use FHIR only for the integration without REST too. I guess we can live with this especially if the FHIR specification suggests that voided/retired resource should not be returned by the read operation.
It’s more that FHIR doesn’t have a consistent idea of “soft-deleted“ data that’s queryable. While we could support it through an extension / custom search parameter, it seems important that, for the most part, the data we return from the FHIR API is valid data. “Retired“ is somewhat distinct from “voided“ in this sense, but again, most metadata domains aren’t exposed through FHIR.
Yes, but I’d prefer that it’s targeted to the domains we want to support immediately. We also need to consider if there’s some sort of rule we need to prevent clobbering data.
For OpenMRS data I agree with you about a possibility of clobbering data like orders, our use case for now is Medication resource (Drug) which is metadata so I don’t think we should worry about clobbering when dealing with metadata. In regard to your concerns, we will restrict the feature only to metadata for now, and if we want, we can will still require the admin to configure which metadata resources to support upsert.
I’m bring this conversation back up, as I’m currently trying to use the FHIR2 module to transfer data between two OpenMRS instances (specifically in this case MedicationDispense objects, but it could be anything in the future) and for that to work properly I need to preserve id/uuid.
Can we open up the discussion of whether we want to restrict this to metadata (not data).
Not sure why this is a non-starter… they are immutable, but there’s no reason we shouldn’t be able to create them with a specific uuid, right?
The issue is how we handle the case with a update-as-create where an obs with that UUID already exists. It’s a non-issue if we confirm it doesn’t exist, but the semantics of update-as-create are meant to be similar to an upsert, which is problematic with obs if it already exists.
But we should be able to figure that out, right? It’s possible we wouldn’t have to do much because the underlying save handlers and validators may already do the right thing and throw an error if you are trying to do something you are not?
It seems clear (to me, at least) that we need a way to specify the id when creating any piece of data/metadata if we plan to have FHIR2 be a way to transfer data between OpenMRS systems, but up for hearing arguments otherwise (or arguments that this isn’t a use case FHIR2 should support). Is there any way to support this in FHIR beyond “upsert”? (the POST specification does not allow setting the id/uuid)
Been a while since I read through this part of the spec. So I think we could make this work, but just for domains like Observation and Orders return something like a 409 error is the UUID already refers to an existing obs or w/e. Does that make some kind of sense?
I’ll dig deeper @ibacher … it looks like Observations already support updating in some manner (at least the updateObservation method already exists). I can play around to see what it already does.
And it looks like we don’t currently support creating MedicationRequests at all, see: Jira
I guess a broader, meta-question is: do we still foresee FHIR being our long-term path forward (vs REST WS)? One of the reasons I went down this path was that there is no REST WS support for Medication Dispense, I could add that, use that for my use case, and be done with this in the short-term. But also happy to work on making FHIR better.
On FHIR in OpenMRS itself, the primary goal is sharing data with systems that are not OpenMRS, i.e., where we don’t necessarily need full object-level fidelity. That said, we should add whatever we need to support the full functionality of OpenMRS.
I think FHIR isn’t a bad place to start for data synchronization, but I don’t think it’s the right representation for most metadata in most cases.
Sorry, @ibacher I pivoted and added what I needed for MedicationDispense REST WS, but I did push up all the work to-date and documented on the ticket in case this comes up again (I still think it is something we will want if we use FHIR2 extensively)