This wiki has undergone a migration to Confluence found Here

Use of UUIDs in II.extension

From HL7Wiki
Jump to navigation Jump to search


There are two views about whether it is appropriate to send a UUID (GUID) in the II.extension property:

1. It's perfectly ok. The II.root represents the assigning authority which provides semantic context for the UUID issued.

2. It's not terribly appropriate and meaningless. The II.root is not intended to convey semantics, merely ensure uniqueness. UUIDs are already globally unique, so having a separate root is just extra overhead. All semantics are conveyed by other RIM attributes (e.g. Role.classCode, Role.code, Role.scoper, Act.classCode, Act.code, Act.moodCode

So: which is it?

Most implementations use root to identify the ID-scheme, and extension as an ID that exists within (i.e. has been created according to) that ID-scheme. The ID Scheme uses/produces values for the extension attribute, the structure and layout are determined by the ID scheme. If it so happens that in itself it is a UUID then this doesn't change the generic mechanism. The identification of the ID scheme is NOT carried elsewhere in the RIM. A Role.scoper merely uses a particular identification, whetever that ID scheme may be. Rene spronk 03:14, 2 Jun 2006 (CDT)
Root provides uniqueness. If the scheme in use assigns UUID's then you can choose to assign it an OID or something, and put the UUID in extension. This would be technically valid but is fairly pointless, since the point of root + extension is to be unique. Since extension is optional, implementations shouldn't be constructed to expect an extension. We have agreed repeatedly that trying to interpret root to provide semantic context is bad practice, you should find the semantic context elsewhere. However since the semantic context always boils down to identifying a constant string of characters in an II, implementors will always be tempted to pick semantic context from II.root rather and a whole II or a code in some related class. But HL7 must always advise against this use. So the answer is that it's not appropriate. Grahame Grieve 1 Jul 2006
Effectively this means you're suggesting that extension (as an attribute) should be done away with, and that root shall never be interpreted. Sort of a suggestion to do away with extension and pre-coordinate ID scheme plus extension in theroot attribute. As with GUIDs this renders an II useless in trying to establish what it is. Taking the semantic context from the model is mostly pretty difficult, hence the request to extend II in R2 datatypes Datatypes R2 Issue 57. The Abstract Datatype Spec for II says: In the presence of a non-null extension, the root is commonly interpreted as the "assigning authority", that is, it is supposed that the root somehow refers to an organization that assigns identifiers sent in the extension. However, the root does not have to be an organizational UID, it can also be a UID specifically registered for an identifier scheme. - so it does assign a semantic meaning to root. Rene spronk 23:25, 30 Jun 2006 (CDT)


MnM Conference call 20060630

  • This is really a question of whether II.root is to be used for semantics. If that question is answered, the answers to the above fall out
  • Additional discussion required on wiki related to this issue

Proposed Resolution

The normal mechanism for transmitting a GUID as an identifier is to send it as the root with no extension. In circumstances where the accuracy of the GUID generation algorithm is suspect, the GUID may be sent in the extension with a distinct root to help ensure uniqueness. A GUID expressed as an extension is not considered to be a match for a GUID in the root. I.e. A match is required on both root and extension to be considered a match.

It is inappropriate to use the root as a means of distinguishing the "semantics" of the identifier.


2006-12-08 - There was no consensus on whether it was appropriate to use the "root" to convey semantic information such as "this is a lab order from XYZ hospital". The Abstract datatype specification isn't clear one way or the other. This will be discussed further at the Jan. WGM when InM representatives can attend

20070108 MnM/INM: Motion to add "The normal mechanism for transmitting a UUID (DCE Universal Unique Identifier) as an identifier is to send it as the root with no extension. A UUID expressed as an extension is not considered to be a match for a UUID in the root. I.e. A match is required on both root and extension to be considered a match. The root can be used to identify a namespace. The design of HL7 specifications SHALL never assume that receiving applications can infer the identity of the scoper or issuer, or the type of the identifier from the namespace identifier." to datatypes R2.