Major update to openEHR Task Planning (workflow) draft specification
pablo.pazos at cabolabs.com
Sat Jun 3 22:28:42 EDT 2017
Hi all, here is my first review:
a. Try to link the concept of task / task list with worklist item /
worklist commonly used in imaginology flows and DICOM terminology.
b. Rephrase "A list of planned tasks need 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)
*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
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
6. all associated information (care + administrative) generated from the
task execution should be available in the EHR
d. "framwork", "OBSRVATION" typos
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.
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
Section 5, 6, 7. review of modela
a. Let me check if I got it right:
orange: execution tracking / status
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.
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.
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)
2. package task_planning includes task execution classes, maybe set the
package name to "tasks" to avoid confusion between definition, planning and
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".
4. It "feels" something in the TASK_LIST_ITEM hierarchy should inherit from
ENTRY, since that is an statement of what should be done.
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.
6. Also DEFINED_TASK.prototype to have of cardinality * confuses me on how
it should be used.
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).
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).
On Thu, Jun 1, 2017 at 1:40 AM, Thomas Beale <thomas.beale at openehr.org>
> I have published a major update to the Task Planning draft specification
> It now includes sequential and parallel groups, conditional pathways, and a
> new model of execution time structures. It's still very rough in places,
> but in the interests of 'publish early publish often'...
> The main thing to be obtained from this version is that the general model
> structure I think is about right, i.e. the separation of Task List
> definition, runtime structures and execution history.
> All comments welcome, either
> - here, for general comments
> - the wiki page
> <https://openehr.atlassian.net/wiki/display/spec/Task+Planning>, for
> solutions to issues flagged in the text
> - SPECRM-58 Change Request on Jira
> for typos, general errors.
> Clinical people may like to look at the requirements, and are of course
> welcome to common on anything else as well.
> - thomas
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> Management Board, Specifications Program Lead, openEHR Foundation
> Chartered IT Professional Fellow, BCS, British Computer Society
> Health IT blog <http://wolandscat.net/> | Culture blog
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
pablo.pazos at cabolabs.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-technical