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.