I am going to put here my findings and discussions we held so far
I went through the documentation on wiki about FHIR Resources and I found that some parts are not properly documented. As an example Delete operation in Person Resource(https://wiki.openmrs.org/display/projects/Person+Resource) is listed under POST operations. There are few similar mistakes and I hope to correct them in the community bonding period ( I suppose that is allowed ).
Also update operation in Location resource is only partially implemented. Creating a new resource by the PUT method is not implemented. Anyway this is not documented in the wiki page. Can you please give me a sample request and the json body that i can try out with this update operation(only if such a sample request is available)?
To date,
Create operation is only implemented in Person Resource.
Update operation is only implemented in Person and Location Resource.
Delete operation is only implemented in Person,Patient, Location, Observation and Encounter Resource.
As we discussed we are interested in implementing create,update and conditional updated under this project. I’ll create tickets for each of this resources as @surangak requested.
The general plan is first to develop create operation, then update operation and conditional updates.
I had to update the docs for this, but have been devoting all my time to the OAuth module since last week. I would like to complete this ticket soon. If you wish to add the docs and make other modifications, feel free :). I will un-assign myself if you would like to work on the ticket this week
I did create a Location if none is found with the uuid in the query. (see line 96 of FHIRLocationUtil.java here ). I think we could add a test to check if new Location is being created when none is found with the query uuid.
You could do a GET Location resource request to get a sample json body and make some changes to it.
Here is a video showing the sample update operation
Also, the current DELETE Location implementation uses Context.getLocationService().purgeLocation(location); (in LocationServiceImpl.java) . The FHIR specification states : (@seedelete)
Resources that have been deleted may subsequently be brought back to life by PUTting an update to them subsequent to the deletion.
The UPDATE operation will un-retire any retired locations, but if we want to support this feature, then DELETE operation should support retiring (via LocationService#setRetired(boolean)) the location rather than purging it. @harsha89@surangak@vaibhavhp. what do you say?
@sashrika, also, a possible limitation in the current implantation of UPDATE Location operations is that clients are passing the uuid as a request parameter to the FHIR module. If no resource is found, then we cannot generate a new Location resource with the same uuid provided (can reduce integrity of the database) as uuid generation should be left implicit to OpenMRS.
A possible solution would be to create a new Location and forward it’s uuid in the Response object. I tried looking this up on FHIR specifications earlier, but it might require some more digging
@maany, Thank you very much for pointing this here You have done a good job
I saw the implementation of the create location method. The problem was I didn’t expect that code in Utility class. May be I can do a code refractoring later.
If you wish to complete the ticket you mentioned, no worries But I understand you have other commitments as well. In that case if you un-assign the ticket I can progress on it.
Thanks for the video.
I also think retire would be suitable rather than purging it.
Good Conversation folks. :). @sashrika I hope @maany has answered most of your questions.
As our offline chat with @surangak we stick not to purge objects and just to retire them within the system on a DELETE request. :). So make sure delete request will retire the object.
@sashrika, also, a possible limitation in the current implantation of UPDATE Location operations is that clients are passing the uuid as a request parameter to the FHIR module. If no resource is found, then we cannot generate a new Location resource with the same uuid provided (can reduce integrity of the database) as uuid generation should be left implicit to OpenMRS.
Agree that we should let OpenMRS to decide the uuid. I think @sashrika we had the conversation before also. We talked about having standard uuid scheme validation if incoming request is associate with uuid. If that the case we need to do some validation to align it with OpenMRS uuid scheme.
@sashrika create tickets for each defect and fix them. :).
Let me know if you have more questions regarding this.
I think we need to think about the UPDATE bit more depth. How we going to update existing fields and when to add new data.Some kind of matchin algorithm, may be bit we need to bit of research on matching algorithm where we can find matches with existing resources and update them if incoming requests are contains them. For Ex. say client going to update the person name attribute John Snow to Johnn Snow, we might look at the similarity of exiting attributes of the person with the update request person name attribute and update them. It will be bit tricky and would be good to have :).
Yes,I do agree that some parts are not properly documented. I missed completing documentation of few tickets like FM-76,FM-70,FM-71. Yes, you can correct them for sure
[quote=“harsha89, post:5, topic:1838”]
If that the case we need to do some validation to align it with OpenMRS uuid scheme.
[/quote] Yes @harsha89 perhaps we can add a utility function for do the utility validation.
[quote=“harsha89, post:5, topic:1838”]
It will be bit tricky and would be good to have :).
[/quote] Agree with what you saying. Let’s keep you thought in mind. But my concern is this can over complicated things for the end user. And the result could leeds to a state which the end user never expected. Problem lies in the data structures used in OpenMRS for save names and addresses.
).
I saw the implementation of the create location method. The problem was I didn’t expect that code in Utility class. May be I can do a code refractoring later.