...
Impact will potentially occur in various places:
specifications
authoring tools
SKD SDK & form builders
CKM and other management and dissemination repositories
operational CDRs
CDR data
archetype-based querying
REST APIs
The changes are described below.
Key Codes
Description
This feature would add synonyms of the current id-codes (and possibly at-codes and ac-codes) in the form of freely named codes, known as keys, such as ‘systolic_pressure’ and ‘date_first_recognized’.
...
Impact Analysis
Area | Description | |
|---|---|---|
Specifications | Archie | Add support for the new constraint typePossible addition to ARCHETYPE_TERM in AOM2, to allow Changes to OPT1.4 and OPT2 - e.g. key-based forms? |
Archie | Change to ARCHETYPE_TERM; add/change path extraction to support key-based paths. | |
Authoring tools | Add support for creating the new constraint type | |
SDKs / form buildersTBD | Add support for extracting key-based paths from OPTs | |
CKM | TBD | |
CDR | Validator needs to implement new constraint typeNone | |
CDR Data | None | |
CDR QueriesTBD | Possibly allow new key-based form for displaying and authoring queries. |
Advanced Form
In a more advanced environment, the keys could be used as the principle codes instead of the id-codes. This would remove the ability to infer subsumption based on the dotted code system in use since ADL1.4, e.g. id4.0.3 is a specialization of id4 (at top level), introduced 2 specialization levels down. With freely-named codes, the IS-A relationships have to be asserted within the archetype terminology. This is a breaking change, and would only be possible by moving to a new major version of ADL, nominally 'ADL3'.
...
Powerful refactoring tools could of course perform such changes automatically, with some subsequent manual fixing (as in typical programming refactoring tools), but paths in queries and forms would break as well, and would require conversion to the new paths.
Replace ODIN
Description
Motivation: ODIN is a custom openEHR serialisation format not used elsewhere in industry. Parsing and serialising to it requires custom software.
...
Link / Reference Constraint
...
Description
The requirement here is to support a kind of constraint that works something like a slot, except for objects that carry references to other objects, e.g. openEHR LINK, DV_EHR_URI and so on.
Discourse discussions:
...
Non-Primitive Tuple Constraint
Description
The need is to be able to represent tuples whose elements are non-primitive archetype nodes, i.e. C_COMPLEX_OBJECTs in AOM terms. Primitive tuples are already solved, as shown in this archetype.
...
Better Terminology and Binding Meta-data
Description
xxxTBD
Benefits
TBD
Impact Analysis
...
More Powerful Annotations
Description
xxx
Benefits
TBD
Impact Analysis
...
Separate Translation Files
Description
Currently one archetype contains all its translations. Some archetypes with numerous translations are very large text files. Size isn’t a serious problem for tools or parsers, but the ongoing changes and additions to translated content mean that the archetype is constantly being re-versioned when no semantic changes are being made.
...
Area | Description |
|---|---|
Archie | TBD |
Authoring tools | TBD |
SDKs / form builders | TBD |
CKM | TBD |
CDR | Should simplify loading of specific language OPTs |
CDR Data | None |
CDR Queries | TBD |
More Powerful Rules
Description
xxx
Benefits
TBD