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.
|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.
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 |
|ISSUE-guideline_id-rep||Section 5.1||how should we best represent |
OBJECT_REF is the type used in
CARE_ENTRY.guideline_id, in the current spec. This was intended to enable the use of a
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 |
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
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.
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?
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|
Typos and Errors
Section / Para
T = Typo
I = Incorrect
M = Missing