FHIR Chat · Search when authenticated as a patient · inferno

Stream: inferno

Topic: Search when authenticated as a patient


view this post on Zulip Lakshmi Bhamidipati (Feb 19 2021 at 23:32):

Hello,
When I am authenticated as a patient and have a patient token, the tool allows search using name, birthDate etc..
../Patient?birthdate=1990-01-01&name=Defect ,
We coded such that the FHIR server returns an access violation (a patient should not be allowed to search another patient's data) .
The Inferno test is expecting a success.
Please advise.
Thank you.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 14:31):

There is the assumption on the US Core 3.1.1 tests ('Single Patient API' for ONC Standardized API certification) that a token is being used that provides sufficient access to perform all required US Core searches. Otherwise we have no way of verifying support for all required US Core searches. In other words, a token with full access to the required searches is prerequisite for the test.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 14:33):

It isn't clear to me that your implementation is the proper behavior. Another way for you to handle this search is to allow patients to search by birthdate/name, but restrict it such that it will at most return their own patient record.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 14:48):

Just like how a patient doing a search with a patient-scoped bearer token for Condition?patient=[my_patientid] needs to return records if they exist, but searching for Condition?patient=[someone_elses_patient_id] must not return any records. Abstractly it would be more consistent to have the search by birthdate/name be the same, where searching by their own name/birthdate gives them back the record they have access to (their own), and searching by someone elses name/birthdate does not return any records.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 14:51):

However, I can't think of a reason why allowing patients to search for their own record by name/birthdate is useful, and I'm not aware of anywhere that states that your interpretation is invalid (just deny patients ever from searching by birthdate/name), so the other option for our testing is for you to use a user-level token that does have access to searching by that to demonstrate support.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 15:08):

This may be a good question for @Brett Marquard and @Eric Haas . Do patients need to have access to searching Patient?birthdate=[their_birthdate]&name=[their_name], which will return their own record if they put in the right birthdate/name? Or is it valid for systems to decide to deny the whole search because it isn't intended to be used by patients using a patient-scoped token?

view this post on Zulip Lakshmi Bhamidipati (Feb 22 2021 at 16:48):

@Robert Scanlon - Thank you. For patient scoped tokens, as you mentioned, I guess we would have to code such that the search result returns just 1 record (ie the patient's own record) if there is a match with DOB or identifier or name, instead of throwing an error.

view this post on Zulip Eric Haas (Feb 22 2021 at 16:49):

I agree the logical intent of this particular search is for providers and agree this is expected system behavior:

Another way for you to handle this search is to allow patients to search by birthdate/name, but restrict it such that it will at most return their own patient record.

We have not considered the intersection of scope and search in the IG and am reluctant to consider it unless the community sees it as a critical issue.

view this post on Zulip Robert Scanlon (Feb 22 2021 at 17:21):

@Lakshmi Bhamidipati -- yes, that is what you would need to do to pass the tests while using a patient scoped token. Which sounds like the expected behavior based on @Eric Haas's response. Though to be precise, you only need to support DOB searches when paired with name as defined in the mandatory search parameters section. Though you can support searching by DOB without name too if you'd like.

view this post on Zulip Lakshmi Bhamidipati (Feb 22 2021 at 18:32):

@Robert Scanlon - Other mandatory searches need to follow the same logic too, correct? -
SHALL support searching for a patient by a string match of any part of name using the name search parameter
SHALL support searching using the combination of the gender and name search parameters
SHALL support searching a patient by an identifier such as a MPI using the identifier search parameter
Thanks!

view this post on Zulip Robert Scanlon (Feb 22 2021 at 18:45):

Yes, the same logic would apply to all mandatory searches on the Patient resource.


Last updated: Apr 12 2022 at 19:14 UTC