Skip to main content

PractitionerCompartment

The PractitionerCompartment validator restricts access to resources that belong to the authenticated practitioner's FHIR Practitioner compartment.

How it works

The FHIR Practitioner compartment groups resources where the practitioner is directly referenced as the performer, author, responsible party, or similar role. For example:

  • An Encounter belongs to a practitioner's compartment if the practitioner is listed as a participant.
  • A DiagnosticReport belongs if the practitioner is listed as a performer.
  • A MedicationRequest belongs if the practitioner is the requester.

This validator is narrower in scope than LegitimateInterest because it only grants access to resources that directly reference the practitioner, not to all resources in the practitioner's organization.

Example configuration

application.yaml
fire-arrow:
authorization:
validation-rules:
- client-role: Practitioner
resource: Encounter
operation: read
validator: PractitionerCompartment

- client-role: Practitioner
resource: DiagnosticReport
operation: search
validator: PractitionerCompartment

Real-world scenario

A radiologist uses a reporting system that authenticates as their Practitioner identity. When searching for diagnostic reports, they only see reports where they are listed as the performer, not reports authored by other radiologists. This is useful in scenarios where practitioners should only access their own work product.

Supported client roles

This validator only supports the Practitioner client role. Using it with any other role will result in an error.

When to choose this validator

Use PractitionerCompartment when a practitioner should only see resources they are directly involved with. If practitioners need access to all patient data within their organization, use LegitimateInterest instead.

Performance

The PractitionerCompartment validator adds negligible overhead to request processing. Compartment membership is evaluated using FHIR's built-in compartment rules, which resolve in constant time regardless of the total number of resources in the system. No additional database lookups are needed beyond the request itself.