Possible change request for Ocean Archetype Editor

Dear Sam,

I personally feel that the publication status is not obvious enough to be well-used, and would suggest that this goes onto the front screen.

I have a less strong view about the other descriptive information being moved, since the tab for it is clearly visible at all times, but the feedback I have had recently suggests that a clear description of the purpose/use is a headline item that might also be nice on the first screen. However, I could understand if you would not wish to separate this from the other descriptive information (misuse, evidence etc.).

With best wishes,

Dipak

Dear Sam,

I would like to see purpose, use, misuse and life-cycle on the first screen. Maybe:

Purpose, Use, Misuse on the left side and Specialisation, Authorship lifecycle and Subject of data (I have never really seen this in use?) on the right side.

If you don’t want to, then I would simply leave the description tab where it is now, I believe the entry model should be second.

The lifecycle/publication status is not very clear to me to be used consistently: Submitted (to whom?), Candidate (for what?) etc.
I believe this will become clear over time, once the process for the development itself is clearer.

Regards
Sebastian

Good day,
It would be interesting and may be more powerful if we could add operators (multiply, devide, substract and additions) in the Ocean Archetype editors.

Regards,
Pratima

Do you mean calculated fields? Sam

Pratima Poudel wrote:

Hi,

If calculated fields are requested, taking the square is needed.
And perhaps more.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 653 108732

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Pratima, Sam,

One example where I miss these operators would be the Barthel archetype - the total score could then explicitly be expressed as the sum of the other scores and automatically calculated.
You probably can do this with invariants somehow? They are just not very user-friendly…

Apart from the four basic operators Pratima mentioned, you could have others like max, min: e.g. an assessment where you take the maximum of several scores to e.g. indicate the severity of a condition.

Sebastian

Good day,
I would like to give some example here what I actually mean. It is may be better to have operators and min, max etc all. People will have flexibility.

1.I am using Ocean Archetype in desigining EHRs may be guidelines
Senerio 1: For example
Alcohol wihdrawl Protocol: guideline for assessment and initiate treatment
Criteria 1: Perspiration
0 = no abnormal sweating
1 = Moist skin
2= Localised sweat (face/chest)
3 = Whole body wet
4 = Profusing sweating (includes linens)

Criteria 1: Tremor
0 = No tremer
1 = Slight intentional
2 = Constant slight in uppper extremities
3 = Constant marked tremor

so on
Clinician can choose appropriate number and criteria based on the objective data (data from the assessment or observation). At the end of the assessment, text box ( square box) should show the sum (sevirity index . Based on the sum we can initiate three plan

  1. mild - continue 4 hrly observation
  2. Mod. - Oral diazepam such dose and such interval
  3. Severe: IV diazepam such dose and such interval
    To do this doctor does not need to be presented nurse can assess and initiate plan as agreed by multidiscplinary team.

2. Senerio 2: For example
I need operators to calculate certain values using observational data and lab test results. Thus, multiple text box need using along with the operators (This should be based on the reserch articles though).This gives sevirity index. Based on this we can create individual based plan. It is more decision making but data input can be done using openEHR archetypes if the calculation ability is incorporated. The data collected through this will be utilize for reserch too (vertual randomise trials). Because these data are complete, accurate and based on the clinical literatures. Again you can modify as reserch changes.
This will help in EBP, research and guideline development. What is your opinion?

Regards,
Pratima

Invariants are, on the whole, the way we would like to express this. This means for example, that you can say if all the scores are present, then the score is the sum of all the ordinals. It is clear, in apgar, that only the total is recorded in many instances - so it cannot just be a calculated field.

I agree that they are not user friendly and hard to write - is there a syntax for calculation we could use for the calculation aspect which many would be happy to use?

Sam

Pratima Poudel wrote:

Sebastian

Just to say that we have to be careful not to try and include decision support in the archetype itself - it just beeds to support DS engines.

Cheers, Sam

Sebastian Garde wrote:

Good morning,
My clinical experiences is:
Clinician does clinical assessment first before initiating plan and intervention. SOAPIE (Subjective data, objective data, assessment, Plan, intervention & Evaluation) are helping in critiical thinking leading to decision making at the end of the day.
From the reality point of view (how we perform our work): Social workers (normally write story about patient’s social life in the clinicial notes) and all other clinician ( physio, doctor, nurses, occupational therapist, specialits ) collects clinical data using SOAPIE to execute intervention (eventually simple way of creating clinical decision). SOAPIE can be the standard way of writing clinical notes. Here in Middlemore hospital, they have been using this method for writing clinical notes. In Auckalnd city hospital doctors and physios writies using SOAPIE. Nurses uses Foci methods. I guess, EHR always helps in making clinical decisions in the most of the clinical situations and some of the decision requires decision engines.

Regards,
Pratima

hospital doctors and physios writies using SOAPIE. Nurses uses Foci methods.
I guess, EHR always helps in making clinical decisions in the most of the
clinical situations and some of the decision requires decision engines.

Pratima, I don't think anyone is suggesting that decision support
wouldn't be delivered at the pointy end of the clinical process, just
that archetypes aren't the best spot to define the decision support.

Archetypes really are about the "data" that can be stored - by
defining the types of data, the meaning of the data and the
rules which say whether the data is valid. The archetype shouldn't
define what happens when the data matches a certain condition.

So in the case of your alcohol protocol

The system would define an archetype "AlcoholEval" with

- a perspiration criteria (defined to be a number between
0-4, potentially with bindings to external terminology to give
the numbers more universal meaning)
- a tremor criteria (defined to be 0-3 etc)
- a protocol score (defined to be an integer between 0-7,
with an invariant in the archetype starting that it is the addition
of the other scores)

Some user interface would be presented to the clinician to
allow them to fill this data in.

Elsewhere, a decision support engine would have some rules
that says if I encounter a "AlcoholEval" archetype, to recommend
different actions.

1. mild - continue 4 hrly observation
2. Mod. - Oral diazepam such dose and such interval
3. Severe: IV diazepam such dose and such interval

But the standards for defining formats for protocol guidelines
and interoperable decision support engines are still a way
off (i.e. your local implementation of openehr will probably have
a way of doing this decision support but its not part of the
standard).

(btw this is my understanding of the situation - others with
more clinical expertise or openehr expertise may disagree :slight_smile:

Andrew

I agree that they are not user friendly and hard to write - is there a
syntax for calculation we could use for the calculation aspect which many
would be happy to use?

I don't think its possible to go down the road of having computation
in the archetypes unless it is very strictly controlled (even then I'm
not sure its possible). As soon as you have invariant statements
with sideeffects (i.e. the ability to calculate the value of a field rather
than just check its validity) you then introduce problem with ordering
(the order the invariants are executed now matters), cycles (an
invariant changes a value that was previously ok'ed by another
invariant - do we go back to check it again) and indeed whether all
this checking will ever terminate.

Whilst it may seem like a subtle difference between an invariant
that says "the scores must sum up to the total", and "make this total
be the sum of the scores", it is a huge difference computationally.
It may be possible to write code that analyses invariants and
tries to construct corresponding code for calculation that is useable in the
user interface "template" for that archetype.

Andrew

Thank you Andrew for your clearification. I was wondering whether I could do both storing EHR and sinple DS through the archetypes therefore I was looking for the calculation field etc. etc. This means that EHR must be linked with separate DS engine. This helps heaps for my thesis.

Regards,
Pratima

Hi to all,

While revising my MST archetypes, I came across some confusion on the
use of cardinality and occurences. And when I reread ADL 1.4 and ADL2,
inspected the sample archetypes and then created new ones with Archetype
Editor and also tested with the Workbench my confusion got even more
increased. Here is the problem description and some questions:

As stated in ADL 1.4: "Cardinalities indicate limits on the number of
members of instances of container types such as lists and sets". From a
simpler point of view, what I understand it tells the min and max
allowed number of beads (same or different beads) in a box. From a more
sensible way in the realm of clinical archetypes written in ADL, it is
used to constrain the min and max allowed number of run-time instances
of child nodes of attributes which can be a container such as CLUSTER,
ITEM_TREE, ITEM_LIST, HISTORY and so on.

So far so good but I have a practical problem to model a situation like
the following:
PARENT_NODE (A container type and might not exist or repeat up to 2 times)
    a) CHILD_NODE (Must appear once)
    b) CHILD_NODE (May appear 0 to 8 times)

So this roughly can be expressed as:
CLUSTER occurences {0..2}
    any container attribute cardinality {1..9}
        QUANTITY occurences {1..1}
        ELEMENT occurences {0..8}

PROBLEM-1: As understood from above description that cardinality simply
depicts the number of instances of subchilds - REGARDLESS of their type
(i.e. QUANTITY or ELEMENT), then above cardinality can be {1..9} or
simply {1..*}. When I examine some sample archetypes such as Line 67 in
autopsy.v1, Line 33 in respiration.v1 and Line 103 in microbiology.v1
the cardinality of container node is {0..1} and they have a number of
child nodes with occurences >0 and it is clear clinically that almost
ALL of those nodes should appear in runtime data. So there is either a
misunderstanding of the use of cardinality here among most of us or I am
totally lost here :slight_smile:

The above model is expressed in those archetypes roughly as follows:

CLUSTER
    any container attribute cardinality {0..2}
        QUANTITY occurences {1..1}
        ELEMENT occurences {0..8}

QUESTION-1: What is the correct approach for above problem?

QUESTION-2: Assume in some other place in the archetype you reference
the ELEMENT node with occurences {0..8} by use_node. And in this
particular place you do not want to have up to 8 instances and but also
you want it to be mandatory (i.e. 1..) or even want {3..5}. What is the
solution? (other than writing the whole thing once again)

QUESTION-3: Related with second question, I also need to disallow usage
of some values when referencing by use_node entries. This I believe is
not an uncommon requirement in clinical medicine.For me I have an
element with a long list of values of sites of an organ (Esophagus,
stomach, colon and so on) and in many places of an observation these
sites repeat without change so I can reference original. But in some
cases selection of certain site(s) is not logical and should better be
restricted or selection of only one site makes sense. What is the solution?

Thanks and happy new year to all...

-koray

Thanks Koray

Your expression of cardinality and occurrences is exactly correct - there are clearly some errors in the archetypes.

The only reason to limit cardinality in the archetype is to force a choice when there are more than one child e.g.

container x with cardinality 1..2
has children a (occurrences 1..1)
b (occurrences 0..1)
c (occurrences 0..1)

This forces a choice between b and c.

Cheers, Sam

Cheers, Sam

Koray Atalag wrote:

Hello Koray,

Reading your issues around cardinallity, perhaps you can solve this issue with help of constrains/business rules. E.g. if you consider in the Archetype model the ability to have a cardinality between A and B of (0..N), you can constrain practically this cardinality to a maximum of e.g. 4. The risk of modelling you cardinalities so precise in the archetype model is that if in future this is changed, your system (e.g. database schema’s or applications) needs to be updated if this cardinality changes. If you are able to define the reason of this cardinality in rules you may create the flexibility in future to adapt this without changing systems or applications. I am not sure if this will help you, but consider this mechanism to handle cardinalities issues.
I hope this may help you in finding a solution for your issue,

regards
Roel

Roel Stap

TNO-ICT
Colosseum 27
7521 PV Enschede
+31 53 4835212
+31 6 10968787

http://www.tno.nl/ict

DISCLAIMER
http://www.tno.nl/disclaimer/email.html

Stap, R.E. (Roel) wrote:

Hello Koray,

Reading your issues around cardinallity, perhaps you can solve this
issue with help of constrains/business rules. E.g. if you consider in
the Archetype model the ability to have a cardinality between A and B
of (0..N), you can constrain practically this cardinality to a maximum
of e.g. 4. The risk of modelling you cardinalities so precise in the
archetype model is that if in future this is changed, your system
(e.g. database schema's or applications) needs to be updated if this
cardinality changes. If you are able to define the reason of this
cardinality in rules you may create the flexibility in future to adapt
this without changing systems or applications. I am not sure if this
will help you, but consider this mechanism to handle cardinalities issues.
I hope this may help you in finding a solution for your issue,

regards
Roel

Hi Roel,

Thanks for the information you provided; especially the one about the
effect of archetype design on the resulting software and database
schema. I would still like to take your attention to my specific
questions 2 and 3. These point out to very detailed aspects of archetype
design - ones that most probably will never encounter while designing
their archetypes.

Best regards and Bedankt!

-koray

Sam Heard wrote:

Thanks Koray

Your expression of cardinality and occurrences is exactly correct -
there are clearly some errors in the archetypes.

The only reason to limit cardinality in the archetype is to force a
choice when there are more than one child e.g.

container x with cardinality 1..2
    has children a (occurrences 1..1)
                       b (occurrences 0..1)
                       c (occurrences 0..1)

This forces a choice between b and c.

Cheers, Sam

Hi Sam,

Thanks for your kind answer and simple explanation; I just needed that
:slight_smile: Regarding the errors in the archetypes (and possibly others as well)
I think it would be nice to have this kind of "semantic/validity" check
built into ADL parser or the tools. Currently both the Editor and the
Workbench allow these type of errors.

Also if you take a look at my previous questions 2 and 3, they are
pointing out to some other aspects of ADL and archetype design. I would
highly appreciate some guidance here though not urgent at the time.

Best regards,

-koray

2007/1/8, Koray Atalag <atalagk@yahoo.com>:

Currently both the Editor and the
Workbench allow these type of errors.

Hi Koray,

The latest code of the Java Archetype Editor now validates cardinalities. It also has support for all but the demographics archetypes now. Lots of new improvements and features have been added and version 0.5 of the editor (including the source code) will be released before the end of this month.

Regards,

Mattias Forss

Hi Koray,

I am not sure if I understand the detailed questions fully, however, I
think that you should keep in mind that the archetypes should be
"generic" as possible. Archetypes are intended to be reused, and if I
read e.g. your issues for a {3..8} cardinality I get the impression that
this could be valid for a specific application. In this situation I
would suggest to make the archetype generic e.g. {0..N}, and configure
your application in terms of (business) rules (constrains on the
association).

If you need more information please provide a little more information
about your requirements and the application in which you need this...

regards
Roel

Roel Stap

TNO-ICT
Colosseum 27
7521 PV Enschede
+31 53 4835212
+31 6 10968787

http://www.tno.nl/ict

DISCLAIMER
http://www.tno.nl/disclaimer/email.html