Major update to openEHR Task Planning (workflow) draft specification

Thomas Beale thomas.beale at
Wed Jun 7 06:14:49 EDT 2017

Hi Pablo,

thanks for the comments.

On 04/06/2017 03:28, Pablo Pazos wrote:
> Hi all, here is my first review:
> Section 2
> a. Try to link the concept of task / task list with worklist item / 
> worklist commonly used in imaginology flows and DICOM terminology.

I've added a new section 
which (briefly) describes the relationship to things like BPMN. Here it 
is noted that the Task Planning spec is designed to primarily address 
the question of patients as 'cases' rather than passive objects, such as 
tissue samples, images, or even the patient-as-imaging-subject, which is 
the patient in a passive role. We could potentially try to cover 
scenarios from imaging as well, but we probably need to work out which 
ones. Do you have specifics in mind?

> b. Rephrase "A list of planned tasksneed not all relate to a single order"
> c. Requirements are too generic on the first 3 paragraphs of 2.1., 
> would be better to use the first section to show samples of concrete 
> requirements, then abstract them to show the family of requirements 
> that will be handled by this spec. I think it goes to a solution too 
> quick without specifying the requirements nor the scope :)
> *Ideas for use cases:*
> 1. physiotherapy rehab sessions (recurrent therapeutic procedure, with 
> end)
> 2. dialysis sessions (recurrent therapeutic procedure, might be chronic)
> 3. diet + physical activity plan for overweight treatment (recurrent 
> tasks, patient feedback, care team evaluation and plan adjustments = 
> plan can change over time, will end when the patient reaches a healthy 
> status)
> 4. medication (consider both acute and chronic, associated with a 
> symptom, condition or problem)
> 5. surgery planning (one time event)
> 6. patient care plan related to goals (goals can be established over 
> vitals or lab results/analytes, tasks are defined for the patient to 
> fulfill; tracking, evaluation and correction to the plan is a common 
> flow; ends when the patient reaches healthy values)

this is a good list; I've incorporated it into the top of the 
requirements section.

> *Basic requirements*: (based on my experience, this might not be 
> complete in any case, and some items might be out of the spec scope 
> but I wish these can be taken into account)
> 1. task definition: what should be done, by whom, in which context, to 
> whom, when, with what priority, where, etc.
> 2. commit defined tasks: share the task in the EHR, will be on planned 
> status
> 3. communicate planned tasks: planned tasks are sent to the 
> correspondent fulfillment systems, departments, units or specific 
> people (actors)
> 4. task execution status tracking: the execution of tasks should be 
> tracked, and each status change be recorded and committed to the EHR 
> so other parties can look at it (query)
> 5. communicate task executions / status change: specific actors should 
> receive information about status change on specific tasks (e.g. tasks 
> they follow, tasks they defined/planned, tasks related to EHRs in 
> which they participate)
> 6. all associated information (care + administrative) generated from 
> the task execution should be available in the EHR

Agree with these, but I think they are taken care of already so far. I 
may add in a section that makes it a bit clearer how the Task plan 
should connect to the EHR.

> d. "framwork", "|OBSRVATION"| typos

fixed, thanks.

> Section 3.
> a. "One difficulty with posting a full plan is that in some cases, the 
> order is effectively open-ended, i.e. it has no intended completion". 
> I think this is used as argument to differentiate INSTRUCTION/ACTIVITY 
> from TASK, but I don't see the problem of creating a new 
> INSTRUCTION/ACTIVITY. A complete plan for a chronic case would not be 
> on one INSTRUCTION, would be a set of INSTRUCTIONs in the EHR of the 
> patient.

actually, this is true regardless of whether there is an order or not. 
I've reworded somewhat. A complete plan for any non-trivial condition 
would almost certainly involve more than one Instruction. But 
Instructions only represent orders, not planned tasks.

> b. One problem we have with the current INSTRUCTION/ACTIVITY and 
> ACTION spec is that it is stated that the archetype for 
> ACTIVITY.description should be equal to the ACTION.description, and 
> that only applies to medication. This is on an email from last year 
> (we talked about that on other thread).

yes, I think we will need to look at that again, and possibly revise it.

> Section 5, 6, 7. review of modela
> a. Let me check if I got it right:
> blue: definition
> orange: execution tracking / status

I've now fixed the colours in the instance diagrams to match those in 
the class diagrams.

> b. I don't see much difference between TASK_LIST and TASK_GROUP. 
> Looking at the hierarchy & composite pattern, is like what we have on 
> ITEM_TREE and CLUSTER, knowing that the tree is basically the same as 
> the cluster.

well, hierarchies appear pretty much ubiquitously in models of complex 
information, so they are bound to recur.

> c. Looking at the execution model on section 7 it seems no ACTIONs are 
> needed to modify the execution status of a task. Is that correct? IMO 
> this is easier to implement because we don't need to model the ACTIONs 
> to make the status change. On the other hand, it give us more 
> responsibility in decide how and when those status changes happen. I'm 
> not sure about this, but I would like to explore to have specific 
> definitions for the records needed to execute a transition in the 
> state machine of the tasks, like ACTION for ACTIVITY.
> d. on fig 4. I'm not sure about some items on the model.

this section of the model still being clarified.

> 1. COMPOSITION.category = task_list, not sure if the task list is more 
> like a persistent (there is one task list per EHR) or event (multiple 
> tasks lists for the same EHR)

There can be multiple task lists per EHR.

> 2. package task_planning includes task execution classes, maybe set 
> the package name to "tasks" to avoid confusion between definition, 
> planning and execution classes.

we might introduce some sub-packages - let's see what implementers think.

> 3. TASK_LIST > CONTENT_ITEM, should there be a non-structural 
> constraint that says "if COMPO.category=task_list, there should be at 
> least one TASK_LIST in COMPO.content".

yes, this will need to be added, good catch.

> 4. It "feels" something in the TASK_LIST_ITEM hierarchy should inherit 
> from ENTRY, since that is an statement of what should be done.

The ENTRY type corresponds to clinical statements, that is, a record of 
something said, thought, ordered, or done. Task Plan items are not 
clinical statements in that sense, they are something like fine-grained 
scheduling / planning notes. ENTRY instances are 'about' a subject of 
care; Task Plan items are 'about' work items.

> 5. The idea of the DEFINED_TASK.prototype as defined in 6.2. seems the 
> same as ACTIVITY.action_archetype_id, but since ENTRY is linked, an 
> actual instance of the ACTION would be needed to be linked to the 
> DEFINED_TASK, and that instance won't have any data, just metadata. 
> Not sure if that is correct, IMO this is not consistent with the 
> current model.

The idea of the prototype is to enable a partly populated ACTION (or 
OBSERVATION or ADMIN_ENTRY etc) to be attached as a prototype to a TASK, 
as a way of defining what the TASK is about. At execution time, this 
prototype can be used to create the 'real' ACTION or other ENTRY.

> 6. Also DEFINED_TASK.prototype to have of cardinality * confuses me on 
> how it should be used.

I've added some explanation about this.

> 7. The only example used to describe the prototype attribute is 
> medication. How should that be used to define tasks related to goals 
> on vitals or lab results? or with the physiotherapy sessions? (see use 
> cases above).

At the moment, we have not looked at using Task Planning for lab result 
orders or goal management.

> General comments:
> There is an overlap with the current INSTRUCTION/ACTIVITY + ACTION 
> model. Looking at the requirements and model hierarchy, DEFINED_TASK 
> is almost the same as ACTIVITY. I would prefer to extend ACTIVITY than 
> define a completely unrelated class that complies with the same 
> requirements. Also, I would like to use the task execution model to 
> represent actual execution status of ACTIVITIES, something that now is 
> modeled in software outside the IM (Ian mentioned this a some time ago 
> in the lists answering my questions about ACTIVITY status tracking).

ACTIVITY defines an order, or part of an order, and generally speaking, 
states the order in a terse clinical manner, e.g. 'Amoxicillin 3td 7d' 
(or equivalent structured form), or 'left hip: Total hip replacement; 
stem type with acrylic cement fixation' etc. The idea of TASKs is to 
define concrete steps, such as 'administer 1 tab Amoxicillin at 16:00', 
'apply bone cement within prepared socket' etc.

In theory, I suppose ACTIVITY could be used to do this, but this would 
not be the normal clinical way of stating an order, and the 
implementation experience from various openEHR customer sites indicates 
that the need is for fine-grained task definition, not order definition 
(which is already available). How this works out across the various use 
cases of course will need some experimentation, and I fully expect 
changes over the trial period of the specification. Right now however, 
there seems to be a pretty clear distinction between orders and tasks or 

- thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-technical mailing list