Skip to end of metadata
Go to start of metadata

This is just a proposal at this point in time and has not been validated with the project team

Summary of Task Resource

  • http://hl7.org/fhir/task.html
  • How to manage workflow with FHIR: http://hl7.org/fhir/workflow-communications.html
  • Highlights 
    • A task resource describes an activity that can be performed and tracks the state of completion of that activity. 
    • Task spans both intent and event and tracks the execution through to completion. 
    • In a RESTful context, a server functions as a repository of tasks. The server itself, or other agents are expected to monitor task activity and initiate appropriate actions to ensure task completion, updating the status of the task as it proceeds through its various stages of completion.
    • Tasks start in a Created state. Once they have been assigned to an owner they transition to the Ready state, indicating that they are ready to be performed. Once the owner initiates activity on the task, the task transitions to the In Progress state, indicating that work is being performed. Upon normal completion, the task enters the Completed state. If there is a failure during the task execution that prevents the task from being completed, it can also enter a Failed state, indicating an abnormal termination of the task. A task in any non-terminal state may also be Cancelled, representing an abnormal termination of the task due to external forces, rather than an error condition.
    • Key elements:
      • status - with required general workflow-related value set (requested, cancelled, completed, etc)
      • statusReason - helps distinguish, for example, cancelled due to patient not present vs. cancelled due to equipment malfuntion 
      • businessStatus - to be bound to business case-specific workflow value set
        • Given that the base standard Task Resource does not have a bound value set (not even an example one), this will likely be outside the bounds of this project as it will be implementation specific
      • basedOn - the link to the focal resource (eg. the ServiceRequest for a task to fulfill an order)
      • intent -  with required value set (proposal, plan, order, etc)
      • code - with example value set (approve, abort, change, etc)
      • focus - reference to the resource being manipulated by the task
        • Would this be the ServiceRequest or the Specimen?

Guidance on Including Tasks

The need for a Task resource may be implicit in the v2 message being transformed, along with the context of the real-world implementation. The system creating the FHIR bundle doesn't need to anticipate all the tasks a receiving system may need, but should know when the receiving system needs to "fulfill" some aspect of the v2 message. For example, a new order message (order control code of NW in ORC-1) may be sent to a system which wants notification of the order but has no intent to fulfill the order. In this case, the FHIR bundle should not include a Task. But if the new order message needs to go the system which should fulfill the order, then it is appropriate to include a Task resource in the bundle indicating the order should be fulfilled (but it's not necessary to include tasks (specimen collection, etc) for each step required to fulfill the order). 

Examples with Order Control Codes

  • ORC-1 = NW
    • This is a notification that a new order has been created
    • An initial map of ORC to Task is available - please add comments and suggestions
    • Results in a ServiceRequest with:
      • .status = "active"
      • .intent = "order" (or maybe one of the other order types)
    • Results in a Task with:
      • .status = "requested"
      • .intent = "order" (or maybe one of the other order types)
      • .code = "fulfill" (from an "example" value set)
  • ORC-1 = SN
    • This is a notification that a new order has been created (typically by a filler application) and sent to a system able to assign a placer ID)
    • Results in a ServiceRequest with:
      • .status = "active"
      • .intent = "order" (or maybe one of the other order types)
    • No Task resource is required if the message originates with the filler application (which already knows to fulfill the order)
  • ORC-1 = SC
    • Is this any different than NW other than the expectation that the ServiceRequest already exists and should be updated with the data in the Bundle?
  • ORC-1 = RE
    • Is this any different than NW other than the ServiceRequest may or may not already exists and should be updated with the data in the Bundle, including a likely DiagnosticReport? Is it even necessary to include a ServiceRequest resource in a Bundle derived from an ORU message?
  • ORC-1 = OC
    • This is a notification that an existing order has been cancelled (it is not a request to cancel)
    • Results in a ServiceRequest with: 
      • .identifier set to a value which has presumably been sent before (ORC-2 and/or ORC-3)
      • .status = "revoked"
      • .intent = "order" (or maybe one of the other order types)
    • This assumes we don't need a Task because the order is already cancelled, we just need the receiving system to update the existing ServiceRequest resource
  • ORC-1 = CA
    • This is a request to cancel the existing order
    • Results in a ServiceRequest with:
      • .identifier set to a value which has presumably been sent before (ORC-2 and/or ORC-3)
      • .status = "revoked"?? Or should the status remain "active" dependent on the associated task (see below)
      • .intent = "order" (or maybe one of the other order types)
    • Results in a Task with:
      • .status = "requested"
      • .intent = "proposal"
      • .code = "abort" (from an "example" value set)
      • Question - is this task the same Task resource as the once created by the "new order" message or is it a new Task to cancel the order? If the former, how do we handle Task.identifier to ensure that the same business ID is used in both cases?

Spreadsheet

Review of detailed mappings: 

Outstanding Questions

  • Do we need to create Tasks for actions that shouldn't need a decision on the part of a receiving system (eg. creation of a new order or cancellation for a control code of OC)?
    • Probably not
  • No labels