Skip to main content

Use Case Design Guidelines (WIP)

The way authorization is designed in a use case influences the effort it will take to implement it.

A use case can restrict access

  • (less restrictive) Few requirements for acquiring an access token, no requirements for authorizing resource access
  • (somewhat restrictive) Few requirements for acquiring an access token, OAuth2 scope-specific requirements for authorizing resource access

Scopes

Policies

Authorization policies should require as

Anti-patterns

  • Bad: "Clients can access /Observation, but the FHIR server has to limit it to /Observation?patient=XYZ"
    • Requires transformation of the HTTP request at the Policy Enforcement Point.
    • Better: TODO
  • Bad: "Clients can update the FHIR resource at /Task/<XYZ> using an HTTP PUT, but only the status field.
    • HTTP PUT is a replace operation, which requires the Policy Decision Point to verify whether delta of the update only updates the status field, which can't be performed atomically.
      • Alternatively, it requires a use case-specific FHIR API, causing more implementation effort.
    • Better: "Clients can update the status field of FHIR resource /Task/<XYZ> using an HTTP PATCH. Updates to other fields must be rejected"