Updating Person Name and Address via REST web services

Projects FHIR
,
1

Hi all, (Specially copying @harsha89 @surangak @darius )

We are in the process of implementing updating Person Resource via FHIR module. We found that updating a Person Name and Person Address is bit complex. Sample Person name representation according to the FHIR specification is

"name": [
	{
		"use": "usual",
		"family": [
			"asd"
		],
		"given": [
			"abc"
		]
	},
	{
		"use": "old",
		"family": [
			"waid"
		],
		"given": [
			"Sashrika"
		]
	}
 ],

updating these names on the server is problematic. because in the JSON representation, names are not associated with the name UUIDs. So we can’t map which names are actually needed to updated on the server.

So what Harsha and I discussed was not allow to update an existing name. And if there is names on the JSON body (of PUT Request) we consider them as new names and add them to the Person as new names.

We would like to hear from the community is there anything else we can do on this matter.

Thank you!

1 Like
2

As we discuss offline, since there is no other way to associate uuid of names and addresses with fhir request, possible alternative is the one that @sashrika suggested in the reply.

I also raise this concern in fhir list also. According to fhir specification update will create a resource with new version or create new resource if there is no resource exist with given id. Since we don’t have version concept, we may either check whether similar names or addresses found while iterating through the person that currently reside in the database. If we found similar one we can update it and else we can create new one. These possibilities are there. @surangak any thoughts?

1 Like
3

@harsha89 @surangak the problem we have is the Person names are not ordered. Even if we use TreeSet to hold the names, the order can be changed later when user changes the preference of the name. The preferred name always becomes the first element in the tree, as I figured out. Otherwise we could have updated the names just in the order they appear, since the names cannot be deleted permanently. I think this is why FHIR doesn’t specify any additional way to identify the mapping of names/address.

Updating a name/address by looking at their similarity can make changes in the server which was not expected by the user. Some times this can work. But we can avoid all the negative possibilities by enforcing a constrain like, user will not be able to update an existing name/address via FHIR.

4

Yeah, this is complicated.

I think that creating everything that is included in the body of the message makes sense. For example, lets say a person has the name ‘Sachin Tendulkar’. The PUT request contains a new one, “little master’. So basically, we don’t check if the name ‘little master’ already exists, but create it anew. On the other hand, if the ‘little master’ name already existed, the API would throw an error. Then we know that it already exists, and set its identifier type to 'Old” or ‘preferred’ instead.

Questions: for PUT, when beginning to modify an existing person resource by adding names, would we start by retiring all the older names that the person object already had? or would we simply let them be? For example, if the person object had the name ‘John Travolta’ but the PUT request did NOT have that name, what happens to the person name in the OpenMRS data model? does it live on, or do we retire it?

Also CC’ing @burke for input :smile:

5

@surangak I think we shouldn’t retire. Also from HAPI end, they said when update happen, it will copy the existing resource content and then update with the latest fields. So if we have some kind of matching, then we are good to keep rest of names and addresses. @sashrika just check whether there is some “use”: “usual” value which indicate whether name need to be deleted or not. Those are in AddressUseEnum.