[TASKING] Tasking Business case requirements gathering

[dubdabasoduba]

Context

• Tasking is a feature aimed at enhancing CHWs' performance in the communities. This being said tasks have to undergo different states/statuses for them to achieve completion of some sort.
• This completion can be achieved by different states as defined here
• This documentation aims to give guidance on the kind of questions to ask when gathering requirements for the tasks to be generated for the Patient and Location entities.
• The example on the flow diagram below is purely hypothetical and not a true representation of any clinical business use case by any chance

Image representation of clinical tasks generation and task state changes

Questions to answer during tasking business requirements gathering.

1. How many task types can be generated per patient based on their health vertical association e.g how many types of tasks can be generated for an ANC patient.
   • Get the names of the tasks
   • Get the tasks descriptions.
2. What action/activities define when the tasks (mentioned above) should be generated.
3. How does the business defines the task states e.g at what time is the task defined as open, in progress, completed, failed, cancelled.
   • Get a write for each state change process.
   • NB: - Some state changes can be determined by the due dates and not necessarily actions performed against the patient.

NB: - Questions 2 & 3 above should be answered for each task type mentioned on question 1

[f-odhiambo]

@dubdabasoduba Other open question(s)

1. This flow chart presumes a clinical implementation and not for structures ? correct?
2. It seems from the code snippet below on $apply, will need to 1st create an encounter for registration, retrieve the CHW ID (practitioner ID) and then append it to the CarePlan during transformation. To be validated.
3. In this diagram the Task does not have an owner, when created, then in the Task status section, Supervisor assigns CHA, does that mean that the supervisor will sync a record of all newly unassigned tasks, then performs the Task assignment in the Supervisors app?
4. As an example, for the Danger signs screening task, for the process (Form completion, extraction and evaluation ), where does evaluation happen, implementors code or $apply operation? To be validated.
5. To close the loop. If all the Tasks of a CarePlan are fulfilled do we mark the CarePlan as completed? where does evaluation happen, implementors code or $apply operation? To be validated.

$apply operation snippet

fun generateCarePlan(
    planDefinitionId: String,
    patientId: String,
    encounterId: String,
    dataEndpoint: Endpoint,
    contentEndpoint: Endpoint,
    terminologyEndpoint: Endpoint
  ): CarePlan {
    return planDefinitionProcessor.apply(
      IdType("PlanDefinition", planDefinitionId),
      patientId,
      encounterId,
      /* practitionerId= */ null,
      /* organizationId= */ null,
      /* userType= */ null,
      /* userLanguage= */ null,
      /* userTaskContext= */ null,
      /* setting= */ null,
      /* settingContext= */ null,
      /* mergeNestedCarePlans= */ null,
      /* parameters= */ Parameters(),
      /* useServerData= */ null,
      /* bundle= */ null,
      /* prefetchData= */ null,
      dataEndpoint,
      contentEndpoint,
      terminologyEndpoint
    )
  }
}

CC @dubdabasoduba

[dubdabasoduba]

1. This flow chart presumes a clinical implementation and not for structures? correct?

This is correct. This only represents the clinical task generation. The tasking workflow after generation is the same hence though.

2. It seems from the code snippet below on $apply, will need to 1st create an encounter for registration, retrieve the CHW ID (practitioner ID) and then append it to the CarePlan during transformation. To be validated.

This is good, we could use the same logic for auto assignments of tasks

3. In this diagram the Task does not have an owner, when created, then in the Task status section, Supervisor assigns CHA, does that mean that the supervisor will sync a record of all newly unassigned tasks, then performs the Task assignment in the Supervisors app?

Yes, this is just one way of task assignments. We can also auto-assign as mentioned above. The method on the flow only works for an online first approach

4. As an example, for the Danger signs screening task, for the process (Form completion, extraction and evaluation ), where does evaluation happen, implementors code or $apply operation? To be validated.

I think form completion represents filling up the questionnaire, extraction represents the generation of the different resources from the QR and evaluation is performing checks on the data to identify the danger signs. This can use CQL.

5. To close the loop. If all the Tasks of a CarePlan are fulfilled do we mark the CarePlan as completed? where does evaluation happen, implementors code or $apply operation? To be validated.

This is a nice question. I am not very sure is the assumption here that the tasks would be used to also track the schedules on the careplan?

cc: @f-odhiambo

[pld]

This all looks great, thanks @dubdabasoduba and @f-odhiambo, some comments on the comments and then general comments below,

(3) Could work using p2p sync as well, not sure if we consider that online, but just noting

(4) Would definitely not be in $apply. For the time being this would be implementer code, but I could imagine this moving to workflow component of the SDK at some point.

(5) Agree, very good question, also nb CarePlans have status beyond active and completed that we may want to use in the future, but not right now. I think Ben's question answer this, it depends on whether we pre-generate all the potential Tasks for a CarePlan or not.

For example, if a PlanDefinition defines a sequence of 3 vaccine doses A, B, C, each dependent on the preceding and a minimum age, we could generate a CarePlan with status active and 3 Tasks in draft status. Then use a workflow component (we write, but join or be replaced by SDK workflow in the future) that runs daily (because the date changes) and on a change in Patient data, that checks whether the requirements for each Task are met and its status should change, to requested. With this model, when all these Tasks have the status completed we would know that the CarePlan is done and can change its status to complete.

However, if when the create the CarePlan, we only create Tasks that are applicable, like if the patient meets the minimum age we'd create a task for dose A, using the task statuses to manage CarePlan status is a bit trickier. It could work if when dose A is complete, we create a new task for dose B that's in draft (supposing the Patient doesn't have the minimum age for that dose) status before we evaluate whether to change CarePlan status, because the CarePlan would still have a not completed Task related to it. But if we completed the task for dose A, then updated CarePlan status, before checking if we have new tasks to complete, we would incorrectly set the CarePlan status to complete, since we won't see the incomplete task yet.

tl;dr we can use tasks to manage careplan status, but depending on how the workflow manages new tasks for a careplan there will be different edge cases to handle for the status to be guaranteed correct.

(6) I think we should add to the Sample Task State changes diagram where we will be writing code and integrating our workflow components. This breaks down into event based and scheduled tasking workflow. For scheduled (daily) task evaluator, I'd add a process icon on the side on the side, probably w/dashed arrows to every task, that checks if task status needs to be altered based on date change (eg if there's a min/max age, or expire date).

Another place for this is the "Does Woman have Danger signs" modal, here we do a task status change -- on this, doesn't the Record danger signs task change to complete regardless? The diagram reads like only on "no" -- and a Task generation. For the referral Task that's created here, is that defined by an existing CarePlan, a different new CarePlan, or not connected to a CarePlan?

(7) On potential outcomes, if a task is overdue, this reads like it needs to be in the failed or cancelled state, but I don't think that's correct. Can't a task be overdue, and then later completed?

K, probably enough for one comment!

[samkanga]

(7) On potential outcomes, if a task is overdue, this reads like it needs to be in the failed or cancelled state, but I don't think that's correct. Can't a task be overdue, and then later completed?

On the above comment, it would be great where a task is made available overdue with an option to complete it. Reason is the health workers may at times be overwhelmed and not complete all tasks in time. Only question is would accumulation of overdue tasks contribute to system response degradation?

Additional thoughts on Tasking:

1. Would the discussions on entity persistence here contribute to the tasking discussion? - The concept was based on the fact that entities such as locations, families and family members persist across plans. In an event where a new plan is activated and tasks are generated on the server side while the android client if offline, there is likely conflict in tasks generation when the android client goes online. Entity persistence provides for the ability to update generated tasks to harmonise server and client side generated tasks.