Defining multiple constraint bindings in AOM/ADL 1.4

Technical (archive)
1

Hello,

A very direct question: Why it is not possible to define multiple constraint bindings for the same archetype node and the same terminology in AOM/ADL 1.4? I know in AOM/ADL 2.0 the management of these constraints change completely, but the following is the situation (limitation?) in existing 1.4.

For a given textual node, it is possible to define multiple term definitions (atNNNN codes), for example:

DV_CODED_TEXT matches {
defining_code matches {
[local::
at0001,
at0002]
}
}

term_definitions = <
[“en”] = <
items = <
[“at0001”] = <
text = <“XXXXX”>
description = <“*”>

[“at0002”] = <
text = <“YYYYY”>
description = <“*”>

However, it is not possible to define the same using constraint bindings (acNNNN codes). More precisely, it is only possible to do it if each code pertains to a different terminology. For example, the following example would be valid:

DV_CODED_TEXT matches {
defining_code matches {[ac0001]}
}

constraint_definitions = <
[“en”] = <
items = <
[“ac0001”] = <
text = <“New constraint”>
description = <“*”>

constraint_bindings = <
[“BI98”] = <
items = <
[“ac0001”] = terminology:BI98?code=YYYY

[“AIR93”] = <
items = <
[“ac0001”] = terminology:AIR93?code=XXXX

But not the following one, the ADL parser and the openEHR Archetype Editor do not even accept it:

DV_CODED_TEXT matches {
defining_code matches {[ac0001]}
}

constraint_definitions = <
[“en”] = <
items = <
[“ac0001”] = <
text = <“New constraint”>
description = <“*”>

constraint_bindings = <
[“BI98”] = <
items = <
[“ac0001”] = terminology:BI98?code=XXXX
[“ac0001”] = terminology:BI98?code=YYYY

Is it mandatory to use predefined subsets to define a coded value set with multiple values in a constraint binging?
Isn’t it reasonable to allow defining coded value sets explicitly at the archetype level (specially in cases where maybe we only have to define two or three codes)?
It would be a simple but very convenient patch to add to AOM/ADL 1.4+ before 2.0.

David

2

Hi David,

well the very direct answer is: ADL 1.4 is ... a bit limited;-)

your last example section:

constraint_bindings = <
["BI98"] = <
items = <
["ac0001"] = <terminology:BI98?code=XXXX>
                         ["ac0001"] = <terminology:BI98?code=YYYY>
>

would not even be allowed in ADL 2. Now, we have to ask why something like the above could exist. Presumably there has to be some distinguishing feature of the two mappings, otherwise how does tooling and systems know what to choose. One concept that has been brought up in the past is the idea of mapping codes and value sets differently for different uses of the same terminology, e.g. GP v nursing. Maybe something like:

constraint_bindings = <
["snomedct"] = <
["nursing"] = <
["ac0001"] = <http://snomed.info/id/1111&gt;
["ac0002"] = <http://snomed.info/id/3333&gt;
>
["general practice"] = <
                         ["ac0001"] = <http://snomed.info/id=/2222&gt;
["ac0002"] = <http://snomed.info/id/3333&gt;
>

The syntax might be different. There are all kinds of questions here. E.g. maybe you want the binding to snomedct to be mostly the same for all purposes, but just a bit different for some. See the ac0002 code above - it's mapped to the same thing in each case. Maybe we want something more like:

constraint_bindings = <
["snomedct"] = <
["ac0002"] = <http://snomed.info/id/3333&gt;
>
["snomedct/nursing"] = <
["ac0001"] = <http://snomed.info/id/1111&gt;
>
["snomedct/general practice"] = <
                 ["ac0001"] = <http://snomed.info/id=/2222&gt;
>

It's easy to imagine a lot of other similar ideas. So far I have never seen a solid statement of requirements on this need. Can you provide some more background on the need you have? It's not out of the question to get it into the soon-to-be-finalised ADL2, but we'd need something pretty clear to go on.

Secondly, your statement:
Isn't it reasonable to allow defining coded value sets explicitly at the archetype level (specially in cases where maybe we only have to define two or three codes)?

I assume you mean the internal code-set construct i.e.
[local::
at0001,
at0002]

which can of course have 1:1 code:concept bindings for each at-code. But you know that, so I probably don't understand what you are really asking...

- thomas

3

I will explain it in another way.

acNNNN codes are used as “placeholder constraints”, i.e. a kind of link to a query or subset in a terminological systems that defines the possible instance values of a coded attribute.

My question was: Is it needed to be always a link to a subset? Cannot we use acNNNN to define bindings to specific terminological codes explicitly enumerated, without the need of defining a subset in the terminological system in advance?

4

I think this is a different Q from before! But this is what ADL 2 does. All subsets in an archetype have an ac-code, and you can either/both define the subset locally. E.g. in , the value set is internally defined, with bindings to each of its terms. In , you can see ac-codes that have both an internal definition and an external binding (ac2, ac3). It could have had just the external binding, and no internal definition, or vice versa. Note that this is different from ADL 1.4, and the 1.4 => 2 converter in the ADL workbench has to synthesise these missing ac-codes - example from CKM. The ADL 1.4 archetype is , the ADL 2 one is . The latter’s value terminology looks like the following - thomas

(attachments)

jfegfacc.png

5

I will explain it in another way.

acNNNN codes are used as "placeholder constraints", i.e. a kind of link
to a query or subset in a terminological systems that defines the possible
instance values of a coded attribute.

My question was: Is it needed to be always a link to a subset? Cannot we
use acNNNN to define bindings to specific terminological codes explicitly
enumerated, without the need of defining a subset in the terminological
system in advance?

I think this is a different Q from before!

Maybe I overcomplicated my first mail :slight_smile:

But this is what ADL 2 does. All subsets in an archetype have an ac-code,
and you can either/both define the subset locally.

I know, that's why I asked if it is feasible to incorporate this or at
least something similar in the transitional 1.4+ since it seems a very
important characteristic.

6

yes, undoubtedly. I will start a wiki page to try and tease out changes to reverse engineer from ADL 2 into a new ADL 1.5, 1.6 etc. But I’ll rely mostly on input of others on this, so this suggestion needs to go there, and any others you have. I’ll do this ASAP. - thomas

7

Use case: to define an ‘ad-hoc’ list of codes that might apply and from which one can be choosen without the need to use the terminology service?

8

I would favor this change, so if there would be a voting, I would vote yes.
I was missing this feature, so I always managed it to handle it by misusing text/description.
According http://semver.org/ it would become 1.5: MINOR version when you add functionality in a backwards-compatible manner

Bert

9

Exactly, many times there are only a few codes needed in an archetype/dataset and the need to have a terminology-service available to resolve some codes in order to use some archetypes would be an overkill-requirement, which could also possible unnecessary slow a system down.