I would expect to have a tag like (2200,000C) 'Requested Media Application Profile' in the DICOMDIR file but it is not there. The thing that puzzles me is that I didn't find any way to know according to what application profile a physical media was created just by checking the value of an element in its DICOMDIR file. I have to admit that I didn't explore deep into this ally in the DICOM Standard because there was never a real need to do so. Most of this work in the standard is around the conformance statement of the application. It also defines the way the DICOMDIR file is constructed and if an icon image should be set in it or not.įor example, The Basic Cardiac X-ray Angiographic Application Profile (from part 11 of the standard) require that an icon image should be set in every image node of the DICOMDIR object. the transfer syntax to use, and so in, even the media to use. In short, application profiles define a set of rules on what objects can be put on a media and in what way, e.g. The DICOM Standard Part 11 defines 'Media Storage Application Profiles'.
#Make dicomdir file series#
Inside ST001 create a directory SE001 for every series.Inside PA001 create a directory ST001 for every study.Create a directory PA001 for every patient.Before calling it, make sure your files are named properly.
This method scans a directory for DICOM files and writes a DICOMDIR file in its root. So for example to go over all the patients in the media you use the getPatientIterator method and get back an object iterator where each DCXOBJ in it is one DICOMDIR patient record. The DCXDICOMDIR class has methods to search and iterate over the different records within the DICOMDIR file. This prolog is made to explain the very thin API of the DICOMDIR Implementation class DCXDICOMDIR. When I take such decisions its because I assume that RZDCX users want to focus on the their strengths and count on RZDCX to do the right thing DICOM-wise. Many times ease of use considerations supersede complete options and flexibility because I take the decision to implement the DICOM internals in a certain way that will be most integrative and still correct. With RZDCX I try to make things easier by providing the very basic API to carry out the task. Because search actions on CD's are much slower then on a hard drive, using the DICOMDIR should theoretically shorten the time required to find and display to the user the information on the media. Its a directory record with information about DICOM files on the media. The DICOMDIR is exactly what it names suggests. All we need to do then is to read the DICOMDIR file, find the record in it with our patient's ID and get from there the references to the DICOM files that we are looking for on the CD. Doable but slow, specially with slow media like CD, But, when this CD is made according to the standard, there's a better way. If we have no more information then that, we need to open the CD, look at every file on it and check if its a DICOM file, read it, figure out what's in it and decide if this is what we are looking for. Var dicomFile = (file.FullName) ĭicomDir.AddFile(dicomFile, file.Let's say we got a CD from someone that tells us there's DICOM files on this CD with the information of the patient we are looking for. If (DicomFile.HasValidHeader(file.FullName) & () != "dicomdir") Var dirInfo = new DirectoryInfo(path.PathOrFilename) įoreach (var file in dirInfo.GetFiles(".
stored in a DICOM files set, and it does not make reference to files that. Also, it created 2 patients, although there is only one (the patient IDs and names are the same). Structure of a DICOMDIR file and its representation in a physical storage. However, in the created DICOMDIR (inspecting it with Visual Studid Debugger), I get this: FileSetID = 'dicomDir.FileSetID' threw an exception of type 'Dicom.DicomDataException'. I am now trying to use that example from the samples page, where I let fo-dicom automatically build a DICOMDIR (if that is missing) out of a directory.
0 kommentar(er)
