$materialize and $dematerialize operations to start and stop task materialization without Subscription write accesspractitioner-role-code rule, not only the first one in configuration403 Responses on Protected OperationsBefore running certain operations, the server checks that the caller is allowed to access the target resource — the same kind of check that applies when issuing an API token for a specific Patient, uploading a binary for a resource, or changing a CarePlan through $materialize or $dematerialize.
Until now, those checks could answer differently depending on whether the ID existed. A token request for a non-existent Patient/{id} often returned HTTP 400 with "Resource not found", while the same request for a patient the caller was not permitted to use returned HTTP 403 Forbidden. A deleted resource could return HTTP 410 Gone. Clients that tried many IDs could infer which ones existed from the status code alone.
Starting with 1.11.0, an unknown or deleted target returns the same HTTP 403 as a genuine permission denial, with one message shape:
Access denied: insufficient permissions for <operation> on <ResourceType>/<id>
The response no longer reveals whether the ID exists or has been deleted.
Do not use HTTP status codes or response text on these operations to tell whether a resource ID exists or has been deleted. Treat every 403 as “not allowed,” and do not branch on 400, 410, or "not found".
| What you call | Examples |
|---|---|
| API token generation | Patient/$generate-durable-token, Patient/$generate-one-time-token (and other identity resource types) |
| Binary upload | Upload paths that authorize against a specific resource instance |
| CarePlan scheduling | CarePlan/{id}/$materialize, CarePlan/{id}/$dematerialize |
If an onboarding flow used token generation to probe whether a patient ID exists (for example, before showing a QR code), use a separate confirmation step instead of interpreting the operation response.
Deployments that use the CareTeam validator on practitioner (or related) roles intend a simple rule: a user may only see data for patients on CareTeams they belong to — the specialist sees their shared caseload, not the whole hospital population.
Under certain conditions the server could apply that rule too loosely. After looking up CareTeams for the practitioner, it treated every active team returned by the search as valid, even when the practitioner was not listed on that team's participant list. That most often surfaced when search indexing was misconfigured or out of date (for example advanced_lucene_indexing: true with an incomplete index, where participant filters on CareTeam?participant=… could be ignored and the query effectively returned all active teams). The authorization bug itself was independent of indexing: any over-broad team list could widen access the same way.
A practitioner session that should see three shared patients might instead receive authorization for every patient linked to any active CareTeam on the server, including:
Patient search and list screens — rosters, typeahead, and "my patients" views populated with records outside the intended caseload.Observation, Condition, MedicationRequest, CarePlan, Task, and other resources for patients the user was not actually assigned to, as long as those rules used the CareTeam validator.$generate-durable-token or $generate-one-time-token under a CareTeam-scoped rule could be issued for patients the practitioner should never have been able to act on.Roles that relied on LegitimateInterest or compartment validators alone were not affected by this particular issue; it applied where access was explicitly scoped through CareTeam membership.
This is unauthorized access to protected health information: users could open, export, or act on the wrong person's record in apps that trust the FHIR API's authorization decisions. That creates confidentiality breaches (including regulatory exposure where PHI must stay within the care relationship), and clinical-safety risk if workflows display another patient's medications, results, or care plans to the wrong user.
The server now checks each candidate CareTeam and grants access to its subject patient only if the practitioner (or their role or organization, per existing matching rules) appears on that team's participant list. Teams returned by a faulty search no longer add patients to the accessible set. Practitioners who were already correctly limited see no change.
If you use advanced Lucene indexing, keep the index complete and current; a healthy index avoids noisy searches, but 1.11.0 enforces membership even when search results are wrong.
$materialize and $dematerializeStarting and stopping CarePlan task materialization previously relied on $subscribe-due-events and $unsubscribe-due-events, which create or disable Subscription resources. Clients without Subscription write permission could not use that path, and stopping materialization depended on finding subscriptions visible in the caller's scope — which was not always predictable.
1.11.0 adds two CarePlan operations (available when CarePlan events are enabled in server configuration):
| Operation | Effect |
|---|---|
POST /CarePlan/{id}/$materialize | Opts the CarePlan into server-side task materialization by adding the scheduling tag (https://firearrow.io/fhir/careplan-scheduling / scheduled). Does not create a Subscription. |
POST /CarePlan/{id}/$dematerialize | Removes the scheduling tag only. Does not delete existing Tasks or turn off Subscriptions already in place. |
Authorization uses a new operation: "materialize" rule on CarePlan (wildcards such as resource: "*" are rejected at startup, as for token-generation rules). The caller must also be allowed to read and update that CarePlan — token-style checks run against the specific instance. Granting materialize without a CarePlan read rule still results in 403 Forbidden, because the server reads the CarePlan before applying the tag.
Example configuration:
fire-arrow:
authorization:
validation-rules:
- client-role: Device
resource: CarePlan
operation: read
validator: Allowed
- client-role: Device
resource: CarePlan
operation: materialize
validator: Allowed
$subscribe-due-events and $unsubscribe-due-events remain for webhook and polling setups. Use the new operations when a client only needs to turn materialization on or off without managing Subscriptions.
A successful call returns Parameters with status=success. Calling $materialize again on an already opted-in CarePlan does not trigger duplicate scheduling work.
Configuration can define several token-generation rules for one client role, each scoped with practitioner-role-code (for example, separate entries for physiotherapists and orthopedists). Search and read rules already combine every entry that applies to the caller; token generation should behave the same way.
Previously, token generation stopped after the first matching line in the file. If an orthopedist rule appeared above a physiotherapist rule, a physiotherapist was denied on $generate-one-time-token and $generate-durable-token even when a later line would have allowed them.
1.11.0 evaluates all matching token-generation rules before allowing or denying the request. Order in the YAML file no longer matters. Deployments with only one rule per role see no change.
1.11.0 includes a routine platform refresh (FHIR server core 8.8.1 → 8.10.0) and patch updates across the server and administration UI. Spring Security 6.5.10 addresses CVE-2026-22732.
If you override binary storage settings manually, note the renamed threshold property binary_storage_minimum_binary_size (replacing inline_resource_storage_below_size). A new optional JPA setting allow_database_validation_override is available for advanced database validation scenarios.
Upgrading the embedded HAPI FHIR platform from 8.8.1 to 8.10.0 includes new HAPI JPA schema migrations. Per the HAPI FHIR upgrade guide, you must run the HAPI CLI migrate-database command against your PostgreSQL database before starting 1.11.0 on the new image — do not rely on the server process to apply HAPI schema changes on first boot.
Recommended sequence:
hapi-fhir-cli migrate-database with a CLI build matching 8.10.0, your JDBC URL, and dialect POSTGRES_9_4 (see CLI migrate-database docs).Fire Arrow–specific tables (V1_* Flyway scripts under db/migration) are unchanged in this release and continue to apply automatically on startup when Flyway is enabled. This step is only for the shared HAPI FHIR JPA schema tracked in FLY_HFJ_MIGRATION.
Deployments using the Azure PostgreSQL migration helper can run scripts/azure-postgres-migration.sh (set --hapi-cli-version to 8.10.0 so the CLI matches the server).
Beyond the HAPI database migration and the authorization breaking change above, no further action is required unless you relied on distinct HTTP status codes to probe resource existence.
]]>$generate-durable-token and $generate-one-time-token are now governed by all validators, not just Allowedresource: "*" are rejected at startup_synchronous mode for CarePlan/$subscribe-due-events returns materialized Task IDs in the responseThe $generate-durable-token and $generate-one-time-token operations issue API tokens that act on behalf of an identity resource (Patient, Practitioner, Device, RelatedPerson). Until now, token-generation rules only worked under the Allowed validator. Operators who wanted to mint tokens under a narrower scope — for example, only for patients in a practitioner's compartment, or only for the patients a care team is responsible for — could not express that with a single rule. The common workaround was to keep the generate-*-token rule under Allowed and pair it with a separate operation: update rule under the appropriate validator, because the underlying authorization framework only considered the update rule's scope when checking who a token could be issued for.
Starting with 1.10.0, every validator that the server supports can be used on a token-generation rule. Tokens can now be issued under any available scope directly from the generate-*-token rule. For example, restricting practitioners to mint durable tokens only for patients in their compartment is now a single rule:
fire-arrow:
authorization:
validation-rules:
- client-role: Practitioner
resource: Patient
operation: generate-durable-token
validator: PractitionerCompartment
Token-generation rules are now self-contained: the chosen validator decides both whether the operation may be invoked and which target instance the caller is allowed to issue a token for. A separate update rule is no longer required for token generation to work.
update RulesIf your authorization configuration carries an operation: update rule that was added solely to enable token generation under a non-Allowed validator, you should remove it after upgrading. That rule grants the client full write access to every instance the validator's scope reaches — far more permission than token generation needs. Removing it tightens the client's permissions to exactly what the new model requires, with no loss of functionality.
Keep the update rule if the client also performs regular PUT requests for reasons unrelated to token generation. In that case it continues to authorize those updates independently.
The full migration note is documented at the top of the API Tokens authorization section.
As part of this work, the wildcard form resource: "*" is no longer accepted on token-generation rules. Token-generation only ever applies to the four identity resource types, and the wildcard previously expanded to a server-wide write grant covering every resource type — far broader than what the operation requires.
Deployments that currently have a rule of this shape:
- operation: generate-durable-token
resource: "*"
validator: Allowed
must update their configuration before upgrading. Replace the wildcard with explicit per-resource-type rules for the identity types tokens should be issuable for:
- operation: generate-durable-token
resource: Patient
validator: Allowed
- operation: generate-durable-token
resource: Practitioner
validator: Allowed
- operation: generate-durable-token
resource: Device
validator: Allowed
- operation: generate-durable-token
resource: RelatedPerson
validator: Allowed
The server logs the offending rule and refuses to start when a wildcard is encountered. Deployments that already enumerate resource types are unaffected.
The administration web UI's Next.js dependency has been updated from 16.2.3 to 16.2.6 to address a cluster of advisories disclosed across the 16.2.4, 16.2.5, and 16.2.6 patch releases. The most operationally relevant ones for Fire Arrow Server deployments are:
| CVE | Severity | Summary |
|---|---|---|
| CVE-2026-23870 | High (7.5) | Specially crafted requests to App Router Server Function endpoints can trigger excessive CPU usage and denial of service. |
| CVE-2026-44573 | High (7.5) | Middleware/proxy authorization bypass on Pages Router applications using i18n, via locale-less /_next/data/<buildId>/<page>.json requests. |
| CVE-2026-44575 / CVE-2026-45109 | High (7.5) | Middleware/proxy authorization bypass on App Router applications via segment-prefetch (.rsc) routes; the follow-up CVE addresses the case of middleware.ts running under Turbopack. |
| CVE-2026-44579 | High (7.5) | Connection-exhaustion denial of service on applications using Cache Components / Partial Prerendering, via crafted Next-Resume headers. |
| CVE-2026-44580 | Medium (6.1) | Cross-site scripting in beforeInteractive scripts when untrusted input is embedded. |
| CVE-2026-44581 | Medium (4.7) | Stored cross-site scripting via malformed CSP nonce values reflected into rendered HTML. |
| CVE-2026-44576 / CVE-2026-44582 | Medium / Low | Cache-poisoning of React Server Component responses behind shared caches that do not partition response variants correctly. |
No application-side configuration change is required to pick up the fixes; the upgraded admin UI is bundled with the server image.
$subscribe-due-eventsThe CarePlan/$subscribe-due-events operation activates a Subscription that triggers Task materialization for due CarePlan activities. Until now, the operation returned as soon as the Subscription was committed — Task materialization itself ran asynchronously and the materialized Tasks only became queryable a few seconds later. Orchestrators that wanted to act on the first due Task immediately (for example, dispatching it to a downstream system) had to poll the FHIR API until the Tasks appeared, which added wall-clock latency and wasted FHIR searches on each cold call.
Starting with 1.10.0, $subscribe-due-events accepts a new optional _synchronous parameter. When set to true, the operation blocks the HTTP response until immediate Task materialization has completed and returns the materialized Task IDs in the response Parameters:
{
"resourceType": "Parameters",
"parameter": [
{ "name": "subscriptionId", "valueId": "Subscription/123" },
{ "name": "effectiveEnd", "valueInstant": "2026-06-01T00:00:00Z" },
{ "name": "action", "valueString": "created" },
{
"name": "task",
"part": [
{ "name": "taskId", "valueId": "Task/456" },
{ "name": "status", "valueString": "ready" }
]
}
]
}
The synchronous wait is bounded at 10 seconds. If materialization does not complete inside that window, the operation still returns 200 OK with synchronousTimedOut=true in the response and the caller can fall back to the usual notification path — the asynchronous materialization continues to run regardless of the synchronous outcome.
Default behaviour is unchanged. With _synchronous absent or false, the response shape is identical to previous releases and no extra processing runs.
The new parameter is documented in CarePlan Events › Waiting for Initial Materialization and in the $subscribe-due-events reference.
Questionnaire items can carry inline media (images and videos) as Attachment references. The server returns those attachments with a freshly pre-signed download URL on every Questionnaire READ — the URL is short-lived by design (around two minutes in default configurations), and clients are expected to re-read the parent Questionnaire if the URL goes stale.
In the administration UI's questionnaire-builder preview pane, and in the patient-dashboard's QuestionnaireResponse viewer, that recovery did not run. As soon as the pre-signed URL expired the embedded image or video silently broke and showed only a generic load-error indicator, requiring the operator to manually refresh the page. The QuestionnaireResponse viewer additionally had no error handling at all, so an expired URL produced a broken media element with no visible error message.
In 1.10.0 both viewers correctly detect the expired URL, re-read the parent Questionnaire to obtain a freshly signed URL, and recover the media in place. The pre-signed URL lifetime configured on the server (presigned-url.expiration-seconds) is unchanged.
When a client stored an attachment with a pre-signed download URL back to the server (for example, an Attachment.url received from an earlier read), the server is supposed to recognize that URL as its own and replace it with the internal storage reference. This ensures the download link is always freshly signed when the resource is read again, rather than retaining a time-limited token that will eventually expire.
Due to how Azure Storage encodes blob paths, the URL returned to clients could contain percent-encoded path separators (e.g. %2F instead of /). The server did not account for this encoding when trying to match the URL, causing it to silently skip the rewrite. The expired pre-signed URL was then persisted as-is in Attachment.url, permanently breaking any out-of-band download — for example, media fetched by WhatsApp or other messaging platforms that retrieve attachments independently.
1.9.1 correctly handles percent-encoded paths, so pre-signed URLs are now reliably recognized regardless of how the client returns them.
]]>_total search parameter in GraphQL_total Parameter in GraphQLThe 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:
| Value | Effect |
|---|---|
accurate | Forces a SELECT COUNT(*) alongside the main query. The total is persisted and available on every page. |
estimated | Requests an estimated count (HAPI default behavior, implementation-dependent). |
none | Explicitly suppresses count computation. |
| (omitted) | Default behavior — count may be null until the async search completes. |
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.
urn:uuid: bundle references blocking logical identifier fallback in authorizationObservations 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).
urn:uuid: preventing logical identifier resolutionWhen 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.
403 Forbidden when no explicit search/read rules are configuredProperty 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.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:
Reference.reference = "Patient/123" (§2.3.0.2)Reference.reference = "Patient?identifier=sys|val" (§3.1.0.11.2)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.
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.
403 Forbidden whenever no explicit search/read rule matchedHFQL 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.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.
1.8.0 includes a broad maintenance pass across the server, administration UI, and tooling.
]]>Task.restriction.period instead of Task.executionPeriodrestriction.periodThis 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 daterestriction.period.end — the deadlineTask.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).
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.
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.
]]>firearrow:// on resource updatesWhen 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).
firearrow:// URLs on round-tripWhen 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:
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.
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.
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.
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.
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.
]]>count fieldThe 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.
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.
]]>Starting with this release, Fire Arrow consists of two products:
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.
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:
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.
Fire Arrow Server 1.0.0 ships with:
_filter-based search modifiersHead 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.
]]>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.
]]>LegitimateInterest validator not blocking resources to unauthorized organizationsThe 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.
]]>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.
]]>PlanDefinitionApplyA 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.
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.
]]>SearchParameter resources via _customSearchParameters in queriesThis 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.
]]>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.
]]>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.
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.
]]>