Rob Horn – Agfa Healthcare Unique IDs Rob Horn – Agfa Healthcare

Opaque Unique ID Fully Opaque These are a meaningless, structure-less, strings. Example: UUID There is no way to verify what the string means unless you already have a short list of candidate meanings based on context. In the context of an ITI SOAP transaction, you can check the short list of assigned IDs. Without context, you cannot tell whether a UUID identifies a partition on disk, a document, a signature, etc.

Structured Opaque Unique ID Structured but opaque These are semi-meaningless structured strings. Example: OID, URN The prefix will lead you to a person or organization that may then be able to assign a meaning OID: 2.25.xxxxxxxxxxx - nope, meaningless UUID OID: 1.2.840.113669 – Ask someone at Merge Technologies OID: 1.3.6.1.4.1.44525 – Ask Dr. LaNette Smith at Breast Surgery of Tulsa (assigned 1 October 2014) Enterprise OIDs are open to any organization, e.g., 1.3.6.1.4.1.44519 – US Railroad Retirement Board, rrb.gov URN: urn:isbn:xxxxxxxx – Ask the ISBN folks

Structured Unique ID Some of the URN’s are structured with fully defined or strongly defined structures. None of these are yet official. Example: urn:lex:fr:etat:loi:2004-05-15;106~art15;par3 The use of urn:lex: is still only proposed. There is no approved RFC yet for the creation of urn:lex: The administration of subordinate responsibilities within urn:lex: is not yet addressed, agreed or approved.

How to achieve Uniqueness Trust Magic “DICOM AE-titles shall be unique” Trust Algorithms UUID Trust Administrative Rules OID URN

Uniqueness Experience Magic doesn’t work. Merely asserting “shall be unique” does not work. People have good intentions, but good intentions are not enough. Algorithms can work. Strengths Algorithm code can be inspected, verified, and validated. Algorithm usage can be inspected, verified, and validated. Problems do happen, people do make mistakes, the level of failure has been acceptably low. Weakness All known algorithm approaches can only generate completely opaque IDs. This leads to problems in some situations.

Uniqueness Experience Administrative Uniqueness can work OID experience Minimal barrier to getting root authority. Currently takes hours to days As of 1 October 44,531 enterprise OIDs have been assigned. On 1 October, 8 more enterprise OIDs were assigned. Obtaining other OID roots takes longer Root authority is given great flexibility in chosing their own rules for assigning subordinate OIDs Rudimentary validation testing easy, only rarely are problems detected.

Administrative Uniqueness Administrative Uniqueness can work URN experience High barrier to getting root authority. Currently takes months to years Requires getting RFC approval Root authority is given modest flexibility (must comply with ITU rules, but these are not that bad for a reasonably mature organization) Rudimentary validation testing easy, and many problems are detected. A vast number of URNs are invalid, but people use them anyhow. IHE still has not performed the administrative steps needed to make urn:ihe a valid urn. (We’re not unique in this. Neither has DOI.) Draft minimal rfc and put it through the process Establish minimal compliance with ITU, e.g., have a staff data librarian function.

Considerations How much (if any) structure is needed for a particular use of a unique ID? What kind of administrative burden is acceptable?