Roles and Access

Every request your app makes runs as a signed-in patient. What that session can see and change is decided by the platform, not by your UI. You never manage permissions yourself; this page is background on the model that is enforcing them, so the API's behavior makes sense.

Access is enforced on the server

On Palamond, each user's permissions are expressed as access policies attached to their membership, parameterized per organization. The server evaluates them on every read and write. Your app never sees the raw policies, and it cannot widen its own access by asking differently.

For a patient session, the policy scopes every call to that patient's own record inside their organization. This shows up in two ways:

• A resource the session is not allowed to read simply does not appear in search results. You will not get an error, you will get fewer rows.
• A change the session is not allowed to make comes back as an error status: 403 when the action is not permitted, 405 when the resource is owned by a workflow endpoint (the response names the endpoint to use). Both carry the standard error envelope.

Behind the scenes: clinician roles

The clinicians caring for your patients work in Palamond's own portals under the same model. A role there is a named selection of capability areas (patient identity, clinical record, orders, schedule, members, and so on), each granted at None, View, or Edit, compiled into per-organization policies on the clinician's membership. The same person can be an administrator in one clinic and read-only in another.

None of this is your app's concern to manage. It matters only as context: when the spine says "a clinician reviews the intake" or "a clinician assigns a Condition", these are the people and permissions doing that work. Your app reads the results in the record.

Handling a denied action

When the API refuses an action, surface it plainly. Do not retry the same call, and do not silently swallow it.

try {
  await palamond.updateResource(patient);
} catch (err) {
  if (err.status === 403) {
    showMessage('You do not have permission to make this change.');
    return;
  }
  throw err;
}

A 405 is different: it means you tried to write on the record plane something a workflow owns. Read the error body, it names the endpoint to call instead. See Errors and Limits for the envelope and the full status conventions.

Next

• Organizations - How data is partitioned per tenant.
• API Overview - The two planes and what each allows.
• Errors and Limits - Statuses, the error envelope, and rate limits.