Skip to main content

Property Filters

Property filters modify or remove specific properties from FHIR resources before they are returned to the client. They are applied after authorization succeeds, allowing you to grant access to a resource while redacting sensitive fields.

Use Cases​

  • Clinical studies -- Provide access to clinical data while hiding patient identifying information
  • Privacy regulations -- Remove contact details or addresses from resources shared with certain roles
  • Data minimization -- Return only the fields a client actually needs

How They Work​

Property filters are attached to authorization rules. When a rule with property filters matches and the validator grants access, Fire Arrow processes each filter against the resource before returning it:

Each filter targets a specific property using a FHIRPath expression and applies a transformation to it.

Available Filters​

NullFilter​

Removes the property entirely from the resource. The field will not appear in the response.

property-filters:
  - property: "name"
    filter: NullFilter

RandomFilter​

Replaces the property with randomly generated data. This preserves the structure of the resource while making the actual values unreadable. RandomFilter supports HumanName and ContactPoint data types.

property-filters:
  - property: "name"
    filter: RandomFilter

For a HumanName, RandomFilter generates a random given name and family name. For a ContactPoint, it generates a random value appropriate for the contact system (e.g., a random phone number or email).

Configuration​

Property filters are defined as part of an authorization rule:

fire-arrow:
  authorization:
    rules:
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: Allowed
        property-filters:
          - property: "name"
            filter: NullFilter
          - property: "telecom"
            filter: RandomFilter
          - property: "address"
            filter: NullFilter

In this example, when a Practitioner reads a Patient:

  • The patient's name is removed entirely
  • The patient's telecom (phone, email) is replaced with random values
  • The patient's address is removed entirely

All other fields (identifiers, clinical links, etc.) are returned normally.

Full Example: Clinical Study Access​

A clinical study needs practitioners to access observation data linked to patients, but patient-identifying information must be hidden:

fire-arrow:
  authorization:
    rules:
      # Study practitioners can read patients but without identifying info
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: OrganizationCompartment
        identity-filter: "meta.tag.where(system = 'http://example.org/role' and code = 'study-practitioner').exists()"
        property-filters:
          - property: "name"
            filter: RandomFilter
          - property: "telecom"
            filter: NullFilter
          - property: "address"
            filter: NullFilter
          - property: "birthDate"
            filter: NullFilter

      # Study practitioners can read observations normally
      - client-role: Practitioner
        resource: Observation
        operation: read
        validator: OrganizationCompartment
        identity-filter: "meta.tag.where(system = 'http://example.org/role' and code = 'study-practitioner').exists()"

      # Regular practitioners see everything
      - client-role: Practitioner
        resource: Patient
        operation: read
        validator: PractitionerCompartment

In this setup, study practitioners see patient resources with randomized names and no contact information or birth dates, while regular practitioners with a compartment relationship see the full patient record.

note

Property filters apply to the response data. They do not affect search behavior -- a search narrowed by PatientCompartment still uses the real patient reference internally, even if the patient's name is filtered in the response.