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?
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
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.
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.
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?
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...