Dear Team, Thank you for building the access policy layer. I understand Access policy use for direct relational restrictions and access ex Patient can see only diagnostic reports belongs to him/her. But I am not able to figure out how can I restrict media which only belongs to the Patient or Physician who needs to review specific report and not having all media read only. Please refer the attached image with Red line where I want Patient to access only media which belong to their report, or physician could see it as they need to approve the report. @rahul1 @reshma

Hi @jay_stark , sorry for the delay. This is a good question, as access policies on transitive resources can be tricky

Hi @rahul1, I am currently working on implementing the access policy and trying to give access only to those resources which are direct or indirect associated to the patient or practitioner. I am facing error “column reference organization is ambiguous” while adding criteria based access policy. Can you guide what wrong are we doing? Due to limit of the discord I am adding few resources setup in Access Policy as an example. Below is an example policy I'm working with:

json
{
  "resourceType": "AccessPolicy",
  "name": "Provider Policy",
  "resource": [
    {
      "resourceType": "Patient",
      "criteria": "Patient?organization=%provider_organization"
    },
    {
      "resourceType": "ServiceRequest",
      "criteria": "ServiceRequest?subject:Patient.organization=%provider_organization"
    },
    {
      "resourceType": "QuestionnaireResponse",
      "criteria": "QuestionnaireResponse?subject:Patient.organization=%provider_organization",
      "readonly": true
    }
  ]
}

While attempting to access resources using this policy, I've encountered the following outcome:

json
{
  "outcome": {
    "resourceType": "OperationOutcome",
    "issue": [
      {
        "severity": "error",
        "code": "invalid",
        "details": {
          "text": "column reference \"organization\" is ambiguous"
        }
      }
    ],
    "extension": [
      {
        "url": "https://medplum.com/fhir/StructureDefinition/tracing",
        "extension": [
          {
            "url": "requestId",
            "valueUuid": "785e203f-28e7-4b51-807a-8b17046f5dba"
          },
          {
            "url": "traceId",
            "valueUuid": "43372935-7d9e-4d75-9c41-a659814c0b83"
          }
        ]
      }
    ]
  }
}

I've also successfully tested a chained search query in Postman, and it's working fine: - Example URL: https://host.com/fhir/R4/ServiceRequest?subject:Patient.organization=Organization/123

Hi @ravindratc - I will file this as a bug. I believe you should not be getting that error message.

@rahul1 thanks

That being said, we currently only support a subset of search semantics in AccessPolicies, and we do not support chained search

@rahul1 I’ll check it. Thanks for your help.

@ravindratc In general we love contributions, but I'll warn you that it will not be a quick change, and therefore probably isn't the best use of your time. This would have pretty severe architectural changes that would be that we don't plan on supporting in the near future. The root of this that we have an in-memory implementation of the the FHIR search logic, in addtio to SQL based one. (https://github.com/medplum/medplum/blob/7dd1e516ffe8df7e162e3f709a9143f13d72b880/packages/core/src/search/match.ts#L13-L25) This is because updated resources can come from the REDIS in-memory cache, as well as from a DB

@rahul1 We need this feature, and I would like to understand the system architecture as well. It would be a good chance for me to understand Medplum’s architecture. Is there anything that I should know about before diving in it?