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.
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:
-
physiotherapy rehab sessions (recurrent therapeutic procedure, with end)
-
dialysis sessions (recurrent therapeutic procedure, might be chronic)
-
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)
-
medication (consider both acute and chronic, associated with a symptom, condition or problem)
-
surgery planning (one time event)
-
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)
-
task definition: what should be done, by whom, in which context, to whom, when, with what priority, where, etc.
-
commit defined tasks: share the task in the EHR, will be on planned status
-
communicate planned tasks: planned tasks are sent to the correspondent fulfillment systems, departments, units or specific people (actors)
-
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)
-
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)
-
all associated information (care + administrative) generated from the task execution should be available in the EHR
d. “framwork”, "OBSRVATION" typos
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.
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).
Section 5, 6, 7. review of modela
a. Let me check if I got it right:
blue: definition
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.
-
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)
-
package task_planning includes task execution classes, maybe set the package name to “tasks” to avoid confusion between definition, planning and execution classes.
-
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”.
-
It “feels” something in the TASK_LIST_ITEM hierarchy should inherit from ENTRY, since that is an statement of what should be done.
-
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.
-
Also DEFINED_TASK.prototype to have of cardinality * confuses me on how it should be used.
-
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).
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).
