Proposal to add Ready, On Hold, and Cancelled statuses to the FHIR2 Task Model

Projects FHIR
, ,
1

Hello everyone, @grace @dkayiwa @raff @mseaton @ibacher @taseew

In our current Bahmni implementation, we are utilizing the FHIR Workflow Module to manage request-fulfillment patterns. We have found that the current implementation of org.openmrs.module.fhir2.model.FhirTask (v2.5.0) only supports a limited set of statuses: REQUESTED, ACCEPTED, REJECTED, and COMPLETED.

To support more granular clinical workflows, we would like to propose adding the following R4-compliant statuses to the model:

READY: Essential for signaling that a specimen has been collected and the task is now actionable.

ON HOLD: Critical for exception handling, such as when a test is paused due to some issues.

CANCELLED: Necessary to track orders that are discontinued after they have already been accepted by the fulfiller.

Expanding the fhir_task table to include these states will significantly improve the visibility of order fulfillment for clinicians using the Order Tracking dashboards.

We are eager to hear the community’s thoughts on expanding the FhirTask status enum to better align with the HL7 FHIR R4 specification.

@angshuonline @mohant @rahu1ramesh @arshiya_sehzad @akhilmalhotra @devsingh05298

2 Likes
2

This makes lots of sense to me!

2 Likes
3

Thanks Daniel.

Please take a look at the JIRA card we have created for the same: Jira Also, kindly review the PR: FM2-678 | Extend FhirTasks to include Ready, On Hold and Cancelled Task Statuses by PoojaSastry-TW · Pull Request #601 · openmrs/openmrs-module-fhir2 · GitHub

Since our Bahmni implementation currently uses the OpenMRS version 2.5.12 and FHIR version 2.5.0, requesting you to backport this to FHIR version of 2.5.0.

Thank you!

4

Can happily backport to FHIR2 2.x, but we can’t really backport to patch versions of specific modules.

5

Thanks for clarifying. Could you please go ahead with backporting to FHIR2 2.x? That should work for us.

6

Already did. It’s available in the SNAPSHOT. If you can confirm that version works for you, we can cut a release.

7

Please accept our apologies for the delayed response. We are in the process of reviewing this and will provide an update with confirmation soon.

8

Hi everyone, @grace @dkayiwa @raff @mseaton @ibacher @taseew

Following up on the initial proposal, we’ve realised that we also need to include Draft and In Progress statuses in the FHIR2 Task model.

We initially missed this because we didn’t foresee a workflow where a task would need to be transitioned back to a ‘New’ state. However, standard clinical workflows often require this capability:

  • Orders or tasks are frequently placed ‘On Hold’ awaiting a specific event (such as patient arrival or a completed triage).

  • Once that event occurs, clinical staff need to transition the task back to a ‘New’ status to alert the respective departments to begin fulfilment.

To support this, we need the Draft status so it can be mapped to a ‘New’ option in the UI dropdown, allowing users to move tasks out of ‘On Hold’. Additionally, we need In Progress to accurately track tasks once active execution begins.

Would love to get the community’s thoughts on expanding the current proposal to include these two statuses.

9

I do not see a problem in adding a feature that you have a real use case for, and is already supported by FHIR. :slight_smile:

1 Like