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
SPECAM-87: Specify the OPT 2 ADL syntax for C_ARCHETYPE_ROOT with child nodesOpen
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 wantsHome
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) isDevice 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 adjustedNote - 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