Runtime name suggestions?

Technical (archive)
1

Hi,

We’re trying to finalise the pattern for exclusion archetypes, and would like to use the element names to carry some flavor differences such as “no known history of …” and “no evidence of …”. We’ve considered adding a runtime name constraint to make some level of standardization of these statements, but at the same time we recognize that there will be considerable variation in what will be required as statements in different use cases. So what we’d like to do is to use a kind of “optional runtime name constraint”, or “runtime name suggestion”. We know this isn’t supported by tooling atm, but is it allowed by the specs? If so, how can it be done?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN

Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF

Tel. +47 40203298

Web: http://arketyper.no / Twitter: @arketyper_no

2

Hi Silje,

I’m not sure enough of the requirement, but this ADL logic may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the following heading after that section.

The basic logic of this is described here.

Although these are references from ADL2, they should apply in ADL 1.4 as well.

  • thomas
3

Thank you Thomas, to the extent I understand the ADL, this looks like what we’re looking for. How would the corresponding syntax look in ADL 1.4?

4

Hi Silje

As Thomas has noted, it is possible in adl but is not supported in archetype editor. That is probably fixable but I’m not sure currently how template designer would handle it.

Ian

5

Thanks! If I knew the syntax I could hack the ADL and test how TD handles it. J

Regards,
Silje

6

It should be the same as for ADL2 except of course, stick to using the correct at-codes, i.e. ‘at0004’ etc, rather than id-codes. SO I think the example from the ADL 2 spec is pretty close to the one you want, with at-codes, and terminal constraints they way you want.

definition
    ...
        name ∈ {
            DV_CODED_TEXT[id79] ∈ {
                defining_code ∈ {[ac1]}
            }
            DV_TEXT[id14] ∈ {
                value ∈ {/.+/} -- non-empty string
            }
        }
    ...

terminology
    ...
    term_bindings = <
        ["snomed_ct"]    = <
            ["ac1"] = <[http://snomed.info/123456789](http://snomed.info/123456789)> -- any SNOMED CT code
        >
    >
7

ITEM_TREE[at0001] matches { – Tree
items cardinality matches {1..; unordered} matches {
CLUSTER[at0009] occurrences matches {0..1} matches { – Flavour
name matches {
DV_TEXT matches {}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0010, – asdasd
at0011] – asdasda
}
}
}
…

The main issue is that though the the Archetype Editor will read that construct, it loses the internal codes if the archetype is changed i.e it does not write the data back out again.

Ian

8

I believe linkEHR supports this, and you can export the archetype to be fully compatible with AD and TD

9

Thanks Diego,

I was hoping you would confirm that.

Ian