Versions Compared

Old Version 1

changes.mady.by.user Thomas Beale

Saved on

compared with

New Version Current

changes.mady.by.user Thomas Beale

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

IdLocationDescriptionWhoCommentsResolution
ISSUE-task-bufferSection 3.4is 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-costingSection 3.7Detailed requirements?


Conceptual Design

IdLocationDescriptionWhoCommentsResolution
ISSUE-task-entry-corrSection 4.2the 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?TBBeing 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-optSection 4.3The 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

IdLocationDescriptionWhoCommentsResolution
ISSUE-indications
Section 5.1Is indications useful?



ISSUE-guideline_id-rep
Section 5.1how 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-refsSection 5.1Is there a better way to specify entry_template_refs/ids?


ISSUE-instr-arch_id-neededSection 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_timeSection 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-refsSection 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-refSection 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-locationSection 5.1We 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 		DescriptionWhoCommentsResolution