The issue is a bit complicated to describe, but I think someone here will understand and probably has a good idea of how to solve it
At some MR machines, we have macros running (that we cannot modify). Those macros automatically do some acquisitions resulting in 5 images that are stored for a newly created patient.
So the structure is:
Patient ID: current time
Patient Name: a fixed value
Study Description: fixed value
Series Description (5x): variable
Instance (1x)
The main issue here is that each image (instance) creates its own series inside the study and the entire structure is shifted.
Usually, I would expect to have one series with 5 instances, but here it is 5 serieses with each having one instance.
The second issue is that each macro execution leads to a new patient and a new series, when I actually (logically) have it running for the same study, but multiple times.
So, what I want to process during upload is:
Get all related DICOM files (instances in this case) into one study, make the original studies to be the serieses and have the actual instances a child elements of those studies.
The patient can be set in the same process or later, that does not really matter anymore, as long as the structure below the study is correct.
My (so far favorite) idea is to get all DICOM files into a zip archive, which I name with an identifier for this type of processing and the study name that I want it to have. The upload mechanism then can create the study and assemble the original studies into serieses and fill them with the according instances.
Is there a better way to do this? And if no one can think of one, where can I start to implement the zip assessment? So far, I could not find a good entry to process zip files.
(If it helps: The macro is for DAQs (spurious) in Philips MR systems )
What I would do in that situation would indeed be similar to what you are suggesting, but without the need for zip files. You could write a Python plugin script that :
runs on the âstable studyâ event.
gather all the instances: you can first use /studies/XXXX to get the list of series and then /series/YYYY to get the sole instance ID
loop on the instance IDs and use /instances/ZZZZ/file to download the raw DICOM instances and load them all in a pydicomDataset` object
use pydicom to generate new SOPInstanceUID (for each instance) and a new SeriesInstanceUID (a single one for all of the 5 instances)
upload this back with a POST to /instances : this will lead to a 6th series being added to this study
once youâve confirmed that the upload went well, delete the five original instances (which will automatically delete the series that will then be empty)
thanks for the description of the process, that makes it easy (for me) to implement once I am at this point.
I still struggle with the the studies, because I also have multiple studies that I want to compress into one and each study becomes a series then.
By only uploading multiple series, I have no information about which series should be combined, that was the main purpose of the zip file. Or is there a way via the âupload jobâ?
Hi,
What is the property that allows you to determine how to group these instances ?
Is there some property that is common to all these five images? Is the PatientID (the current time) the same for all of them?
In other words, how did you plan to group the files into a zip file? In my opinion, using a zip or not is just a tool. I would like to understand what would be the pseudo-code logic that youâd use. You do not mention anything about the study ID. Is it fixed all the time, or fixed for these 5 images?
Letâs say that the PatientID is the common property between them. Letâs also assume that you can afford iterating on all studies (if there are too many studies, you can instead perform a find for recent ones)
when a new instance arrives, check if a study with metadata MyMetadata_PatientID is present and equals the new instance PatientID (youâll need to define a new metadata in the Orthanc JSON configuration file⌠you can perhaps use the study description instead if thatâs OK)
if it does not exist:
you decide that this instance study and series will be the ones weâre keeping
you can thus simply set MyMetadata_PatientID to PatientID on its series
do nothing else
if it does exist:
it means that we need to move this new instance to the study that weâve already picked for this PatientID|
you read the study Orthanc UUID, the StudyInstanceUID and SeriesInstanceUID of the matching study
Note: the series will be the sole entry in the Series array in the output of /studies/{studyUuid}
once you have the IDs, you can use /modify to download an instance with these IDs, and upload it right away (youâll need Force) with a POST to /instances.
once youâve done that, you can safely delete the original instance that was initially uploaded.
the goal of the items above is to group all the instances with the same PatientID in a single study/series that is specific to the PatientID. And, for this, we take the study and series of the first instance in the bunch
if this instance was the 5th, one, you know youâre done and you can maybe perform some action
Apologies if I got your question wrong, but it wasnât clear what is the common property that allows to group the instances together
Maybe my proposal is a little too convoluted and something easier can be done, though !
unfortunately, there is no common property. Even the the patient ID is made of date and time of the study.
There can be multiple different studies in one day, so even the date is not a distinct property.
This is why I wanted to implement a âcommon propertyâ by putting all the instances/âstudiesâ into on zip file, that acts as grouping container.
Only other mechanisms I can think of, are:
Run all files through a script locally beforehand and add a common custom tag
Have a dedicated submit formular that handles the grouping
Somehow use an index file to group the uploaded instances
But all of them are probably more complicated to implement and also to handle for the user.
So, some kind of a container would probably be the easiest way, but I would not know where to start implementing it.
It contains 3 (wrong) studies with each having 5 series of which each contains 1 single instance.
In the end, I would like to have 1 study with 3 series and each containing 5 instances.
When youâre saying âthere is no common propertyâ, you mean that, basically, there is no way an application could tell how to group lone instances together, is that right ?
In that case, and if I understand correctly, youâre looking for the easiest way to manually tag instances with sth like âI want to collect this instanceâ , run through all five such instances, and then launch some sort of automation that would create a single series.
I would go the explicit route in that case and write an external python script that downloads the Dicom files, run them through pydicom to put the same study id and series id, then upload them back.
Putting them in a zip does not help that their series ids are different and need to be reunified.
