Archetypes - regex question

Technical (archive)
1

Dear All,

Could you explain a little piece of expected beahviour to me wrt
including/allowing one archetype to include others

A) If the include is a list of regex's matching archetype names etc e.g.

/checklist_item-general-cvs1\.v1|checklist_item-general-cvs2\.v1|checklist_
item-general-cvs3\.v2|checklist_item-general-cvs4\.v2draft|checklist_item-ge
neral\.v1|checklist_item-general\.v2|checklist_item-general\.v3/

& the exclude is:

/.*/

Then......I include those that match the include but exclude all others?
If so surely that is exactly the same as not having the exclude /.*/ at
all....

or...

if the exclude says exclude all....do I simply exclude all?

B) The reverse. i.e. the iinclude says /.*/ & the exclude is a list of
regex'es ....

What then?

TIA

Adam

2

Hi Adam

This is another example of the approach to be as specific as possible. The exclude statement can be used to exclude specific archetypes and the Include ALL in this case means that all others are allowed. If the Exclude ALL statement is added to an archetype, it means ONLY those specifically stated can be added.

The issue here is backward compatibility and new archetypes. The include will generally be seen as the appropriate list but others could be added if they arise and are required (the list is not closed). Tony Shannon has argued (along with me) that this should be the default (ie we do not usually know that it would never be appropriate to add another archetype here.

Is that helpful? Do you think this is useful? It does mean there is no need to reversion archetypes if new ones might fit in a cluster (which is also useful).

Cheers, Sam

Adam Flinton wrote:

(attachments)

OceanInformaticsl.JPG

3

In a message dated 13-6-2008 19:10:07 W. Europe Daylight Time, sam.heard@oceaninformatics.com writes:

We are getting into dangerous options here: include all and exclude all in a time series where ‘all’ definitely changes both with respect to revisions of the existing ones, deletions and new to be added might lead to inconsistent calls to archetypes over time.

I believe such constraining should not take place on the archetype over archetype level, but at the (OpenEHR) template level. In here you can be explicit in what is to be included or excluded.

Hi Adam

This is another example of the approach to be as specific as possible. The exclude statement can be used to exclude specific archetypes and the Include ALL in this case means that all others are allowed. If the Exclude ALL statement is added to an archetype, it means ONLY those specifically stated can be added.

The issue here is backward compatibility and new archetypes. The include will generally be seen as the appropriate list but others could be added if they arise and are required (the list is not closed). Tony Shannon has argued (along with me) that this should be the default (ie we do not usually know that it would never be appropriate to add another archetype here.

Is that helpful? Do you think this is useful? It does mean there is no need to reversion archetypes if new ones might fit in a cluster (which is also useful).

Cheers, Sam

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

4

William,

It is potentially dangerous ground.
But …

  • Archetypes express what can be documented about a specific topic.
    Since such a ‘Real Archetype’ can or will consist of re-usable patterns, ‘Real Archetypes’ consist many times of a collection of sub-archetypes that express recurring patterns of documentation.
    In other words archetypes can and will be nested.
    And there must be a way to specify what archetypes are part of the ensemble at what spots.

  • It will create the problem for Archetype Governance.
    We need to have rules and ways to manage and enforce them.
    This needs a tool.
    Ocean Informatics, for this purpose, has developed the Archetype Knowledge Manager.

Gerard

We are getting into dangerous options here: include all and exclude all in a time series where ‘all’ definitely changes both with respect to revisions of the existing ones, deletions and new to be added might lead to inconsistent calls to archetypes over time.

I believe such constraining should not take place on the archetype over archetype level, but at the (OpenEHR) template level. In here you can be explicit in what is to be included or excluded.

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

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

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

5

Hi William

This only applies to slots - not to events, so the problems you allude to in regard to timing could not arise.
Closing slots is a problem for backward compatibility and, as you point out, should probably be left to templates. But documenting archetypes that are known to fit the slot at design time is knowledge worth capturing.

Cheers, Sam

(attachments)

OceanInformaticsl.JPG

6

This is another example of the approach to be as specific as possible. The
exclude statement can be used to exclude specific archetypes and the Include
ALL in this case means that all others are allowed. If the Exclude ALL
statement is added to an archetype, it means ONLY those specifically stated
can be added.

Sam, without putting words in Adams mouth, I think he was asking about
the precedence of include/exclude sections. It is a common problem is
coming up with rule system like this - for instance one can look at the
allow/deny pattern of the apache2.conf file for how to setup IP address
ranges. In the apache case, there is an explicit clause that allows the
order to be changed - either allow first then deny, or deny first then allow.

In the ADL spec, this is mentioned as a "yet to be defined" (section 5.3.8).

Andrew

7

Andrew Patterson wrote:

Sam, without putting words in Adams mouth, I think he was asking about
the precedence of include/exclude sections. It is a common problem is
coming up with rule system like this - for instance one can look at the
allow/deny pattern of the apache2.conf file for how to setup IP address
ranges. In the apache case, there is an explicit clause that allows the
order to be changed - either allow first then deny, or deny first then allow.

In the ADL spec, this is mentioned as a "yet to be defined" (section 5.3.8).
  

Indeed. I don't think the requirements have been adequately defined, so
this remains one of the few little holes to plug properly in ADL.

- thomas

8

Sam Heard wrote:

Hi Adam

This is another example of the approach to be as specific as possible.
The exclude statement can be used to exclude specific archetypes and
the Include ALL in this case means that all others are allowed. If the
Exclude ALL statement is added to an archetype, it means ONLY those
specifically stated can be added.

So if the include is ALL & the Exclude is ALL (as I believe one can do
in the tool) that would be the same as Include ALL?

The issue here is backward compatibility and new archetypes. The
include will generally be seen as the appropriate list but others
could be added if they arise and are required (the list is not
closed). Tony Shannon has argued (along with me) that this should be
the default (ie we do not usually know that it would never be
appropriate to add another archetype here.

Is that helpful? Do you think this is useful? It does mean there is no
need to reversion archetypes if new ones might fit in a cluster (which
is also useful).

I am a little concerned with the overlap twixt the Archetype editor &
the template editor in that in the template editor, unless one excludes
all then one can add what ever archetype you want to a given archetype
in whihc case....what's the point of doing so in the archetype editor?

i.e. I can see a division of labour occuring where a core team defines
archetypes & then a team working with hospitals etc define the archetypes.

Were that to be the case & were the core team to say "this archetype can
only contain....." then they might get concerned if template designers
can then go ahead & include any they feel like.

Adam
.

9

Williamtfgoossen@cs.com wrote:

In a message dated 13-6-2008 19:10:07 W. Europe Daylight Time,
sam.heard@oceaninformatics.com writes:

We are getting into dangerous options here: include all and exclude
all in a time series where 'all' definitely changes both with respect
to revisions of the existing ones, deletions and new to be added might
lead to inconsistent calls to archetypes over time.

I believe such constraining should not take place on the archetype
over archetype level, but at the (OpenEHR) template level. In here you
can be explicit in what is to be included or excluded.

Fine by me.....I don't mind where such restrictions occur, simply that
they not occur in 2 different places where an archetype says "can only
contain B or C" but the template says "contains D,E,F or G".

Adam

10

Thomas Beale wrote:

Andrew Patterson wrote:
  

Sam, without putting words in Adams mouth, I think he was asking about
the precedence of include/exclude sections. It is a common problem is
coming up with rule system like this - for instance one can look at the
allow/deny pattern of the apache2.conf file for how to setup IP address
ranges. In the apache case, there is an explicit clause that allows the
order to be changed - either allow first then deny, or deny first then allow.

In the ADL spec, this is mentioned as a "yet to be defined" (section 5.3.8).
  

Indeed. I don't think the requirements have been adequately defined, so
this remains one of the few little holes to plug properly in ADL.

- thomas

_______________________________________________
openEHR-technical mailing list
openEHR-technical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  
I am assuming allow then deny i.e. include all, exclude all = include all.

Otherwise...exclude all becomes somewhere between pointless & dangerous.

Adam

11

Adam Flinton wrote:

I am assuming allow then deny i.e. include all, exclude all = include all.

Otherwise...exclude all becomes somewhere between pointless & dangerous.

I think of it in terms of items moving back and forth between an "include"
list and an "exclude" list.

* Initially, the slot is completely unconstrained. Therefore, all archetypes
are in the "include" list.
* Excluding some archetypes shifts them to the "exclude" list.
* Excluding all shifts all archetypes into the "exclude" list.
* Including some archetypes overrides exclusion, moving them back to the
"include" list.
* Include all shifts all archetypes back into the "include" list.

So it's basically a three-state process:

1. All initially included.
2. Move some (or all) to the "exclude" list.
3. Move some (or all) back to the "include" list.

This seems to be the behaviour that we observe in Ocean's Template Designer.
In particular, this way of conceptualising it is consistent with how
including has no effect unless you also exclude all; and it is also
consistent with your hope, Adam, that include all should override exclude
all.

It also means that "include all" is rather pointless, doesn't it, because
doesn't "include all" have exactly the same effect as not constraining it at
all?

Maybe it would be clearer if there was only one list. It could have worked
like this, I think:

* By default, the list would be an "exclude" list; i.e. it would serve to
constrain the slot by specifying that certain patterns be disallowed.
* There would be an option to treat it as an "include" list; i.e. only the
specified patterns would be allowed.
* There would be no need for the "all" options. They would be redundant,
because "include all" would be the same as not constraining it at all, and
"exclude all" would be the same as an empty "include" list.

Unless there's something I don't understand about how it is meant to work
now, this suggestion would give us most of the power of the current
arrangement, minus the confusion. (The only capability that we would lose,
that I can think of, would be the ability to exclude a proper subset of the
archetypes, but then to re-include a subset of that subset: e.g., to exclude
"problem-.*", but then to re-include "problem" itself. Do we really need
such fine-grained control?)

- Peter