I got a question about following DICOM tags
0002,0003 MediaStorageSOPInstanceUID
0004,1511 ReferencedSOPInstanceUIDInFile
0008,0018 SOPInstanceUID
0008,0058 FailedSOPInstanceUIDList
0008,1155 ReferencedSOPInstanceUID
Looks like there are all the same.
How did I get new 0008,0018 values and it is posible that two files have the same value?
This is perfectly legimitimate to have two different DICOM files with identical SOP Instance UID. This happens a lot when losslessly compressing a DICOM DataSet.
Since the compression is lossless, the professional interpretation of the DICOM contained Pixel Data cannot possibly be affected, thus it is legal to preserve the exact same SOP Instance UID.
An application is required to change a SOP Instance UID whenever the professional interpretation of the Pixel Data may be affected (eg. lossy compression).
You may find a minimal explanation of what is the derivation mecanism in DICOM at GDCM wiki:
http://gdcm.sourceforge.net/wiki/index.php/Writing_DICOM
But in any case, you should always refer to the DICOM standard, when in doubt.
As a side note Media Storage SOP Instance UID and SOP Instance UID are identical, by definition. Information from group 0x2 is simply derived from the DICOM DataSet to generate valid Part-10 DICOM File.
Also Referenced SOP Instance UID In File is kind of special since it belong to group 0x4. Therefore it may only be present within a DICOMDIR DataSet, which is not a typical DICOM DataSet. DICOMDIR are only needed to index other DICOM File on medias (eg. CDROM...)
Failed SOP Instance UID List is also not present in typical DICOM DataSet since it should only be present in C-STORE response DataSet.
And clearly Referenced SOP Instance UID cannot possibly have the same value as SOP Instance UID since it would create a self-referencing loop in the DICOM DataSet.
Related
I am developing a Modality Worklist client using fo-dicom library.
Following thing are not clear to me related to [Referenced SOP Instance UID (0008,1155)].
What is Referenced SOP Instance UID?
Is Referenced SOP Instance UID same for entire series?
I have seen 2 Referenced SOP Class UIDs in some sample images; Why?
Scenario 1:
I'm trying to retrieve Modality work list to create some image series for a requested study. I have to create a captured image sequence to send the "Completed" notification to the MPPS server. The fo-dicom sample for modality work list includes Referenced SOP Class/Instance UID when creating the completed image sequence to send "Competed" notification to MPPS. My question is what is this Referenced SOP Class/Instance UID?
Scenario 2:
In addition to that, I found some sample DICOM file series and each image contents
Referenced SOP Class/Instance UID twice and same to a series.
Are these Referenced SOP Class/Instance UID same or different?
Below is a sample DICOM file contents Referenced SOP Class/Instance UID two times:
First of all:
The Referenced SOP Class/Instance UID are always items of a sequence, and the sequence defines the meaning of the reference.
The Referenced Image Sequence does not refer to Modality Worklist, it refers to images and other objects only.
The sequence is intended to accommodate other objects which are relevant for the interpretation of a given image. In DICOM: "A Sequence that references other images significantly related to this image."
These may be:
other images which are related to the current image (e.g. the ID of the other plane in a Bi-Plane acquisition)
other images on which the calculation of the current image is based
the second image in case the current image is part of a stereo pair
Any particular meaning of the reference may be constrained or enforced by the particular type of image you are creating. This information can be obtained by following the references in the IOD (Information Object Definition as defined in DICOM Part 3).
For most images, the referenced image sequence is an optional (Type 3) or "may-be empty" (Type 2) attribute which means that if there is no significant relation to other images, it may be omitted.
I have done more research about Referenced SOP Class/Instance UID to understand practical relation to DICOM Modality WorkList implementation which I am currently working on.
#kritzel_sw has already answered mainly for my Scenario 2: question and I have found following more information related to my Scenario 1:question.
According to the DICOM Part4 F.7.2.1.1 Modality Performed Procedure Step Subset Specification (Table F.7.2-1), [Performed Series Sequence (0040,0340)] is a required attribute for N-SET protocol which is part of Modality WorkList Management(send the "COMPLETED" notification to the MPPS server).
Referenced SOP Class/Instance UID are sub attributes of [Referenced Image Sequence
(0008,1140)] under [Performed Series Sequence (0040,0340)].
Practically, SCU Modality should send a list of SOPInstanceUID of captured images to SCP to complete the requested procedure step with N-SET. Referenced SOP Class/Instance UID under [Referenced Image Sequence (0008,1140)] should be used to send these information.
Following is the basic Modality WorkList Management sequence
SCP request Modality WorkList from SCU
SCU send Modality WorkLists
SCU send "IN PROGRESS" notification to SCU
SCP create Image sequences
SCU store Images to PACS
SCU send "COMPLETED" notification to SCU by referring created Images SOPInstanceUIDs
DICOM Part4 F.7
While working with the DICOM study, series and media concepts, I wondered if these values are to be unique over all data, or only to the patient they belong to.
Phrased otherwise; can I have 2 patients having a study/series/sop instance uid that is the same value for both patients?
Or does the DICOM standard simply doesn't care about that and is that open to the implementor to decide?
In DICOM, a Study (identified by its Study Instance UID) is always associated with a single Patient. See DICOM standard part 3 for details.
To answer your initial question/thought: a Unique Identifier (UID) has to be globally unique, i.e. world-wide over all patients, devices, hospitals, etc.
UID in DICOM (no matter what UID) is always globally unique. So, as you asked in question, uniqueness is not limited to Patient level or something.
Following is from specifications:
2017a Part 5 - Data Structures and Encoding (9 Unique Identifiers (UIDs))
Unique Identifiers (UIDs) provide the capability to uniquely identify a wide variety of items. They guarantee uniqueness across multiple countries, sites, vendors and equipment. Different classes of objects, instance of objects and information entities can be distinguished from one another across the DICOM universe of discourse irrespective of any semantic context.
More details about DICOM UID can be found in this answer.
Your comment on question as below:
My question was more about what to do in case I choose to clone a patient in my system and attach the same dicom(s) to it. Should I regenerate the dicom-uid's or could I keep them as-is.
I am not sure what you mean by "clone". While cloning, if there is change in dataset, you should regenerate the SOPInstance UID. Even if you simply apply lossy transfer syntax to your dataset, you should regenerate the SOPInstance UID. Any action that differentiates/separates the the datasets from original require new SOPInstance UID. So, while cloning, if you are changing patient demographics, new UID should be generated. Whether new StudyInstance UID should be generated or not depends upon what is changed.
OTOH, if you are just copying your dataset at different location, it is still same dataset. You do not need to regenerate UIDs in this case.
Unfortunately although the standard states the UID should be globally unique you can not guarantee it at the series level in my experience. I have come across series with duplicate ids across studies. To protect yourself assume you have to use StudyUID +SeriesUID to ensure a unique series key.
Is it reliable to map modalities to SOPClassUIDs? In other words, does a one-one mapping for SOPClassUID to modality is fine?
No, a one-to-one mapping is not possible. Consider this common example where 4 SOP Class UIDs all map to 'US':
1.2.840.10008.5.1.4.1.1.6 Ultrasound Image Storage (Retired)
1.2.840.10008.5.1.4.1.1.6.1 Ultrasound Image Storage
1.2.840.10008.5.1.4.1.1.3 Ultrasound Multi-frame Image Storage (Retired)
1.2.840.10008.5.1.4.1.1.3.1 Ultrasound Multi-frame Image Storage
If you had an object for each one of the SOP Class UIDs shown above, they would all have 'US' in the modality tag.
So if you just look at 'US' in modality tag 0008,0060, is it a single-frame or multi-frame echo image? It is better to consider the SOP Class UID for precisely defining the type of DICOM object you are dealing with.
Reference: see "Annex A Registry of DICOM unique identifiers (UID)" of Part 6 of the standard.
From what you can see here, this is indeed possible. Actually, storing correct modality information in the modality (0008,0060) tag is obligatory. I have never used SOPClassUID for that, because this would be so cumbersome, but yes, this is possible.
One to one mapping:
No; not possible. Reason and example is already given in accepted answer. US modality value may be included in multiple SOP Classes. Private SOP Classes for specific modalities is another example.
One to many mapping:
One modality value cannot be mapped with multiple SOP classes in reliable way. Secondary Capture SOP class is an example here. Any modality value could be assigned to this class; generally SC or OT is used.
Equipment sending different values for same study:
Further to above, an equipment (modality) may send instances with multiple modality values. Pet CT equipment may send instances with PT and CT value in Modality tag. Almost any equipment may include instances with SC/OT value. Modality value SR is also used by many equipment to transfer report data.
SOP Class value and Modality value have their own purposes and the values should be used in same way. One should not try to overlap the purpose. I agree there is some relation between those two; but do not just rely on it. Use each tag for it's intended purpose.
I wonder if it is possible to have two different images with the same header. If so, can we display this two images in the PACS or otherwise which tags should be changed to display them?
No you can't. The issue is that Dicom requires every image to have it's own Unique UID stored in the header.
PACS systems commonly ignore newly received images if their UID is identical to one they already have in the database, so if you don't follow this part of the standard you probably don't get very far.
If you want to generate DICOM images, and you are unfamiliar with the standard, my advice is to use OFFIS img2dcm or a similar tool to convert them from normal images.
Jan de Vaan is correct, you SHOULDNT have duplicate headers with different image bitmaps and that is 'guaranteed' by the unique SOP instance UID. I've never seen a duplicate UID come from any modality. Saying that, there are sloppy applications with terrible UID implementations to generate the unique UID. There are teleradiology apps, secondary capture devices and other open source DICOM packages (for instance) that, typically on reset, could and do create a repeatable UID sequence. Many research labs get along fine with these. I expect you have one of these applications up the pipeline back to the source modality. If its messing up something as fundamental to DICOM as the UID, I would wonder what other wonderful things are happening.
If you must get these into the PACS, you would have to change the SOP Instance UID, which is not a recommended practice.
DICOM already provides a unique enough identifier for the Series (e.g. Series Instance UID), so why also include one on the lower level objects (e.g. SOPInstanceUID)?
What I find really annoying is the fact that when referencing other objects - for example when RTPlan object references RTStruct object via ReferencedStructureSetSequence / ReferencedSOPInstanceUID - it's done using the SOP Instance UID. However any of the DICOM SCPs - such as find/move - don't work with SOP Instance UID, they work with the Series Instance UID. So what gives? Do I have to load the whole Series to find all the referenced objects?
This question was from quite a while ago, but I thought I'd add that, ignoring QR altogether, a SeriesInstanceUID is a globally unique identifier for a single series. SOPInstanceUID is a globally unique identifier for a DICOM file. A series can have multiple DICOM files, so each would share that same SeriesInstanceUID, but each file would have it's own SOPInstanceUID.
As you probably know, DICOM has a hierarchy of identifiers for each individual SOP (Service Object Pair) Instance (Patient ID / Study Instance UID / Series Instance UID / SOP Instance UID). This hierarchy is built into the Query/Retrieve mechanism in DICOM, and is also used to identify specific SOP Instances.
In the specific case you're mentioning, I believe there could be the possibility of multiple RT Structure Sets within a Series/Study. The individual SOP Instance must be referenced so that you know which Structure Set the RT Plan is referencing.
As for products supporting retrieving by SOP Instance UID, unfortunately, relational queries are not widely supported in DICOM Query/Retrieve SCPs, as you've discovered, and some DICOM servers do not support Image level queries. In this specific case, you could query at the series level specifically for the RTSTRUCT modality, and only retrieve the Series that have this modality, thus narrowing down which data you need to download to just the RT Structure Sets.
SOPInstanceUID represent separate uid of the Dicom Image File. Study, series and sopinstace uids are based on data model. StudyUID give you the particular study information. In which different series devided. Series instance uid used for for this. And SOP instance uid represent seperate Dicom image. It's hierarchy structure. I also never used SOPInstanceUID when i developed PACS workstation in Java. As per my experience, Study & Series uids are enough for represent patient's data. But still SOPInstanceUID gives unique identity to dicom image.
SOP Instance UID : Represent your a unique Identifier for IOD, Its a TYPE 1 tag must present with value.
For Example :
Each DICOM Image has unique identifier
Series reference is not specific enough. In the case of structure sets the Reference SOP Instance UID ties the contours in the structure set to the specific slice in the dataset. It's not enough to just reference the series because you have to ensure that the contour is exactly aligning with a slice.
SOPInstanceUId is for image level identification.
Understand it like:
A study can have multiple series and a series can have multiple images/DICOM
So,
to identify study uniquely we use StudyInstanceUID
to identify series uniquely we use SeriesInstanceUID and
to identify an image/DICOM uniquely we use SOPInstanceUId