@Pablo PazosOK, I think I got your point. Reading a bit further, it should be allowed to use any predicates, including the uid:https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_using_a_uid_based_predicate

The spec is also saying the following:

Archetype paths are not guaranteed to uniquely identify items in data, due to the fact that one archetype node may correspond to multiple instances in the data. However it is often useful to be able to construct a unique path to an item in real data. This can be done by using attributes other than archetype_node_id in path predicates…The most reliable way to obtain unique path for run-time nodes in data is is by populating the inherited LOCATABLE.uid field with UUIDs.

So this sounds like uid is actually valid as part of an archetype paths. Maybe this is actually a grey area between runtime expressions and what’s inside the AOM.

@Thomas Beale EHRbase is surely not ahead, but I would be happy to introduce such functionality. We might even think about adding a UID to every entry level object etc. This can also have advantages to identify data for FHIR mappings, but this is a different topic.

Edit: instead of using a String, may DV_EHR_URI be used instead? Would make things a bit more formal.

@Birger Haarbrandt IMO this is the correct definition of an archetype path https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_node_id_and_paths

“The existence of node_ids in an archetype allows archetype paths to be created, which refer to each node.”

a. Also IMO: all “archetype paths” should be returned from: ARCHETYPE.physical_paths (): List<String>

b. And all archetype paths should return true from ARCHETYPE_CONSTRAINT.has_path(): Boolean

Then the other paths could be used to query the archetype, for instance the ones with other predicates than node_id (from your reference I just saw the node_id is also a predicate): https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_predicate_expressions

If a data instance predicate like uid=xxx is used, then that is referring to a RM node, not to an archetype node, so for that path the has_path() will return false (see b. above). You’ll need to process that path and remove the uid predicate in order to make it refer to an archetype node. So I think “instance predicates” in paths are also “instance paths”, and “archetype paths” are the alternative ways of identifying nodes in an archetype (AOM instance) besides node_id, and considering node_id is not mandatory for each node in the archetype, the archetype path becomes the only way to reference to each node in an archetype instance.

Not sure if that makes sense.

This is all my interpretation of the specs, there might be gray areas, but to provide a definitive answer I would need to review and cross-check the current specs.

@Pablo Pazos Mh, do you have a reference to the definition of an Archetype path? I found this one, but this seems outdated: https://specifications.openehr.org/releases/1.0.1/html/architecture/overview/Output/paths_and_locators.html

Just to be clear, I don’t have a problem with any of the solutions offered here. Pablo is right that Birger’s ‘path’ is really an AQL path, but if everyone wants to go that way, we can. I’d see the resolution to this issue coming from a vendors/implementers discussion rather than trying to be too theoretical.

My personal leaning is not to require UUIDs on ACTIVITYs and to do it more like Pablo. BUT…. achieving a generic approach to order tracking could well be based on doing just that, so maybe EhrBase is ahead of the curve

I think @Birger Haarbrandt ‘s solution could work, though the current spec says activity_id is an “archetype path”, and the path with the predicate using the UID I don’t think is an “archetype path”, it seems to be an AQL path.

1. An archetype path, should be IMO, a path valid in an archetype that you can use to get a C_OBJECT instance from an AOM instance, which is the /a[atxxxx]/b[atyyyy]/c

2. Then what I call the “instance path” is a path that can be resolved in a RM instance to get a specific PATHABLE from the tree, which is like an archetype path but includes the indexes for the collections, like “…/events[at1234](0)/…” or “…/items[at1234](3)/…”

3. Then the paths used in AQL are more complex and could hold complex predicates.

I think the current spec is compatible with only with 1. and that is the main reason why I raised this issue. There is a change needed to handle the case mentioned before.

@Thomas Beale I don’t see an issue on having uids in ACTIVITY since the model allows it and AFAIK there is no recommendation against it. If there are cases in the current RM that in practice shouldn’t work in the way the RM allows them to work, then we need to provide a profile of the specs to implementers, we can’t expect everyone to follow rules that are not written.