When hitting the endpoint of a root FHIR resource, the read operation should return a listing of its resources, AFAIK. For instance, a GET /fhir/Patient/ should result in a Bundle of Patient resources. What I was wondering is how this (or these, if filtering in some way) listing is/should affected by the current user’s authorization level? Normally, for single resources I would return HTTP 403 Access Restricted along with the right OperationOutcome, but should some kind of filtered version of the restricted Patients be included to notify “something” was there, or should one just list the ones one would normally have access to (ie. HTTP 200 and the Patient resource)?
you should definitely only show the user what they’re authorised to see. Whether to simply omit them or tell the user they’re there but not visible is a business decision. However most security experts will tell you that telling the user there’s information they can’t see is an information leak that they can use anyway, and that you should simply not return them. For a similar reason, most experts will recommend returning 404 not found not 403 not authorised, unless the user could change their authorization level and get access. So the spec doesn’t make any rules about this - it’s up to you and your risk analysis
1 Like
Thanks. I just read a related and very interesting discussion on FHIRBlog that concerned just this. They went for the indicate something is missing approach, but I do see this is up to each implementer:
If the user is unable to access a patient – but is allowed to know that they are on the list then that is just another annotation – but what to do if they aren’t even allowed to know? Maybe the patient is a VIP of some sort? We should let the client know that the list is incomplete, but no more than that.