Description
CR fixes the problem in
Activity
Pieter Bos June 13, 2022 at 1:45 PMEdited
what is the purpose of the ordinal id, and what can it be used for? Is this for easy history display for data, without actually building a proper comparison? For easier merging of data? Or for something else?
This is a mandatory field, so it means old data will need migration or conversion to comply with the RM version. What is the migration or conversion method/algorithm for this data? If we need to comply with ‘ordinal number of version in versioned_composition or other versioned container, in which this node was first added’ in migrated data - how does one determine that number for existing data? Do we need to traverse the entire version history to convert old data and compare the different versions, or can we do something more simple? What will that mean for systems using that ordinal node?
is the analysis done on how the ‘in which the node was first added’ is determined in various version update scenario’s? Can it always be done in an automated way, even if the API caller has no notion of this field, so with just the content of the previous version and the content of the new one?
this being a mandatory new field, should it be in RM 2.0.0, or is a minor change ok?
Pablo Pazos April 22, 2019 at 7:46 PMEdited
It is not clear what is the use case behind this change request. Can someone clarify that?
Erik Sundvall April 18, 2018 at 1:53 PMEdited
We should clarify and exemplify the....
"In the case of branched version ids, we will have something like: uid1:uid2:1.1 "
...regarding what to do when updating an imported verision by creating new sibling nodes.
Reusing figure 12 from Common IM might be good and showing an example using those version numbers
Add LOCATABLE.sequence_id, to be set on all LOCATABLE objects in openEHR systems.
The field type is String, and is of the form 'n.m', where:
n = ordinal number of version in versioned_composition or other versioned container, in which this node was first added.
m = ordinal number of child item, in order of creation.
Examples: "1.3" = 3rd child under a parent node, in 1st version of some Composition.
A node added in version 6 has an id like '6.m'.
In the case of branched version ids, we will have something like:
uid1:uid2:1.1
In branched version structures, if used, clashes in the final part can occur which is desirable to indicate clashes that need to be resolved.
URI syntax: need a short form:
e.g. items[at0003,#1.1] means the 1st child in 1st version. If no #n.m, then follow current behaviour and return all matching (normally = all children).
LOCATABLE.sequence_id will be mandatory.