• (feature) Support _total search parameter in GraphQL

_total Parameter in GraphQL​

The FHIR _total search parameter was previously only honoured on the REST API. For GraphQL searches using stored (async) pagination, the count field — corresponding to Bundle.total — could be null on early pages because the total is only known once the asynchronous search task has loaded all results. Clients that needed a reliable total on the first page had to either poll until the search completed or switch to Cache-Control: no-store, which disables caching entirely.

Starting with 1.8.2, _total can be passed as an argument on any *Connection query:

Example:

{
  PatientConnection(_count: 10, name: "Smith", _total: "accurate") {
    count next edges { resource { id } }
  }
}

_total is excluded from encoded cursors, so it only needs to be specified on the initial query — subsequent pages retrieved via _cursor inherit the computed total automatically.

Note that _total has no effect on multi-alternative authorization searches where deduplication across alternatives makes the total unreliable; count stays null in that case regardless.

• (feature) Display SampledData observations in charts with dynamic aggregation
• (bugfix) Fix urn:uuid: bundle references blocking logical identifier fallback in authorization

SampledData Observation Charts​

Observations that carry continuous time-series data in valueSampledData — such as heart rate, respiratory rate, or temperature recorded by wearables — were previously ignored by the observation charts. Starting with 1.8.1, valueSampledData is fully supported alongside valueQuantity.

Individual samples are expanded into discrete data points and dynamically aggregated based on the selected time range. At wider zoom levels the chart groups samples into time buckets and displays the mean value as a line with a shaded min/max range band, giving a clear overview without losing the ability to drill into the raw signal by zooming in.

This release also adds support for the LOINC code 93831-6 (sleep duration).

Bug Fixes​

Bundle references with urn:uuid: preventing logical identifier resolution​

When a FHIR bundle used a urn:uuid: placeholder in Reference.reference alongside a business identifier in Reference.identifier, the authorization layer did not fall through to logical identifier resolution. Because urn:uuid: is a bundle-internal placeholder that the FHIR server resolves after authorization runs, it cannot be treated as a resolvable literal reference — but the authorization tester previously returned empty instead of checking Reference.identifier.

1.8.1 recognises the urn:uuid: scheme and correctly falls through to logical identifier resolution, matching the FHIR R4 spec intent that logical identifiers are a valid fallback when the literal reference is not directly resolvable.

• (security) Close search-parameter side-channel for property-filtered fields
• (feature) Resolve FHIR R4 conditional and logical Patient references in authorization
• (bugfix) Fix inherited roles being dropped when a child organization has a direct role
• (bugfix) Fix HFQL rejecting every request with 403 Forbidden when no explicit search/read rules are configured
• (maintenance) Dependency upgrades across server, UI, and tooling

Blocked Search Parameters and Includes​

Property filters redact fields from outgoing FHIR resources — for example, stripping Patient.name so that a practitioner with legitimate interest can list patients without seeing personally identifying information. Until now, the underlying data remained fully indexed, which opened a side-channel: a client could issue a targeted search (Patient?name=Smith) and infer the redacted value from the search result, or use _include/_revinclude to traverse references that had been filtered out of the primary response.

Starting with 1.8.0, validation rules accept two new optional fields that close this channel:

• blocked-search-params — a list of FHIR search parameter names that are rejected with 403 Forbidden when used in a search, a _sort, or a _filter expression.
• blocked-includes — a list of _include / _revinclude directives in ResourceType:searchparam form that are rejected when used.

Identifier-Based Patient References in Authorization​

When the authorization layer needs to decide whether an incoming resource belongs to a patient the caller is allowed to access, it previously resolved only literal Patient/{id} references on the subject reference. Import bundles that identified patients by their business identifier — using the conditional or logical reference forms permitted by FHIR R4 — were therefore rejected with 403 Forbidden, even when the caller had legitimate interest in those patients.

Version 1.8.0 accepts all three forms defined by FHIR R4 in the order the spec prescribes:

1. Literal — Reference.reference = "Patient/123" (§2.3.0.2)
2. Conditional — Reference.reference = "Patient?identifier=sys|val" (§3.1.0.11.2)
3. Logical — Reference.identifier (§2.3.0.3)

Ambiguous identifiers (more than one Patient sharing the same business identifier) deliberately do not resolve, so a duplicate identifier can never silently authorize. The set of rules and identities that grant access is unchanged — only the resolution of which Patient a reference points to has been extended.

Bug Fixes​

Role inheritance dropping parent roles on child organizations​

When role inheritance was enabled, parent roles were silently dropped whenever a child organization already had a direct role of its own. An elevated role declared at the root (e.g. ICT) disappeared as soon as a different role (e.g. Nurse) existed anywhere below it, and the inherited role was unavailable on every descendant beyond that point.

The fix correctly accumulates parent and direct roles together at each descendant within the configured depth, so the union of all inherited and directly-assigned roles is now visible to the authorization layer.

HFQL rejected with 403 Forbidden whenever no explicit search/read rule matched​

HFQL authorization required at least one explicit search or read rule to be configured for the calling client role. In deployments where access is controlled purely via default-validator (no explicit rules), or for unauthenticated requests, every $hfql-execute query was rejected with 403 Forbidden regardless of what the default validator would have decided.

In 1.8.0 the configured default validator is honoured for HFQL just as it is for ordinary searches. When no explicit rule matches the queried resource type:

• Allowed — the query returns the data its FROM clause selects.
• Forbidden — the query succeeds with zero rows rather than being rejected.
• Other validators (e.g. LegitimateInterest) — the matching explicit rules determine which rows the client sees, with the same compartment narrowing applied as for normal searches.

Unauthenticated requests and requests from clients without explicit rules now return HTTP 200 with an empty result under a restrictive default validator, return data under a permissive default validator, and return the narrowed subset the client is authorized for when explicit rules are in place.

Dependency Upgrades​

1.8.0 includes a broad maintenance pass across the server, administration UI, and tooling.

• (breaking) Task scheduling data now written to Task.restriction.period instead of Task.executionPeriod
• (security) Update Next.js to 16.2.3 (CVE-2026-23869)

Task Scheduling Data in restriction.period​

This release changes where the server persists planned scheduling data on materialized Tasks. Previously, the due date was written to executionPeriod.start and the deadline to executionPeriod.end. This overloaded fields that the FHIR R4 spec defines as actual execution times, and caused incorrect dependency propagation when ActivityCompletionService interpreted executionPeriod.end as the client-written completion time.

Starting with 1.7.0, server-managed scheduling data is written to Task.restriction.period:

• restriction.period.start — the due date
• restriction.period.end — the deadline

Task.executionPeriod is now exclusively client-written (actual start and end of execution). When resolving completion times for dependency propagation, the server uses a four-step fallback chain: executionPeriod.end → restriction.period.end → executionPeriod.start → restriction.period.start.

The due-timestamp-field configuration toggle has been removed. Two new configuration options — auto-propagate-period-start and auto-propagate-period-end (both off by default) — allow headless clients that cannot write back execution periods to have the server propagate scheduling data automatically.

The fa-careplan-due-tasks SearchParameter has been updated to index Task.restriction.period.start (version bumped to 2.0.0, which triggers automatic reindexing on startup).

Breaking Change​

Existing materialized Tasks still have due dates stored in executionPeriod. Affected deployments must regenerate their CarePlans after upgrading to ensure all Tasks use the new field mapping.

Security​

Next.js updated to 16.2.3 (CVE-2026-23869)​

The administration web UI's Next.js dependency has been updated from 16.2.1 to 16.2.3 to address CVE-2026-23869. A specially crafted HTTP request to an App Router Server Function endpoint could trigger excessive CPU usage, resulting in denial of service.

• (feature) Automatically ensure canonical URLs exist for definition resources in plans
• (bugfix) Reverse pre-signed Azure Blob URLs back to firearrow:// on resource updates

Canonical URLs for Definition Resources​

When building a PlanDefinition in the administration UI, definition resources such as ActivityDefinition or Questionnaire must be referenced by their canonical URL. Previously, if a selected resource did not have a canonical URL set, the reference was silently broken.

Starting with this release, the ResourceReferenceSelector detects when a chosen resource lacks a canonical URL and automatically generates one from the FHIR base URL, writing it back to the resource before inserting the reference. If the resource already has a canonical URL, it is used as-is. When a business version is present, it is appended with the | separator (e.g. http://example.com/ActivityDefinition/ad-1|2.0).

Bug Fixes​

Pre-signed Azure Blob URLs overwriting firearrow:// URLs on round-trip​

When binary storage is enabled, Fire Arrow rewrites firearrow:// attachment URLs to pre-signed Azure Blob URLs in outgoing responses so that clients can fetch media directly. If a client then saved the resource back — for example through the administration UI — the pre-signed URL replaced the canonical firearrow:// URL in the database. This caused two problems:

1. The stored pre-signed URL eventually expired, permanently breaking media access.
2. The blob cleanup interceptor saw the original firearrow:// URL as removed and deleted the underlying blob.

A new BinaryUrlReverseRewriteInterceptor now runs before resource storage, scanning all Attachment elements for recognised pre-signed Azure Blob URLs and converting them back to their firearrow:// form. URLs that do not match the configured blob container are left untouched.

• (feature) Add licensing system
• (bugfix) Fix CarePlan task scheduling drift after DST transitions
• (bugfix) Fix delivery tracking for message channel subscriptions

Why 1.5.0?​

This release jumps from 1.0.0 directly to 1.5.0 to signal a significant operational change: the introduction of a licensing system. While the release contains no breaking API changes, Fire Arrow Server can no longer start without a valid license file from this version onwards. We chose the version bump to make this requirement clearly visible to anyone upgrading, rather than burying it in a patch release.

Existing deployments upgrading from 1.0.0 will need to obtain a license before moving to 1.5.0. Reach out to Evoleen to get your license file.

Licensing System​

Fire Arrow Server now requires a license to start and continue running.

The license is configured via the fire-arrow.license.* properties and can be supplied as a file path or inline value.

Bug Fixes​

CarePlan task scheduling drift after DST transitions​

When a CarePlan was created, the UTC offset from period.start (e.g. +01:00 for CET in winter) was used as a fixed timezone for all task scheduling. After a DST transition, tasks that should have been scheduled at 08:00 local time would instead appear at 09:00 because the offset no longer matched the wall-clock time.

The fix ensures that when a proper IANA timezone (e.g. Europe/Berlin) is available on the CarePlan or Patient resource, it takes precedence over fixed offsets extracted from datetime values. This means task schedules now correctly follow DST transitions. Deployments using only fixed-offset timezones like UTC are unaffected.

Delivery tracking for message channel subscriptions​

The subscription success tracker was bound to a rest-hook-specific delivery hook, which meant that message channel subscriptions (such as the Azure Storage Queue delivery) never recorded a successful delivery. After seven days without a recorded success, the subscription sweep job would disable these subscriptions, which in turn broke CarePlan lifecycle re-materialization.

The fix now works for all channel types, and also prevents redundant delivery to the internal message broker after a successful Azure Queue send.

• (feature) Show total number of search results instead of page size in the GraphQL count field
• (bugfix) Fix crash in development license handler preventing release versions from starting

Total Search Count in GraphQL​

The count field on GraphQL *Connection types previously reflected the page size rather than the total number of matching resources. Starting with this release, count returns the actual total from the FHIR Bundle.total, giving clients an accurate result count for building pagination UIs.

For Cache-Control: no-store queries, the first page requests an accurate total from the database and carries it forward in cursor metadata so subsequent pages can report the same value without re-counting. When the true total cannot be determined — for example, during aggregated authorization searches with multiple alternatives — count returns null rather than an incorrect number.

Bug Fixes​

License handler crash with packaged deployments​

The license handler introduced in 1.5.0 crashed when deployed as a nested WAR. The fix broadens the exception handling so that the "not running from source" detection covers more scenarios, allowing the server to start normally.

Two Products, One Platform​

Starting with this release, Fire Arrow consists of two products:

• Fire Arrow Core — the lightweight GraphQL facade that connects to an external FHIR server (e.g. Azure Health Data Services). This is the product previously known simply as "Fire Arrow", now rebranded as Fire Arrow Core.
• Fire Arrow Server — a fully integrated FHIR server built on the open-source HAPI FHIR project. Fire Arrow Server bundles its own PostgreSQL-backed data store together with the authorization, authentication, and workflow capabilities that Fire Arrow is known for.

The rebranding of the original product to Fire Arrow Core is a naming change only — there are no breaking changes and existing deployments continue to work as before.

Why Fire Arrow Server?​

Fire Arrow Core was designed for managed cloud environments where an external FHIR service handles data storage and scaling. That model works well for many use cases, but some deployments need:

• On-premise or sovereign hosting — running outside of US-owned hyperscalers, or within an organization's own infrastructure
• Lower latency — eliminating the network hop to an external FHIR service
• Richer server-side workflows — built-in FHIR Subscriptions, server-side CarePlan expansion, and an administration UI

Fire Arrow Server addresses all of these while sharing the same authorization model, authentication providers, and GraphQL API that Core users are already familiar with.

What's Included​

Fire Arrow Server 1.0.0 ships with:

• Full FHIR R4 REST API with Swagger UI for interactive exploration
• GraphQL API with read support, nested queries, and _filter-based search modifiers
• Authentication via OAuth 2.0 / OIDC, Azure Identity, and API tokens (including QR-code-based one-time tokens for anonymous study participation)
• Fine-grained authorization with additive rules, identity filters, property filters, and a rule debugger
• FHIR Subscriptions (REST hook, email, websocket, Azure Storage Queue)
• Server-side CarePlan workflows — automatic expansion of CarePlans into Tasks, with dynamic schedule updates based on Task completion
• Administration Web UI with a GraphQL explorer, resource browser, and configuration overview
• Pre-built Docker image available from the Evoleen Public ACR

Getting Started​

Head over to the First Run guide to pull the Docker image and have a server running in minutes. For a detailed comparison of both editions, see Editions.

• (bugfix) Fix identifier serialization when looking up identity resources by auth user ID

Fire Arrow supports looking up identity resources through a credential like an email address or by using the client's object ID from the authentication server. A bug in serializing the client's object ID led to an incorrect lookup of identity resources, causing multiple resources to be created and the client to be locked out if this was the primary method of identifying the client.

• (security) Fix LegitimateInterest validator not blocking resources to unauthorized organizations

The LegitimateInterest validator compartmentalizes resources through an association with an Organization. This association is driven via PractitionerRole resources for Practitioner clients. A Practitioner client should not be able to see resources for which they don't have an active role.

A bug in processing search requests compromised this behavior.

PatientList(organization: "123") {
    id
}

Executing the query above without having an active role in this organization would still return patients associated with this organization. The root cause was improper parsing of search parameters, leading to an invalid comparison when computing the intersection between the allowed and requested organizations.

This release fixes the problem and improves the automated test suite to cover this case.

• (bugfix) Refresh Azure Identity key stores on every request

Azure Identity is a variant of the OAuth authentication method. Fire Arrow uses it to authenticate backend services. To validate incoming requests, authentication tokens are cryptographically validated against public keys found in a key store. An implementation difference between OAuth and Azure Identity caused the key stores not to be refreshed for every incoming request, which led to a situation where a client signed their token with a newer key than was known to Fire Arrow.

This release ensures that the key store is always up to date before validating incoming tokens.

• (feature) Add configurable option to propagate PlanDefinition extensions to CarePlan during PlanDefinitionApply

A new feature plan_definition_apply.propagate_plan_definition_extensions has been introduced. This flag defaults to false, so Fire Arrow 2.5.0 will behave exactly as the previous release with unchanged configuration.

When the flag is set to true, all extensions contained in a PlanDefinition resource will be copied over to the CarePlan resource during PlanDefinitionApply.

• (breaking) Replace decimal values with literals in API (previously used strings)
• (chore) Update dependencies

The HL7 FHIR specification states that client shall not modify the precision of decimal values. This led to Fire Arrow using strings in its API to ensure that decimal values are passed through unchanged. However, this also caused breakage with APIs and libraries that insisted on parsing decimal values only.

Since the HL7 FHIR specification also states that a 64bit IEEE 754 compliant implementation is sufficient and values are unlikely to be in a range where precision matters, Fire Arrow has now switched to using floating point literals in its API.

This is a breaking change to previous versions.

• (enhancement) Support custom search parameters created via SearchParameter resources via _customSearchParameters in queries
• (enhancment) Add GraphQL schema documentation for standard search parameters
• (bugfix) Fix GraphiQL UI not loading due to incorrect CDN URL
• (chore) Update dependencies

This release enables support for custom search parameters that have been created on the FHIR server via SearchParameter resources. The GraphQL schema now exposes a new parameter _customSearchParameters. This parameter accepts a string through which custom parameters can be supplied. Fire Arrow will add them to the query string as-is.

The GraphiQL UI didn't load anymore because GraphiQL's CDN didn't serve the original JavaScript file anymore. This version serves an updated UI loader.

Furthermore, the GraphQL schema now also documents standard search parameters.

• (bugfix) Fix plan definition action without definition removal

This release resolves a configuration issue with the plan_definition_apply.remove_plan_definition_actions_without_definitions setting. This configuration option allows the removal of PlanDefinition actions that lack references to other resources through their definitionUri or definitionCanonical fields during the PlanDefinitionApply operation.

The previous version prevented users from properly configuring this setting. This bugfix now enables correct configuration of this option, ensuring PlanDefinition operations work as intended.

• (bugfix) Fix intersect search filter

This release resolves an issue with adding search filter with intersect option. Previously, when the search parameter included a list of conditions, for example: organization': '1,2,3,4,5, the intersect filter incorrectly converted OR logic into AND logic. Instead of searching for organization=1,2,3,4,5 as a group, the query was split into organization=1&organization=2&organization=3 etc. As a result, no records were returned because none could satisfy all these conditions at once. The update restores correct behavior, ensuring that searches with multiple values function as expected.

• (bugfix) Fix empty value in search parameter request

The string sanitizing method was enhanced to properly handle empty values in search parameter chains. Previously, when a search parameter chain contained an empty value, it could cause issues with FHIR server requests. The fix ensures that any subquery containing empty parameters is automatically excluded from the chain, as FHIR servers do not recognize empty parameters as valid search parameters.

This improvement makes Fire Arrow more robust when dealing with complex search queries and prevents potential errors when working with FHIR servers.

• (enhancement) Optionally remove empty actions during PlanDefinitionApply
• (bugfix) Fix evaluation of multiple role codes for same access rule
• (chore) Update dependencies

Fire Arrow now supports the removal of empty actions (actions that neither contain definitionCanonical nor definitionUri) during PlanDefinitionApply. This supports use cases where actions are only used for sequencing, such as determining the duration of the resulting CarePlan or determining timings of dependent actions.

A critical bug affecting access validation rules with multiple role codes has been fixed. This issue was causing problems in role-based access control scenarios where different role codes were assigned to the same operation, causing only the first to be evaluated. The fix restores the desired behavior of evaluating all role codes.

• (enhancement) Support for 'total' field in search response
• (bugfix) Fix crash while trying to process parent trace ID from request headers
• (chore) Update dependencies

A critical bug was fixed that caused a crash while trying to process parent trace IDs from client request headers.

In addition, when performing searches, Fire Arrow can now optionally return the total number of search results if the backend server populates it.

• (feature) Post-request pre-response hooks are now supported
• (enhancement) Telemetry sent to Azure Application Insights now contains full request graph
• (enhancement) Per-request caching speeds up multiple retrieval of dependencies

Fire Arrow now supports two request hooks:

• Post-validation, pre-request: This hook can be used to inject custom, business-case specific validation logic (added in 2.1.0)
• Post-request, pre-response: This hook can be used to modify the respose before it is sent to the client. Example use cases include on-the-fly anonymization or data enrichment (added in 2.2.0)

This release also greatly enhances telemetry sent to Azure Application Insights. Fire Arrow now supports the Open Telemetry traceparent header and will properly group its own requests in the parent's span ID. This allows visibility into performance bottlenecks, especially when validation requires complex sub-requests before a response can be generated.

Fire Arrow now also speeds up nested resource retrieval. If lists of Observations were retrieved and for each Observation the Patient entity needed to be retrieved, Fire Arrow needed to handle each Patient entity through a single request (as each request is subject to re-validation). These requests are now cached, so that multiple retrievals of the same entity can be returned directly from memory.