DICOM interface.
Alessio
I am developing some DICOM tools which must receive images directly
from the diagnostic machines.
Right now i can't use a machine to do tries so I upload images
found on the internet. My question is: the Patient ID field of
the DICOM files I found was always set, but is it set from the machine
which sends the image or must be set in a future moment?
Thanks a lot.
Alessio
Marco Eichelberg
>My question is: the Patient ID field of
> the DICOM files I found was always set, but is it set from the machine
> which sends the image or must be set in a future moment?
Patient ID is type 2 (I think for all image IODs), which means that the
field will always be present but can be empty. In general you cannot rely
on this field always having a valid value.
If the value is present, there are different ways how it could have got
there:
- manually entered on the console
- received from the RIS by the modality, using Modality Worklist
- added later by some "black box" (gateway or the like)
Regards,
Marco Eichelberg
OFFIS
Alessio
> Patient ID is type 2 (I think for all image IODs), which means that the
> field will always be present but can be empty. In general you cannot rely
> on this field always having a valid value.
> If the value is present, there are different ways how it could have got
> there:
> - manually entered on the console
> - received from the RIS by the modality, using Modality Worklist
> - added later by some "black box" (gateway or the like)
>
> Regards,
> Marco Eichelberg
> OFFIS
Ok, now another question .. this about Instance IDs.
Your (OFFIS's one) DICOM toolkit storse incoming images as
EXAM_TYPE.SOPInstanteUID.
Looking for a univoque method to distinguish between different parts
of
different exams for different patients I have encountered some doubts
about the UIDs.
First of all: they are univoque at which depth ? can they distinguish
with the only UID different parts of different exams ? or can only
give
an hint ?
I mean, this are 2 sample UIDs (got from a PACS server):
1.2.840.113654.2.4.4.3.4.119950730060300
1.2.840.113663.19950726.13.0
The first 3 numbers should identify the 'DICOM' standard in the ISO
format.
The fourth as far as I know should be a code assigned to each
diagnostic machine manufacturer (like kodak, agfa, and so..)
Then the thing becomes confusing.
The first UID puts a series of infos and then a timestamp of the exam.
The second one put it in a different way (only the day).
So, how can I distinguish the different DICOM images of a single exam?
Is there any way to distinguish 'supplementary parts' of the UID
depending
on the machine manufacturer id?
Thanks in advance,
Alessio
Marco Eichelberg
>of different exams for different patients I have encountered
>I mean, this are 2 sample UIDs (got from a PACS server):
>1.2.840.113654.2.4.4.3.4.119950730060300
>1.2.840.113663.19950726.13.0
>The first 3 numbers should identify the 'DICOM' standard in the ISO
>format.
>The fourth as far as I know should be a code assigned to each
>diagnostic machine manufacturer (like kodak, agfa, and so..)
>Then the thing becomes confusing.
Unlike Object Identifiers in the OSI world, DICOM UIDs have no structure!
All you know is that the UID has been created by some device, and the UID is
worldwide unique. You cannot read anything from the structure of a UID, the
DICOM standard is really clear with this. It is up to the implementor to
decide how he guarantees that UIDs are unique - they will have some UID root
assigned by a national body (ANSI, DIN, AFNOR etc.) and a "tail" generated
by some algorithm. This may include a serial number, a date and time, or
whatever the vendor believes is a good idea. You just don't know and you
don't care.
If you want to identify the different images of a series or study (there is
no notion of an "exam" in DICOM), you have to compare different UIDs:
- if two objects have the same Series Instance UID, they belong to the
same series.
- if two objects have the same Study Instance UID, they belong to the
same study.
- if two objects have the same SOP Instance UID, they must be identical!
If they aren't, sombody has messed up.
See the DICOM information model in part 3 of the standard.
Best regards,
Marco Eichelberg
OFFIS
Alessio
This is ok, thanks again.
The next question is only a hope: with the 'IstanceNumber' parameter you can
sort the frames of a multi-image serie, but is there any field where I can
find the total number of parts I must receive? I mean, a serie is 10 frames, so
I will have 10 different DICOM objs with same series istance ID and Istance
number from 1 to 10. As far as i have seen there is no way to know every time
how much dicom objs i must expect to complete the serie. The only way is to look
for a change of Serie/Study instance uid or similar ?
Thanks .
Alessio
Marco Eichelberg
>The next question is only a hope: with the 'IstanceNumber' parameter you
can
>sort the frames of a multi-image serie, but is there any field where I can
>find the total number of parts I must receive? I mean, a serie is 10
frames, so
>I will have 10 different DICOM objs with same series istance ID and Istance
>number from 1 to 10. As far as i have seen there is no way to know every
time
>how much dicom objs i must expect to complete the serie. The only way is to
look
>for a change of Serie/Study instance uid or similar ?
Actually it's even worse :-)
1. You cannot rely on the "instance number". Neither to sort nor to count
the frames.
Some devices will always use instance number 1, and this isn't even
illegal.
2. There is no "counter" inside the objects that will tell you how many
objects belong to any particular study or series. Even if you receive an
object with a different Series Instance UID, that does not mean that later
on there could not be other objects with the same Series Instance UID. If
you need to know that, only "Modality Performed Procedure Step" (or possibly
Study Content Notification) will do, although they are not supported by many
devices.
Baseline: Studies are never complete (e.g. because Presentation State
objects might be added to an old study later on); Series are complete when
you
- have MPPS available
- have some non-standard way of "guessing" that (e.g. because you know
how a particular modality behaves).
Regards,
Marco Eichelberg
Blech
> - if two objects have the same SOP Instance UID, they must be identical!
> If they aren't, sombody has messed up.
Hello,
I'm writing a diploma about DICOM an I have a question In the context of this
discussion .
1. is it right that: An image is always identified with an own image-UID?
2. is it right that: an Image-UID , is identical to the SOP-Instance-UID which
identify the whole SOP-Instance ?
3. if there is a SOP-Instance (encapsulated in a file) with two or more images ,
which Image-UID is used to identify the SOP-Instance ?
Regards,
Michael Blech
Marco Eichelberg
>1. is it right that: An image is always identified with an own image-UID?
>2. is it right that: an Image-UID , is identical to the SOP-Instance-UID
which
>identify the whole SOP-Instance ?
There is no such thing as an "Image UID" in DICOM. The only thing you have
is the "SOP Instance UID", which is guaranteed to be unique for a SOP
instance (i.e. DICOM object).
>3. if there is a SOP-Instance (encapsulated in a file) with two or more
images ,
>which Image-UID is used to identify the SOP-Instance ?
One SOP Instance never contains more than one image.
Wha you can have are so-called "multiframe" objects which contain multiple
frames that make up a cine-run (movie). In this case only the complete
multiframe has a single SOP Instance UID, there are no UIDs that identify
the separate frames. If you need to "point to" a certain frame of a certain
multiframe object, you would use the following keys:
- Patient ID
- Study Instance UID
- Series Instance UID
- SOP Instance UID
- Frame Number
Regards,
Marco Eichelberg