AccessPolicy "writeable" fields, vs. "readonly"

[rahul1]

User Driven: https://discord.com/channels/905144809105260605/1133436813869064202

This should be part of a broader conversation on the next iteration of AccessPolicies.
There are cases when users want to lock down almost every field, except for a few status fields.

In this case, the user wants to lock down all fields on ServiceRequest except for ServiceRequest.note.

[codyebberson]

@rahul1 @mattwiller

Counter proposal...

Rather than adding "writeable", we deprecate "readonly", and move to "supported interactions".

It would be an array of FHIR interactions and operations: https://hl7.org/fhir/R4/http.html

• Instance Level Interactions
  • read Read the current state of the resource
  • vread Read the state of a specific version of the resource
  • update Update an existing resource by its id (or create it if it is new)
  • patch Update an existing resource by posting a set of changes to it
  • delete Delete a resource
  • history Retrieve the change history for a particular resource
• Type Level Interactions
  • create Create a new resource with a server assigned id
  • search Search the resource type based on some filter criteria
  • history Retrieve the change history for a particular resource type
• Whole System Interactions
  • capabilities Get a capability statement for the system
  • batch/transaction Update, create or delete a set of resources in a single interaction
  • history Retrieve the change history for all resources
  • search Search across all resource types based on some filter criteria

For example:

// full access (default)
['*'],

// readonly
['read'],

// readonly with history
['read', 'vread', 'history'],

// read with history and search
['read', 'vread', 'history', 'search'],

// read and write, but no delete
['read', 'vread', 'history', 'search', 'update', 'patch'],

Is that too granular? Would it be too annoying to list out all operations like that?

Or maybe "operations" should be separate?

That is the terminology that we use in our Subscription extension "supported interactions": https://www.medplum.com/docs/subscriptions/subscription-extensions#interactions

That was inspired by CapabilityStatement.rest.resource.interaction:

• https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.interaction
• https://hl7.org/fhir/R4/valueset-type-restful-interaction.html

---

Or, as @mattwiller suggested, we could align with SMART scopes:

• https://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html

We define permissions to support the following FHIR REST API interactions:

• c for create
  • Type level create
• r for read
  • Instance level read
  • Instance level vread
  • Instance level history
• u for update
  • Instance level update Note that some servers allow for an update operation to create a new instance, and this is allowed by the update scope
  • Instance level patch
• d for delete
  • Instance level delete
• s for search
  • Type level search
  • Type level history
  • System level search
  • System level history

The main limitation here is that it does not include anything about FHIR operations.

Of course, when performing a FHIR Operation, we use the current user's permissions, so we could always defer at that level too.

[mattwiller]

Between those options, I would actually prefer aligning to the full set of RESTful interactions codes rather than SMART scopes, since the latter are more subject to change and should map down to the supported operations anyways. The granularity of the operations feels pretty good to me, and I believe it will be critical to have a clear distinction between a user's inherent permissions (i.e. what they are allowed to do per access policies in a given context) and scopes (what a given token is permitted to do on behalf of a user)

[rahul1]

Summary of our discussion offline:

• fieldRules: [{path: 'status', action: read | write | hidden}]
• For a given field, find the first rule in the that matches
• Final rule should be `{path: '*', action: read | write | hidden}
• TBD what happens if users omit this rule