Access policies
An AccessPolicy limits what a project member can do. It is the authorization layer for signed-in users: settings decide whether a flow can run, while an AccessPolicy decides which resources and operations a member can access.
Ovok uses AccessPolicies in two ways:
- FHIR and project access: policy rows grant interactions such as reading, searching, creating, updating, or deleting resources. Policies can also scope access with criteria.
- Signals routes: Ovok checks a small set of custom AccessPolicy rows for alert, configuration, and threshold operations. These rows work alongside the member's Patient access.
Start with the page that matches your question:
| If you need to… | Read |
|---|---|
| Understand policy rows, membership assignment, and what happens when a member has no policy | AccessPolicy model and membership |
| Configure the policies assigned to new patients and practitioners | Default policies |
| Grant access to Signals alerts, thresholds, and settings | Signals route policies |
The key safety rule
Do not assume that a missing policy means limited access. For ordinary project and FHIR access, a project membership without a policy is not restricted by one and can access the project broadly. Assign an intentional, least-privilege policy when you create or invite a member.
Signals routes have an additional check: non-admin callers need the named Signals capability as well as the corresponding Patient access. A broad FHIR policy by itself does not grant the custom Signals capabilities.