Description

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.

Activity

Show:

Pieter Bos June 13, 2022 at 1:45 PM
Edited

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 PM
Edited

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 PM
Edited

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

Pinned fields
Click on the next to a field label to start pinning.
Details

Reporter

Thomas Beale

Raised By

Bjørn Næss
Sebastian Iancu

Original estimate

2d

Components

Affects versions

Created April 18, 2018 at 1:24 PM
Updated June 13, 2022 at 3:24 PM