Versions Compared

Old Version 54

changes.mady.by.user Ian McNicoll

Saved on

compared with

New Version Current

changes.mady.by.user Thomas Beale

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

-

...

  • 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

Page Tree
expandCollapseAlltrue
root@self
startDepth2

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

  • id/at codes (breaking AQL queries)

  • 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

Ian McNicoll

  • idCodes

  • 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…

Borut Fabjan

  • AD internally is ADL2 based, it already supports ADL14 export to ADL2. Currently export of a template is not allowed - due to limitation of ADL2 to address some features present in ADL14 templates

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

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.

Discussion page.

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.

Discussion page.

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

🥘 🍽 🍺

...

Time

Item

Presenter

Notes

09:00

Coffee

☕ ☕ ☕ 🍵

Show and tell

ADL-designer on openEHR.org

‘ADL3’ updates

TB

  • Structured bindings - adds meta-data to current bindings

  • non-primitive tuples - fixes Action archetypes

  • allow annotations to be Hash<String, Any> where the value is any primitive type (strings, dates, …)

Terminology Services and tooling

LM

  • check the Restful API and the nesting possibilities of value set and system versions.

  • need a parameter to determine the connector to use. This means determining the datatypes etc. returned. It does not need to be set in the AQL instruction but it has to be provided.

  • in order to avoid ambiguity we need to know the data type returned. So there is a need for a Terminology Server minimal API. It should be easily translatable to FHIR.

  • sooner or later we will need to be able to work with the FHIR TS. The closest our specification is to it the better.

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.

IM - this seems to need discussion of package management approaches (Maven, NPM) to include other dependencies like termsets / valuesets.

We also need to clarify template identification and versioning - id, uid and concept are a bit mixed-up right in terms of source of truth. Can we shoehorn semver into .opt 1.4?

Ian McNicoll No conclusion but good discussion and need for some kind of dependency manager was agreed. I will start a gentle exploration of this with NPM and discuss with Bjørn Næss re DIPS use of NuGet.

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.

...

  • Major: lack of specialisation e.g. ophthalmology, examination.

  • Minor; Empty C_DV_QUANTITY etc.

  • Discussion page.

  • 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).

Action items

  •  Review Luis Marco-Ruiz terminology page - ALL
  •  Draft and circulate hide/show/aliasing model - Thomas Beale
  •  Demographics: look at adding facility model to RM.
  •  Value set redefine draft - Thomas Beale

...