Lets say we got a CD from someone that tells us theres DICOM files on this CD with the information of the patient we are looking for. Ive already discussed part of it, the DICOM File Meta Header, when talking about DICOM Transfer Syntax. The DICOM Objects can be either be written into DICOM files and then take the right side (or the left foot if this robot is facing us) through some physical media like a CD, DVD and USB, or it can take the left side and be sent over a TCPIP network connection using DICOM commands like C-STORE. Then it is ready to be shared or sent to other applications, not yours, that can read the data and make useful things with it because that application too, just like your application, speaks the same language - DICOM.

RZDCX toolkit ) taking its data and putting it into DICOM Objects encoded properly. The gray body box is your DICOM implementation (e.g. The oval head that reads Medical Information is representing your application data. It is worth staying a bit longer on this figure because it has a lot of valuable information in it so lets work it top to bottom.Īt a first view, ignoring its content and looking only at the shape, it looks like some kind of humanoid robot with flat oval head walking on two clumsy legs made of crude blocks. The picture above, which is by the way the first figure in the DICOM standard (page 10 of chapter 1), explains that very well although when I first looked at thirteen years ago it it didnt mean anything to me. They can communicate over TCPIP network connection or they can exchange files over some physical media. There are two ways DICOM application can collaborate with one another. So when creating your DICOM images if you intend to create DICOMDIR for them, add these elements too. For example Study ID which is Type 2 in DICOM Image objects is Type 1 in DICOMDIR STUDY Record.

Opening dicomdir file vivoquant