April 2017

Review

A number of issues have been marked in the text and are reproduced here in groups corresponding to sections. Visitors to this page can comment on them in the tables below.

Typos and other kinds of problems can be indicated in the final table at the bottom of the page.

In both cases, please add a new row for each separate comment or commenter. Please use the Who column to identify yourself.

Issues

Requirements

Id	Location	Description	Who	Comments	Resolution
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?

Conceptual Design

Id	Location	Description	Who	Comments
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.

Formal Model

Id	Location	Description	Who
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_TASK`that 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

Typos and Errors

Location Section / Para	Type T = Typo I = Incorrect M = Missing	Description	Who	Comments	Resolution