Is your feature request related to a problem? Please describe.
Currently, fhir-smart controls "direct" (read, vread, delete, and history-instance) access to the Patient resource based on the resource id.
For almost every other resource type, its based on compartment membership instead.
Describe the solution you'd like
With a patient/Patient.read scope, a user should be able to access the Patient resources that are linked to the in-context patient.
Describe alternatives you've considered
Acceptance Criteria
-
GIVEN a Patient resource on the server with a link to a specific patient (e.g. Patient/123)
AND a valid access token with a patient_id that includes that patient id (e.g. 123)
WHEN the user performs a direct interaction (read, vread, delete, and history-instance) with that resource
THEN the interaction is permitted
-
GIVEN a valid access token with a patient_id
WHEN the user attempts to performs a direct interaction (read, vread, delete, and history-instance) with any Patient resource (existent or not)
THEN the interaction is rejected with an HTTP 403 (Forbidden)
Additional context
I think the reason we originally prohibited any interaction with any Patient resource with any other id was because we didn’t want to leak whether or not that other patient id was a valid id. If the patient doesn't exist it still needs to be a 403 (not a 404).
Is your feature request related to a problem? Please describe.
Currently, fhir-smart controls "direct" (read, vread, delete, and history-instance) access to the Patient resource based on the resource id.
For almost every other resource type, its based on compartment membership instead.
Describe the solution you'd like
With a
patient/Patient.readscope, a user should be able to access the Patient resources that are linked to the in-context patient.Describe alternatives you've considered
Acceptance Criteria
GIVEN a Patient resource on the server with a link to a specific patient (e.g. Patient/123)
AND a valid access token with a patient_id that includes that patient id (e.g. 123)
WHEN the user performs a direct interaction (read, vread, delete, and history-instance) with that resource
THEN the interaction is permitted
GIVEN a valid access token with a patient_id
WHEN the user attempts to performs a direct interaction (read, vread, delete, and history-instance) with any Patient resource (existent or not)
THEN the interaction is rejected with an HTTP 403 (Forbidden)
Additional context
I think the reason we originally prohibited any interaction with any Patient resource with any other id was because we didn’t want to leak whether or not that other patient id was a valid id. If the patient doesn't exist it still needs to be a 403 (not a 404).