Thanks for the post Niquola, we’ve ended up having similar conversations around how to provide a sensible authorization model aligned with our FHIR resources. What we’ve ended up with for now is a combination of RBAC & ACL approachs, complete with the hacks you describe.
There’s a complementary issue which is where we’ve been putting most of our focus, which is how to expose authorization decisions to clients of the FHIR API so that the clients do not need to known anything about the underlying authorization model and can still respond accordingly. This gives us the freedom to change and enhance the underlying authorization model over time as needed.
What we settled on to achieve this is the use of HATEOAS links around the various built in and custom operations. Where the presence of the link indicates that the current actor can perform the operation in the current context. E.g. when listing a resource, the bundle may contain a create link indicating that the user is permitted to create a new resource of that type. Similarly each entry in the bundle can have an update link indicating that the user is allowed to update that particular resource.
This allows us to expose a FHIR interface that can be used now, and improve our authorization model over time without having to update the clients.