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
Related
This question already has an answer here:
How to generate unique DICOM UID?
(1 answer)
Closed 4 years ago.
I am a newbie to the world of DICOM, and I would like to send a modified DICOM file (created from a copy of a DICOM queried from a PACS server), back to the same server, as a new series for the same patient+study.
The modified DICOM would be a new single series, and I increment the last subnumber by +1. I do the same for the SOPUID. However, I am worried about the posibility of a new series being added in the same SUID getting added in the meantime and being rejected.
What is the accepted way of numbering when sending a new DICOM Image to a PACS server? Is it enough to increment SOPUID and SUID?
Creator must guarantee the global uniqueness of any UID value they generate. Incrementing an existing UID by 1 is by no means sufficient.
Basically the primary way of creating UID-s is to register a UID prefix for your organisation and then issue unique UID-s under that prefix, where you guarantee the uniqueness yourself by any means you see fit. The process is described in the DICOM standard here.
Another way proposed by the standard itself is to generate a UUID and convert that value to a single integer, to which you add a 2.25. prefix. This method is described in the DICOM standard also. This would generate a UID such as 2.25.34528018848038895355275102816408995430, which should be unique with sufficient reliability.
I need to create a Secondary Capture Image representing a report related to radiopharmaceutical and dose injected to the patient during the medical examination.
I know Secondary Capture Image is not the right choice to accomplish the task but that is what the customer requires.
Following are the steps I thought to implement for developing the feature and I would like to read some opinions or suggestion from the community.
Assumption: MWL is implemented and the Study Instance UID is generated in the RIS
query the MWL (C-FIND) to get the requested procedure object
parse the result to get the StudyInstanceUID and patient related
informations (name, sex, birthdate etc.)
query (C –FIND) the modality looking for the specific Study
Instance UID
parse the result to get the Series Instance UID
create the image setting the three mandatory attribute Study
Instance UID, Series Instance UID, Modality (together with some type
2 attributes I got querying MWL and modality in the previous
steps)
C-STORE to persist the image to the storage archive
Commit of the image (do I really need?)
I really appreciate comments opinions or someone that can address me to a more solid architecture.
correct
correct. Do not forget about attributes that are not so obvious like Admission ID, Accession Number, Referring Physicians Name and others.
The majority of modalities does not support Query/Retrieve as an SCP. If you would really need to query for the images, send the C-FIND to the PACS rather than the modality. The Study Instance UID comes with the worklist. Even if the UID you find by Query differs from that, I would strongly recommend to use the one from the worklist. However, I do not see any sense in using attributes from other sources than the MWL and your own "acquisition".
Why would you want to add the image to an existing series? It would probably be more appropriate to create a new one. There are a lot of reasons for that, e.g. Modality and vendor/equipment information are series level information and probably different.
There are more mandatory attributes for SC (e.g. in the general image module). Not all come from the MWL.
yes.
You do not have to. However, suppose that your images are lost:
a) you have received a storage commitment from the PACS -> blame on the PACS
b) you have not received a storage commitment from the PACS -> blame on ...? ;-)
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.
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.
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