Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional Create in transaction Bundle not working for Observations when the identifier is used #2653

brianreinhold opened this issue May 12, 2021 · 3 comments · Fixed by #2658


Copy link

brianreinhold commented May 12, 2021

NOTE: Before filing a ticket, please see the following URL:

Describe the bug
If I do an upload of a transaction bundle with conditional creates twice, I expect that the second upload will return a status of 200 OK. That is true for the Device and Patient resources, but not for the Observation. All the conditional create options for the 'ifNoneExist' use the identifier.

To Reproduce
Upload the attached transaction bundle on the R4 version.
Upload the same bundle again.

Expected behavior
Only one of the resources on the second upload should result in a 201 create, but all the Observations are recreated. One can then go to the server and do a search on the very identifier used and you will get multiple duplicates of the Observations.
For example the identifier here:


There is another problem. The response I get after the upload (though a 200) does NOT contain the standard Bundle response for a transaction. That is a second bug.

Environment (please complete the following information):

  • HAPI FHIR Version R4
  • OS: [e.g. iOS] Windows 10
Copy link

jamesagnew commented May 13, 2021

Hi Brian!

I spent some time staring at this pondering how it could possibly not work, given that conditional creates are really basic and used all the time. Eventually it hit me: The issue is this part of the ID: 444+0800

It's completely fine to have a plus symbol in an identifier, but of course when you create the IfNoneExist expression, it's a URL and it needs to be URL encoded. And wouldnt you know it, a + translates to a space character when we unescape the URL.

So the solution is to escape the + in your URL.

I am gonna leave this ticket open though- I think it would be reasonable for HAPI FHIR to be lenient here and not unescape plus symbols. I can't imagine a situation where someone would actually want a space character in their URL and intentionally put a plus symbol there to represent it. Or at least it seems way less likely than the opposite...

Copy link

brianreinhold commented May 13, 2021

James! Thanks for that. I would have NEVER guessed that a '+' sign would need to be escaped. I will give it a try and see if it works

%2B is the correct escape. At first I got an error but the problem is that I have all those previously uploaded resources and now it will fail. Bummer! But thats the way it is

Copy link

FWIW feel free to delete the previously uploaded resources. It should work fine after that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging a pull request may close this issue.

2 participants