AccessPolicy model and membership
An AccessPolicy is a project resource that describes which operations a member can perform. A policy contains one or more resource rules. Each rule identifies a resource type and can allow specific interactions, restrict the matching resources with criteria, or provide parameters used by the policy.
Resource rules
The interaction list is the permission surface. Common interactions include read, search, create, update, delete, history, and vread.
| Rule field | What it controls |
|---|---|
resourceType | The resource type covered by the rule, such as Patient or Observation. Ovok also uses custom values for Signals capabilities; see Signals route policies. |
interaction | The operations allowed for that resource type. Grant only the interactions the member needs. |
criteria | A FHIR search expression that scopes which resources the rule applies to. |
readonly | Restricts the rule to read-only behavior when enabled. |
For example, a Patient rule can permit reading and searching patients in a ward, while a separate rule controls whether the member can update them. A member may be able to read a patient but not change that patient's data.
Assigning policies to practitioners
Project membership and the admin flag are separate from AccessPolicy rules. A project admin can manage project-level operations. A non-admin member's resource access is shaped by their AccessPolicy.
When creating a practitioner through POST /v1/projects/me/members:
- If the request omits
access, the new member has no AccessPolicy and can reach the project broadly. - If the request includes
access, Ovok uses the project's default practitioner policy as the base, then adds the policies named by theaccessentries. - Each referenced policy must belong to the same project. An entry may also provide named
parametervalues for a parameterized policy.
The membership endpoint's PATCH operation replaces the member's access list. Read the full team invitation and membership reference before using this API; in particular, do not omit access when the member should be restricted.
No policy is not least privilege
For normal FHIR authorization, a membership without an AccessPolicy is not constrained by a policy and can have broad project access. This surprises teams who assume that an unconfigured member is denied by default.
There is one deliberate distinction: Signals routes do not treat a missing policy as permission to use Signals. Non-admin callers must carry the explicit signals_* capability rows and must also have the required Patient interaction. See Signals route policies.
Build policies for project scope
Use policies to divide access by resource and by the records a member should handle. For example, a practitioner who may review a care team's patients needs the relevant Patient read/search rule and the corresponding access to other FHIR resources used in that workflow. If they must edit a patient or change monitoring settings, grant those update interactions intentionally.
Test each policy with accounts that represent its intended roles. Check both allowed and denied cases, including access to a patient outside the member's assigned scope. When scoping criteria, verify the expression against the project data and the FHIR search parameters supported by Ovok.