Re: Major update to openEHR Task Planning (workflow) draft specification

[Pablo Pazos]

Hi Thomas, is there any way to see a diff of the changes? Going through the
full document again to detect changes is difficult. Thanks!

On Wed, Jun 7, 2017 at 3:31 PM, Thomas Beale 
wrote:

>
>
> On 07/06/2017 19:03, Thomas Beale wrote:
>
>
> A new version is now up, with substantial rework on the runtime classes,
> also other new sections elsewhere in the document.
>
> - thomas
>
>
> with link
> 
> ...
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Major update to openEHR Task Planning (workflow) draft specification

[Thomas Beale]

On 07/06/2017 19:03, Thomas Beale wrote:



A new version is now up, with substantial rework on the runtime 
classes, also other new sections elsewhere in the document.


- thomas



with link 
...
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Major update to openEHR Task Planning (workflow) draft specification

[Thomas Beale]

A new version is now up, with substantial rework on the runtime classes, 
also other new sections elsewhere in the document.


- thomas


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Major update to openEHR Task Planning (workflow) draft specification

[Thomas Beale]

Hi Pablo,

thanks for the comments.


On 04/06/2017 03:28, Pablo Pazos wrote:

Hi all, here is my first review:

Section 2

a. Try to link the concept of task / task list with worklist item / 
worklist commonly used in imaginology flows and DICOM terminology.


I've added a new section 
 
which (briefly) describes the relationship to things like BPMN. Here it 
is noted that the Task Planning spec is designed to primarily address 
the question of patients as 'cases' rather than passive objects, such as 
tissue samples, images, or even the patient-as-imaging-subject, which is 
the patient in a passive role. We could potentially try to cover 
scenarios from imaging as well, but we probably need to work out which 
ones. Do you have specifics in mind?




b. Rephrase "A list of planned tasksneed not all relate to a single order"

c. Requirements are too generic on the first 3 paragraphs of 2.1., 
would be better to use the first section to show samples of concrete 
requirements, then abstract them to show the family of requirements 
that will be handled by this spec. I think it goes to a solution too 
quick without specifying the requirements nor the scope :)


*Ideas for use cases:*

1. physiotherapy rehab sessions (recurrent therapeutic procedure, with 
end)

2. dialysis sessions (recurrent therapeutic procedure, might be chronic)
3. diet + physical activity plan for overweight treatment (recurrent 
tasks, patient feedback, care team evaluation and plan adjustments = 
plan can change over time, will end when the patient reaches a healthy 
status)
4. medication (consider both acute and chronic, associated with a 
symptom, condition or problem)

5. surgery planning (one time event)
6. patient care plan related to goals (goals can be established over 
vitals or lab results/analytes, tasks are defined for the patient to 
fulfill; tracking, evaluation and correction to the plan is a common 
flow; ends when the patient reaches healthy values)


this is a good list; I've incorporated it into the top of the 
requirements section.




*Basic requirements*: (based on my experience, this might not be 
complete in any case, and some items might be out of the spec scope 
but I wish these can be taken into account)


1. task definition: what should be done, by whom, in which context, to 
whom, when, with what priority, where, etc.
2. commit defined tasks: share the task in the EHR, will be on planned 
status
3. communicate planned tasks: planned tasks are sent to the 
correspondent fulfillment systems, departments, units or specific 
people (actors)
4. task execution status tracking: the execution of tasks should be 
tracked, and each status change be recorded and committed to the EHR 
so other parties can look at it (query)
5. communicate task executions / status change: specific actors should 
receive information about status change on specific tasks (e.g. tasks 
they follow, tasks they defined/planned, tasks related to EHRs in 
which they participate)
6. all associated information (care + administrative) generated from 
the task execution should be available in the EHR


Agree with these, but I think they are taken care of already so far. I 
may add in a section that makes it a bit clearer how the Task plan 
should connect to the EHR.





d. "framwork", "|OBSRVATION"| typos


fixed, thanks.




Section 3.

a. "One difficulty with posting a full plan is that in some cases, the 
order is effectively open-ended, i.e. it has no intended completion". 
I think this is used as argument to differentiate INSTRUCTION/ACTIVITY 
from TASK, but I don't see the problem of creating a new 
INSTRUCTION/ACTIVITY. A complete plan for a chronic case would not be 
on one INSTRUCTION, would be a set of INSTRUCTIONs in the EHR of the 
patient.


actually, this is true regardless of whether there is an order or not. 
I've reworded somewhat. A complete plan for any non-trivial condition 
would almost certainly involve more than one Instruction. But 
Instructions only represent orders, not planned tasks.




b. One problem we have with the current INSTRUCTION/ACTIVITY and 
ACTION spec is that it is stated that the archetype for 
ACTIVITY.description should be equal to the ACTION.description, and 
that only applies to medication. This is on an email from last year 
(we talked about that on other thread).


yes, I think we will need to look at that again, and possibly revise it.





Section 5, 6, 7. review of modela

a. Let me check if I got it right:

blue: definition
orange: execution tracking / status



I've now fixed the colours in the instance diagrams to match those in 
the class diagrams.




b. I don't see much difference between TASK_LIST and TASK_GROUP. 
Looking at the hierarchy & composite pattern, is like what we have on 
ITEM_TREE and CLUSTER, knowing that the tree is basically the same as 
the 

Re: openEHR-technical Digest, Vol 64, Issue 6

[Karsten Hilbert]

On Mon, Jun 05, 2017 at 05:54:49PM +0100, Thomas Beale wrote:

> With 'true' questionnaires, the questions can be nearly anything. For
> example, my local GP clinical has a first time patient questionnaire
> containing the question 'have you ever had heart trouble?'. It's pretty
> clear that many different answers are possible for the same physical facts
> (in my case, occasional arrhythmia with ventricular ectopics whose onset is
> caused by stress, caffeine etc; do I answer 'yes'? - maybe, since I had this
> diagnosed by the NHS, or maybe 'no', if I think they are only talking about
> heart attacks etc).

And, in fact, the GP may not actually be interested that much
in whether you actually really had any (clinical) *heart*
trouble. After all, quite a few people will list their
esophageal burns or intercostal nerve irritations (which
is NOT a problem !).

What a GP may be after is likely your internal model of your
state of health...

Large swathes of Primary Care have needs way different from
the more restricted areas of health management.

Regards,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR-technical Digest, Vol 64, Issue 6

[GF]

Dear Silje,

I understand that at the clinical (health care provider) level each wants/needs 
to do its own thing in each unique way.

But:
Modelling Templates using recurring patterns (Archetypes) has a (a lot of) 
value.
Doing the same things the same has value.
In this way we can create an ordered way to query the data safely.

What means ‘the way that best represents the data’?
Is it the way clinicians see it how it is presented?
Or is it the way we can query the best, most safe way?
Requirements for both are not the same.

Questions in questionnaire are observations.
But what is it, when a Scale makes use of existing data in the database and 
calculates an aggregate result?
(E.g. BMI)
Isn’t the latter an evaluation of existing observations by means of a rule?
In the case of BMI the weight and length are real observable properties of a 
(human) body.
Question: Is the BMI an observable property? I think not. It is an aggregate, 
an evaluation.



Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 6 Jun 2017, at 19:34, Bakke, Silje Ljosland 
>  wrote:
> 
> I agree and disagree.  <>J
>  
> An EHR needs to be able to cope with all kinds of data, “questionnaire” or 
> not. However I’m not so sure a modelling pattern that works for everything 
> that could be labelled a “questionnaire” is achievable, or even useful.
>  
> Modelling patterns are sometimes extremely useful, for instance for 
> facilitating modelling by non-clinicians or newbies, but sometimes they 
> aren’t very practical. One of the problems is that clinical information in 
> itself is messy, because healthcare information doesn’t follow nice semantic 
> rules. Clinical modelling must above all be faithful to the way clinicians 
> need to record and use data, not to a notion of semantically “pure” models.
>  
> Finding “sweet spots” by identifying patterns that are sensible, logical, and 
> above else *work* for recording actual clinical information is often an 
> excruciatingly slow process of trial and error, exemplified by the substance 
> use summary EVALUATION and the physical examination CLUSTER patterns of 
> modelling, which both had taken years of trial and error long before I got 
> involved in them.
>  
> If we can find patterns across some kinds of “questionnaires”, like clinical 
> scores, great! However, since there isn’t a standardised pattern for paper 
> questionnaires, it’s not likely that it’s possible to make one for electronic 
> questionnaires. Outside the RM/AOM, a generic pattern archetype for every 
> questionnaire with variable levels of nesting, variable data points, etc 
> isn’t possible, nor would it in my opinion be useful. It would put all the 
> modelling load on the template modellers, which arguably would be more work 
> than modelling the same structures as made-for-purpose archetypes.
>  
> Some rules of thumb have developed over time though:
> 1.   Model the score/assessment/questionnaire in the way that best 
> represents the data
> 2.   Use the most commonly used name for identifying it
> 3.   Model them as OBSERVATION archetypes, unless they’re *clearly* 
> attributes of f.ex. diagnoses, in which case they should be CLUSTERs 
> (example: AO classification of fractures)
> 4.   Make sure to get references that support the chosen structure and 
> wording into the archetypes
>  
> In my opinion this pragmatic approach is likely to capture the data 
> correctly, while at the same time minimising overall modelling workload.
>  
> Regards,
> Silje
>  
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org 
> ] On Behalf Of GF
> Sent: Tuesday, June 6, 2017 3:58 PM
> To: For openEHR clinical discussions  >
> Cc: Thomas Beale  >
> Subject: Re: openEHR-technical Digest, Vol 64, Issue 6
>  
> I agree.
> ‘questionnaire’ is many things, but not at the same time.
>  
> In any case any EHR needs to be able to cope with all kinds.
> From ones with one or more qualitative results: such as the checklist
> To the validated Score where individual results are aggregated in one total 
> score.
>  
> It must be possible to create one pattern that can deal with all kinds.
>  
> 
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl 
>  
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>  
> On 6 Jun 2017, at 14:46, Vebjørn Arntzen  > wrote:
>  
> Hi all
>  
> To me a "questionnaire" is a vague notion. There can be a lot of different 
> "questionnaires" in health. From the GP's in Thomas's example to a Apgar 
> score, to a clinical guideline and even a checklist. Those are all a set of 
> "questions and answers", but