“LOCATABLE descendants may have a *uid*, containing a GUID”
The optional/recommended nature of uid makes it impossible to implement some features that I have in mind because I can’t rely on all implementations to follow the same approach.
However I realise that making it mandatory could introduce compatibility issues with existing data so it is not simply making a decision and putting it into specs.
Generally the top-level structures will have a UID, and the other nodes can be reached with a path from there. So a UID plus path combination should make all features possible. It’s already recommended to set the uid on those top-level structures.
Setting an uid on all locatables is quite a lot of overhead.
What are you trying to do that cannot be solved with a top-level UID plus a path?
Generally the top-level structures will have a UID, and the other nodes can be reached with a path from there. So a UID plus path combination should make all features possible. It’s already recommended to set the uid on those top-level structures.
Setting an uid on all locatables is quite a lot of overhead.
that's pretty much the view we have on this to date...
Generally the top-level structures will have a UID, and the other nodes can be reached with a path from there. So a UID plus path combination should make all features possible. It’s already recommended to set the uid on those top-level structures.
Setting an uid on all locatables is quite a lot of overhead.
that's pretty much the view we have on this to date...
- thomas
There was a discussion about introducing an additional identifier for nodes besides UID, something lighter.
Current generation of paths to uniquely identify an element within a composition is difficult and it became even more difficult when name uniqueness was dropped.
Think of identifying a specific POINT_EVENT in a HISTORY.
There was a suggestion to use other attributes, for example for POINT_EVENT it would be 'time' but this makes things even worse as one would need to use different attribute depending on the node type.
I would welcome the idea of having some kind of lightweight identifier on every node in order to make unique path generation easier.
My preferred scenario would be to have an identifier on every node indeed. Not having that, I could live with identifiers for at least some types, such as entry subtypes and a few more. If it cannot be UID, so be it.
What is the meaning of overhead here? Processing time? Memory/disk space? According to which criteria the overhead is quantified as “quite a lot”?
perfectly reasonable ... But I actually did calculations a few years ago on the overhead imposed by ISO 13606, which would force UIDs everywhere. It's quite significant based on a reasonable sample of mixed EHR data, mainly because Guids are much longer than a lot of values. I will try to locate this. But it's not hard to replicate.
When one is purchasing terabyte RAID 10 secure storage, adding another 20% or even 10% starts to matter.
If you add UID on ENTRY level and you want to use that for some referencing/look up functionality:
How do you handle versioning of Compositions and its content? Is it a new entry UID for each version ?
Here are description on some functions we have added to DIPS Arena EHR Server to make it simpler/more convenient to work with addressing LOCATABLES.
To make it simple for client application to access the unique reference to LOCATABLE we have added the function ehr-uri(<LOCATABLE>) to the AQL query syntax. One example may be:
select
ehr-uri(o) as EHRUri,
o/data[at0002]/origin/value as Time,
o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude as Weight, o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/units as Unit
FROM
COMPOSITION c contains observation o[openEHR-EHR-OBSERVATION.body_weight.v1]
order by o/data[at0002]/origin/value desc
limit 5
One example of the ehr-uri may be:
ehr:compositions/131b9960-a2b0-452b-a140-34990dd3487d::9624982A-9F42-41A5-9318-AE13D5F5031F::1/content[openEHR-EHR-OBSERVATION.body_weight.v1 and name/value='Body weight_001']
And then when you want to get the resource defined by the EHR-URI we have added a simple LINK endpoint. This looks like this:
I think it should be a strong recommendation rather than mandatory considering it is currently optional and the need for backward compatibility.
I also think it maybe difficult to apply consistently in some cases such as feeder data. There are cases in CDA profiles where there are mandatory IDs and you have to populate it with something but then need to some how retain this same ID over revisions etc.
I also think a uri should be an allowed type of UID to support ids that are not guids and possibly associated with real world ids such as lab result ids, etc.
What kind of identifier should this be? ENTRY is not versioned. Will this UID be a version independent identifier or should it also keep references across a version hierarchy?
I agree that there are good reasons to add some identifier on an ENTRY. And it must not be mandatory - because it breaks existing systems. Which also tells it is not needed since existing systems didn’t need to use the optional UID.
