[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian OID / dicom3tools packaging


To begin, I think there's some confusion about UID and OID.  They
are actually the same thing, according to Clunie:

  What DICOM calls "UIDs" are referred to in the 
  ISO OSI world as Object Identifiers (OIDs). 

What Mathieu is talking about is the "UID Root" (or "org root",
according to DICOM PS3.5), and I assume subsquent posts in this thread
mistakenly call that an OID.

On Tue, Jan 27, 2009 at 01:16:35PM +0100, Michael Hanke wrote:
> On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote:

> >   One important step of the packaging is the DICOM UID. In order to
> > write a DICOM file, one need a unique UID for each instance of a DICOM
> > object.  For more details:

> I wonder whether it is possible/feasible to come up with a single OID
> suiteable for all users. IMHO every user/institution would need an OID
> -- since somehow each DICOM generated by that OID needs to result in a unique
> UID.

It's not exactly the case that every user/institution needs their own
UID Root.  

I used to work for a PACS company and all UIDs generated by our
software -- running across hundreds of different PCs in dozens of
client sites -- use the same UID Root.  We could do that because we
controlled the algorithm for generating the UID suffix.  I expect that
pretty much all PACS vendors do the same thing.

To pull this off, you need to be sure that everyone using the same UID
Root is using a good algorithm; e.g. one that encodes something unique
(e.g. an ethernet address) from the computer, and a time/date stamp
with sufficient resolution (millisecond?) to guarantee uniqueness.  

An industrial-strength user will likely be using their own UID Root,
but a common Debian UID Root for the rest of us is probably fine.

By the way, since UIDs are only 64 characters long (restricted to 0-9
and "."), I'd urge you to consider keeping the Root as short as
possible, so as to leave room for the suffix generation.  Instead of
adding "med | od -b", perhaps just add ".0" for dicom3tools:

The next software package that needs a UID Root could then use

etc.  Basically, the idea is to parcel up the Debian UID space across
different UID generation algorithms -- i.e. the one in dicom3tools
versus the next one (using ".1" root).


Attachment: signature.asc
Description: Digital signature

Reply to: