DICOM AND PACS Value Representation How Did DICOM

DICOM AND PACS Value Representation

How Did DICOM Get Started? - The standard was conceived in 1983 by a joint committee formed by the American College of Radiology (ACR), and the National Electrical Manufacturers Association (NEMA). - The primary goal was to develop a standard that would make digital medical imaging independent of particular device manufacturers, thus facilitating the expansion of digital imaging and PACS. - The first version of the standard, called ACR-NEMA 300 -1985 or ACRNEMA 1. 0, was published in 1985 - As with any first version, ACR-NEMA 1. 0 contained errors and imperfections. It was soon realized that the standard required further work with continuous effort and better structure. For these reasons, ACRNEMA embraced the idea of working groups (WGs), which are separate subcommittees dedicated to improving specific parts of the growing standard. - The result of this work was the second revised version, ACR-NEMA 2. 0 (or ACR-NEMA 300 -1988), which was released in 1988. - The ability of ACR-NEMA 2. 0 to communicate medical data between devices was extremely limited. For example, a user could send an image to a remote device, but the standard did not specify what the device should do with the image.

How Did DICOM Get Started? (continued) - Another issue mandating a major revision was the need to accommodate the increasing variety of digital devices and their communications protocols. - In response to these changing needs, a third version of the ACR-NEMA standard was created and showcased at RSNA in 1992 in its most basic, prototypical form. The following year was spent in monthly WG meetings. The first nine parts of the new ACR-NEMA standard were completed by September 1993 and were presented at the 1993 meeting of the RSNA in a much more functional form. The revamped standard was called ACR-NEMA DICOM or, because it followed the first two ACR-NEMA editions, DICOM 3. 0. - DICOM 3. 0 has never been replaced by a DICOM 4. 0 and such. Instead, the same 3. 0 standard is reviewed annually by the designated DICOM WGs, publishing the updated DICOM 3. 0 versions and new supplements. - The volumes of the standard revisions are numbered as PS 3. X-YYYY, where 3 is the standard number, X represents the volume number, and YYYY represents the year of the edition. For example, PS 3. 5 -2008 identifies DICOM 3, part 5, revision 2008, and supersedes the earlier versions of PS 3. 5.

DICOM and Clinical Data - Whatever you need to accomplish in a medical workflow, you will face one of two principal tasks: collecting and processing clinical data. DICOM was designed to assist you with both tasks in a consistent, clinically sound manner. - DICOM segments all real world data into standardized attributes (listed in the DICOM Data Dictionary) and describes any real object as a collection of these attributes, known as IOD (Information Object Definition). - As a general rule, remember that nearly all numerical data in DICOM is stored in hexadecimal (binary) format.

Text vs. Binary in DICOM standard - Depending on its format, any data can be stored in either text or binary representations. The text format is typically used for names, dates, IDs, and other text strings. The binary format is used for encoding single numerical values or numerical sequences (image pixels and the like). - Different computer systems use different byte orders to represent the same multibyte number. While some systems record the numbers starting from the least significant byte (Little Endian order), others record the same numbers starting from the most significant byte (Big Endian order). 10 For example, what a Little Endian computer (MS Windows OS) stores in byte (binary) format as 0 x 007 F, a Big Endian computer (Mac OS) would keep as 0 x 7 F 00, reordering the 2 bytes. - To avoid data transfer errors, DICOM applications always keep track of their Endian types, and any two connected DICOM units agree on the choice of Endian type during the initial network handshake between them before they start transmitting any data (this will be covered in 9. 4. ) To make this agreement always possible, DICOM reserves Little Endian as its default byte-ordering type, meaning that all DICOM applications, whatever systems or hardware they are running on, must understand process Little Endian byte order. - In comparison to numerical values, text data stores each character (byte) independently and therefore always remains in the same order regardless of the hardware.

DICOM Grammar: Value Representations - So how does DICOM deal with this multitude of formats? Part PS 3. 5 of the standard defines 27 basic data types, known as value representations (VRs), which are designed to encapsulate all possible clinical data types. Anything written (encoded) in DICOM must match one of these 27 types. Each VR has its own abbreviated two-letter name, a definition of what it represents, a description of what characters are allowed in its data, and a prescribed data length.

VR Length - VRs, define DICOM data types, and data size (VR length) is a very important part of this definition. - DICOM keeps track of all data sizes in two ways. First, DICOM always records data sizes along with data values; this is how DICOM knows where each data element starts and ends. - Second, for some VRs, their data length is either fixed or limited, as you can see in the last column of our VR table. - Whether fixed-length or not, all DICOM data elements are supposed to have even lengths; that is, they must contain an even number of characters (if text) or bytes (if binary). - To ensure this, DICOM adds a single blank space character to any odd-sized text string (such as short text, ST), and a blank NULL byte to any odd-sized binary string (such as other byte string, OB) to make their lengths even. - For example, the name “Smith^Joe” will always be internally stored in DICOM as “Smith^Joe ” with a trailing space added and length set to 10. - In one respect, even-length padding of DICOM data can be viewed as an advantage. One can always use it as a parity check to verify the validity of data strings and to mark anything odd-sized as corrupted.

VR Length (continued) - Moreover, because many DICOM applications are often used in conjunction with other software (such as databases used in PACS archives, Radiology Information Systems (RISs)), the issue of ignoring and trimming the trailing blanks permeates the entire workflow chain. - The safest approach is to trim DICOM data strings as soon as DICOM data is decoded to be sent to a non-DICOM application.