>
> >
> >
> >
> >
>
> ```
In the above, the expression `evt/apgar_total_value` is shorthand for `evt.child(apgar_total_value)`, i.e. an Xpath-like expression that gets a child at a certain path.
If we were to agree on this, the next question is in what version do we add it? Possibilities:
- I think we leave it out of [Release 2.2.0](https://openehr.atlassian.net/projects/SPECAM/versions/12512/tab/release-report-all-issues), which otherwise has additions that are mostly implemented or being implemented in tools.
- Possibly the same argument for [release 2.3.0](https://openehr.atlassian.net/projects/SPECAM/versions/12548/tab/release-report-all-issues).
- We define the next release of ADL 2.5, and add it there.
- We define a 3.0 release and add it there.
I would propose we put it in a release called ADL 2.5, because we are not proposing to change ADL itself, i.e. ADL2 and AOM2 are still valid; the rules section just adds something.
If we agree on this, I will try to complete ADL 2.2 and ADL 2.3 in a form that doesn’t update the rules section syntax (the meta-model will change to the newer EL meta-model, because the old EL meta-model is now some years out of date and no longer maintained).
Thoughts?
---
### Author:  [@yampeku](https://discourse.openehr.org/u/yampeku)
#### Post date: [25 March 2021 15:45 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/7 "2021-03-25T15:45:44Z")
One thing that would break every ADL parser out there but could be quite useful in this context would be to declare aliases in a kind of AQL way:
e.g.
```auto
ELEMENT[id10] as myvariable occurrences ∈ {0..1} ∈ {
value ∈ {
DV_ORDINAL[id43] ∈ {
[value, symbol] ∈ { -- apgar_respiratory_value
[{0}, {[at11]}],
[{1}, {[at12]}],
[{2}, {[at13]}]
}
}
}
}
```
This would remove the need of the symbol section, arguably making the archetype less verbose and more clear. In any case I would assume this additional rules to be declared when creating templates, so having them into the archetypes is not a big deal.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [25 March 2021 20:15 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/8 "2021-03-25T20:15:45Z")
There’s a better way to do that, but it’s for ADL3, which is what is in the Decision Language, i.e. symbols are just codes. Then you can have:
```auto
definition
ELEMENT[respiratory_effort] occurrences ∈ {0..1} ∈ {
value ∈ {
DV_ORDINAL[id43] ∈ {
[value, symbol] ∈ {
[{0}, {[respiratory_effort_absent]}],
[{1}, {[respiratory_effort_weak]}],
[{2}, {[respiratory_effort_normal]}]
}
}
}
}
terminology
term_definitions = <
["en"] = <
items = <
["apgar_score"] = <
text = <"Apgar score">
description = <"A tool to assess the clinical status of the newborn infant immediately after birth and their response to resuscitation.">
>
["respiratory_effort"] = <
text = <"Respiratory effort">
description = <"Observation of the infant's respiratory effort.">
>
["absent"] = <
text = <"Absent">
description = <"No effort to breath.">
>
["respiratory_effort_weak"] = <
text = <"Weak or irregular">
description = <"Some effort to breath, moving chest.">
>
["respiratory_effort_normal"] = <
text = <"Normal">
description = <"Breathing normally or crying.">
>
```
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [8 April 2021 12:14 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/9 "2021-04-08T12:14:54Z")
I like that but how do specialisations work?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [8 April 2021 13:20 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/10 "2021-04-08T13:20:58Z")
@ian.mcnicoll are you referring to my last proposal, i.e. [#6 above](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/6)?
Yes - specialisations. I think the realistic approach is that the terms (i.e. symbol names) created for rules exist in all children, as they would in say a Java or Python class inheriting names from a parent class.
For the rules, they can either be added to (rules with new tag) or overridden - define a rule with the same tag. I.e. in the following:
```auto
Apgar_sum_validity: for_all evt: apgar_events |
evt/apgar_total_value =
evt/apgar_heartrate_value +
evt/apgar_respiratory_value +
evt/apgar_reflex_value +
evt/apgar_muscle_tone_value +
evt/apgar_skin_colour_value
```
In the above, `Apgar_sum_validity` is the tag. If you were to create a rule in a child with this same tag (some specialised idea of Apgar sum), then it would replace the original.
If we don’t like ‘tags’, we can define rules as proper functions, as I have done in the Decision Language. This would technically be a breaking change, but it would be a lot nicer. Then you would have:
```auto
apgar_sum_valid: Boolean
Result := for_all evt: apgar_events |
evt/apgar_total_value =
evt/apgar_heartrate_value +
evt/apgar_respiratory_value +
evt/apgar_reflex_value +
evt/apgar_muscle_tone_value +
evt/apgar_skin_colour_value
;
```
Now we have a properly defined function `apgar_sum_valid`, not just an expression, and it can be made clearer when this function is executed - for example, at every call to the archetype validator, or on some other basis. Then how redefinition works is clearer as well, since `apgar_sum_valid` has to remain a Boolean-returning 0-argument function in any child.
This would break Nedap’s current archetype-level rules, but am interested to know what @pieterbos thinks as a future direction.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [8 April 2021 14:11 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/11 "2021-04-08T14:11:18Z")
I’m thinking how would querying work with a term specialised from “apgar\_score” ?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [8 April 2021 15:16 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/12 "2021-04-08T15:16:36Z")
Ah - the ADL3 version.
For the purpose of illustration, assume that some org ACME published a specialised kind of Apgar score called a ‘neonate score’.
There are two ways to go:
## Partially self-defining hierarchy
We specialise the term `apgar_score` with the term `apgar_score.neonate`, i.e. using a dot (or some other character) to esablish the IS-A relation. Then an even more specialised code could be `apgar_score.neonate.weird`. If we wanted to preserve the ability to detect the depth at which a code is defined, then we need to also allow `apgar_score..strange`, which is the same idea as a code like `at2.0.4`. For the same reason, codes like `..really_strange` would then be possible. It is clear that ids starting with dots (or whatever else) and /or having double and triple dots internally are not going to be attractive kinds of ids for writing rules. We could go halfway, such that `apgar_score.neonate` is a specialisation child (at any level) of `apgar_score`, and `really_strange` is just a new code, again at any level. `apgar_score..strange` would just be `apgar_score.strange`, no matter at what level `apgar_score` and `apgar_score.strange` were defined at.
This gets us out of defining IS-A relations explicitly, but we’d lose the knowledge of what level of archetype specialisation a code was defined at (and we probably wouldn’t care). I think this might work well enough, but needs to be analysed more carefully.
## Full independent terminology approach
The above is likely to be unweildy, and a better approach is likely to be that we forget the old system of self-defining term hierarchies base on lexical ids like at4 ← at4.1 ← at4.1.7 etc, and just do the same as Snomed, modern ontologies etc. So you could potentially define `acme_neonate_score` as a child of `apgar_score`. To do this, we have to do what Snomed or any ontology does: add the relation as well, i.e. `acme_neonate_score IS-A apgar_score`. This might look as follows (in JSON5-ish syntax):
```auto
-- in Parent archetype
symbols: {
symbol_definitions: {
en: {
apgar_respiratory_value: {
text: "Apgar score respiratory value"
},
apgar_heartrate_value: {
text: "Apgar score heartrate value"
},
apgar_muscle_tone_value: {
text: "Apgar score muscle tone value"
},
apgar_reflex_value: {
text: "Apgar score reflex value"
},
apgar_skin_colour_value: {
text: "Apgar score skin_colour value"
},
apgar_score: {
text: "Apgar score total value"
}
}
}
}
-- in child archetype:
symbols: {
symbol_definitions: {
en: {
neonate_score: {
text: "ACME neonate score total value"
}
}
}
symbol_relations: [
["neonate_score", "is-a", "apgar_score"],
]
-- In 2nd level child
symbols: {
symbol_definitions: {
en: {
weird: {
text: "weird kind of neonate score"
}
really_strange: {
text: "something really strange"
}
}
}
symbol_relations: [
["weird", "is-a", "neonate_score"],
["really_strange", "is-a", "apgar_score"]
]
```
This approach means that querying has to work logically like you are querying with Snomed or whatever, except that the Query processor has the archetypes to provide the term hierarchy.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [9 April 2021 08:45 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/13 "2021-04-09T08:45:43Z")
Controversial, I know but I think what we will mostly need is the self-defining hierarchy, as these kind of term specialisations will not be commonly required and ‘proper ontologising’ even more rarely.
`apgar_score.0.strange` or `apgar_score._.strange`
If there is a need for proper ontologising, I would leave that to labelling with an external terminology, otherwise we enter a whole world of other pain!!
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [9 April 2021 09:51 UTC](https://discourse.openehr.org/t/rules-in-archetypes-getting-it-right/1272/14 "2021-04-09T09:51:31Z")
> [@ian.mcnicoll](#):
>
> Controversial, I know but I think what we will mostly need is the self-defining hierarchy, as these kind of term specialisations will not be commonly required and ‘proper ontologising’ even more rarely.
The argument against doing that is that, say you define this variable `neonate_score`, and you also want it to be in the IS-A relationship with `apgar_score`, for querying purposes. If we stick with self defining, wherever the neonate variable is mentioned, it will look like this:
```auto
apgar_score.neonate_score: Integer
Result := a + b + c + 1.4 -- or whatever
;
adjusted_score: Integer
Result := 80% * (apgar_score.neonate_score + 2 ) -- or whatever
;
```
Not easy to read, plus verbose. Compared to:
```auto
neonate_score: Integer
Result := a + b + c + 1.4 -- or whatever
;
adjusted_score: Integer
Result := 80% * (neonate_score + 2 ) -- or whatever
;
```
If we add the capability to represent IS-A relationships to archetypes (we are already talking about this remember), processing them at runtime in the query processor will not be complicated - it’s not like the processor has to call out to an actual separate ontology or terminology.
As usual, to be discussed.