What are the key drivers for ADL2?
Quick round table - why do we need ADL2 at all? What is still missing from the current tooling stack? (ADL2 or not).
@Silje Ljosland Bakke (Unlicensed) governance of specialisations, limitations related to template building
@Sebastian Iancu level of multilanguage support in adl1.4 and oet; oet vs adl2-template management as packages; existing tooling (for adl2) is not mature enough, but for 1.4 is a outdated
@Borut Fabjan Template management & multi language support
@Sebastian Garde Templating is the most important use case.
@Ian McNicoll Templating is most important. Composition level mostly but ‘embeddedtemplates’ are going to become increasingly important. Specialisation will be improved with ADL2 but will still have realtively limited utility in modelling vs. aggregated ‘compound archetypes’ = “Embedded templates”
What are the barriers - Upgrading CDRs
@Sebastian Iancu adl2 tools maturity and adoption (customers still locked in adl1.4 tools); risks and avoidance of data conversion
valueset inheritance/specialization (needs to be relaxed)
limit to list (ADL14/Template)
alias (rm node rename)
term binding (["at0004"] = <[SNOMED-CT::60621009]> vs. <http://snomed.info/id/60621009>)
rock-solid bidirectional mapping between ADL14/ADL20
mixed namespace specialisations
bidirectional mapping will be critical
can we move with templates first?
What are the barriers
- Upgrading other tools esp CKM
SG, IM, BF…
@Sebastian Garde (Barriers apply more or less to CDR and CKM)
id codes in ADL2
ADL1.4 to ADL2 conversion and vice versa. Especially when underlying archetypes change (additional codes), the at/id codes should be preserved over the revisions.
current ADL2 template mechanism does not support critical features of the old oet mechnism (hide, visible-in-view, limit to list
Generally smoother migration path - such as ADL1.5 with the compatible additions
Non-semantic attribute (path) aliases needed in design tools.
@Borut Fabjan AD supports it in native template format which uses ADL2 model + annotation extension.
Replacing local internal sets with local (custom) code-sets.
There was a long discussion on this (subject = The strange case of DV_TEXT…). Some summary on this discussion page.
Should paths contain name constraints on nodes, whether the path otherwise is duplicated or not?
@Borut Fabjan I think we agreed the AD principle is correct. However this is not the way CKM would validate the template.
@Ian McNicoll I think we agreed to work the CKM approach for now as the easiest way to make progress.
Template limit to list
In TemplateDesigner for a Template (.OET) on DV_TEXT element, you can set a ‘limit to list’ property. Which eventually tells either the valueSet is open/closed list.
@Borut Fabjan I think we agreed we need to relax the rule in ADL2, potentially adding a ‘strength’ like flag.
@Ian McNicoll Yes - we agreed to relax the rule
Hide-on-form and other non-UI specific reviewer/consumer ‘mark-up’
Discussion page. GUI markup is out of scope but this is about asking templates and archetypes easier to understand in viewers e.g for template review or by devs who are not familiar with openEHR RM (some cross-over with web templates)
@Ian McNicoll Good discussion and option to add show/hide attribute annotation was agreed