ADL2 outstanding issues - Berlin 2024

A. ADL2 idSystem numbering

• Has it been reverted to atCode numbering for IDsystems (as proposed by TB)

B. OPT2

• Not fully specified https://specifications.openehr.org/releases/AM/Release-2.3.0/OPT2.html

• Archie implementation??

• Raw vs profiled

• Serialisations

• Web template status

• Do we need OPT2→ 1.4 capacity

• https://specifications.openehr.org/releases/AM/Release-2.3.0/OPT2.html#_terminology_substitution

• Anything missing?

• JIRA issues

  https://openehr.atlassian.net/browse/SPECAM-86

•  

• Impact: tooling, CDR

C. Replacing .oet

• ADL2 serialisation or

• Jsonifed ADL2 (Archetype Designer but not fully conformant)

• Fully conformant ADL2 json

• Impact: tooling

D. Support for archetypeID namespaces

• Changes to RM to store specialisation hierarchy in CDR

• handled hierarchy external to CDR (as per NEDAP)

• defer support for mixed namespaces e.g. [org.openehr.uk](<http://org.openehr.uk/>)::OPENEHR-EHR-OBSERVATION.org.openehr::blood_pressure.v2-ukvariant.v1

• Impact: CDR, AQL (full namespaces)

E. ADL2 terminology ‘gaps’

Outstanding JIRA PRs

• Mixed terminology Valuesets e.g LOINC + local codes

• Nested Codesystems/ Valuesets “Use FHIR Valuesets”

• Binding/ mapping directives

  • Bindings can be applied at template-level

  • Is this enough?

• Handling of keyed items e.g comment in .opt generation

• Missing??

  • Support for external mapping directives e.g FHIR ConceptMaps

  • Local synonym constraints - see https://chat.fhir.org/#narrow/stream/179244-snomed/topic/Display.20texts.20in.20SNOMED.20valuesets

    • Where formal term value is SCT::123456::Preferred place of death- Home but UI wants Home

  • Agreement / guidance on defining_code vs. term_mapping

• Future direction ?? FHIR terminology

F. Transition from ‘text-based’ templateIds to formal ADL2 templateIds

• There is no equivalent in AOM2 to the current human text templateID in ADL1.4 only th HRID e.g. org.openehr::openEHR-EHR-COMPOSITION.encounter_report.v1

• There is IMO a need for a ‘fully defined conceptId’

  • Essentially the human design-time name of the template or archetype

  • Different from human ‘working name’ of root node (archetype or template)

  e.g.

  • Root name is ‘Device details’ but a specialised version is created by Scotland, adding a couple of datapoints

  Root name ‘working name’ is still Device details but the title (design time name) is Device details (Scotland)

  • Similar challenge of template root ‘working name’ of ‘Vital signs’ vs. Design time concept name of Vital Signs - London UCP

  • Suggestion

    • TemplateId is migrated to a new title attribute (as per FHIR StructureDefinition) that is added to AOM2 ResourceDecriptionItem (language-dependent) - on creation it should have the same value as the archetype/templateRootID but be capable of being independently adjusted

    • Note - querying against HRID will require full namespace support

    • Is there a place for an openEHR namespace registry??

  • Impact AQL, tooling, CDR

  •  

  G. Interim ADL1.x release?

  If migrating to ADL2 is likely to take some time, is there an argument for adding partial support for easy extensions to ADL1?

  • Enhanced design-time artefacts - e.g template-level descriptions, template binding overrides, hide-on-form, RM attribute visibility etc mostly supported by 1.4 /1.5

  • node ordering - before and after keywords

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

  • Proper Semver support - deprecate MD5 hashes

  • Formalise status of Webtemplates

  • Challenges

    • Would require some updates to OPT1.4 but non-breaking extensions, some already partly handled by Archetype Designer

    • Would require updates to Webtemplates (Needed in any case)

    • Would require updates to .oet(practically impossible)

  • Possible approach

    • Priotitise .oet replacement (CKM)

    • Shared effort on ADL2→ opt 1.x generation

    • Shared effort on .oet→ ADL2 generation