To keep everyone informed of a recent conversation @sashrika and I had.
Lets say that you’re using FHIR to update an obs. A client sends a POST that basically reads, “Update Obs identified by UUID XYZ”. As you know, the OpenMRS API will do this by creating a brand new obs, and giving it a new UUID. And so, if the same client were to try and retrieve it using the UUID that they know of (XYZ), they won’t be able to obtain the newest info.
My recommendation is that we ensure that FHIR returns the uuid of the new object as part of the response sent to the client whenever he creates or updates any resource. The uuid can be returned as part of the MethodOutcome and thus, the client will be aware of the newly updated resource.
In the Java API, and in the REST API, when you edit an existing obs, the
call return the newly-created obs, with a new UUID. So the client would
need to actually look at the UUID or “self” link in the response.
Looking through the OpenMRS API, not every element of the data model behaves this way. For example, Person and Patient objects can be edited, while Obs itself results in a new UUID being generated.
I recommend that we return the uuid’s of each object for both creates and updates, irrespective of wether a new UUID was created or not. This way, the user doesn’t need to know how the OpenMRS data model behaved. Rather, he is simply aware of the uuid (new or existing) that was returned in response to an action. Does this make sense, @harsha89?
@surangak yeah that would be the better way. We are sending the uuid back to the client when resource creation always. Should do the same for the update as well.
Peeking at the definition of the FHIR Observation resource, I see that you can have a “related” observation with “type” of “replaces”, which is defined as
This observation replaces a previous observation (i.e. a revised value). The target observation is now obsolete.
That seems exactly analogous to the OpenMRS API situation. So, my suggestion is that a POST to the observation resource should return the actually-created observation, and if it was an edit then the original obs is referenced via “related”.
(This comment takes precedence over the one I just emailed, that hasn’t appeared yet…)
@darius Yes we can have a link to old Obs resource through the related attribute in FHIR. So we are good with that aspect. Thanks for pointing about it @darius.
