出典(authority):フリー百科事典『ウィキペディア(Wikipedia)』「2015/08/21 11:09:57」(JST)
DICOM(ダイコム)とは、Digital Imaging and COmmunication in Medicineの略で、米国放射線学会 (ACR) と北米電子機器工業会 (NEMA) が開発した、CTやMRI、CRなどで撮影した医用画像のフォーマットと、それらの画像を扱う医用画像機器間の通信プロトコルを定義した標準規格のことである。
基本的には撮影直後の生成直後はビットマップ系のRAWフォーマットを用いる場合が多く、DICOMサーバなどへの短期保存時にはRAWフォーマットのまま、もしくはRLE圧縮やロスレスJPEGなどの劣化のない可逆フォーマットを用いる場合が多く、長期保存時にはロッシーJPEGなど非可逆フォーマットを用いる場合が多い。また、DICOMサーバからDICOMビューアへの配信時には、通信効率を上げるためにJPEG系のフォーマットを利用する場合が多く、一部ではJPEG 2000や独自フォーマットへ内包データを変換して配信している場面も見受けられる。
ただし、DICOMの仕様では、規格の特性上、画像を主とするものの、画像に限らず、ありとあらゆるデータを内包できるようになっている(コンテナフォーマット)。内包物がある場合はDICOMファイル内のタグ情報に、内包物のフォーマット名及びデータ長を記載するようになっており、加えて上記のタグ情報が複数ある場合は画像データも複数枚が内包されている状態となる。これをマルチフレームという。
以上のように、画像以外の情報も内包可能なため、超音波診断装置などでは、画像に加えて心拍などの音声データを内包している場合もある。また、この音声データと、前述のマルチフレーム等の画像データをパラパラアニメのようにし、同時再生することにより音声付き動画データとして扱うことも可能である。
DICOMの通信仕様については、RS-232などのシリアルケーブルを用いた通信など、幅広い通信手段を網羅するため、OSI参照モデルに準拠している。
しかし、1990年代中ごろからインターネットが爆発的に普及したことにより、OSI参照モデルではなく、RFC 1122(通称DARPAモデル)に準拠した製品が一般化することとなった。
この情勢の変化に対し、DICOMの最新仕様では、OSI参照モデルに準じたDICOM通信プロトコルをTCP/IPを用いてカプセル化する、という方法で大幅な仕様変更を回避している。
しかし、DICOM通信プロトコルでは、カプセル化によるオーバーヘッドが生じ、TCP/IPであればネットワークカード上のハードウェアで処理されるパケットの再構成処理などもカプセル化されたデータについてはソフトウェアで実現しなければならず、HTTPなどの純粋にTCP/IPを用いた通信プロトコルに比べ、負荷や速度などは大幅に劣る。このため、一部製品では、他社製品との通信にはDICOMに準拠するものの、自社製品間における通信は独自プロトコルを用いている場合も多く見受けられる。
英語版に仕様書のリストが掲載されているので参照のこと。
印刷・データ保存に関する規定や、個人情報になりうる性質のデータである以上セキュリティに関する仕様も盛り込まれている。またDICOMフォーマットへのWebアクセスに関する規定もある。
実際の医療現場では、「DICOM準拠」をうたっているにも関わらず、実際にはメーカーによって画像フォーマットやテキストデータなどの扱いが異なっている(いわゆる「メーカー方言」が存在する)[1]ことが多い。そのために相互運用が行えないケースも多く、病院関係者から問題視されている[2]。
またDICOMのフォーマットは「人間の医療情報」を保存することに特化しているため、人間以外の動物の医用画像(例:競走馬のレントゲン写真など)をDICOMで管理するためには病院側での項目の読み替えなどの手間が必要になる。この点についても、動物医療に携わる人間からは改善を求める意見があり、近年ではそういったニーズに対応して動物医療向けに強引にカスタマイズされたシステムも登場してきている。ただし、DICOM規格に準拠するという意味では、DICOM規格ではプライベートタグという独自拡張を認めており、その範囲内で適用すべきである。
[ヘルプ] |
この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています(PJ:コンピュータ/P:コンピュータ)。 |
この項目は、医学に関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています(プロジェクト:医学/Portal:医学と医療)。 |
|
Digital Imaging and Communications in Medicine (DICOM) is a standard for handling, storing, printing, and transmitting information in medical imaging. It includes a file format definition and a network communications protocol. The communication protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format. The National Electrical Manufacturers Association (NEMA) holds the copyright to this standard.[1] It was developed by the DICOM Standards Committee, whose members[2] are also partly members of NEMA.[3]
DICOM enables the integration of scanners, servers, workstations, printers, and network hardware from multiple manufacturers into a picture archiving and communication system (PACS). The different devices come with DICOM conformance statements which clearly state which DICOM classes they support. DICOM has been widely adopted by hospitals and is making inroads in smaller applications like dentists' and doctors' offices.
DICOM is known as NEMA standard PS3, and as ISO standard 12052:2006 "Health informatics -- Digital imaging and communication in medicine (DICOM) including workflow and data management".
DICOM is the First version of a standard developed by American College of Radiology (ACR) and National Electrical Manufacturers Association (NEMA).
In the beginning of the 1980s, it was very difficult for anyone other than manufacturers of computed tomography or magnetic resonance imaging devices to decode the images that the machines generated. Radiologists and medical physicists wanted to use the images for dose-planning for radiation therapy. ACR and NEMA joined forces and formed a standard committee in 1983. Their first standard, ACR/NEMA 300, was released in 1985. Very soon after its release, it became clear that improvements were needed. The text was vague and had internal contradictions.
In 1988 the second version was released. This version gained more acceptance among vendors. The image transmission was specified as over a dedicated 2 pair cable (EIA-485). The first demonstration of ACR/NEMA V2.0 interconnectivity technology was held at Georgetown University, May 21–23, 1990. Six companies participated in this event, DeJarnette Research Systems, General Electric Medical Systems, Merge Technologies, Siemens Medical Systems, Vortech (acquired by Kodak that same year) and 3M. Commercial equipment supporting ACR/NEMA 2.0 was presented at the annual meeting of the Radiological Society of North America (RSNA) in 1990 by these same vendors. Many soon realized that the second version also needed improvement. Several extensions to ACR/NEMA 2.0 were created, like Papyrus (developed by the University Hospital of Geneva, Switzerland) and SPI (Standard Product Interconnect), driven by Siemens Medical Systems and Philips Medical Systems.
The first large-scale deployment of ACR/NEMA technology was made in 1992 by the US Army and Air Force, as part of the MDIS (Medical Diagnostic Imaging Support) program based at f Ft. Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying the first US military PACS (Picture Archiving and Communications System) at all major Army and Air Force medical treatment facilities and teleradiology nodes at a large number of US military clinics. DeJarnette Research Systems and Merge Technologies provided the modality gateway interfaces from third party imaging modalities to the Siemens SPI network. The Veterans Administration and the Navy also purchased systems off this contract.
In 1993 the third version of the standard was released. Its name was then changed to "DICOM" so as to improve the possibility of international acceptance as a standard. New service classes were defined, network support added and the Conformance Statement was introduced. Officially, the latest version of the standard is still 3.0. However, it has been constantly updated and extended since 1993. Instead of using the version number, the standard is often version-numbered using the release year, like "the 2007 version of DICOM".
While the DICOM standard has achieved a near universal level of acceptance amongst medical imaging equipment vendors and healthcare IT organizations, the standard has its limitations. DICOM is a standard directed at addressing technical interoperability issues in medical imaging. It is not a framework 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 final piece of the medical imaging interoperability puzzle.
There are some derivations from the DICOM standard into other application areas. These include:
DICOM differs from some, but not all, data formats in that it groups information into data sets. That means that a file of a chest x-ray image, for example, actually contains the patient ID within the file, so that the image can never be separated from this information by mistake. This is similar to the way that image formats such as JPEG can also have embedded tags to identify and otherwise describe the image.
A DICOM data object 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 of attributes, including the pixel data). A single DICOM object can have only one attribute containing pixel data. For many modalities, this corresponds to a single 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 a multi-dimensional multi-frame image. In these cases, three- or four-dimensional data can be encapsulated in a single DICOM object. Pixel data can be compressed using a variety of standards, including JPEG, JPEG Lossless, JPEG 2000, and Run-length encoding (RLE). LZW (zip) compression can be used for the whole data set (not just the pixel data), but this has rarely been implemented.
DICOM uses three different 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.1 of Part 5 of the DICOM Standard.
The same basic format is used for all applications, including network and file usage, but when written to a file, usually a true "header" (containing copies of a few key attributes and details of the application which wrote it) is added.
To promote identical grayscale image display on different monitors and consistent hard-copy images from various printers, the DICOM committee developed a lookup table to display digitally assigned pixel values. To use the DICOM grayscale standard display function (GSDF),[6] images must be viewed (or printed) on devices that have this lookup curve or on devices that have been calibrated to the GSDF curve.[7]
Extracted from Chapter 6.2 of PS 3.5-2007: Data Structure and Encoding PDF (1.43 MiB)
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 a Value Representation, each attribute also has a Value Multiplicity to indicate the number of data elements contained in the attribute. For character string value representations, if more than one data element is being encoded, the successive data elements are separated by the backslash character "\".
DICOM consists of many different services, most of which involve transmission of data over a network, and the file format below is a later and relatively minor addition to the standard.
The DICOM Store service is used to send images or other persistent objects (structured reports, etc.) to a picture archiving and communication system (PACS) or workstation.
The DICOM storage commitment service is used to confirm that an image has been permanently stored by 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., uses the confirmation from the Service Class Provider (SCP: similar to a server), an archive station for instance, to make sure that it is safe to delete the images locally.
This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system.
This enables a piece of imaging equipment (a modality) to obtain details of patients and scheduled examinations electronically, avoiding the need to type such information multiple times (and the mistakes caused by retyping).
A complementary service to Modality Worklist, this enables the modality to send a report about a performed examination including data about the images acquired, beginning time, end time, and duration of a study, dose delivered, etc. It helps give the radiology department a more precise handle on resource (acquisition station) use. Also known as MPPS, this service allows a modality to better coordinate with image storage servers by giving the server a list of objects to send before or while actually sending such objects.
The DICOM Printing service is used to send images to a DICOM Printer, normally to print an "X-Ray" film. There is a standard calibration (defined in DICOM Part 14) to help ensure consistency between various display devices, including hard copy printout.
The off-line media files correspond to Part 10 of the DICOM standard. It describes how to store medical imaging information on removable media. Except for the data set containing, for example, an image and demography, it's also mandatory to include the File Meta Information.
DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3, but this does not conform to the standard). No information must be extracted from these names (PS3.10 Section 6.2.3.2). This is a common source of problems with media created by developers who did not read the specifications carefully. This is a historical requirement to maintain compatibility with older existing systems. It also mandates the presence of a media directory, the DICOMDIR file, which provides index and summary information for all the DICOM files on the media. The DICOMDIR information provides substantially greater information about each file than any filename could, so there is less need for meaningful file names.
DICOM files typically 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 DICOM files is defined by RFC 3240 as application/dicom.
The Uniform Type Identifier type for DICOM files is org.nema.dicom.
There is also an ongoing media exchange test and "connectathon" process for CD media and network operation that is organized by the IHE organization. MicroDicom is free Windows software for reading DICOM data.
Extracted from Chapter C.7.3.1.1.1 of PS 3.3-2011: Information Object Definitions PDF (6.51 MiB)
Modality | Description | Status |
---|---|---|
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 | |
IO | Modality of type Intra-oral Radiography | |
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 | |
OP | Modality of type Ophthalmic Photography | |
OPM | Modality of type Ophthalmic Mapping | |
OPR | Modality of type Ophthalmic Refraction | |
OPV | Modality of type Ophthalmic Visual Field | |
OT | Modality of type Other | |
PT | Modality of type Positron Emission Tomography (PET) | |
PX | Modality of type Panoramic X-Ray | |
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 | |
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 have reserved the following TCP and UDP port numbers by the Internet Assigned Numbers Authority (IANA):
The standard recommends but does not require the use of these port numbers.
According to a paper presented at an international symposium in 2008, the DICOM standard has problems related to data entry. "A major disadvantage of the DICOM Standard is the possibility for entering probably too many optional fields. This disadvantage is mostly showing in inconsistency of filling all the fields with the data. Some image objects are often incomplete because some fields are left blank and some are filled with incorrect data."[8]
DICOM is a standard for handling, storing, printing, and transmitting information in medical imaging. The communication protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between two entities that are capable of receiving image and patient data in DICOM format. The National Electrical Manufacturers Association (NEMA) holds the copyright to this standard. It was developed by the DICOM Standards Committee, whose members are also partly members of NEMA.[9]
This article contains content that is written like an advertisement. Please help improve it by removing promotional content and inappropriate external links, and by adding encyclopedic content written from a neutral point of view. (December 2014) |
Health Level Seven (HL7), is a non-profit organization involved in the development of international healthcare informatics interoperability standards.[1] "HL7" also refers to some of the specific standards created by the organization (e.g., HL7 v2.x, v3.0, HL7 RIM). The HL7 Strategic Initiatives document is a business plan for our products and services and was designed specifically to meet the business needs of its members and stakeholders. Derived from collaborative efforts with its members, government and non-government agencies and other standards development organizations, the Strategic Initiatives are five high-level organizational strategies that are supported by a detailed tactical plan with clearly defined objectives, milestones, and metrics for success.[10]
Both of the standards are focused on the data exchange and the data compatibility. Among many standards for the syntax, HL7 and DICOM are most successful. However, everything could not be handled by HL7 solely. DICOM is good for radiology images, but, other clinical images are already handled by other ‘lighter’ data formats like JPEG, TIFF. So, it is not realistic to use only one standard for every area of clinical information.[11]
Opening the HL7 and DICOM standards in order to foster the integrated use of persistent health information objects is proposed as a step towards the creation of the health information infrastructure.[12]
Integrating the Healthcare Enterprise (IHE) was founded in 1997 by members of the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society for the purpose of improving interoperability between information systems. The IHE initiative was charged with the task of using existing standards of health care data communication such as DICOM and HL7 to improve exchange of medical information beyond the radiology department at the hospital level or health systems level. Just as radiologists were confronted in the past with imaging connectivity incompatibilities, entire health systems are continually faced with the task of connecting multiple disparate information systems in which the only reliable communications pathway is the paper printout.
The IHE working group is a panel made up of industry representatives from medical informatics and imaging vendors as well as medical professionals. Their primary focus is to develop a common information model of medical information exchange. The devised IHE technical framework consists of a common lexicon that defines specific medical information transactions using the existing standards of medical information exchange (DICOM and HL7). The specifics of these transactions have been worked out in great detail so that vendors have been free to independently develop solutions to meet the goals of the technical framework. In the year 2001 to 2002, 30 companies took part in the testing and implementation of the IHE demonstrations.[13]
.dic
/ .dicom
for MIME type application/dicom
[14]
|
|
全文を閲覧するには購読必要です。 To read the full text you will need to subscribe.
リンク元 | 「医用画像規格」 |
関連記事 | 「DIC」 |
.