Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Monday, March 14, 2016

Workflow Management State vs. Business Logic State

Imagine you are engaged in a complex business process, and your boss comes along and asks you how are you doing on the task type for concerned party (a business identifier in many cases).

You respond: I've finished the subtask A, and am working on the subtask B, and subtasks C and D are still waiting on input from subtask performer.  I can't do subtask E and F until those are done.

What you've just done is break down the business logic of your workflow into the components necessary to manage the workflow.  It's probably the kind of input your boss wants because his job is to make sure the workflow is completed efficiently, and he wants to know where he should take action.

Workflow management deals with the underlined stuff.  Business logic with the italicized stuff, which link tasks to execution.  When we talk of the state of a workflow, we often confuse these two sets of "state".  The overall task is in progress (workflow management state), and the task itself has completed one subtask, has another three in progress, with a final two waiting to be started (until their inputs are ready)  The business logic state of this workflow is often described in shorthand, assuming a stepwise set of refinements through execution of subtasks.

It is awareness of this distinction that enables workflow to be automated in a consistent way, and yet still linked to business logic.  At times I find it difficult to explain to folks in healthcare, that even though your workflows are different, that in fact, everyone's are, and yet, there are a common set of task states that can be applied to any task within a workflow.

Once you wrap your head around that, the Task resource makes a lot more sense.


Post a Comment