AOM 1.4 - Archetype.uid a UUID or OID?

Bert Verhees bert.verhees at
Thu Jun 15 03:32:30 EDT 2017

Although the OID and UUID as used in the archetypes are (in the most 
simple (one arc) OID-occurrence) technical interchangeable is their 
semantical meaning completely different. So what do we want to express 
here? Is it ever used in the way a OID is meant to be used? (to trace 
back the organization that is responsible for creating/maintaining the 
archetype and assign a purpose/meaning to the archetype)

The OID is a paper tiger, it suggests something, with structured 
meaning, but no organization I know has the overhead of maintaining 
useful use of OID's in archetypes implemented. That is why, also, they 
do not occur in CKM and no-one ever complained about that, for ten 
years. No software I know is interpreting the arcs of the OID in the 
uid-property of an archetype, it would run into trouble when it did. The 
tooling (including CKM) has no way to support administrative overhead.

That the use of OID in the uid-property of archetypes is not useful, is 
illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x

When remaining to the OID in 1.4.x, we create an illusion, we suggest 
some structure in the uid-property which is not there. In fact opposite, 
we suggest that all archetypes are to be maintained by different 
organizations because they have a different uid and only one arc.

The problem I have is that the current situation with OID in the 
uid-property corrupts the administrative use. We write a UUID, we call 
it OID but we treat it as a UUID, because the practical use does not 
allow to see it as a meaningful structure.


On 15-06-17 03:17, Heath Frankel wrote:
> Hi Thomas,
> Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is 
> used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a 
> value attribute of type UID, which may be either UUID, ISO_OID or 
> The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from 
> a XML schema perspective as UUID is a simple type with a restricted 
> string value while HIER_OBJECT_ID is a complex type with a child 
> element value. The V1.4 AOM XML schema uses this HIER_OBJECT_ID type 
> (as per the AOM specification) and since the OPT schema inherits this 
> model, it also uses this type and all OPTs generated by CKM (and the 
> template designer) populate the uid element with the template GUID 
> specified in the OET file.
> I suggest that the ADL 2 specification is that one that needs to 
> change or there needs to be a specified mapping between the two.
> Regards
> Heath
> *From:*openEHR-technical 
> [mailto:openehr-technical-bounces at] *On Behalf Of 
> *Thomas Beale
> *Sent:* Thursday, 15 June 2017 5:40 AM
> *To:* Openehr-Technical <openehr-technical at>
> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
> Bert picked up an anomaly in this PR 
> <> that I think should 
> probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but 
> of type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the 
> openEHR type for OIDs). However it appears that all ADL1.4 archetypes 
> that have a uid have it as a Guid (i.e. UUID), and I assume the 
> various tools do as well. We avoid Oids like the plague in openEHR, 
> and I am not aware of them being used anywhere.
> If we can verify that everything assumes a UUID for this field, then 
> the spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. 
> treat this as an error correction.
> Could tool makers check this issue and report here?
> thanks
> - thomas
> -- 
> Thomas Beale
> Principal, Ars Semantica <>
> Consultant, ABD Team, Intermountain Healthcare 
> <>
> Management Board, Specifications Program Lead, openEHR Foundation 
> <>
> Chartered IT Professional Fellow, BCS, British Computer Society 
> <>
> Health IT blog <> | Culture blog 
> <>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-technical mailing list