I would definitely support this, and even extend it to adding uids to repeating structures like activity in INSTRUCTION and event in OBSERVATIONS.
1 Like
@birger.haarbrandt and @ian.mcnicoll completely agreed.
The use case for uids extends way beyond linking. Having a unique stable pointer to LOCATABLES seems to be invaluable for external systems that need to keep track of and reference archetypes in compositions.
We were trying to build a billing system that needs to keep track of which INSTRUCTION orders and ACTIONs already got invoiced and which ones didn’t. It’s almost impossible to do without a unique identifier for the archetypes - especially when there are multiple instances of the same archetype in the same AQL path.
Apart from saving on storage space, what other reasons are there for not populating locatable with unique uids? Should we be considering making this part of the spec? And making uid under LOCATABLE class as 1..1 instead of 0..1 ?
Also might interest @sebastian.iancu.
It will create a lot of work for external systems to record and track GUIDs on every node, and they will never use 99% of them. Tracking just Compositions and Entries is the 1%, but it’s mostly useful.
The better way to do this in my view is to record order ids in a standard place in the RM, e.g. on ENTRY. Then you just have the correct kinds of ids (not GUIDs) for order tracking.
1 Like
So by Order IDs here - it’ll be something like incremental integer ids?
What happens when an order gets deleted for example?
The order ids will normally be set outside the system, and assigned to anything ordered, which could be any of the openEHR Entry types (probably not EVALUATION, but it wouldn’t matter too much if it were available on that). At the moment, some openEHR archetypes have a place for these kinds of ids in the /protocol section but that’s not a great solution long term.