Skip to main content

Fire Arrow Server 2.6.5

· 2 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 2.6.5 has been released.

  • (feature) The administration UI adds an optional clinical Inbox of patient events
  • (feature) A patient-chart tab can list a patient's full measurement history
  • (bugfix) Subscription notifications are no longer lost when the server is under heavy load

Clinical Inbox​

The administration UI can show an Inbox under Clinical that lists patient events, such as a flare report submitted from a patient app, as Open and Done queues. Each event is a FHIR Task with a configured Task.code. Opening an event marks it as seen and opens the patient's chart. Marking it done completes the Task and records who completed it.

The Inbox is hidden until fire-arrow.ui.inbox is configured, so existing deployments see no change. It is available to users with the patient-viewer or patient-manager UI feature.

Measurement History on the Patient Chart​

A configured patient-chart tab can include a new time-series-list section. It lists the patient's recorded observation values for selected series, either chronologically or grouped by series, and shows how each reading changed from the previous one. Existing patient-chart configurations are unchanged.

Bug Fixes​

Subscription notifications were lost under heavy load​

Under heavy load, for example when database connections ran out, the server could temporarily forget most of its active subscriptions. Resources created or changed during that time matched no subscription, and their notifications were never sent. Nothing was logged. In one load test, about nine in ten notifications for new CarePlans were lost. All channel types were affected. This applied to deployments using the default fire-arrow.subscription.optimized-matching.enabled: true.

Starting with 2.6.5, an incomplete refresh under load no longer removes subscriptions that are still active. Deleted or deactivated subscriptions are still removed promptly. No configuration change is required.

Notifications lost under an earlier version are not sent again. If a consumer depends on receiving every notification, reconcile it after upgrading, for example by searching with _lastUpdated for resources changed during periods of heavy load.