14
order-entry process. The order is then sent to the radiology department, where it
must be scheduled and subsequently performed as an imaging study. The study is
then interpreted by radiologists. This step yields the imaging report, the final prod-
uct, which is delivered back to the ordering physician.
This sequence may appear simple and straightforward but, upon closer inspec-
tion, it is anything but. In fact, it is not even a sequence, but rather a branching net-
work of interdependent events and decisions, where each major step leads to several
smaller sub-processes, each with its own meaning and value. For instance,
Fig. 2.1 Sample HL7 message with radiology report. You can see that the message consists of
separate segments, identified by three-character segment names (for instance, the second line
begins with a segment named PID because it contains patient information; the OBX segment,
observations and reports; and so on). Each segment, in turn, contains individual data fields, sepa-
rated by vertical lines (|) known as “pipes.” You can read and understand most of the message even
if you do not know its format. Patient names, reports, and timestamps are all quite visible. For
instance, the PID segment in the example above contains patient name (SAMPLE^JOHN) fol-
lowed by patient date of birth (19600507—May 07, 1960), patient sex (M for male), etc. Note that
empty fields still keep their pipes, so fragments like ||||| correspond to sequences of empty fields
(0x0008, 0x0008) 22 bytes CS <ORIGINAL\PRIMARY\AXIAL> ImageType
(0x0008, 0x0018) 56 bytes UI <1.2.840.113619.2.267.3.1258978082.959.1287659962.737.22 > SOPInstanceUID
(0x0008, 0x0020) 8 bytes DA <20101021> StudyDate
(0x0008, 0x0021) 8 bytes DA <20101021> SeriesDate
(0x0008, 0x0022) 8 bytes DA <20101021> AcquisitionDate
(0x0008, 0x0023) 8 bytes DA <20101021> ContentDate
(0x0008, 0x0030) 6 bytes TM <094100> StudyTime
(0x0008, 0x0031) 6 bytes TM <094228> SeriesTime
(0x0008, 0x0032) 14 bytes TM <094248.342448 > AcquisitionTime
(0x0008, 0x0033) 6 bytes TM <094401> ContentTime
(0x0008, 0x0050) 8 bytes SH <5527426 > AccessionNumber
(0x0008, 0x0060) 2 bytes CS <CT> Modality
(0x0008, 0x0090) 14 bytes PN <GOLDFINGER^BOB> ReferringPhysician’sName
(0x0008, 0x1010) 4 bytes SH <ct05> StationName
(0x0008, 0x1030) 22 bytes LO <CT CHEST W/O CONTRAST > StudyDescription
(0x0008, 0x103e) 22 bytes LO <C-CHEST - THIN STD ALG> SeriesDescription
(0x0008, 0x1090) 18 bytes LO <Discovery CT750 HD> Manufecturer’sModel
(0x0010, 0x0010) 12 bytes PN <BOND^JAMES> Patient’sName
(0x0010, 0x0020) 8 bytes LO <2185908 > PatientID
(0x0010, 0x0030) 8 bytes DA <19881112> Patient'sBirthDate
(0x0010, 0x0040) 2 bytes CS <M >
(0x0010, 0x1040) 58 bytes LO <1 MAPLE STREET, BOSTON, MA, 00123, US> Patient'sAddress
(0x0010, 0x21b0) 0 bytes LT <Empty> AdditionalPatientHistory
(0x0018, 0x0010) 10 bytes LO <GL/ SPERN > Contrast/BolusAgent
(0x0018, 0x0022) 12 bytes CS <HELICAL MODE> ScanOptions
(0x0018, 0x0050) 8 bytes DS <1.250000> SliceThickness
(0x0018, 0x0060) 4 bytes DS <120 > KVP
ELEMENT TAG LENGTHV R VALUE DESCRIPTION
Fig. 2.2 DICOM image, aka DICOM “information object,” and some of the information it con-
tains in addition to the image data. Instead of the segment names used in HL7, DICOM data ele-
ments are identified by element tag numbers, and instead of HL7 “pipes,” DICOM fields are
separated according to their data lengths. For example, data element (0×0010, 0×0030) contains
the patient’s birth date (in our case, November 12, 1988). When extracted and processed properly,
these DICOM data elements support a broad spectrum of fascinating and indispensable radiology
applications—from routine reconstruction to complex imaging analysis or workflow management2 Mining Your Own Business