Skip to main content

Fire Arrow Server 2.2.2

· 3 min read
Till Gerken
Till Gerken
CTO

Fire Arrow Server 2.2.2 has been released.

  • (bugfix) CarePlans with activity completion enabled now reach completed when their last Task finishes
  • (bugfix) Task search with an unqualified numeric patient id no longer returns 412

Bug Fixes​

CarePlans stayed active after all Tasks finished​

When fire-arrow.careplan-events.activity-completion.enabled is true, the server is supposed to mark a CarePlan completed once every bounded activity's Tasks have reached a terminal status — completed, or cancelled when fire-arrow.careplan-events.activity-completion.count-cancelled-as-complete is also true. Typical cases are a one-shot questionnaire Task that the patient answered, or a response-window Task the server cancelled on timeout.

From 2.0.0 through 2.2.1 that update never landed. The Task itself was stored correctly, but the CarePlan (and any contained RequestGroup) stayed active with no error. Activity statuses on the plan were not updated, and applications that treat CarePlan.status as the signal that a conversation or pathway is over kept treating those plans as live.

Deployments that leave activity completion off (the default) were not affected. Recurring or otherwise unbounded plans, which are not auto-completed by design, were not affected either.

Starting with 2.2.2, completing or cancelling the last Task of a bounded plan marks the CarePlan completed.

The check runs only when a Task changes to a terminal status. Plans that already finished under 2.0.0–2.2.1 stay active until they are updated. After upgrading, find CarePlans that are still active whose Tasks are all terminal and set CarePlan.status to completed where that matches the intended outcome. $renew-due-events and re-saving a Task with the same status do not retrigger the check. No configuration change is required.

Task search with unqualified patient id returned 412​

A Patient client searching their own Tasks with an unqualified numeric id — for example GET /Task?patient=1004 — was rejected with 412 Precondition Failed and the message Non-unique ID specified. The same search with a typed reference (GET /Task?patient=Patient/1004) returned 200 OK. Unqualified patient searches on other resource types (Observation, Condition, DocumentReference, and so on) were not affected.

Authorization-narrowed Task search adds the caller's typed patient reference (Patient/{id}) as a filter. When the client also sent the bare numeric id, the two forms denote the same patient but were treated as a conflicting pair, and the whole search failed. The failure appeared after the HAPI FHIR 8.12.0 upgrade in 2.2.0; typed Task searches and searches that were not authorization-narrowed continued to work.

Starting with 2.2.2, an unqualified numeric reference that denotes the same target as the authorization filter is treated as that typed reference. GET /Task?patient=1004 and GET /Task?patient=Patient/1004 return the same narrowed Task set. A numeric id that is not the caller's patient is still narrowed away (empty 200 OK or 403 Forbidden), not widened. No configuration change is required.