DICOM: Difference between revisions
(549 intermediate revisions by more than 100 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Open standard from the medical computer science}} |
|||
[[File:Corta transversal PET TAC keosys.JPG|thumb|A nuclear medicine image in Dicom format]] |
|||
'''Digital Imaging and Communications in Medicine''' ('''DICOM''') is a [[technical standard]] for the digital storage and [[Medical image sharing|transmission of medical images]] and related information.<ref>{{cite web|url=http://dicom.nema.org/medical/dicom/current/output/chtml/part01/chapter_1.html#sect_1.1|title=1 Scope and Field of Application|website=dicom.nema.org}}</ref> It includes a [[file format]] definition, which specifies the structure of a '''DICOM file''', as well as a network [[communication protocol]] that uses [[Internet protocol suite|TCP/IP]] to communicate between systems. The primary purpose of the standard is to facilitate communication between the [[software]] and [[Computer hardware|hardware]] entities involved in [[medical imaging]], especially those that are created by different manufacturers. Entities that utilize DICOM files include components of [[Picture archiving and communication system|picture archiving and communication systems (PACS)]], such as [[Modality (medical imaging)|imaging machines (modalities)]], [[Radiological information system|radiological information systems (RIS)]], [[Image scanner|scanners]], [[Printer (computing)|printers]], [[Server (computing)|computing servers]], and [[networking hardware]]. |
|||
'''D'''igital '''I'''maging and '''Co'''mmunications in '''M'''edicine ('''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.<ref>[http://medical.nema.org/dicom/geninfo/Brochure.pdf DICOM brochure]</ref> It was developed by the ''DICOM Standards Committee'', whose members<ref>[http://medical.nema.org/members.pdf MEMBERS of the DICOM STANDARDS COMMITTEE]</ref> are also partly members of NEMA.<ref>[http://www.nema.org/about/members/ NEMA Members]</ref> |
|||
The DICOM standard has been widely adopted by [[hospital]]s and the [[medical software]] industry, and is sometimes used in smaller-scale applications, such as dentists' and doctors' offices. |
|||
The [[National Electrical Manufacturers Association]] (NEMA) holds the copyright to the published standard,<ref>[http://medical.nema.org/dicom/geninfo/Brochure.pdf DICOM brochure], nema.org.</ref> which was developed by the DICOM Standards Committee (which includes some NEMA members.<ref>{{Cite web|url=http://medical.nema.org/members.pdf|title=Members of the DICOM Standards Committee}}</ref><ref>{{Cite web|url=http://www.nema.org/About/Pages/Members.aspx|title=NEMA Members – NEMA|last=NEMA|website=www.nema.org|access-date=2016-09-15|archive-url=https://web.archive.org/web/20160901105441/http://www.nema.org/About/Pages/Members.aspx|archive-date=2016-09-01|url-status=dead}}</ref> It is also known as [[National Electrical Manufacturers Association|NEMA]] standard PS3, and as [[ISO standard]] 12052:2017: ''"Health informatics – Digital imaging and communication in medicine (DICOM) including workflow and data management"''. |
|||
==Parts of the DICOM Standard== |
|||
==Applications== |
|||
The DICOM standard is divided into related but independent parts:<ref>{{cite book | year=2006 | title=Digital Imaging and Communications in Medicine (DICOM) Part 1: Introduction and Overview | chapter=6.1 DIMSE Services | pages=11 | publisher=National Electrical Manufacturers Association | chapterurl=ftp://medical.nema.org/medical/dicom/2008/08_01pu.pdf }}</ref> |
|||
DICOM is used worldwide to store, exchange, and transmit [[Medical imaging|medical images]]. DICOM has been central to the development of [[Medical imaging|modern |
|||
The links below are to the 2007 version published in December 2006 |
|||
radiological imaging]]: DICOM incorporates standards for imaging modalities such as radiography, ultrasonography, computed tomography (CT), [[magnetic resonance imaging]] (MRI), and radiation therapy. DICOM includes protocols for image exchange (e.g., via portable media such as DVDs), image compression, 3-D visualization, image presentation, and results reporting.<ref>{{cite journal |last1=Kahn |first1=Charles E. |last2=Carrino |first2=John A. |last3=Flynn |first3=Michael J. |last4=Peck |first4=Donald J. |last5=Horii |first5=Steven C. |title=DICOM and Radiology: Past, Present, and Future |journal=Journal of the American College of Radiology |date=September 2007 |volume=4 |issue=9 |pages=652–657 |doi=10.1016/j.jacr.2007.06.004 |pmid=17845973 }}</ref> |
|||
*PS 3.1: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_01pu.pdf Introduction and Overview]|241 [[Kibibyte|KiB]]<!-- application/pdf, 246976 bytes -->}} |
|||
*PS 3.2: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_02pu.pdf Conformance]|6.46 [[Mebibyte|MiB]]<!-- application/pdf, 6779397 bytes -->}} |
|||
*PS 3.3: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_03pu.pdf Information Object Definitions]|4.48 [[Mebibyte|MiB]]<!-- application/pdf, 4703812 bytes -->}} |
|||
*PS 3.4: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_04pu.pdf Service Class Specifications]|1.07 [[Mebibyte|MiB]]<!-- application/pdf, 1123043 bytes -->}} |
|||
*PS 3.5: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_05pu.pdf Data Structure and Encoding]|1.43 [[Mebibyte|MiB]]<!-- application/pdf, 1500997 bytes -->}} |
|||
*PS 3.6: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_06pu.pdf Data Dictionary]|7.32 [[Mebibyte|MiB]]<!-- application/pdf, 7684079 bytes -->}} |
|||
*PS 3.7: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_07pu.pdf Message Exchange]|1.97 [[Mebibyte|MiB]]<!-- application/pdf, 2067816 bytes -->}} |
|||
*PS 3.8: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_08pu.pdf Network Communication Support for Message Exchange]|901 [[Kibibyte|KiB]]<!-- application/pdf, 923233 bytes -->}} |
|||
*PS 3.9: Retired (formerly Point-to-Point Communication Support for Message Exchange) |
|||
*PS 3.10: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_10pu.pdf Media Storage and File Format for Data Interchange]|406 [[Kibibyte|KiB]]<!-- application/pdf, 415931 bytes -->}} |
|||
*PS 3.11: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_11pu.pdf Media Storage Application Profiles]|1.14 [[Mebibyte|MiB]]<!-- application/pdf, 1196821 bytes -->}} |
|||
*PS 3.12: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_12pu.pdf Storage Functions and Media Formats for Data Interchange]|593 [[Kibibyte|KiB]]<!-- application/pdf, 607418 bytes -->}} |
|||
*PS 3.13: Retired (formerly Print Management Point-to-Point Communication Support) |
|||
*PS 3.14: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_14pu.pdf Grayscale Standard Display Function]|2.88 [[Mebibyte|MiB]]<!-- application/pdf, 3019941 bytes -->}} |
|||
*PS 3.15: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_15pu.pdf Security and System Management Profiles]|1.00 [[Mebibyte|MiB]]<!-- application/pdf, 1052005 bytes -->}} |
|||
*PS 3.16: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_16pu.pdf Content Mapping Resource]|3.08 [[Mebibyte|MiB]]<!-- application/pdf, 3231484 bytes -->}} |
|||
*PS 3.17: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_17pu.pdf Explanatory Information]|3.28 [[Mebibyte|MiB]]<!-- application/pdf, 3444552 bytes -->}} |
|||
*PS 3.18: {{PDFlink|[ftp://medical.nema.org/medical/dicom/2008/08_18pu.pdf Web Access to DICOM Persistent Objects (WADO)]|291 [[Kibibyte|KiB]]<!-- application/pdf, 298042 bytes -->}} |
|||
==History== |
== History == |
||
[[ |
[[File:Acrnema1.jpg|thumb|Front page of ACR/NEMA 300, version 1.0, which was released in 1985]] |
||
DICOM is the third version of a standard developed by [[American College of Radiology]] (ACR) and [[National Electrical Manufacturers Association]] (NEMA). |
|||
DICOM is a standard developed by [[American College of Radiology]] (ACR) and [[National Electrical Manufacturers Association]] (NEMA). |
|||
In the beginning of the 1980s it was almost impossible for anyone other than manufacturers of [[computed tomography]] or [[magnetic resonance imaging]] devices to decode the images that the machines generated. Radiologists 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 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 collaborated and formed a standard committee in 1983. Their first standard, ACR/NEMA 300, entitled "Digital Imaging and Communications", 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 25 differential (EIA-485) pair cable. 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). |
|||
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 [http://www.ncbi.nlm.nih.gov/pubmed/7612705?dopt=Abstract MDIS (Medical Diagnostic Imaging Support)] program run out of Ft. Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying the first US military [[Picture archiving and communication system|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. |
|||
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)<ref>{{cite journal |last1=Smith |first1=D. V. |last2=Smith |first2=S. |last3=Bender |first3=G. N. |last4=Carter |first4=J. R. |last5=Kim |first5=Y. |last6=Cawthon |first6=M. A. |last7=Leckie |first7=R. G. |last8=Weiser |first8=J. C. |last9=Romlein |first9=J. |last10=Goeringer |first10=F. |title=Evaluation of the Medical Diagnostic Imaging Support system based on 2 years of clinical experience |journal=Journal of Digital Imaging |date=May 1995 |volume=8 |issue=2 |pages=75–87 |doi=10.1007/BF03168130 |pmid=7612705 |doi-access=free }}</ref> program based at Ft. Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying the first US military [[Picture archiving and communication system|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 from this contract.{{citation needed|date=December 2018}} |
|||
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". |
|||
In 1993 the third version of the standard was released. Its name was then changed to "Digital Imaging and Communications in Medicine", abbreviated DICOM. New service classes were defined, network support added and the Conformance Statement was introduced. Initially the DICOM standard was referred to as "DICOM 3.0" to distinguish it from its predecessors.<ref>{{cite journal |last1=Best |first1=David E. |last2=Horii |first2=Steven C. |last3=Bennett |first3=William C. |last4=Parisot |first4=Charles R. |editor-first1=R. Gilbert |editor-last1=Jost |title=Update of the ACR-NEMA digital imaging and communications in medicine standard |journal=Medical Imaging VI: Pacs Design and Evaluation |date=1 July 1992 |volume=1654 |pages=356–361 |doi=10.1117/12.60322 |bibcode=1992SPIE.1654..356B }}</ref> DICOM has been constantly updated and extended since 1993, with the intent that changes are backward compatible, except in rare cases where the earlier specification was incorrect or ambiguous. Officially there is no "version" of the standard except the current standard, hence the "3.0" version number is no longer used. There are no "minor" versions to the standard (e.g., no such thing as "DICOM 3.1") and there are no current plans to develop a new, incompatible, version of the standard (i.e., no "DICOM 4.0"). The standard should be referenced without specification of the date of release of a particular published edition,<ref>{{Cite web|url=http://dicom.nema.org/medical/dicom/current/output/chtml/part01/chapter_7.html|title=7 Referencing The DICOM Standard|website=dicom.nema.org}}</ref> except when specific conformance requirements are invoked that depend on a retired feature that is no longer documented in the current standard.<ref>{{Cite web|url=http://dicom.nema.org/medical/dicom/current/output/chtml/part01/sect_1.4.2.html|title=1.4.2 Continuous Maintenance|website=dicom.nema.org}}</ref> |
|||
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 [[IHE|Integrating the Healthcare Enterprise (IHE)]] initiative layered on top of DICOM (and [[HL7|HL-7]]) provides this final piece of the medical imaging interoperability puzzle. |
|||
While the DICOM standard has achieved a near universal level of acceptance among 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. The [[Integrating the Healthcare Enterprise|Integrating the Healthcare Enterprise (IHE)]] initiative layered on top of DICOM (and [[HL7|HL-7]]) defines profiles to select features from these standards to implement transactions for specific medical imaging interoperability use cases. |
|||
---- |
|||
Though always Internet compatible and based on transport over [[Transmission Control Protocol|TCP]], over time there has been an increasing need to support port 80 [[Hypertext Transfer Protocol|HTTP]] transport to make use easier within the web browser. Most recently, a family of DICOM [[Representational state transfer|REST]]ful web services have been defined to allow mobile device friendly access to DICOM objects and services, which include WADO-RS, STOW-RS and QIDO-RS, which together constitute the [[DICOMweb]] initiative. |
|||
==DICOM Data Format== |
|||
[[Image:Knie mr.jpg|left|200px|A knee examined via [[magnetic resonance imaging]].]] |
|||
DICOM differs from other data formats in that it groups information into [[data set]]s. 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. |
|||
=== Derivations === |
|||
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 only contain 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|Run-length encoding (RLE)]]. [[LZW]] (zip) compression can be used for the whole data set (not just the pixel data) but this is rarely implemented. |
|||
There are some derivations from the DICOM standard into other application areas. These include [[DICONDE]] (''Digital Imaging and Communication in Nondestructive Evaluation'') that was established in 2004 by [[ASTM International]] as a way for [[nondestructive testing]] manufacturers and users to share image data.<ref>{{cite web|url=https://www.astm.org/SNEWS/OCTOBER_2003/voelker_oct03.html|title=ASTM DICONDE Standard|website=www.astm.org|access-date=2018-12-21|archive-date=2019-04-06|archive-url=https://web.archive.org/web/20190406132524/https://www.astm.org/SNEWS/OCTOBER_2003/voelker_oct03.html|url-status=dead}}</ref> DICONDE can be used for [[Photostimulated luminescence|computed radiography]],<ref>{{cite web|url=https://www.astm.org/e2738-18.html|title=ASTM E2738-18 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Computed Radiography (CR) Test}}</ref> [[digital radiography]],<ref>{{cite web|url=https://www.astm.org/e2699-20.html|title=ASTM E2699-20 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Digital Radiographic (DR) Test Methods}}</ref> [[computed tomography]],<ref>{{cite web|url=https://www.astm.org/e2767-21.html|title=ASTM E2767-21 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for X-ray Computed Tomography (CT) Test Methods}}</ref> [[ultrasonic testing]],<ref>{{cite web|url=https://www.astm.org/e2663-23.html|title=ASTM E2663-23 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Ultrasonic Test Methods}}</ref> and [[Eddy-current testing]].,<ref>{{cite web|url=https://www.astm.org/e2934-23.html|title=ASTM E2934-23 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Eddy Current (EC) Test Methods}}</ref> |
|||
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. |
|||
DICOS (''Digital Imaging and Communication in Security'') that was established in 2009 to be used for image sharing in [[airport security]].<ref>{{cite web|url=http://www.nema.org/prod/security/indust-Img.cfm|title=http://www.nema.org: Industrial Imaging and Communications Section|access-date=2010-02-11|archive-url=https://web.archive.org/web/20100515113502/http://www.nema.org/prod/security/indust-Img.cfm|archive-date=2010-05-15|url-status=dead}}</ref> |
|||
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. |
|||
---- |
|||
== Data format == |
|||
==DICOM Value Representations== |
|||
{{Infobox file format |
|||
| name = DICOM |
|||
| icon = |
|||
| extension = {{code|.dcm}}<ref name="nemak12">{{cite web |url=https://dicom.nema.org/medical/dicom/current/output/html/part12.html#sect_K.1.2 |title=K.1.2: DICOM File |work=DICOM PS3.12 2023b - Media Formats and Physical Media for Media Interchange |date=2023 |institution=NEMA}}</ref> |
|||
| mime = application/dicom<ref name="nemak12"/> |
|||
| type code = |
|||
| uniform type = org.nema.dicom<ref name="nemak12"/> |
|||
| magic = |
|||
| owner = |
|||
| genre = |
|||
| container for = |
|||
| contained by = |
|||
| extended from = |
|||
| extended to = |
|||
| standard = |
|||
}} |
|||
DICOM groups information into [[data set]]s. For example, a file of a chest x-ray image may contain 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 [[Exchangeable image file format|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, being 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. However, 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]], [[lossless JPEG]], [[JPEG 2000]], and [[Run-length encoding|run-length encoding (RLE)]]. [[Lempel–Ziv–Welch|LZW]] (zip) compression can be used for the whole data set (not just the pixel data), but this has rarely been implemented. |
|||
Extracted from Chapter 6.2 of |
|||
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{{clarify|date=May 2020}}, 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. |
|||
*PS 3.5: {{PDFlink|[http://medical.nema.org/dicom/2007/07_05pu.pdf Data Structure and Encoding]|1.43 [[Mebibyte|MiB]]<!-- application/pdf, 1500997 bytes -->}} |
|||
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 that wrote it) is added. |
|||
{|border="1" cellpadding="5" cellspacing="0" |
|||
|- |
|||
!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 |
|||
|} |
|||
== Image display == |
|||
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 "\". |
|||
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)''',<ref>http://medical.nema.org/Dicom/2011/11_14pu.pdf{{full citation needed|date=August 2020}}</ref> images must be viewed (or printed) on devices that have this lookup curve or on devices that have been calibrated to the GSDF curve.<ref>{{cite journal |last1=Shiroma |first1=Jonathan T. |title=An introduction to DICOM |journal=Veterinary Medicine |date=December 2006 |pages=19–20 |id={{ProQuest|195482647}} }}</ref> |
|||
== Value representations == |
|||
==DICOM Services== |
|||
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 "\".<ref>See [http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html#table_6.2-1 Table 6.2-1 of PS 3.5]</ref> |
|||
== Services == |
|||
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. |
|||
DICOM consists of services, most of which involve transmission of data over a network. The file format for offline media is a later addition to the standard. |
|||
===Store=== |
=== Store === |
||
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. |
|||
=== Storage commitment === |
|||
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–server model|client]]), a modality or workstation, etc., uses the confirmation from the Service Class Provider (SCP: similar to a [[Client–server model|server]]), an archive station for instance, to make sure that it is safe to delete the images locally. |
|||
=== |
=== Query/retrieve === |
||
This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system. |
|||
=== Modality worklist === |
|||
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-server|client]]), a modality or workstation, etc., uses the confirmation from the Service Class Provider (SCP - similar to a [[Client-server|server]]), an archive station for instance, to make sure that it is safe to delete the images locally. |
|||
The DICOM modality worklist service provides a list of imaging procedures that have been scheduled for performance by an image acquisition device (sometimes referred to as a modality system). The items in the worklist include relevant details about the subject of the procedure (patient ID, name, sex, and age), the type of procedure (equipment type, procedure description, procedure code) and the procedure order (referring physician, [[Accession number (bioinformatics)|accession number]], reason for exam). An image acquisition device, such as a CT scanner, queries a service provider, such as a [[Radiological information system|RIS]], to get this information which is then presented to the system operator and is used by the imaging device to populate details in the image metadata. |
|||
Prior to the use of the DICOM modality worklist service, the scanner operator was required to manually enter all the relevant details. Manual entry is slower and introduces the risk of misspelled patient names, and other data entry errors. |
|||
===Query/Retrieve=== |
|||
=== Modality performed procedure step === |
|||
This enables a workstation to find lists of images or other such objects and then retrieve them from a [[Picture archiving and communication system|PACS]]. |
|||
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. |
|||
=== |
=== Print === |
||
The DICOM print 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. |
|||
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). |
|||
=== |
=== Offline media (files) === |
||
The format for offline media files is specified in Part 10 of the DICOM Standard. Such files are sometimes referred to as "Part 10 files". |
|||
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. |
|||
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. |
|||
DICOM files typically have a .dcm file extension if they are not part of a DICOM media (which requires them to be without extension). |
|||
===Printing=== |
|||
The [[MIME]] type for DICOM files is defined by RFC 3240 as application/dicom. |
|||
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 [[Uniform Type Identifier]] type for DICOM files is org.nema.dicom. |
|||
===Off-line Media (DICOM Files)=== |
|||
There is also an ongoing media exchange test and "connectathon" process for CD media and network operation that is organized by the [[Integrating the Healthcare Enterprise|IHE]] organization. |
|||
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. |
|||
== Application areas == |
|||
DICOM restricts the filenames on DICOM media to 8 characters (many people wrongly use 8.3, but this is not legal). No information must be extracted from these names (PS10: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 core application of the DICOM standard is to capture, store and distribute medical images. The standard also provides services related to imaging such as managing imaging procedure worklists, printing images on film or digital media like DVDs, reporting procedure status like completion of an imaging acquisition, confirming successful archiving of images, encrypting datasets, removing patient identifying information from datasets, organizing layouts of images for review, saving image manipulations and annotations, calibrating image displays, encoding ECGs, encoding CAD results, encoding structured measurement data, and storing acquisition protocols. |
|||
The DICOMDIR information provides substantially greater information about each file than any filename could, so there is less need for meaningful file names. |
|||
=== Types of equipment === |
|||
DICOM files typically have a .dcm file extension. |
|||
The DICOM information object definitions<ref>{{Cite web | url=http://dicom.nema.org/medical/dicom/current/output/chtml/part03/PS3.3.html | title=PS3.3}}</ref> encode the data produced by a wide variety of imaging device types,<ref>{{Cite web | url=http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1 | title=C.7.3 Common Series IE Modules}}</ref> including, [[CT scan|CT]] (computed tomography), [[MRI]] (magnetic resonance imaging), [[ultrasound]], [[X-ray]], [[fluoroscopy]], [[angiography]], [[mammography]], breast tomosynthesis, PET ([[positron emission tomography]]), [[single-photon emission computed tomography|SPECT]] (single-photon emission computed tomography), Endoscopy, microscopy, nd whole slide imaging, OCT (optical coherence tomography). |
|||
DICOM is also implemented by devices associated with images or imaging workflow including, [[Picture archiving and communication system|PACS]] (picture archiving and communication systems), image viewers and display stations, CAD (computer-aided detection/diagnosis systems), 3D visualization systems, clinical analysis applications, image printers, Film scanners, media burners (that export DICOM files onto CDs, DVDs, etc.), media importers (that import DICOM files from CDs, DVDs, USBs, etc.), [[Radiological information system|RIS]] (radiology information systems), VNA (vendor-neutral archives), EMR (electronic medical record) systems, and radiology reporting systems |
|||
The [[MIME]] type for DICOM files is defined by RFC 3240 as application/dicom. |
|||
=== Fields of medicine === |
|||
There is also an ongoing media exchange test and "connectathon" process for CD media and network operation that is organized by the [[Integrating the Healthcare Environment|IHE]] organization. |
|||
Many fields of medicine have a dedicated Working Group within DICOM,<ref>{{Cite web|url=http://dicom.nema.org/dicom/geninfo/Strategy.pdf|title=DICOM Strategy Document}}</ref> and DICOM is applicable to any field of medicine in which imaging is prevalent, including:, radiology, cardiology, oncology, nuclear medicine, radiotherapy, neurology, orthopedics, obstetrics, gynecology, ophthalmology, dentistry, maxillofacial surgery, dermatology, pathology, clinical trials, veterinary medicine, and medical/clinical photography |
|||
== Port numbers over IP == |
|||
==Application areas== |
|||
DICOM have reserved the following [[TCP and UDP port]] numbers by the [[Internet Assigned Numbers Authority]] (IANA): 104 [[well-known port]] for DICOM over [[Transmission Control Protocol]] (TCP) or [[User Datagram Protocol]] (UDP). Since 104 is in the reserved subset, many operating systems require special privileges to use it; |
|||
2761 [[registered port]] for DICOM using [[Integrated Secure Communication Layer]] (ISCL) over TCP or UDP; |
|||
2762 registered port for DICOM using [[Transport Layer Security]] (TLS) over TCP or UDP; |
|||
11112 registered port for DICOM using standard, open communication over TCP or UDP. |
|||
The standard recommends but does not require the use of these port numbers. |
|||
== Disadvantages== |
|||
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."<ref>{{cite conference |url=http://www.vcl.fer.hr/papers_pdf/Overview%20of%20the%20DICOM%20Standard.pdf |first1=Mario |last1=Mustra |first2=Kresimir |last2=Delac |first3=Mislav |last3=Grgic |date=September 2008 |title=Overview of the DICOM Standard |conference=ELMAR, 2008. 50th International Symposium |location=Zadar, Croatia |isbn=978-1-4244-3364-3 |pages=39–44}}</ref> |
|||
Another disadvantage is that the file format admits executable code and may contain [[malware]].<ref>{{ cite web | url = https://labs.cylera.com/2019/04/16/pe-dicom-medical-malware/ | title = HIPAA-Protected Malware? Exploiting DICOM Flaw to Embed Malware in CT/MRI Imagery | access-date = 23 April 2019 | date = 16 April 2019 | website = Cylera Labs | quote = A weakness in the DICOM image format enables malware to infect patient data by directly inserting itself into medical imaging files. These hybrid files are both fully-executable malware binaries and fully-functioning, standards-compliant DICOM images that preserve the original patient data and can be used by clinicians without arousing suspicion. | archive-url = https://web.archive.org/web/20190423094606/https://labs.cylera.com/2019/04/16/pe-dicom-medical-malware/ | archive-date = 23 April 2019 | df = dmy-all }}</ref> |
|||
{|border="1" cellpadding="5" cellspacing="0" |
|||
|- |
|||
!Modality |
|||
!Description |
|||
|- |
|||
|BI |
|||
|Modality of type Biomagnetic Imaging |
|||
|- |
|||
|CD |
|||
|Modality of type Color Flow Doppler-Retired 2008 |
|||
|- |
|||
|CR |
|||
|Modality of type Computed Radiography |
|||
|- |
|||
|CT |
|||
|Modality of type Computed Tomography |
|||
|- |
|||
|DD |
|||
|Modality of type Duplex Doppler-Retired 2008 |
|||
|- |
|||
|DG |
|||
|Modality of type Diaphangraphy |
|||
|- |
|||
|EC |
|||
|Modality of type Echo cardiography - Retired |
|||
|- |
|||
|EM |
|||
|Modality of type Electron Microscope |
|||
|- |
|||
|ES |
|||
|Modality of type Endoscopy |
|||
|- |
|||
|GM |
|||
|Modality of type General Microscopy |
|||
|- |
|||
|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 |
|||
|- |
|||
|RF |
|||
|Modality of type Radio Fluoroscopy |
|||
|- |
|||
|RG |
|||
|Modality of type Radiographic Imaging (conventional film screen) |
|||
|- |
|||
|RT |
|||
|Modality of type Radiation Therapy |
|||
|- |
|||
|SC |
|||
|Modality of type Secondary Capture |
|||
|- |
|||
|SM |
|||
|Modality of type Slide Microscopy |
|||
|- |
|||
|ST |
|||
|Modality of type Single-Photon Emission Computed Tomography - Retired 2008 |
|||
|- |
|||
|TG |
|||
|Modality of type Thermography |
|||
|- |
|||
|US |
|||
|Modality of type Ultra Sound |
|||
|- |
|||
|VL |
|||
|Modality of type Visible Light |
|||
|- |
|||
|XA |
|||
|Modality of type X-Ray Angiography |
|||
|- |
|||
|XC |
|||
|Modality of type External Camera (Photography) |
|||
|} |
|||
== Related standards and SDOs == |
|||
[[DVTk]] is an Open Source project for testing, validating and diagnosing communication protocols and scenarios in medical environments. It supports DICOM, HL7 and IHE integration profiles. |
|||
[[HL7|Health Level 7]] is a non-profit organization involved in the development of international healthcare informatics interoperability standards. HL7 and DICOM manage a joint Working Group to harmonize areas where the two standards overlap and address imaging integration in the electronic medical record. |
|||
Examples of [[Modality|Modalities]] supported in DICOM are: |
|||
*AS = [[Angioscopy]]-Retired |
|||
*BI = [[Biomagnetic Imaging]] |
|||
*CD = [[Color Flow Doppler]]-Retired |
|||
*CF = [[Cinefluorography]] (retired) |
|||
*CP = [[Colposcopy]] Retired |
|||
*CR = [[Computed radiography|Computed Radiography]] |
|||
*CS = [[Cystoscopy]]Retired |
|||
*CT = [[Computed Tomography]] |
|||
*DD = [[Duplex Doppler]] Retired |
|||
*DF = [[Digital Fluoroscopy]] (retired) |
|||
*DG = [[Diaphanography]] |
|||
*DM = [[Digital Microscopy]] |
|||
*DS = [[Digital subtraction angiography|Digital Subtraction Angiography]] Retired |
|||
*DX = [[Digital X-Ray]] |
|||
*EC = [[Echocardiography]] Retired |
|||
*ES = [[Endoscopy]] |
|||
*FA = [[Fluorescein angiography|Fluorescein Angiography]] Retired |
|||
*FS = [[Fundoscopy]] Retired |
|||
*HC = Hard Copy |
|||
*LP = [[Laparoscopy]] Retired |
|||
*LS = [[Laser Surface Scan]] |
|||
*MA = [[Magnetic resonance angiography]] Retired |
|||
*MG = [[Mammography]] |
|||
*MR = [[Magnetic Resonance Imaging|Magnetic Resonance]] |
|||
*MS = [[Magnetic Resonance Spectroscopy]] Retired |
|||
*NM = [[Nuclear Medicine]] |
|||
*OT = Other |
|||
*PT = [[Positron Emission Tomography]] (PET) |
|||
*RF = [[Fluoroscopy|Radio Fluoroscopy]] |
|||
*RG = Radiographic Imaging (conventional film screen) |
|||
*RTDOSE (a.k.a. RD) = [[Radiotherapy]] Dose |
|||
*RTIMAGE = Radiotherapy Image |
|||
*RTPLAN (a.k.a. RP) = Radiotherapy Plan |
|||
*RTSTRUCT (a.k.a. RS) = Radiotherapy Structure Set |
|||
*SR = Structured Reporting |
|||
*ST = Single-photon Emission Computed Tomography Retired |
|||
*TG = [[Thermography]] |
|||
*US = [[Ultrasound]] |
|||
*VF = Videofluorography (retired) |
|||
*XA = [[Angiogram|X-Ray Angiography]] |
|||
*XC = eXternal Camera |
|||
*ECG = [[Electrocardiograms]] |
|||
[[Integrating the Healthcare Enterprise|Integrating the Healthcare Enterprise (IHE)]] is an industry sponsored non-profit organization that profiles the use of standards to address specific healthcare use cases. DICOM is incorporated in a variety of imaging related IHE profiles.<ref>{{cite web|url=https://wiki.ihe.net/index.php/Profiles|title=Profiles – IHE Wiki|website=wiki.ihe.net}}</ref><ref>Flanders, A.E., Carrino, J.A., 2003. Understanding DICOM and IHE. Seminars in Roentgenology 38, 270–281.</ref> |
|||
== Dicom Software == |
|||
[[Systematized Nomenclature of Medicine]] (SNOMED) is a systematic, computer-processable collection of medical terms, in human and veterinary medicine, to provide codes, terms, synonyms and definitions which cover anatomy, diseases, findings, procedures, microorganisms, substances, etc. DICOM data makes use of SNOMED to encode relevant concepts. |
|||
=== Free software === |
|||
[[XnView]] supports <code>.dic</code> / <code>.dicom</code> for [[MIME]] type <code>application/dicom</code><ref>{{cite IETF |title=Digital Imaging and Communications in Medicine (DICOM) – Application/dicom MIME Sub-type Registration |rfc=3240 |last1=Clunie |first1=D. |last2=Cordonnier |first2=K. |date=February 2002 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=2014-03-02}}</ref> |
|||
* [http://www.mytrialwire.com Trial Wire] - free, web-based tool to transfer, de-identify and organize DICOM data |
|||
* [[GDCM]] - Grass root dicom. Image but no network support. |
|||
* [http://dicom.offis.de/dcmtk dcmtk] - DICOM Toolkit. DICOM protocol client. |
|||
* [[OsiriX]] - A Dicom viewer and Dicom protocol client for MacOS |
|||
* [http://www.dcm4che.org/ dcm4che] - A java implementation of the DICOM standard that includes a [[PACS]] server. |
|||
* [http://puntoexe.com/content/view/11/2/ Imebra] - GPL and commercial versions. Image support, but no network support. |
|||
* [http://sourceforge.net/projects/dicom-cs/ dicom-cs] - A rewrite of dcm4che in C#. |
|||
* [http://opendicom.sourceforge.net/ OpenDicom] - Another C# library in early stages of development. |
|||
* [http://www.dvtk.org/modules/wiwimod/index.php?page=DVTk&cmenu=home DVTk] - A testing framework for Dicom servers. |
|||
* [[ImageVis3D]] - An open source volume visualization tool with DICOM reading capabilities |
|||
* [http://code.google.com/p/pydicom/ pydicom] - A DICOM library for [[Python_(programming_language)|Python]] |
|||
* [http://dicom.rubyforge.org/ ruby-dicom] - A DICOM library for [[Ruby_(programming_language)|Ruby]] |
|||
* [http://dicom.online.fr/ DicomWorks] - Free DICOM viewer for Windows |
|||
* [http://www.sph.sc.edu/comd/rorden/mricro.html MRIcro] - Free DICOM viewer for Windows and Linux |
|||
* [http://www.sph.sc.edu/comd/rorden/ezdicom.html ezDICOM Software] - Free DICOM viewer for Windows |
|||
* [http://www.e-dicom.com/ Agnosco DICOM viewer] - Freeware DICOM viewer for Windows |
|||
* [http://www.irfanview.com/ Irfanview] - A popular freeware image viewer for Windows. A plug-in is available for viewing 8-bit DICOM images. |
|||
* [http://rsb.info.nih.gov/ij/ ImageJ] - freeware Java-based DICOM viewer |
|||
* [http://www.microdicom.com MicroDicom] - Free DICOM viewer for Windows |
|||
== Standards used by DICOM == |
|||
=== Commercial === |
|||
The best known standards and protocols used by DICOM are:<ref name="auto">{{Cite web|url=https://www.dicomstandard.org/|title=DICOM|website=DICOM}}</ref> |
|||
* [http://www.aware.com/imaging/medicalimaging.htm Aware, Inc. SDKs for DICOM] compression, streaming, and viewing of medical image data. |
|||
*DICOM Makes use of the OSI network model. It uses the 2 network protocols on which the Internet is based and which allow data transfer, [[Transmission Control Protocol|TCP]] / [[Internet Protocol|IP]], and the [[HTTP]] hypertext transfer protocol. Additionally DICOM has its own [[MIME]] content type. |
|||
* [http://www.leadtools.com/SDK/Medical/Medical-Addon-DICOM-PACS.htm LEADTOOLS DICOM PACS Framework] |
|||
*DICOM uses other protocols such as [[DHCP]], SAML ... |
|||
* [http://www.merge.com/fusion/index.asp Merge eFilm] - Libraries, client, viewer, server solutions. |
|||
*DICOM makes use of a coding system called [[SNOMED CT]] that is based on medical and clinical terms. |
|||
* [http://www.pacsdrive.com/ PacsDrive DICOM Archiving] |
|||
*DICOM uses an external alphabet known as [[LOINC]]. |
|||
* [http://www.dicomlab.com DICOMLAB] - Feature-rich DICOM framework focused on performance. |
|||
*In the case of breast images, use is made of other types of structured files known as [[BI-RADS]]. |
|||
== Standards that use DICOM == |
|||
The DICOM standard is used in a wide variety of resources (IHE, HL7 ... a) that are related to images. |
|||
The ISO12052: 2017 and CEN 12052 standards refer to the DICOM standard.<ref name="auto"/> |
|||
== Security == |
|||
In December 2023, cybersecurity researcher Sina Yazdanmehr unveiled a critical security issue within the Store service. This revelation, presented at [[Black Hat Briefings]], demonstrated the potential for malicious actors to manipulate existing series of medical images. Yazdanmehr's research highlighted the alarming capability of attackers to destroy a series of images or introduce misleading indicators of illness.<ref>{{cite web|url=https://i.blackhat.com/EU-23/Presentations/EU-23-Yazdanmehr-Millions_of_Patient_Records_at_Risk.pdf|title=Millions of Patient Records at Risk: The Perils of Legacy Protocols|website=i.blackhat.com}}</ref><ref>{{cite web|url=https://techcrunch.com/2023/12/06/medical-scans-health-records-dicom-pacs-security/|title=Millions of patient scans and health records spilling online thanks to decades-old protocol bug|website=techcrunch.com|date=6 December 2023 }}</ref> |
|||
Ensuring the security of patient data within DICOM is critical, as these files often contain sensitive personal health information (PHI). Security measures for DICOM data include encryption, access control, and auditing mechanisms to prevent unauthorized access, modification, or disclosure of patient information. Compliance with regulations such as the Health Insurance Portability and Accountability Act ([[Health Insurance Portability and Accountability Act|HIPAA]]) in the United States and the General Data Protection Regulation ([[General Data Protection Regulation|GDPR]]) in Europe is essential for protecting patient privacy and ensuring the integrity of medical records. |
|||
=== De-identification of DICOM === |
|||
De-identification of DICOM refers to the process of removing or anonymizing personal health information (PHI) from medical images to protect patient privacy. This process is vital for sharing medical data for research, educational purposes, or public health activities while complying with privacy regulations. Techniques for de-identification involve stripping out or masking identifiable data elements within the DICOM metadata, such as patient names, birth dates, and other unique identifiers. Ensuring thorough de-identification is crucial to balance the benefits of data sharing with the obligation to maintain patient confidentiality.<ref>{{cite web|url=https://apicom.pro/dicom-de-identification/|title=DICOM De-identification/Anonymization: Protecting Patient Privacy in Medical Imaging}}</ref> |
|||
== See also == |
== See also == |
||
* [[3DSlicer]] – a free, open source software package for image analysis and scientific visualization, with the integrated support of components of DICOM standard. |
|||
*[[DICOM Conformance statement]] |
|||
* [[Ambra Health]] – offers a free web-based DICOM Viewer |
|||
*[[DICOM Data dictionary]] |
|||
* [[Amira (software)|Amira]] |
|||
*[[DICOM Media Storage Application Profile]] |
|||
* [[CinePaint]] |
|||
*[[DICOM Security profile]] |
|||
* [[GIMP]] |
|||
*[[DICOM Service class]] |
|||
* [[Ginkgo CADx]] – cross-platform DICOM viewer. |
|||
*[[DICOM Service Object Pair]] |
|||
* [[IDL (programming language)|IDL]] – often used to view medical images |
|||
* [[ImageJ]] |
|||
* [[InVesalius]] – free, open source software that can be used to view DICOM images and transform DICOM image stacks to 3D models and export them to .STL |
|||
* [[IrfanView]] |
|||
* [[MicroDicom]] – free DICOM viewer for [[Microsoft Windows|Windows]]. |
|||
* [[Noesis (software)|Noesis]] – free DICOM importer and exporter with 3D visualization for [[Microsoft Windows|Windows]]. |
|||
* [[OsiriX]] – commercial image processing application dedicated to DICOM images. |
|||
* [[Orthanc (software)|Orthanc]] – lightweight, [[RESTful]] DICOM store. |
|||
* [[Studierfenster|Studierfenster (StudierFenster)]] – free, non-commercial Open Science client/server-based Medical Imaging Processing (MIP) online framework |
|||
== References == |
== References == |
||
{{reflist}} |
|||
<references/> |
|||
== External links == |
== External links == |
||
* [ |
* [http://medical.nema.org/standard.html DICOM standard], NEMA. |
||
* [http://medical.nema.org/ DICOM Homepage - NEMA] |
|||
* [http://www.dclunie.com/dicom-status/status.html DICOM Standard Status (approved and proposed changes)] |
|||
* [http://www.sph.sc.edu/comd/rorden/dicom.html Brief introduction to DICOM] |
|||
* [http://www.dclunie.com/medical-image-faq/html/part8.html Medical Image FAQ part 8] - Contains a long list DICOM software. |
|||
* [http://www.mytrialwire.com Trial Wire] - Free DICOM tool to transfer and anonymize DICOM files. Provides an audit trail for HIPAA Compliance |
|||
* [http://www.ms-technology.com/medical-solutions/sure-vista-vision.html SureVistaVision] - Multi-platform DICOM viewer. |
|||
* [http://www.osirix-viewer.com OsiriX] - OsiriX Open Source DICOM Viewer |
|||
{{Health informatics}} |
|||
[[Category:Radiology]] |
|||
{{health software}} |
|||
[[Category:Medical imaging]] |
|||
{{ISO standards}} |
|||
[[Category:Network protocols]] |
|||
{{DEFAULTSORT:Dicom}} |
|||
[[bg:DICOM]] |
|||
[[Category:Application layer protocols]] |
|||
[[ca:DICOM]] |
|||
[[Category:Computing in medical imaging]] |
|||
[[de:Digital Imaging and Communications in Medicine]] |
|||
[[ |
[[Category:DICOM software]] |
||
[[Category:Standards for electronic health records]] |
|||
[[fa:دایکام]] |
|||
[[fr:Digital imaging and commmunications in medicine]] |
|||
[[ko:의료용 디지털 영상 및 통신 표준]] |
|||
[[it:DICOM]] |
|||
[[hu:Digital Imaging and Communications in Medicine]] |
|||
[[nl:DICOM]] |
|||
[[ja:DICOM]] |
|||
[[pl:DICOM]] |
|||
[[pt:DICOM]] |
|||
[[ru:DICOM]] |
|||
[[sv:Digital Imaging and Communications in Medicine]] |
|||
[[vi:DICOM]] |
|||
[[zh:DICOM]] |
Latest revision as of 02:58, 28 November 2024
Digital Imaging and Communications in Medicine (DICOM) is a technical standard for the digital storage and transmission of medical images and related information.[1] It includes a file format definition, which specifies the structure of a DICOM file, as well as a network communication protocol that uses TCP/IP to communicate between systems. The primary purpose of the standard is to facilitate communication between the software and hardware entities involved in medical imaging, especially those that are created by different manufacturers. Entities that utilize DICOM files include components of picture archiving and communication systems (PACS), such as imaging machines (modalities), radiological information systems (RIS), scanners, printers, computing servers, and networking hardware.
The DICOM standard has been widely adopted by hospitals and the medical software industry, and is sometimes used in smaller-scale applications, such as dentists' and doctors' offices.
The National Electrical Manufacturers Association (NEMA) holds the copyright to the published standard,[2] which was developed by the DICOM Standards Committee (which includes some NEMA members.[3][4] It is also known as NEMA standard PS3, and as ISO standard 12052:2017: "Health informatics – Digital imaging and communication in medicine (DICOM) including workflow and data management".
Applications
[edit]DICOM is used worldwide to store, exchange, and transmit medical images. DICOM has been central to the development of modern radiological imaging: DICOM incorporates standards for imaging modalities such as radiography, ultrasonography, computed tomography (CT), magnetic resonance imaging (MRI), and radiation therapy. DICOM includes protocols for image exchange (e.g., via portable media such as DVDs), image compression, 3-D visualization, image presentation, and results reporting.[5]
History
[edit]DICOM is 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 collaborated and formed a standard committee in 1983. Their first standard, ACR/NEMA 300, entitled "Digital Imaging and Communications", 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)[6] program based at 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 from this contract.[citation needed]
In 1993 the third version of the standard was released. Its name was then changed to "Digital Imaging and Communications in Medicine", abbreviated DICOM. New service classes were defined, network support added and the Conformance Statement was introduced. Initially the DICOM standard was referred to as "DICOM 3.0" to distinguish it from its predecessors.[7] DICOM has been constantly updated and extended since 1993, with the intent that changes are backward compatible, except in rare cases where the earlier specification was incorrect or ambiguous. Officially there is no "version" of the standard except the current standard, hence the "3.0" version number is no longer used. There are no "minor" versions to the standard (e.g., no such thing as "DICOM 3.1") and there are no current plans to develop a new, incompatible, version of the standard (i.e., no "DICOM 4.0"). The standard should be referenced without specification of the date of release of a particular published edition,[8] except when specific conformance requirements are invoked that depend on a retired feature that is no longer documented in the current standard.[9]
While the DICOM standard has achieved a near universal level of acceptance among 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. The Integrating the Healthcare Enterprise (IHE) initiative layered on top of DICOM (and HL-7) defines profiles to select features from these standards to implement transactions for specific medical imaging interoperability use cases.
Though always Internet compatible and based on transport over TCP, over time there has been an increasing need to support port 80 HTTP transport to make use easier within the web browser. Most recently, a family of DICOM RESTful web services have been defined to allow mobile device friendly access to DICOM objects and services, which include WADO-RS, STOW-RS and QIDO-RS, which together constitute the DICOMweb initiative.
Derivations
[edit]There are some derivations from the DICOM standard into other application areas. These include DICONDE (Digital Imaging and Communication in Nondestructive Evaluation) that was established in 2004 by ASTM International as a way for nondestructive testing manufacturers and users to share image data.[10] DICONDE can be used for computed radiography,[11] digital radiography,[12] computed tomography,[13] ultrasonic testing,[14] and Eddy-current testing.,[15]
DICOS (Digital Imaging and Communication in Security) that was established in 2009 to be used for image sharing in airport security.[16]
Data format
[edit]Filename extension | .dcm [17] |
---|---|
Internet media type |
application/dicom[17] |
Uniform Type Identifier (UTI) | org.nema.dicom[17] |
DICOM groups information into data sets. For example, a file of a chest x-ray image may contain 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, being 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. However, 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, lossless JPEG, 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[clarification needed], 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 that wrote it) is added.
Image display
[edit]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),[18] images must be viewed (or printed) on devices that have this lookup curve or on devices that have been calibrated to the GSDF curve.[19]
Value representations
[edit]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 "\".[20]
Services
[edit]DICOM consists of services, most of which involve transmission of data over a network. The file format for offline media is a later addition to the standard.
Store
[edit]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.
Storage commitment
[edit]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.
Query/retrieve
[edit]This enables a workstation to find lists of images or other such objects and then retrieve them from a picture archiving and communication system.
Modality worklist
[edit]The DICOM modality worklist service provides a list of imaging procedures that have been scheduled for performance by an image acquisition device (sometimes referred to as a modality system). The items in the worklist include relevant details about the subject of the procedure (patient ID, name, sex, and age), the type of procedure (equipment type, procedure description, procedure code) and the procedure order (referring physician, accession number, reason for exam). An image acquisition device, such as a CT scanner, queries a service provider, such as a RIS, to get this information which is then presented to the system operator and is used by the imaging device to populate details in the image metadata.
Prior to the use of the DICOM modality worklist service, the scanner operator was required to manually enter all the relevant details. Manual entry is slower and introduces the risk of misspelled patient names, and other data entry errors.
Modality performed procedure step
[edit]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 print 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.
Offline media (files)
[edit]The format for offline media files is specified in Part 10 of the DICOM Standard. Such files are sometimes referred to as "Part 10 files".
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.
Application areas
[edit]The core application of the DICOM standard is to capture, store and distribute medical images. The standard also provides services related to imaging such as managing imaging procedure worklists, printing images on film or digital media like DVDs, reporting procedure status like completion of an imaging acquisition, confirming successful archiving of images, encrypting datasets, removing patient identifying information from datasets, organizing layouts of images for review, saving image manipulations and annotations, calibrating image displays, encoding ECGs, encoding CAD results, encoding structured measurement data, and storing acquisition protocols.
Types of equipment
[edit]The DICOM information object definitions[21] encode the data produced by a wide variety of imaging device types,[22] including, CT (computed tomography), MRI (magnetic resonance imaging), ultrasound, X-ray, fluoroscopy, angiography, mammography, breast tomosynthesis, PET (positron emission tomography), SPECT (single-photon emission computed tomography), Endoscopy, microscopy, nd whole slide imaging, OCT (optical coherence tomography).
DICOM is also implemented by devices associated with images or imaging workflow including, PACS (picture archiving and communication systems), image viewers and display stations, CAD (computer-aided detection/diagnosis systems), 3D visualization systems, clinical analysis applications, image printers, Film scanners, media burners (that export DICOM files onto CDs, DVDs, etc.), media importers (that import DICOM files from CDs, DVDs, USBs, etc.), RIS (radiology information systems), VNA (vendor-neutral archives), EMR (electronic medical record) systems, and radiology reporting systems
Fields of medicine
[edit]Many fields of medicine have a dedicated Working Group within DICOM,[23] and DICOM is applicable to any field of medicine in which imaging is prevalent, including:, radiology, cardiology, oncology, nuclear medicine, radiotherapy, neurology, orthopedics, obstetrics, gynecology, ophthalmology, dentistry, maxillofacial surgery, dermatology, pathology, clinical trials, veterinary medicine, and medical/clinical photography
Port numbers over IP
[edit]DICOM have reserved the following TCP and UDP port numbers by the Internet Assigned Numbers Authority (IANA): 104 well-known port for DICOM over Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Since 104 is in the reserved subset, many operating systems require special privileges to use it; 2761 registered port for DICOM using Integrated Secure Communication Layer (ISCL) over TCP or UDP; 2762 registered port for DICOM using Transport Layer Security (TLS) over TCP or UDP; 11112 registered port for DICOM using standard, open communication over TCP or UDP. The standard recommends but does not require the use of these port numbers.
Disadvantages
[edit]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."[24]
Another disadvantage is that the file format admits executable code and may contain malware.[25]
Related standards and SDOs
[edit]DVTk is an Open Source project for testing, validating and diagnosing communication protocols and scenarios in medical environments. It supports DICOM, HL7 and IHE integration profiles.
Health Level 7 is a non-profit organization involved in the development of international healthcare informatics interoperability standards. HL7 and DICOM manage a joint Working Group to harmonize areas where the two standards overlap and address imaging integration in the electronic medical record.
Integrating the Healthcare Enterprise (IHE) is an industry sponsored non-profit organization that profiles the use of standards to address specific healthcare use cases. DICOM is incorporated in a variety of imaging related IHE profiles.[26][27]
Systematized Nomenclature of Medicine (SNOMED) is a systematic, computer-processable collection of medical terms, in human and veterinary medicine, to provide codes, terms, synonyms and definitions which cover anatomy, diseases, findings, procedures, microorganisms, substances, etc. DICOM data makes use of SNOMED to encode relevant concepts.
XnView supports .dic
/ .dicom
for MIME type application/dicom
[28]
Standards used by DICOM
[edit]The best known standards and protocols used by DICOM are:[29]
- DICOM Makes use of the OSI network model. It uses the 2 network protocols on which the Internet is based and which allow data transfer, TCP / IP, and the HTTP hypertext transfer protocol. Additionally DICOM has its own MIME content type.
- DICOM uses other protocols such as DHCP, SAML ...
- DICOM makes use of a coding system called SNOMED CT that is based on medical and clinical terms.
- DICOM uses an external alphabet known as LOINC.
- In the case of breast images, use is made of other types of structured files known as BI-RADS.
Standards that use DICOM
[edit]The DICOM standard is used in a wide variety of resources (IHE, HL7 ... a) that are related to images.
The ISO12052: 2017 and CEN 12052 standards refer to the DICOM standard.[29]
Security
[edit]In December 2023, cybersecurity researcher Sina Yazdanmehr unveiled a critical security issue within the Store service. This revelation, presented at Black Hat Briefings, demonstrated the potential for malicious actors to manipulate existing series of medical images. Yazdanmehr's research highlighted the alarming capability of attackers to destroy a series of images or introduce misleading indicators of illness.[30][31]
Ensuring the security of patient data within DICOM is critical, as these files often contain sensitive personal health information (PHI). Security measures for DICOM data include encryption, access control, and auditing mechanisms to prevent unauthorized access, modification, or disclosure of patient information. Compliance with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States and the General Data Protection Regulation (GDPR) in Europe is essential for protecting patient privacy and ensuring the integrity of medical records.
De-identification of DICOM
[edit]De-identification of DICOM refers to the process of removing or anonymizing personal health information (PHI) from medical images to protect patient privacy. This process is vital for sharing medical data for research, educational purposes, or public health activities while complying with privacy regulations. Techniques for de-identification involve stripping out or masking identifiable data elements within the DICOM metadata, such as patient names, birth dates, and other unique identifiers. Ensuring thorough de-identification is crucial to balance the benefits of data sharing with the obligation to maintain patient confidentiality.[32]
See also
[edit]- 3DSlicer – a free, open source software package for image analysis and scientific visualization, with the integrated support of components of DICOM standard.
- Ambra Health – offers a free web-based DICOM Viewer
- Amira
- CinePaint
- GIMP
- Ginkgo CADx – cross-platform DICOM viewer.
- IDL – often used to view medical images
- ImageJ
- InVesalius – free, open source software that can be used to view DICOM images and transform DICOM image stacks to 3D models and export them to .STL
- IrfanView
- MicroDicom – free DICOM viewer for Windows.
- Noesis – free DICOM importer and exporter with 3D visualization for Windows.
- OsiriX – commercial image processing application dedicated to DICOM images.
- Orthanc – lightweight, RESTful DICOM store.
- Studierfenster (StudierFenster) – free, non-commercial Open Science client/server-based Medical Imaging Processing (MIP) online framework
References
[edit]- ^ "1 Scope and Field of Application". dicom.nema.org.
- ^ DICOM brochure, nema.org.
- ^ "Members of the DICOM Standards Committee" (PDF).
- ^ NEMA. "NEMA Members – NEMA". www.nema.org. Archived from the original on 2016-09-01. Retrieved 2016-09-15.
- ^ Kahn, Charles E.; Carrino, John A.; Flynn, Michael J.; Peck, Donald J.; Horii, Steven C. (September 2007). "DICOM and Radiology: Past, Present, and Future". Journal of the American College of Radiology. 4 (9): 652–657. doi:10.1016/j.jacr.2007.06.004. PMID 17845973.
- ^ Smith, D. V.; Smith, S.; Bender, G. N.; Carter, J. R.; Kim, Y.; Cawthon, M. A.; Leckie, R. G.; Weiser, J. C.; Romlein, J.; Goeringer, F. (May 1995). "Evaluation of the Medical Diagnostic Imaging Support system based on 2 years of clinical experience". Journal of Digital Imaging. 8 (2): 75–87. doi:10.1007/BF03168130. PMID 7612705.
- ^ Best, David E.; Horii, Steven C.; Bennett, William C.; Parisot, Charles R. (1 July 1992). Jost, R. Gilbert (ed.). "Update of the ACR-NEMA digital imaging and communications in medicine standard". Medical Imaging VI: Pacs Design and Evaluation. 1654: 356–361. Bibcode:1992SPIE.1654..356B. doi:10.1117/12.60322.
- ^ "7 Referencing The DICOM Standard". dicom.nema.org.
- ^ "1.4.2 Continuous Maintenance". dicom.nema.org.
- ^ "ASTM DICONDE Standard". www.astm.org. Archived from the original on 2019-04-06. Retrieved 2018-12-21.
- ^ "ASTM E2738-18 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Computed Radiography (CR) Test".
- ^ "ASTM E2699-20 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Digital Radiographic (DR) Test Methods".
- ^ "ASTM E2767-21 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for X-ray Computed Tomography (CT) Test Methods".
- ^ "ASTM E2663-23 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Ultrasonic Test Methods".
- ^ "ASTM E2934-23 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation (DICONDE) for Eddy Current (EC) Test Methods".
- ^ "http://www.nema.org: Industrial Imaging and Communications Section". Archived from the original on 2010-05-15. Retrieved 2010-02-11.
- ^ a b c "K.1.2: DICOM File". DICOM PS3.12 2023b - Media Formats and Physical Media for Media Interchange. NEMA. 2023.
- ^ http://medical.nema.org/Dicom/2011/11_14pu.pdf[full citation needed]
- ^ Shiroma, Jonathan T. (December 2006). "An introduction to DICOM". Veterinary Medicine: 19–20. ProQuest 195482647.
- ^ See Table 6.2-1 of PS 3.5
- ^ "PS3.3".
- ^ "C.7.3 Common Series IE Modules".
- ^ "DICOM Strategy Document" (PDF).
- ^ Mustra, Mario; Delac, Kresimir; Grgic, Mislav (September 2008). Overview of the DICOM Standard (PDF). ELMAR, 2008. 50th International Symposium. Zadar, Croatia. pp. 39–44. ISBN 978-1-4244-3364-3.
- ^ "HIPAA-Protected Malware? Exploiting DICOM Flaw to Embed Malware in CT/MRI Imagery". Cylera Labs. 16 April 2019. Archived from the original on 23 April 2019. Retrieved 23 April 2019.
A weakness in the DICOM image format enables malware to infect patient data by directly inserting itself into medical imaging files. These hybrid files are both fully-executable malware binaries and fully-functioning, standards-compliant DICOM images that preserve the original patient data and can be used by clinicians without arousing suspicion.
- ^ "Profiles – IHE Wiki". wiki.ihe.net.
- ^ Flanders, A.E., Carrino, J.A., 2003. Understanding DICOM and IHE. Seminars in Roentgenology 38, 270–281.
- ^ Clunie, D.; Cordonnier, K. (February 2002). Digital Imaging and Communications in Medicine (DICOM) – Application/dicom MIME Sub-type Registration. IETF. doi:10.17487/RFC3240. RFC 3240. Retrieved 2014-03-02.
- ^ a b "DICOM". DICOM.
- ^ "Millions of Patient Records at Risk: The Perils of Legacy Protocols" (PDF). i.blackhat.com.
- ^ "Millions of patient scans and health records spilling online thanks to decades-old protocol bug". techcrunch.com. 6 December 2023.
- ^ "DICOM De-identification/Anonymization: Protecting Patient Privacy in Medical Imaging".
External links
[edit]- DICOM standard, NEMA.