Task Planning - Early draft issues

ISSUE-task-buffer

Section 3.4

is a better assumption that whatever planned Tasks have been defined in a Task List represent a clinical intention by the responsible clinicians, and should therefore always go in the EHR? Technically this would be simpler…

ISSUE-costing

Section 3.7

Detailed requirements?

ISSUE-task-entry-corr

Section 4.2

the alternative seems to be to allow a Planned Task to correspond to e.g. a whole Compositoin template, where the COMPOSITION contains a number of e.g. ACTIONs or OBSERVATIONs. Problems I see with this: a) who knows what is in the Composition template? It may change over time; b) what if only some of the items in the Composition template can be done? Is the Task half complete? Or should the performer not do any of it?

TB

Being able to document a real world clinical action with more than just an ACTION would be more flexible. But the target ACTION would be in a COMPOSITION in any case, which could be interpreted as documenting the original planned task.

ISSUE-actions-mand-or-opt

Section 4.3

The alternative view of this is that a Planned Task always results in an ACTION, but possibly another kind of Entry as well. For example a planned Task that logically describes an Observation to be performed could result in a linked ACTION/OBSERVATION pair. This creates a bit more data in the EHR, but arguably is more consistent, since there will always be an ACTION documenting any performed Task.

ISSUE-indications

Section 5.1

Is indications useful?

ISSUE-guideline_id-rep

Section 5.1

how should we best represent guideline_id? OBJECT_REF is the type used in CARE_ENTRY.guideline_id, in the current spec. This was intended to enable the use of a HIER_OBJECT_ID or GENERIC_ID. However, there is probably no reliable machine identifier system for guidelines or Care Pathways. Perhaps a DV_IDENTIFIER would be better - this would allow things like <`issuer` = "NICE"; id = "Sepsis pathway"; type = "care pathway">.

ISSUE-template-refs

Section 5.1

Is there a better way to specify entry_template_refs/ids?

ISSUE-instr-arch_id-needed

Section 5.1

instruction_archetype_ref/instruction_archetype_id() may be redundant; the planning application that creates these structures will know the relevant archetype ids; is there any value in recording them in the PLANNED_ACTION instances, especially since they can be determined by following the instruction_activity_instance_ref reverse runtime ref and looking at the INSTRUCTION.

ISSUE-generic-planned_time

Section 5.1

The class PLANNED_TIME should probably be made generic and added to the BASE component. Needs to take into account some of the other models of time specification.

ISSUE-fwd-refs

Section 5.2.2

entry_instance_ref is a forward reference - which requires updating the Task List after the Tasks have beed performed and relevant Entries committed. Is this complication worth the benefit obtained, i.e. directly followable links rather than querying, to find Entries from the Task List items? Is being able to determine the resulting Entries starting from the Task List even useful?

ISSUE-separate-task-ref

Section 5.2.2

A more flexible way of forward referencing may be to have a separate class e.g. EXECUTED_TASKthat can contain any forward ref, plus other meta-data such as time completed, whether completed and an other_details attribute that can be archetyped for more information.

ISSUE-location

Section 5.1

We need a way to capture where the planned task should be executed. This may be handled by using PLANNED_PARTICIPATION - where a planned participation is some location and/or physical resources like a room/ward/bed/etc. But I think this is not intended use of that relation??

DIPS-BNA