Definitions and purpose of Task.basedOn, and Task.focus are unclear and confusing

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • Task
    • Workflow
    • Hide

      Will change the definition of Request.basedOn to:

      A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this title.  Authorization from the 'basedOn' request flows through to the referencing title.

      Will add the following usage note to Request.basedOn:

      basedOn represents the 'authorization' chain for an action, not the 'reason for action'.  For example, an order might be placed on hold under the authorization for a surgery.  However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications".

      Will add the following usage notes to Task.basedOn:

      Task.basedOn is never the same as Task.focus.  Task.basedOn will typically not be present for "please fulfill" Tasks as a distinct authorization is rarely needed to request fulfillment.  If the Task is seeking fulfillment of an order, the order to be fulfilled is always communicated using `focus`, never basedOn.  However, authorization may be needed to perform other types of Task actions.  As an example of when both would be present, a Task seeking suspension of a prescription might have a Task.basedOn pointing to the ServiceRequest ordering surgery (which is the driver for suspending the MedicationRequest - which would be the Task.focus).

      Will change the definition of Task.focus to:

      The request being fulfilled or the resource being manipulated (changed, suspended, etc.) by this task.

       Will replace the current usage notes on Task.reasonCodeableReference (which say "This should only be included if there is no focus or if it differs from the reason indicated on the focus.") to instead say:

      This will typically not be present for Tasks with a code of "please fulfill" as, for those, the reason for action is conveyed on the Request pointed to by Task.focus.  Some types of tasks will not need a 'reason'.  E.g. a request to discharge a patient can be inferred to be "because the patient is ready" and this would not need a reason to be stated on the Task.

       

      Show
      Will change the definition of Request.basedOn to: A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this title .  Authorization from the 'basedOn' request flows through to the referencing title . Will add the following usage note to Request.basedOn: basedOn represents the 'authorization' chain for an action, not the 'reason for action'.  For example, an order might be placed on hold under the authorization for a surgery.  However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications". Will add the following usage notes to Task.basedOn: Task.basedOn is never the same as Task.focus.  Task.basedOn will typically not be present for "please fulfill" Tasks as a distinct authorization is rarely needed to request fulfillment.  If the Task is seeking fulfillment of an order, the order to be fulfilled is always communicated using `focus`, never basedOn.  However, authorization may be needed to perform other types of Task actions.  As an example of when both would be present, a Task seeking suspension of a prescription might have a Task.basedOn pointing to the ServiceRequest ordering surgery (which is the driver for suspending the MedicationRequest - which would be the Task.focus). Will change the definition of Task.focus to: The request being fulfilled or the resource being manipulated (changed, suspended, etc.) by this task.  Will replace the current usage notes on Task.reasonCodeableReference (which say "This should only be included if there is no focus or if it differs from the reason indicated on the focus.") to instead say: This will typically not be present for Tasks with a code of "please fulfill" as, for those, the reason for action is conveyed on the Request pointed to by Task.focus.  Some types of tasks will not need a 'reason'.  E.g. a request to discharge a patient can be inferred to be "because the patient is ready" and this would not need a reason to be stated on the Task.  
    • Vassil Peytchev/Jose Costa Teixeira: 5-0-0
    • Clarification
    • Non-substantive

      The current documentation for Task.basedOn states:

      Description: Request fulfilled by this task
      Definition: BasedOn refers to a higher-level authorization that triggered the creation of the task. It references a "request" resource such as a ServiceRequest, MedicationRequest, ServiceRequest, CarePlan, etc. which is distinct from the "request" resource the task is seeking to fulfill. This latter resource is referenced by FocusOn. For example, based on a ServiceRequest (= BasedOn), a task is created to fulfill a procedureRequest ( = FocusOn ) to collect a specimen from a patient.

      The documentation of Task.focus states:

      Description: What task is acting on
      Definition: The request being actioned or the resource being manipulated by this task.

      These definitions are not very clear, and create confusion. In general, I don't think there there will be a secondary "request" for task.focusOn to reference. It makes more sense to use sub-tasks for parts of the original request, rather than expecting additional ServiceRequests. Example:
      ServiceRequest: lab order for CBC Panel
      Task 1: basedOn ServiceRequest, no focus, please fulfill order for CBC Panel
      Task 2: basedOn ServiceRequest, focus Specimen, partOf Task 1, collect specimen

            Assignee:
            Unassigned
            Reporter:
            Vassil Peytchev
            Vassil Peytchev
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: