DICOM 标准简介
DICOM( Digital Imaging and Communications in Medicine )
中文介绍：
DICOM即数字影像和通信标准。在医学影像信息学的发展和PACS的研究过程中，由于医疗设备生产厂商的不同，造成与各种设备有关的医学图像存储格式、传输方式千差万别，使得医学影像及其相关信息在不同系统、不同应用之间的交换受到严重阻碍。为此，美国放射学会（ACR）和全美电子厂商联合会（NEMA）认识到急需建立一种标准，以规范医学影像及其相关信息的交换， DICOM标准就是在这样的背景下产生的
1 DICOM标准
ACR和NEMA联合组成委员会，在参考了其他相关国际标准（CNET251、JIRA、IEEE、HL7、ANSI等）的基础上，联合推出了医学数字图像存储与通信标准，即DICOM标准。它从最初的1.0版本（ACR-NEMAStandards Publications No.300-1985）到1988年推出的2.0版本（ACR-NEMA Standards PublicationsNO.300-1988），到1993年发布的DICOM标准3.0，已发展成为医学影像信息学领域的国际通用标准。
DICOM标准中涵盖了医学数字图像的采集、归档、通信、显示及查询等几乎所有信息交换的协议；以开放互联的架构和面向对象的方法定义了一套包含各种类型的医学诊断图像及其相关的分析、报告等信息的对象集；定义了用于信息传递、交换的服务类与命令集，以及消息的标准响应；详述了唯一标识各类信息对象的技术；提供了应用干网络环境（OSI或TCP/IP）的服务支持；结构化地定义了制造厂商的兼容性声明（Conformance Statement）。
DICOM标准的推出与实现，大大简化了医学影像信息交换的实现，推动了远程放射学系统、图像管理与通信系统（PACS）的研究与发展，并且由于DICOM的开放性与互联性，使得与其它医学应用系统（HIS、RIS等）的集成成为可能。
2 DICOM标准的组成部分
DICOM标准具有良好的可扩充性。它由多部分组成，可以单独对某部分进行扩充；在各部分中，又将易于增加和修改的内容放到附录中，方便更新。目前DICOM标准（指DICOM3.0）由九部分组成（其它部分为正在讨论中的DICOM扩展部分）。
每一部分的标题我们大致可以知道该部分所包含的主题，其具体的内容在DICOM标准的文档中有着非常详实而且严谨的描述和定义，因为篇幅的缘故，我们在这里只能对其中的某些部分略为介绍，其它具体内容请参阅文档。
通过本论文前面章节的介绍可以知道，DICOM标准中的核心内容主要是在第三到第八部分，以及扩展的第十部分。其中第三部分的DICOM信息对象定义（IOD）和第四部分的服务类（Service Class）在本论文的第三章中已有介绍；第七、第八部分所讨论的DICOM通信规程，包括网络支持和网络消息交换等也在论文的第五章中有所介绍。因此，在这里要特别介绍的是标准中第五、第六部分所定义的DICOM数据结构、编码方式和解释，以及第十部分中的文件存储格式等。
3 DICOM 数据结构和文件格式
DICOM标准的第五部分介绍它的数据结构，它定义了数据集（Data Set）来保存前面所介绍的信息对象定义（IOD），数据集又由多个数据元素（Data Element）组成。每个数据元素描述一条信息（所有的标准数据元素及其对应信息在标准的第六部分列出），它由对应的标记（8位16进制数，如（0008，0016），前4位是组号（GroupNumber），后十位是元素号（Element Number）唯一确定 DICOM数据元素分为两种，即：
● 标准（Standard）数据元素，组号为偶数，含义在标准中已定义。
● 私有（Private）数据元素，组号为奇数，其描述信息的内容由用户定义
DICOM3.0 标 准 文 件 内 容 概 要
第一部分：引言与概述，简要介绍了DICOM的概念及其组成。
第二部分：兼容性，精确地定义了声明DICOM要求制造商精确地描述其产品的DICOM兼容性，即构造一个该产品的DICOM兼容性声明，它包括选择什么样的信息对象、服务类、数据编码方法等，每一个用户都可以从制造商处得到这样一份声明。
第三部分：利用面向对象的方法，定义了两类信息对象类：普通性、复合型。
第四部分：服务类，说明了许多服务类，服务类详细论述了作用与信息对象上的命令及其产生的结果。
第五部分：数据结构及语意，描述了怎样对信息对象类和服务类进行构造和编码。
第六部分：数据字典，描述了所有信息对象是由数据元素组成的，数据元素是对属性值的编码。
第七部分：消息交换，定义了进行消息交换通讯的医学图像应用实体所用到的服务和协议。
第八部分：消息交换的网络通讯支持，说明了在网络环境下的通讯服务和支持DICOM应用进行消息交换的必要的上层协议。
第九部分：消息交换的点对点通讯支持，说明了与ACR—NEMA2.0兼容的点对点通讯的服务和协议。
第十部分：便于数据互换的介质存储方式和文件格式
第十一部分：介质存储应用框架
第十二部分：便于数据互换的介质格式和物理介质
第十三部分：打印管理的点对点通讯支持
第十四部分：亮度[灰度]色标显示功能标准
第十五部分：安全性概述
第十六部分：绘制资源目录
DICOM3.0标准特点
a)它对于一个网络环境是可用的。前几个版本只在点对点的环境中可用；对于在网络环境中的操作，需要一个网络接口单元（NIU）。DICOM版本3.0支持在网络环境中使用标准的网络协议的操作，如OSI和TCP/IP。
b)它详细说明了声称与标准兼容的设备如何对命令做出应答和数据如何被交换。前面几个版本在传输数据上受到限制，但DICOM 3.0通过服务类别的概念，指定了命令和相关数据的语义。
c)它详述了兼容性的等级。前面的版本指定了兼容性等级的最小集合。DICOM3.0清楚地描述了一个实现者必须如何构造一个与所选的特殊选项兼容的声明。
d)它按照多部分的文档结构来组织。通过简化新特性的增加，这种结构使标准在迅速发展的环境中的演变更为容易。ISO指示——定义如何去构造多部分文档——已经加入到DICOM标准的构造中。
e)它提出了明确的信息对象，并不只是针对图象和图形，还有研究、报告等。
f)它为唯一地识别任何信息对象指定了一个确定的技术。这促进了在网络上运作的信息对象之间的关系的明确定义。
符号和缩写
ACSE：联合控制服务元素
CT：计算X射线断层造影术
DICOM：医学数字成像和通讯
HIS：医院信息系统
NIU：网络接口单元
OSI：开放系统互连
PACS：图像归档和传输系统
RIS：放射学信息系统
TCP/IP：传输控制协议/互连网协议
DICOM官网：http://medical.nema.org/
英文介绍：
History
Front page of ACR/NEMA 300, version 1.0, which wasreleased in 1985
DICOM is thethird version of a standard developed by American Collegeof Radiology (ACR) and National ElectricalManufacturers Association (NEMA).
In the beginningof the 1980s it was almost impossible for anyone other than manufacturers ofcomputed tomography or magnetic resonance imaging devices to decode the imagesthat the machines generated. Radiologists and medical physicists wanted to usethe images for dose-planning for radiation therapy. ACR and NEMA joined forcesand formed a standard committee in 1983. Their first standard, ACR/NEMA 300,was released in 1985. Very soon after its release, it became clear thatimprovements were needed. The text was vague and had internal contradictions.
In 1988 thesecond version was released. This version gained more acceptances amongvendors. The image transmission was specified as over a dedicated 25differential (EIA-485) pair cable. The first demonstration of ACR/NEMA V2.0interconnectivity technology was held at Georgetown University,May 21–23, 1990. Six companies participated in this event, DeJarnette ResearchSystems, General Electric Medical Systems, Merge Technologies, Siemens MedicalSystems, Vortech (acquired by Kodak that same year) and 3M. Commercial equipment supporting ACR/NEMA2.0 was presented at the annual meeting of the Radiological Society of NorthAmerica (RSNA) in 1990 by these same vendors. Many soon realized that thesecond version also needed improvement. Several extensions to ACR/NEMA 2.0 werecreated, like Papyrus (developed by the University Hospital of Geneva,Switzerland) and SPI, (Standard Product Interconnect, driven by Siemens MedicalSystems and Philips Medical Systems).
The first largescale deployment of ACR/NEMA technology was made in 1992 by the US Army and AirForce as part of the MDIS (Medical Diagnostic Imaging Support) program run outof Ft. Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led aconsortium of companies in deploying the first US military PACS (Picture Archivingand Communications System) at all major Army and Air Force medical treatmentfacilities and teleradiology nodes at a large number of US military clinics.DeJarnette Research Systems and Merge Technologies provided the modalitygateway interfaces from third party imaging modalities to the Siemens SPInetwork. The Veterans Administration and the Navy also purchased systems offthis contract.
In 1993 the thirdversion of the standard was released. Its name was then changed to DICOM so asto improve the possibility of international acceptance as a standard. Newservice classes were defined, network support added and the ConformanceStatement was introduced. Officially, the latest version of the standard isstill 3.0, however, it has been constantlyupdated and extended since 1993. Instead of using the version number thestandard is often version-numbered using the release year, like "the 2007version of DICOM".
While the DICOMstandard has achieved a near universal level of acceptance amongst medicalimaging equipment vendors and healthcare IT organizations, the standard has itslimitations.DICOM is a standard directed ataddressing technical interoperability issues in medical imaging. It is not aframework or architecture for achieving a useful clinical workflow.RSNA's Integrating the Healthcare Enterprise(IHE)initiative layered on top of DICOM (and HL-7) provides this finalpiece of the medical imaging interoperability puzzle.
Derivations
There are somederivations from the DICOM standard into other application areas. This includes
· DICONDE -Digital Imaging and Communication in Nondestructive Evaluation, wasestablished in 2004 as a way for nondestructive testing manufacturers and usersto share image data.[5]
· DICOS - DigitalImaging and Communication in Security was established in 2009 to be usedfor image sharing in airport security.
DICOM Data Format
DICOM differsfrom some, but not all, data formats in that it groups information intodata sets.That means that a file of a chest X-Ray image, for example, actually containsthe patient ID within the file, so that the image can never be separated fromthis information by mistake. This is similar to the way that image formats suchasJPEG can alsohave embedded tags to identify and otherwise describe the image.
A DICOM dataobject consists of a number of attributes, including items such as name, ID,etc., and also one special attribute containing the image pixel data (i.e.logically, the main object has no "header" as such: merely a list ofattributes, including the pixel data). A single DICOM object can only containone attribute containing pixel data. For many modalities, this corresponds to asingle image. But note that the attribute may contain multiple"frames", allowing storage of cine loops or other multi-frame data.Another example is NM data, where an NM image by definition is amulti-dimensional multi-frame image. In these cases three- or four-dimensionaldata can be encapsulated in a single DICOM object. Pixel data can be compressedusing a variety of standards, including JPEG, JPEG Lossless, JPEG 2000, andRun-length encoding (RLE). LZW (zip) compression can be used for the whole dataset (not just the pixel data) but this is rarely implemented.
DICOM uses threedifferent Data Element encoding schemes. With Explicit Value Representation(VR) Data Elements, for VRs that are not OB,OW, OF, SQ, UT, or UN, the format for each Data Element is: GROUP (2 bytes)ELEMENT (2 bytes) VR (2 bytes) LengthInByte (2 bytes) Data (variable length).For the other Explicit Data Elements or Implicit Data Elements, see section 7.1of Part 5 of the DICOM Standard.
The same basicformat is used for all applications, including network and file usage, but whenwritten to a file, usually a true "header" (containing copies of afew key attributes and details of the application which wrote it) is added.
DICOM Value Representations
· Extractedfrom Chapter 6.2
| Value Representation |
Description |
| AE |
Application Entity |
| AS |
Age String |
| AT |
Attribute Tag |
| CS |
Code String |
| DA |
Date |
| DS |
Decimal String |
| DT |
Date/Time |
| FL |
Floating Point Single (4 bytes) |
| FD |
Floating Point Double (8 bytes) |
| IS |
Integer String |
| LO |
Long String |
| LT |
Long Text |
| OB |
Other Byte |
| OF |
Other Float |
| OW |
Other Word |
| PN |
Person Name |
| SH |
Short String |
| SL |
Signed Long |
| SQ |
Sequence of Items |
| SS |
Signed Short |
| ST |
Short Text |
| TM |
Time |
| UI |
Unique Identifier |
| UL |
Unsigned Long |
| UN |
Unknown |
| US |
Unsigned Short |
| UT |
Unlimited Text |
In addition to aValue Representation, each attribute also has a Value Multiplicity to indicatethe number of data elements contained in the attribute. For character stringvalue representations, if more than one data element is being encoded, thesuccessive data elements are separated by the backslash character"\".
DICOM Services
DICOM consists ofmany different services, most of which involve transmission of data over anetwork, and the file format below is a later and relatively minor addition tothe standard.
Store
The DICOM Storeservice is used to send images or other persistent objects (structured reports,etc.) to aPACS or workstation.
Storage Commitment
The DICOM storagecommitment service is used to confirm that an image has been permanently storedby a device (either on redundant disks or on backup media, e.g. burnt to a CD).The Service Class User (SCU: similar to a client), a modality or workstation, etc., usesthe confirmation from the Service Class Provider (SCP: similar to aserver), an archive station for instance, tomake sure that it is safe to delete the images locally.
Query/Retrieve
This enables aworkstation to find lists of images or other such objects and then retrievethem from a PACS.
Modality Worklist
This enables apiece of imaging equipment (a modality) to obtain details of patients andscheduled examinations electronically, avoiding the need to type suchinformation multiple times (and the mistakes caused by retyping).
Modality Performed Procedure Step
A complementaryservice to Modality Worklist, this enables the modality to send a report abouta performed examination including data about the images acquired, beginningtime, end time, and duration of a study, dose delivered, etc. It helps give theradiology department a more precise handle on resource (acquisition station)use. Also known as MPPS, this service allows a modality to better coordinatewith image storage servers by giving the server a list of objects to sendbefore or while actually sending such objects.
Printing
The DICOMPrinting service is used to send images to a DICOM Printer, normally to printan "X-Ray" film. There is a standard calibration (defined in DICOMPart 14) to help ensure consistency between various display devices, includinghard copy printout.
Off-line Media (DICOM Files)
The off-linemedia files correspond to Part 10 of the DICOM standard. It describes how tostore medical imaging information on removable media. Except for the data setcontaining, for example, an image and demography, it's also mandatory toinclude the File Meta Information.
DICOM restrictsthe filenames on DICOM media to 8 characters (some systems wrongly use 8.3, butthis does not conform to the standard). No information must be extracted fromthese names (PS3.10 Section 6.2.3.2). This is acommon source of problems with media created by developers who did not read thespecifications carefully. This is a historical requirement to maintaincompatibility with older existing systems. It also mandates the presence of amedia directory, the DICOMDIR file, which provides index and summaryinformation for all the DICOM files on the media. The DICOMDIR informationprovides substantially greater information about each file than any filenamecould, so there is less need for meaningful file names.
DICOM filestypically have a .dcm file extension if they are not part of a DICOM media(which requires them to be without extension).
The MIME type for DICOMfiles is defined by RFC 3240as application/dicom.
The Uniform Type Identifier type for DICOMfiles is org.nema.dicom.
There is also anongoing media exchange test and "connectathon" process for CD mediaand network operation that is organized by theIHE organization.
Application areas
| Modality |
Description |
| AS |
Modality of type Angioscopy - Retired |
| BI |
Modality of type Biomagnetic Imaging |
| CD |
Modality of type Color Flow Doppler - Retired 2008 |
| CF |
Modality of type Cinefluorography - Retired |
| CP |
Modality of type Colposcopy - Retired |
| CR |
Modality of type Computed Radiography |
| CS |
Modality of type Cystoscopy - Retired |
| CT |
Modality of type Computed Tomography |
| DD |
Modality of type Duplex Doppler - Retired 2008 |
| DG |
Modality of type Diaphanography |
| DM |
Modality of type Digital Microscopy - Retired |
| DS |
Modality of type Digital Subtraction Angiography - Retired |
| DX |
Modality of type Digital Radiography |
| EC |
Modality of type Echocardiography - Retired |
| ECG |
Modality of type Electrocardiograms |
| EM |
Modality of type Electron Microscope |
| ES |
Modality of type Endoscopy |
| FA |
Modality of type Fluorescein Angiography - Retired |
| FS |
Modality of type Fundoscopy - Retired |
| GM |
Modality of type General Microscopy |
| HC |
Modality of type Hard Copy |
| LP |
Modality of type Laparoscopy - Retired |
| LS |
Modality of type Laser Surface Scan |
| MA |
Modality of type Magnetic Resonance Angiography (retired) |
| MG |
Modality of type Mammography |
| MR |
Modality of type Magnetic Resonance |
| MS |
Modality of type Magnetic Resonance Spectroscopy - Retired |
| NM |
Modality of type Nuclear Medicine |
| OT |
Modality of type Other |
| PT |
Modality of type Positron Emission Tomography (PET) |
| RD |
Modality of type Radiotherapy Dose (a.k.a. RTDOSE) |
| RF |
Modality of type Radio Fluoroscopy |
| RG |
Modality of type Radiographic Imaging (conventional film screen) |
| RTIMAG |
Modality of type Radiotherapy Image |
| RP |
Modality of type Radiotherapy Plan (a.k.a. RTPLAN) |
| RS |
Modality of type Radiotherapy Structure Set (a.k.a RTSTRUCT) |
| RT |
Modality of type Radiation Therapy |
| SC |
Modality of type Secondary Capture |
| SM |
Modality of type Slide Microscopy |
| SR |
Modality of type Structured Reporting |
| ST |
Modality of type Single-Photon Emission Computed Tomography (retired 2008) |
| TG |
Modality of type Thermography |
| US |
Modality of type Ultrasound |
| VF |
Modality of type Videofluorography - Retired |
| VL |
Modality of type Visible Light |
| XA |
Modality of type X-Ray Angiography |
| XC |
Modality of type External Camera (Photography) |
DICOM transmission protocol port numbers overIP
DICOM havereserved the following TCP and UDP port numbers by the Internet AssignedNumbers Authority (IANA):
· 104 well-known port for DICOM over TCP or UDP. Since 104is in the reserved subset, many operating systems require special privileges touse it.
· 2761registered port for DICOM usingIntegrated SecureCommunication Layer (ISCL) over TCP or UDP
· 2762registered port for DICOM using Transport Layer Security (TLS) over TCP or UDP
· 11112registered port for DICOM using standard, open communication over TCP or UDP
The standardrecommends but does not require the use of these port numbers.
}