Scopes and gated fields

A scope names one operation exactly, in the form resource:action. A call without the scope it needs is refused with 403 and an error naming that scope.

Operations

• Patients: patients:read, patients:create, patients:update
• Requests: requests:read, requests:create, requests:update
• Appointments: appointments:read, appointments:create, appointments:update, appointments:cancel
• Results: results:read. Only signed results are returned.

Opt-in field scopes

Two scopes unlock sensitive fields. Without them a read leaves the fields out and a write that sends them is refused. The API reference marks each gated field with the scope it needs.

• patients:identifiers: date of birth, Medicare, private health and DVA details, and patient contact details. Without it a patient carries birthYear instead of a date of birth.
• clinical:notes: patient allergies, history and notes; request clinical history, indication and notes; appointment notes; and report content on results.

Patient search follows the same rule. Without patients:identifiers it matches names and MRN only, so a key cannot confirm a phone number or date of birth it may not read.

A patient must have a date of birth, and date of birth is gated on writes as well. Registering a patient therefore needs patients:identifiers as well as patients:create.

Sites

A key can be confined to some of your sites. Requests, appointments, results and forms are then limited to those sites: a record with no site never matches, and the key cannot create one without a site.

Patients are not confined by site. A site-restricted key lists, reads, creates and updates any patient in your tenant, as staff at one site can. That includes patients:identifiers and clinical:notes fields if the key holds those scopes, so withhold them, or the patients scopes altogether, when a key needs narrower access.