Fire Arrow Server 1.12.0

Fire Arrow Server 1.12.0 has been released.

• (feature) Server warns at startup when authorization rules could allow a role to escalate its own access
• (feature) License details are now visible to administrators in the web UI
• (feature) Due-task transition throughput is configurable; defaults now drain backlogs of up to 5,000 Tasks per run
• (bugfix) QuestionnaireResponse/$extract is now granted by an operation: extract authorization rule as intended
• (maintenance) Dependency updates

Authorization Configuration Auditor

Deployments with complex authorization configurations can accumulate rules where a role with write access to certain FHIR resources could indirectly influence its own authorization scope. For example, if a role that is limited to the patients on its CareTeams can also update those CareTeams, it could modify the membership list that governs what patients it may access. These combinations are hard to spot by reading YAML alone.

1.12.0 adds a startup auditor that inspects the fire-arrow.authorization.validation-rules configuration after the server has finished loading. It cross-references mutating rules (create, update, delete, transaction, token operations) against the FHIR resource types that each configured validator uses to make access decisions, and logs findings at startup:

• WARN when a role's write scope overlaps with a resource type that determines its own access.
• ERROR when a non-Practitioner role holds write access to PractitionerRole — a combination that can widen the role's own access through the GeneralPractitioner or CareTeam validators.

The auditor is advisory only. It never blocks the server from starting and does not change any runtime authorization decision. Findings appear in the application log at startup, tagged with the logger name for filtering in log aggregation tools.

What the auditor does and does not flag

The auditor understands that some write access is benign by design. LegitimateInterest roles are expected to create and update Patient, Organization, and PractitionerRole resources — those writes are subject to LegitimateInterest's own runtime access checks and cannot be used to claim data outside the role's scope. The auditor suppresses these combinations and logs them at INFO rather than WARN.

Rules using resource: "*" or transaction where the full scope cannot be statically determined are flagged as requiring manual review, because the auditor cannot expand them to a concrete resource list.

No configuration changes are required to use the auditor. Review the startup logs after upgrading to see whether your rule set produces any findings.

License Details in the Administration UI

Administrators can now view the server's product license from the administration web UI. A License item appears in the user dropdown (visible only when the current session holds administrator privileges) and links to a new /license page. The page shows customer name, deployment environment, licensed features, and the range of server versions the license covers.

The page is read-only. It is served through the existing admin API authorization chain, so only admin-role sessions may access it; API tokens are rejected at the endpoint. No configuration change is required to enable the page.

Configurable Due-Task Transition Throughput

Each scheduled run of the due-task sweep transitions Tasks from requested to ready once they become due. Before 1.12.0 the sweep processed at most 100 Tasks per run, regardless of how many were waiting. A sustained burst — for example, after a planned maintenance window or when many CarePlans become due simultaneously — could leave a large backlog that took many consecutive ticks to drain, delaying downstream due-event consumers.

1.12.0 replaces the hardcoded limit with two new settings under fire-arrow.careplan.events.task:

Property	Default	Description
due-transition-batch-size	1000	Tasks fetched and transitioned per batch
due-transition-max-batches-per-run	5	Maximum batches processed in one scheduled run

At the defaults, one scheduled run can drain up to 5,000 Tasks. Due Tasks are now processed oldest-due-first, so the longest-waiting tasks are cleared before newer arrivals. Between batches the sweep cooperatively yields the cluster lock to avoid starving other nodes; if lock renewal fails, the drain stops immediately rather than continuing without holding the lock.

Two new Micrometer metrics are available for monitoring:

• careplan.events.due-transition.backlog (gauge) — number of requested Tasks currently due and awaiting transition.
• careplan.events.due-transition.batches (distribution summary) — batches processed per scheduled run.

To reproduce the previous single-batch-of-100 behavior without a redeploy, set due-transition-batch-size: 100 and due-transition-max-batches-per-run: 1. The FHIR API and Task status values are unchanged.

Bug Fixes

QuestionnaireResponse/$extract always denied for non-admin clients

POST /fhir/QuestionnaireResponse/{id}/$extract (the Structured Data Capture extract operation) derives clinical resources such as Observation and Condition from a completed questionnaire response. Authorization rules of the form operation: extract on QuestionnaireResponse should grant specific client roles permission to call this operation.

Before 1.12.0, every non-admin call to this operation returned 403 Forbidden regardless of configuration. The server was not mapping the $extract operation name to the extract token that the policy engine checks against rules, so no operation: extract rule could ever match. As a result, deployments that added an operation: extract rule to their configuration saw no effect.

1.12.0 adds the correct mapping. Client roles with an operation: extract rule on QuestionnaireResponse can now call $extract. Deployments without such a rule continue to deny the operation to non-admin clients — no change in behavior for them.

Dependency Upgrades

1.12.0 includes patch and minor updates across the server and administration UI: Flyway 11.7.2 → 11.20.3, Spring Security 6.5.10 → 6.5.11, Kotlin 2.3.21 → 2.4.0, Spring Boot 3.5.14 → 3.5.15, Micrometer 1.16.5 → 1.17.0, and Next.js 16.2.6 → 16.2.9 (administration UI). No CVEs are addressed in this batch. No application-side configuration change is required.