patient_id field of userinfo . This is the id of the Patient resource associated with our user. It will be used further in Access Policies to decide if access should be granted or not. In general, you need to specify data.patient_id: some_patient_id in your User resource to establish a relation to a Patient resource.‌access-token field of user-info will be needed to perform requests on behalf of our User. See here how to perform user request with a token.GET access to a URI that matches #/Patient/.* regex if the request parameter named resource/id matches data.patient value of the user that makes the request.‌/Patient/, namely new-patient, is parsed by Access Policy engine as the resource/id parameter of the request:new-patient1, will be denied./Encounter and it doesn't contain any additional parts that could be identified as request parameters as in the previous case. So, in order to provide the required request parameter patient to the Access Policy matching engine, we have to specify it as the query parameter of our request. And after the Access Policy engine allows such a request, the Search Engine comes into play. It filters out encounters that do not match the condition of patient = our-patient-id. To know more about how the AidBox Search works, see the Search section. To know more about the available search parameters, refer to the Search Parameters section of the FHIR documentation for the resource of interest.CompartmentDefinition resource.CompartmentDefinition resource, we can access patient-related resources with such requests: GET /Patient/{patient-id}/{resource}. To know in detail about how compartments work, see the Compartments tutorial./Patient/.* regex.CompartmentDefinition resource that we've created earlier. See FHIR documentation to know what resources can be added to a patient compartment. And we can get rid of the Access Policy that was previously created for encounters.CompartmentDefinition approach to grant write access to many resources at once, as we did previously for read access. That's because resources may require sophisticated logic to define which part of a resource could have write access and which not. Such logic may even lie beyond the abilities of the Access Control mechanism and in this case custom API is the only resort. But in a quite simple scenario like the creation of observation, Access Policies are helpful.PATCH method. Matcho engine is no longer enough to make a rule for this kind of request since it only relies on the request and the user parameters. Now we need to peek into the requested resource to understand if it is related to our user and could be patched.User resource with the list of related patients. Let's define that Patient-2 is related to User-1.User-1 access to related patients, we should simply update patient-access policy.