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
<http://www.openehr.org/releases/RM/latest/docs/task_planning/task_planning.html#_relationship_to_workflow_formalisms_and_systems>
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
steps.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
