FHIR API Authentication & Authorization Architecture

Overview

The security layer combines:

• Azure B2C for identity management
• JWT validation with rotating keys
• Role-Based Access Control (RBAC)
• FHIR compartment validation
• Legitimate interest assessments

Validation Workflow

Core Components

1. JWT Validation

• Validates token signature using Azure JWKS
• Verifies standard claims (aud, iss, exp)
• Extracts custom claims for RBAC
• Handles key rotation automatically

2. RBAC Engine

• Matches user role to validation rules
• Supports multiple rules per operation
• Configurable default policy (allow/deny)
• Combines compartment and custom validators

Validators Reference

1. Patient Compartment

• Purpose: Restrict access to patient-specific data
• Checks:
  • User is a Patient entity
  • Resource references patient in allowed fields
  • Create/update operations include valid patient reference
• Reference Fields: subject, patient, performer

2. Practitioner Compartment

• Purpose: Control provider access
• Checks:
  • User is a Practitioner
  • Resource links to practitioner via references
  • Validates active organization relationships
• Reference Fields: practitioner, performer, requester

3. Legitimate Interest

• Purpose: Allow controlled access without explicit consent
• Validation Types:
  • Patient compartment fallback
  • Organization relationships
  • Managing organization checks
  • Active organization membership
• GDPR Compliance: Requires documented balancing test

4. Organization Compartment

• Purpose: Manage multi-organization access
• Checks:
  • Practitioner has active role in resource's organization
  • Patient's managing org matches practitioner's org
  • Resource contains valid organization reference
• Validation Methods:
  • PractitionerRole lookup
  • Organization reference matching
  • ManagingOrganization checks

5. General Practitioner

• Purpose: Manage primary care relationships
• Rules:
  • Practitioners must be listed in patient's GP
  • Patients can only access their GP's resources
  • No create operations allowed
• Validation:
  • Checks patient's generalPractitioner references
  • Validates GP-patient relationship exists

6. Allowed/Forbidden

• Purpose: Explicit allow/deny overrides
• Use Cases:
  • Publicly accessible resources (allowed)
  • Sensitive operations (forbidden)
  • Temporary access controls

Query Handler Security

FHIRQueryHandler implements read access validation with:

Security Filters

1. Patient Access:

   • Direct ID matching for Patient resources
   • Reference checks in subject, patient, performer fields
   • Strict compartment isolation

2. Practitioner Access:

   # PractitionerRole search pattern
   PractitionerRole.where(practitioner="Practitioner/<ID>")
                   .where(active=True)
                   .include('organization')
   • Organization-based pre-filtering
   • ManagingOrganization validation
   • Cross-resource reference checks

3. RBAC Configuration:

   {
     "client_role": "Practitioner",
     "entity_name": "Observation",
     "operation": "read",
     "validator": "legitimate_interest"
   }
   • client_role: User's entity type from claims
   • entity_name: FHIR resource type
   • operation: create/read/update/delete
   • validator: Compartment or policy validator

Settings Configuration

RBAC Rules Structure

Field	Description	Example
client_role	Azure B2C entity type	"Patient", "Practitioner"
entity_name	FHIR resource type	"Observation", "Patient"
operation	CRUD operation	"create", "read"
validator	Validation mechanism	"patient_compartment", "legitimate_interest"

Validation Types

1. Compartment Validators:

   • patient_compartment: Patient-owned resources
   • practitioner_compartment: Provider-associated resources
   • organization_compartment: Organization-linked resources

2. Policy Validators:

   • legitimate_interest: GDPR-compliant override
   • allowed: Whitelist access
   • forbidden: Explicit deny rule