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.
Related
This question already has answers here:
How can I get the current time in Cosmos DB
(2 answers)
Closed 4 days ago.
This post was edited and submitted for review 3 days ago and failed to reopen the post:
Original close reason(s) were not resolved
Is it possible to create a new item and set a field to the current time - as set on the server, in Cosmos DB?
I'm looking for something similar to INSERT INTO t VALUES (NOW()); in SQL.
I'd like to avoid asserting that the client time is correctly synced.
Update: To clarify, I don't mean GetCurrentDateTime().
I want to set the value of a custom field to the current server time.
e.g. {"started": "<NOW>"}
Can anyone share the code (in C# or Python, for example) that can be used?
A call to GetCurrentDateTime() will return current timestamp, which you can then store in a property of your new document. You would retrieve this via a SELECT. You'd then have to use a language-specific SDK call to write your document to your collection. Note that there is no INSERT statement in Cosmos DB's SQL dialect - it has to be done via SDK (or low-level API) call.
Also note that _ts will be automatically set to the exact time (in clock ticks) that the document is saved/updated. This will be the exact time the document was written. You could then save this value somewhere, upon first creating your document, to preserve original creation timestamp.
See here for more info on all date/time functions.
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.
This question already has an answer here:
How to create auto incremented key in Firebase?
(1 answer)
Closed 2 months ago.
How can I get next key value (User03) continue from last recent key (User02) like image below:
To know the next key in this sequence, you will need to first load all the current keys.
This is one of the many reasons Firebase recommends against using arrays, since such an operation doesn't scale well, and will only work while the user is connected to the database. I recommend reading best practices for arrays in Firebase and what are Firebase push IDs.
Suppose key contains following data
{name:"abc"}
Then I override it with new data
{name:"aaa",grade:"A"} .
Is their any way in riak where I get old data ? i.e {name:"abc"}
The short answer is that without using siblings there is no automated way in Riak to retrieve that last value for a specific key.
The answer to this type of problem is to build a versioning system into your application where you store N number of versions of your key/value pair based on your business needs.
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