Correct errors and improve examples - S Garde review Nov 2018

Description

Errors from Review by Nov 2018

1.6.3 an explanation of how to use the negated match operator (~matches, or ∈) to define value set exclusions in specialised archetypes; -> should this not be ~∈ or an ∉ ?

3.1 For ideographic and script-oriented /languuages/

4.2.2 (shown in green in this document) – green?? I assume you mean blue?

Talking of identifiers here is a bit confusing when in 4.3.3 “node identifiers” are introduced. Not sure if this can be reworded in 4.2.2

4.2.4 Constraints expressed in cADL cannot be stronger than those from the information model. -> Am I misreading this, or should this be something like “can only be stronger”?

4.3.4.2 ("1 minute sample") vs “1 min sample” in the comment

4.3.4.2 no 'orphans': at least one instance of one optional child obj

4.4.2. Group Constraints

Sub-lists example: (Should this be called sub-groups instead?)
group cardinality ∈ {1} occurrences ∈ {0..1} ∈ { – at least one ?
Further, I assume that for groups within groups the individual ELEMENTs and CLUSTERs of the sub-group are counted individually towards the super-group’s cardinality, so e.g. in the example below, I can pick exactly 3 of id6-id11, but have to pick at least one of id9-id11 and a maximum of 2 of id9-id11. They are effectively all at the same level…

group cardinality ∈ {3} occurrences ∈ {*} ∈ { – pick any 2 & repeat
ELEMENT[id6] occurrences ∈ {0..1} ∈ {...}
ELEMENT[id7] occurrences ∈ {0..1} ∈ {...}
CLUSTER[id8] occurrences ∈ {0..1} ∈ {...}
group cardinality ∈ {1..2} occurrences ∈ {0..1} ∈ {
ELEMENT[id9] occurrences ∈ {0..1} ∈ {...}
CLUSTER[id10] occurrences ∈ {0..1} ∈ {...}
CLUSTER[id11] occurrences ∈ {0..1} ∈ {...}
}
}

Assuming what I assume is correct, it may be worth mentioning since the group constraint is different to ELEMENT and CLUSTER in this regard?

4.4.2.1 'any number of problem and diagnosis Entries, followed by one or more plan & treatment Entries'

I think the example needs to read:

'any number of problem and diagnosis Entries, followed by one plan & then any number of treatment Entries'

allow_archetype INSTRUCTION[id9] occurrences ∈ {*} ∈ { – Intervention
include
archetype_id/value ∈ {/openEHR-EHR-INSTRUCTION\.plan\.v*/} -> This must be something else for id9 – intervention -> medication/therapy (2x)
}

And at the end of 4.4.2.1: The above has the desired result in data: a group of any number of problems and diagnoses, followed by a plan, followed by one or more Interventions

Any number of Interventions

4.5 If the former is used, any specialised that adds a value constraint must use the regular form, as in the following example.

“Specialisation” or “specialised archetype”

4.5.2.2 “A similar warning should be noted” -> A similar warning as for a list of strings should be noted.

4.5.10 Although /stricly/ speaking

9.3.2 meaning that the type of the value /attirbute/ can be any descendant of DATA_VALUE .

Why does the example use 79.2 -79.9 and not 79.1 – 79.8 and why is the order so funny (I know it doesn’t matter technically, but reading it is just gives you extra things to think about that are not worth thinking about).

Can it be explicitly stated here if using the unspecialised id79 (i.e. without Dv_Quantity constraint) is still valid, or if as soon as it is specialised in some way this is no longer possible.

I assume this is not valid, but one way of thinking is – ah, I specialise the original 0..* occurring id79, once as id79.2, once as id79.3, etc… but since there are * occurrences, the rest can be filled with normal unspecialised id79 elements in data…

(Ah now I see that this is discussed later as exhaustive or non exhaustive redefinition… maybe the reference to this should be given at the end of this section already (instead of or in addition to the end of 9.3.2.1)

9.3.2.1 The link at the very end of the section does not work and should point to: https://openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_exhaustive_and_non_exhaustive_redefinition

9.4.1 typically done for single-valued /attirbutes/

9.5.3 + 9.5.4
…is quite hard to understand..If I understand correctly you make some assumptions in 9.5.3 (redefinition is non-exhaustive), then ask the question in 9.5.4 whether it is or should be exhaustive or non-exhaustive.

Mix in an unclear reference to what the second example refers to “The second shows a single node…” in 9.5.3 and a new example of Hepatitis in 9.5.4 and my confusion was complete for a while

9.5.4 discovered varieties of /hepratitis/

“The default situation is that they do, unless explicitly stated otherwise,”
The reference to what it is that they “do” is fairly unclear

9.5.8 “Since node identifiers are only required to disambiguate multiple sibling nodes, they may not exist on all nodes in a typical archetype. It is therefore possible to have a slot that carries no node identifier (e.g. due to being under a single-valued attribute). A use_archetype specification within a template will accordingly only mention the archetype identifier, with no node id, as per the following example (archetype followed by a template).”

The examples underneath have an node identifier just like the example above – or what am I missing?

9.5.9 This kind of constraint is similar to 'slot-filling', except there is no slot providing any constraint, and typically occurs <missing text here?>.

Using an external reference <missing text here?> for in an unarchetyped part of the RM structure is almost always done in specialised archetypes or templates, but is technically valid in a top-level archetype.

10.2 …the generic concept 'disharge summary' followed…

In the example:
content matches {
allow_archetype CONTENT_ITEM[id2] matches {
< openEHR-EHR-SECTION or < openEHR-EHR-EVALUATION
}

Did I miss this syntax? But looking at the grammar I don’t see how this could be constructed…

Appendix B1:
build_uid is defined, in the rest of the document it is build_id.

I think we agreed on build_uid, which is what is used in CKM.

BTW, looking at the identification specs, there is a build_count which has been removed according to the Revision History, but in fact is all over the place in the document.

Instance_id is probably the same as build_uid…the latter is what is in CKM and (I think) was agreed on for this.

Status

Reporter

Thomas Beale

Raised By

Sebastian Garde

Components

Affects versions

ADL 2.0
Configure