ADL2 - SWOT

Owned by Ian McNicoll
06-Jun-2024
2 min read

 

1. Making specialisation work - by differential specialisation + inheritance flattening

Benefits

  • Handling specialisation diffs is more logical in tooling and easier to manage changes to upstream artefacts

  • Ultimately ‘less code’

  • Specialisation by slot-filling is now a preferred pattern v.s simple inheritance. ADL2 supports this more cleanly

Challenges:

  • Issues of legacy conversion

  • Ultimately the correct flattened version needs to be created/recreated in tooling such as CKM - on the fly or cached??

  • Reviews need to be based on a specific flattened version -

  • Ongoing issues of version dependency management - need better semver use ? package.json or embedded semvers.

  • If semver is the answer, do we put the dependencies inside artefacts or outside e.g package.json

  • Is the natural primary artefact actually a bundle inside a zip container? with a minimum of a package.json manifest

  • Does this change AQL behaviour?

  • Do we differentiate compound, specialised archetypes (slot-fills) from templates (really constrained profiles)

2.Templates as archetypes and overlays, solving all the existing redefinition, template id, versioning and language problems

Benefits

  • Cleaner implementation (no .oet), archetypes and templates are almost identical

  • proper multi-language support

  • coded node name overrides

  • Proper support for

  • Enhanced design-time artefacts - e.g template-level descriptions, hide-on-form, RM attribute visbility etc mostly supported by 1.4 /1.5 but not well by .oet

Challenges:

  • Not clear how this affects querying - existing templates are profiles on composition not specialisation of composition - does the aQL path change?

  • CKM would need .oet->Adl2 convertor (as per AD) - still some conversion issues in AD. Needs to be a community effort

  • Issues for historical CKM reviews

  • Moving from MD5 hashes to semver

3. Tuples to replace irregular special constructs for C_DV_QUANTITY, C_DV_ORDINAL and C_CODE_PHRASE

TOOLING: minor benefit. Streamlining ? add to 1.5

4. ADL enhancements

  • default values on any node

  • node ordering - before and after keywords

  • direct archetype inclusion for re-use - supported by C_ARCHETYPE_ROOT and use_archetype

  • make cardinality and existence constraints optional: mandatory ‘existence’ was the #1 complaint for a long while!

  • plus a lot of properly defined semantics for node-level conformance, congruence, flattening

5. Regular internal code system / Greatly improved modelling of terminology constraint

Benefits

  • tidies up name vs. value codes but was that ever a real problem

  • more consistent numbering (“less code”)

  • approach is closer to FHIR Valuesets but lacks e.g nested values, multi- terminology valueset, mapping constraints

Challenges

  • complex and risky to convert atCodes to iDcodes

  • Terminology handling feels very messy to me. Argument for using FHIR Valuesets and Codesystem as baseline then enhance?

6. Name-spaced archetype ids: allowing archetypes from different institutions with the same concept name to be distinguished (e.g. NHS bp_measurement and Norway bp_measurement)

Benefits

  • Will become significant as complex systems evolve

Challenges

  • Current approach is tricky for CDRs as the full specialisation lineage has to be carried in the patient data

Examples

Single domain specialisation

org.openehr.uk ‘variant.v1’ specialisation of openehr.org blood_pressure.v2

org.openehr::OPENEHR-EHR-OBSERVATION.blood_pressure.v2-variant.v1

Mixed domain specialisation

org.openehr.uk ‘ukvariant.v1’ specialisation of openehr.org blood_pressure.v2

org.openehr.uk::OPENEHR-EHR-OBSERVATION.org.openehr::blood_pressure.v2-ukvariant.v1

Complex domain specialisation

org.openehr ‘int_variant.v1’ specialisation of openehr.org uk_variant.v1

org.openehr::OPENEHR-EHR-OBSERVATION.org.openehr.uk::blood_pressure.v2-ukvariant.v1