GeneralPractitioner

The GeneralPractitioner validator implements access control based on the FHIR Patient.generalPractitioner field. It grants practitioners access to patients who list them (or their organization / role) as a general practitioner, and gives patients access to the practitioner, organization, and practitioner role resources referenced in their own GP list.

When to use

Use GeneralPractitioner when:

• Primary care relationships define access boundaries. A general practitioner should see their own patients' clinical data, and those patients should see their GP's details.
• Access should follow the GP link, not organizational membership. The practitioner does not need to be in the patient's managing organization — only in the patient's generalPractitioner list.
• You need a lighter-weight alternative to LegitimateInterest for scenarios where the GP relationship is the sole access criterion.

Choose the simplest validator

If a compartment validator (PatientCompartment, PractitionerCompartment) covers your use case, prefer it — compartment validators are simpler and faster. Use GeneralPractitioner specifically when the Patient.generalPractitioner link is the access-granting relationship.

Supported client roles

Client role	Access model
Patient	GP-related resources: Practitioner, Organization, and PractitionerRole entries from the patient's generalPractitioner list
Practitioner	Patients whose generalPractitioner contains the practitioner (or their roles/organizations), plus patient compartment resources for those patients

Using GeneralPractitioner with any other client role (RelatedPerson, Device) will result in an error.

How it works: Patient clients

For patient clients, the validator grants access to the resources referenced in the patient's Patient.generalPractitioner field. Only three resource types are accessible:

• Practitioner — practitioners listed directly or resolved through a PractitionerRole entry in the GP list.
• Organization — organizations listed directly or resolved through a PractitionerRole entry in the GP list.
• PractitionerRole — practitioner roles listed directly in the GP list.

Any attempt to access a different resource type through this validator will be denied.

PractitionerRole expansion

When the patient's generalPractitioner list contains a PractitionerRole reference, the validator expands it. If the referenced PractitionerRole is active, the validator makes both the underlying Practitioner (via PractitionerRole.practitioner) and the Organization (via PractitionerRole.organization) accessible. This means a patient whose GP list contains only a PractitionerRole entry can still access the corresponding practitioner and organization.

Resource creation

Resource creation is denied for patient clients. The relationship between the patient and the general practitioner cannot be validated at creation time. Use an explicit Allowed rule if patients need to create resources.

Real-world example: Patient viewing their GP

A patient's record contains:

{
  "resourceType": "Patient",
  "id": "patient-123",
  "generalPractitioner": [
    { "reference": "Practitioner/dr-mueller" },
    { "reference": "Organization/family-practice" }
  ]
}

Through the GeneralPractitioner validator, the patient can:

• Read Practitioner/dr-mueller (their GP)
• Read Organization/family-practice (their GP's practice)
• Search for Practitioner and Organization resources — results are narrowed to the entries in their GP list

They cannot read observations, conditions, or any other clinical data through this validator — use PatientCompartment for that.

How it works: Practitioner clients

For practitioner clients, the validator builds access based on which patients list the practitioner as a general practitioner. The validator resolves the practitioner's "GP references" — the set of identifiers by which the practitioner might appear in any patient's generalPractitioner field — and then gates access accordingly.

GP reference resolution

A practitioner's GP references include:

1. The practitioner itself — Practitioner/<id>.
2. Active PractitionerRoles — all PractitionerRole resources where PractitionerRole.practitioner references the practitioner and the role is active.
3. Organizations from those roles — every Organization referenced by PractitionerRole.organization in the active roles above.

A patient is accessible if their Patient.generalPractitioner list contains any of these references.

Patient access

The practitioner can perform read, create, update, and delete operations on Patient resources where the patient's generalPractitioner list contains one of the practitioner's GP references. Search queries are automatically narrowed using the general-practitioner search parameter so that only matching patients are returned.

Patient compartment resources

For resources that belong to the FHIR Patient compartment (Observation, Condition, Encounter, MedicationRequest, etc.), access is granted when the resource's primary patient reference points to a patient whose GP list contains one of the practitioner's GP references.

Only primary compartment parameters are used for access checks. Secondary parameters (such as performer, author, or recorder) are intentionally excluded from both per-result ownership checks and search-time narrowing to prevent cross-patient data leakage.

Search queries for compartment resources are narrowed using a forward-chained predicate (e.g., subject:Patient.general-practitioner=<gpRefs>), which keeps query complexity proportional to the number of GP references rather than the number of accessible patients.

Unsupported resource types

Any resource type that is neither Patient nor part of the FHIR Patient compartment will result in a Forbidden error. For access to organizational or practitioner-directory resources, combine this validator with LegitimateInterest or use explicit Allowed rules.

Real-world example: GP accessing patient data

Dr. Mueller is a general practitioner. She has an active PractitionerRole at "Family Practice":

• Practitioner/dr-mueller
• PractitionerRole/role-456 (practitioner: Practitioner/dr-mueller, organization: Organization/family-practice)

Her GP references are: Practitioner/dr-mueller, PractitionerRole/role-456, and Organization/family-practice.

Patient Anna has generalPractitioner = [Practitioner/dr-mueller]. Patient Ben has generalPractitioner = [Organization/family-practice]. Patient Clara has no GP entries.

Through the GeneralPractitioner validator, Dr. Mueller can:

• Read and update Anna's patient record (direct practitioner match)
• Read and update Ben's patient record (organization match via PractitionerRole)
• Search for observations, conditions, and other clinical data for Anna and Ben
• Create new observations for Anna and Ben (e.g., documenting a consultation)

She cannot access Clara's data because Clara does not list any of Dr. Mueller's GP references.

Combining with other validators

The GeneralPractitioner validator works well alongside other validators. Since Fire Arrow Server evaluates rules additively, a practitioner can gain access through multiple paths simultaneously.

application.yaml

fire-arrow:
  authorization:
    validation-rules:
      # GP practitioners can access their patients
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: GeneralPractitioner

      # Organization members can also access patients in their org
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: LegitimateInterest

      # Patients can see their GP details
      - client-role: Patient
        resource: Practitioner
        operation: read
        validator: GeneralPractitioner

      # Patients can also see their own clinical data
      - client-role: Patient
        resource: Observation
        operation: read
        validator: PatientCompartment

With this configuration, a practitioner who is both a GP for a patient and a member of the patient's managing organization gains access through either route.

Configuration

Validation rules

GeneralPractitioner is specified as a string value in the validator field of a validation rule:

application.yaml

fire-arrow:
  authorization:
    validation-rules:
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: GeneralPractitioner

      - client-role: Practitioner
        resource: Observation
        operation: search
        validator: GeneralPractitioner

      - client-role: Patient
        resource: Practitioner
        operation: read
        validator: GeneralPractitioner

      - client-role: Patient
        resource: Organization
        operation: read
        validator: GeneralPractitioner

Validation strategy by resource type

Practitioner clients

Resource	Access rule
Patient	Patients whose generalPractitioner contains any of the practitioner's GP references
Patient compartment resources	Resources whose primary patient reference points to an accessible patient (one whose GP list matches)
All other resources	Denied

Patient clients

Resource	Access rule
Practitioner	Practitioners listed in generalPractitioner (directly or via PractitionerRole expansion)
Organization	Organizations listed in generalPractitioner (directly or via PractitionerRole expansion)
PractitionerRole	PractitionerRoles listed directly in generalPractitioner
All other resources	Denied

Performance

The GeneralPractitioner validator is less resource-intensive than LegitimateInterest because it resolves a smaller scope — the practitioner's GP references (typically a handful of entries) rather than full organizational membership across potentially many organizations.

Scaling characteristics

Factor	Impact
Number of GP references per practitioner	Small — the practitioner itself + active PractitionerRoles + linked Organizations. Typically single digits.
Number of patients per GP	Does not affect authorization overhead. Search predicates are injected at the database level rather than materialized in memory.
Patient compartment resource volume	Search narrowing operates at the database level; authorization overhead is independent of result set size.

Recommendations

• Use GeneralPractitioner when the GP link defines access — it is more efficient than LegitimateInterest for this specific relationship because it resolves a smaller scope.
• Combine with PatientCompartment for patient clients — the GeneralPractitioner validator only grants patients access to their GP-related resources (Practitioner, Organization, PractitionerRole). Use PatientCompartment to give patients access to their clinical data.
• Use explicit Allowed rules for patient-side resource creation — the validator denies all create operations for patient clients because the GP relationship cannot be validated at creation time.