Add rm_visibility top-level section to state hide/show and RM attribute aliasing.

Activity

Show:
Thomas Beale
May 22, 2020, 11:52 AM

Well if we want a path to an attribute within a subtype on an unconstrained node, we can already do that, but you can’t tell the type just from the path, without access to the RM. I.e. we already have this:

If you want to encode the RM type in the path as well, we could add something to the RM path syntax that indicates the RM type in the predicate part, e.g.

or perhaps

Doing either of these, or something equivalent would be relatively easy.

This is a very obscure corner case. I would not be thinking of adding id-codes to attributes, which breaks the entire AOM and all tooling, and also breaks the mapping to Xpath just to solve it.

Diego Bosca
May 22, 2020, 1:02 PM

We define a kind of special atcode that has the rmtype embeded (the above example can be written asitems[at0001]/value[DV_CODED_TEXTat]/defining_code

We used this to allow the definition of mappings to unconstrained parts of the archetype (which you needed to distinguish in which rmtype you want to include a given mapping or value).

These idcodes/atcodes reside on the archetype node id, so nothing breaks in AOM (you don’t really need to add anything to the attributes)

Thomas Beale
May 22, 2020, 1:53 PM

Does that mean you have some ‘DV_CODED_TEXTat’ code in the terminology section of the archetype? That would entail a text and description for something that is already defined in the RM, which seems redundant. I’d prefer to just use value[DV_CODED_TEXT] - 'DV_CODED_TEXTat' is a pretty weird label…!

Diego Bosca
May 22, 2020, 2:13 PM
Edited

Does that mean you have some ‘DV_CODED_TEXTat’ code in the terminology section of the archetype?

Nope, RM archetype terminology section is empty.

'DV_CODED_TEXTat' is a pretty weird label…!

It is, I don’t exactly remember the rationale for that specific thing we decided ~15 years ago, but probably because it’s easy to test if a nodeid starts with ‘at’ (archetype node) or ends with ‘at' (rm archetype node). I think we didn’t put the type exactly in there because some RMs allow some very nasty things as types (or attributes), so always transforming and making it explicit helps to treat those cases too (this doesn’t affect openEHR AFAIK, but could potentially affect any other standard where AOM is used)

In any case, this kind of paths was what we came with when dealing with unique RM paths that are not present in the archetype. Not saying that we must use the kind of ids we use, but that this mechanism solves the problem of identifying RM paths.

Thomas Beale
May 22, 2020, 2:45 PM

I think we’ve all learned something here today

Reporter

Thomas Beale

Raised By

Ian McNicoll

Components

Affects versions

Configure