Clarify Work Plan instantiation and distribution semantics.

Description

The WORK_PLAN.top_level_plans attribute should be changed to List<TASK_PLAN>. WORK_PLAN.plans should potentially be converted to a function that returns the same result.

These changes will allow archetype slots / refs to be used at the definition level.

The relationship between WORK_PLANs, TASK_PLANs and where they are committed to the EHR when materialised is not clear in the current spec.

The relationship between where WORK_PLANs are executed with respect to enterprises and workers in the real world is also not clear - how is a Plan that clinical implicates N enterprises (say GP, multiple hospitals, specialists etc) coordinated if there is no single shared place to execute it?

Activity

Show:
Bjørn Næss
October 11, 2018, 9:54 PM

I have written a note about this issues. It is influenced by the discussions on #slack yesterday.
The intention is to be as precise as possible about the use-cases we try to support . This is the base to understand the changes to be made.
Please have a look here and provide some feedback.

https://github.com/bjornna/TP-examples/blob/master/issues_tp_references.adoc

Thomas Beale
October 11, 2018, 10:33 PM

Before I go ahead and do it, two things:

1. I did not get to the bottom of what Matija's objections were, i.e. why he thinks multiple COMPOSITIONs are needed. I may be missing something here.

2. I wonder if instead of the type being adjusted to a Hash, i.e. WORK_PLAN.top_level_plans: Hash<String, TASK_PLAN>, where the String key is a name or other useful key (role name maybe) referring to the TASK_PLAN. Just an idea - have a think about how you might want to display and traverse this relationship.

Bjørn Næss
October 12, 2018, 10:07 PM

About 2. I wonder if instead of the type being adjusted to a Hash, i.e. WORK_PLAN.top_level_plans: Hash<String, TASK_PLAN>, where the String key is a name or other useful key (role name maybe) referring to the TASK_PLAN. Just an idea - have a think about how you might want to display and traverse this relationship

Is the key a UID_BASED_ID and the TASK_PLAN might be NULL?
If so - this might solve the issues. I need to look more into that.

Matija Polajnar
March 19, 2020, 10:54 AM

The beginning of the task is duplicated with SPECPROC-16.

This task then contains some philosophical questions that probably need to get answered, but most probably not for 1.5.0. , do you disagree?

Thomas Beale
March 19, 2020, 3:07 PM

for whatever reason, the one logical change got done over and this CR. I adjusted the description text to match what was actually done. Can't collapse them into one, since the Github commits already quote the two separate CR ids...

Reporter

Thomas Beale

Raised By

Bjørn Næss

Components

Affects versions

Configure