ADL2 Tooling Workshop 2019
Date
Apr 8, 2019 - Apr 9, 2019
Location
Braunschweig, Germany
Vitasystems/symeda GmbH
Hamburger Straße 273b
38114 Braunschweig
Participants
@Thomas Beale (arr Hannover 20:40 7th; dep 9th evening)
@Birger Haarbrandt
@Luis Marco-Ruiz
@Ian McNicoll (arr Hannover 21:30, staying in Braunschweig till the 10th- then off to Hannover am)
@Sebastian Garde (arr Braunscheig sunday ~19:30, dep Tue 16:15)
@Silje Ljosland Bakke (Unlicensed) (arr Braunschweig on the morning of the 8th, staying till the 11th)
@Diego Bosca (arr Hamburg 2pm 7th; dep Hamburg 9th evening)
@Pieter Bos (by train, arr sunday at 20:09, dep Tuesday at 17:26)
@Borut Fabjan (arr Hannover: 1805 7th, dep Hannover: 1730, 9th)
@Sebastian Iancu (by train, arr Sun 20:09h, dep Tue 17:26h)
Goals
Identify challenges for modelling communities (CKM), industry and organizations to adapt ADL2 in both modelling tooling and CDRs.
‘Show and tell’ of where different groups have reached - success and fail!! Alternative serialisation approaches e.g Web templates
Explore better tooling integration/ standardisation e.g. hooking up APIs and standardising approaches to Git repos and folder structures
Establish a work group?
Allocate resources for the openEHR software program?
Define a first roadmap for the transition from ADL1.4 to ADL2 for industry and modelling community. How can we get there with minimum impact on existing systems .esp instance data?
Page Map
Discussion topics
Day 1
Time | Item | Presenter | Notes |
---|---|---|---|
09:00 | Coffee |
|
|
| What are the key drivers for ADL2? | ALL | 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 | ALL | @Sebastian Iancu adl2 tools maturity and adoption (customers still locked in adl1.4 tools); risks and avoidance of data conversion @Borut Fabjan
@Ian McNicoll
|
| What are the barriers | SG, IM, BF… | @Borut Fabjan
@Sebastian Garde (Barriers apply more or less to CDR and CKM)
|
| Attribute aliasing | BF/IM | 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. | SLB, IM | There was a long discussion on this (subject = The strange case of DV_TEXT…). Some summary on this discussion page. |
| Canonical paths | SLB/BF/SG | 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. |
13:00 | Lunch |
|
|
| Template limit to list | BF, SLB | 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’ | SLB,IM | 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 |
19:00 | Dinner |
|
|
Day 2
Time | Item | Presenter | Notes |
---|---|---|---|
09:00 | Coffee |
|
|
| Show and tell |
|
|
| ADL-designer on openEHR.org |
|
|
| ‘ADL3’ updates | TB |
|
| Terminology Services and tooling | LM |
CONCLUSION AND NEXT STEPS: we need a FHIR-like TS specification. Implement prototype in Ethercis and start discussing and drafting a TS API specification. |
| Dependency analysis and compilation model of tools | BF, IM | Dependencies can only be evaluated when archetypes and templates are compiled as a ‘system’, just as with classes and a programming IDE like IntelliJ. |
12:45 | Lunch |
|
|
|
|
| @Ian McNicoll Discussion on current non-duplicate numerics issue with DV_ORDINAL. Agreed to relax this rule in ADL1.4, in line with ADL2. Defer ability to have real numbers in DV_ORDINAL as this is a potential breaking change. |
Related discussion items
Fixing common problems in CKM archetypes
Major: lack of specialisation e.g. ophthalmology, examination.
Minor; Empty C_DV_QUANTITY etc.
IM: If we do go there, we should focus on technical issues e,g C_DV_QUANTITY and not modelling patterns = that needs discussed but not here IMO (and actually is already being looked at).