[医疗信息化][DICOM教程]DICOM标准简介

使用OsiriX的DICOM标准简介

内容

1. 介绍
2. 什么是DICOM
3. 医院系统内的图像传输
4. 了解DICOM服务
5. OsiriX提供的DICOM服务
6. 其他DICOM服务
7. DICOM文件格式
8. DICOM结构化报告
9. 符合DICOM
10. DICOM与其他标准的互操作性
11. 结论

介绍

这是我有关DICOM标准的系列文章的一部分，并快速概述了DICOM标准。

DICOM是一种医疗保健标准，负责管理医学成像的几乎所有方面，例如图像传输，图像解释，打印管理，程序管理和离线存储，并且几乎用于与医疗保健相关的所有成像“模态”，例如磁共振，核医学，计算机断层扫描和超声检查。全世界几乎所有的临床成像工作流程都基于DICOM标准。如果您在医疗信息学行业工作或想要工作，那么学习此标准至关重要。我希望写本系列文章的目的是通过查看简短但有针对性的代码示例，帮助进入“ DICOM世界”的人们更快地学习标准的各个方面和部分。在本文中，我们将从较高的层次看待该标准的所有主要部分，本系列的文章中，我们将使用有助于将DICOM的理论与实际实现联系起来的代码示例，对这些方面的每个方面进行更详细的研究。

为了说明该标准中的许多核心概念，我决定使用一个免费可用的功能强大的工具“ OsiriX”，该工具具有许多开箱即用的DICOM功能。但是，请记住，该软件只能在Mac OS X操作系统上运行。因此，如果您正在运行其他操作系统，我深表歉意。但是，只需阅读此处的材料以及查看显示的屏幕截图，即可帮助您理解这些概念并将其应用于您选择使用的任何其他DICOM软件。另外，请记住，这不是编程教程，尽管很像我以前的HL7文章中采用的方法，

什么是DICOM

DICOM代表“医学数字成像和通信”，由美国国家电气制造商协会（NEMA）和美国放射学院（ACR）联合开发，以允许成像设备之间以及与其他设备之间的互操作性。该标准负责管理图像格式以及传输在许多与医疗保健相关的成像“方式”（例如磁共振，核医学，计算机断层扫描和超声）期间生成的医学图像信息所需的各种网络协议。自1983年以来，DICOM标准就以一种或多种形式存在，并且每年都在不断发展。

医院系统内的图像传输

我认为，解释该标准的最佳方法是首先描述在诊所，医院或大型卫生网络中经常发生的与影像相关的工作流程。稍后，我将以这种情况为基础来解释标准的“细节”。

假设某位患者因胸痛入院。主治医师可以命令进行MRI扫描，并且当此请求记录在医院信息系统（HIS）上时，通常会将电子请求发送到位于成像中心的放射学信息系统（RIS）。该请求通常包括有关该请求的来源，订购者，患者的详细信息，所请求的成像方式的类型等信息。一旦完成预订，就将患者发送到成像中心进行扫描。扫描完成后，将从原始数据中创建一组符合DICOM要求的图像，并将其称为“研究”。一项研究本身可能由多个采集组成，具体取决于扫描配置，这些采集中的每一个都称为“系列”。

扫描程序完成后，所有图像都将被存档以传输到PACS系统（图片存档和通信系统）。在将扫描的图像传输到PACS系统之前，可以检查其质量，如果不满意，检查技术人员可以再次下令进行扫描。然后可以将存档的图像从PACS系统中检索到工作站，以供放射科医生查看。放射科医生可以直接在屏幕上查看图像，也可以在胶片上打印这些图像。稍后，她可以在报告中添加有关其观察结果的其他注释。一旦她完成了此过程，更改将与PACS系统上的原始研究合并。电子消息也被发送回RIS，指示模态请求已经完成。

“我们应该被教导不要等到灵感来开始做某件事。行动总能激发灵感。灵感很少产生作用。” 弗兰克·蒂博特

在继续阅读我的文章之前，您可能需要暂停一下，并观看Marc Kohli的精彩视频，该视频解释放射学的典型工作流程，包括DICOM标准（以及其他标准，例如HL7）如何适合其中。我觉得这段视频确实说明了DICOM如何与任何医院网络中更大的医疗保健工作流程集成。

了解DICOM服务

如果不使用DICOM（和HL7），则很难轻松实现前面部分所述的工作流中涉及的多种类型的硬件和软件之间的图像和图像相关信息的无缝流动。现在让我们深入研究细节，看看DICOM标准如何使这种类型的信息流发生。

DICOM标准的本质是基于服务提供商（也称为“服务类别提供商”或“ SCP”），服务使用者（也称为“服务类别用户”或“ SCU”）和信息的概念提供者和消费者所作用的对象。例如，前面部分中描述的打印机是服务提供商的示例，被称为具有“ C-PRINT SCP”功能。请求打印活动的应用程序充当服务使用者，并具有“ C-PRINT SCU”功能。服务类及其作用于其上的信息对象模板的组合称为“服务对象对”类，也称为“ SOP”。SOP为与DICOM相关的合规性（或“合规性”）奠定了基础，并允许供应商披露其软件和硬件支持的与DICOM相关的功能。每个SOP类都有一个由DICOM委员会颁发的唯一标识号。SOP类的列表已经很长了，并且随着支持更多的方式而继续增长。

DICOM标准的目标是在任何医疗保健信息网络中实现“即插即用”架构。因此，该标准规定，所有具有DICOM功能的设备都会在兼容DICOM的设备之间发生的初始“握手”期间以电子方式公开其功能。这种握手通常称为“协会建立”。根据支持的功能，此关联可以成功还是失败。如果关联成功，则将在握手期间协商的格式下，在服务的使用者和提供者之间交换SOP类的实例。先前描述的打印示例中的SOP实例可以携带诸如患者信息之类的信息，要打印图像的像素数据，以及需要与图像一起打印的所有注释。让我们进一步了解使用OsiriX的DICOM兼容设备提供的各种服务。

OsiriX提供的DICOM服务

OsiriX软件具有“ C-STORE SCP”功能，因此能够将传入的DICOM图像存储到本地数据库中。这使软件可以作为基本的PACS服务器运行。为了能够使用此功能，您将在“首选项”屏幕中配置设置，以使OsiriX能够作为DICOM侦听器运行。该软件具有许多功能，包括能够使用DICOM标准的“ WADO”规范通过HTTP协议接收图像（WADO表示“对DICOM对象的Web访问”）。它还通过基于SOAP的消息传递提供Web服务集成。OsiriX提供的另一项与存储相关的功能是“ C-STORE SCU”。此功能使我们能够将OCOM的DICOM信息发送到其他DICOM存储服务提供商，例如PACS系统。“本地数据库”屏幕（如下所示）显示了在OsiriX中如何组织患者的图像。图像始终存储在由患者，他们的研究以及研究中的图像（或“系列”）组成的层次结构中。

通常，当将DICOM图像从查看工作站推送到PACS系统以在硬盘上或在备份介质（例如CD）上进行长期存档时，至关重要的是，存储设备必须提供一些确认，说明信息已成功接收并存储在发送方删除图像之前。使用存储承诺服务在DICOM中可以使用此功能，该服务通常通过结合使用其他服务（例如“ C-MOVE SCU”，“ C-MOVE SCP”，“ N-ACTION”和“ N-EVENT”）来实现。此功能由OsiriX提供。

OsiriX提供的另一个DICOM功能是DICOM图像的查询/检索。这使用户可以搜索远程PACS系统，然后检索他们感兴趣的图像以在本地查看。查询功能指定为“ C-FIND SCU”和“ C-FIND SCP”，检索功能通过“ C-GET SCU”和“ C-GET SCP”以及使用“ C-MOVE SCU”指定”和“ C-MOVE SCP”操作。C-GET操作非常类似于大多数软件开发人员应该熟悉的HTTP协议中使用的HTTP GET请求，并且经常在从医院等医院环境进行通信以从运行中的服务器提取放射图像时使用在医院网络中。C-MOVE操作主要在医院网络内使用，既可以检索图像，也可以将图像发送到完全不同的目的地。请查看上面的屏幕截图，显示在OsiriX软件中如何实现某些查询/检索功能。

DICOM打印服务使图像采集设备和查看工作站可以共享与DICOM兼容的打印机，类似于在信息网络中通常使用普通打印机的方式。DICOM打印可以使用标准校准（在DICOM图像本身中进行编码），以确保各种显示设备以及在其上可以看到图像的硬拷贝打印输出之间的一致性。设备的打印功能指定为“ C-PRINT SCU”或“ C-PRINT SCP”。有多种类型的DICOM打印机可用，它们的功能通过它们声称支持的SOP类来描述。基本支持始终包括灰度打印，彩色打印，具有查找表增强功能的灰度打印以及具有查找表增强功能的彩色打印。可选功能包括注释，图像覆盖和打印作业执行状态报告。OsiriX支持标准中指定的所有基本打印功能。

“最小的善举比最大的意图有价值。” 〜Kahlil Gibran

DICOM离线存储服务使用户可以在可移动存储介质（例如软盘，CD-ROM和光盘）上交换DICOM文件。基于成像环境，例如冠状动脉造影，一般诊断超声或胃肠道内窥镜检查，优选不同的存储机制。OsiriX提供了将DICOM图像刻录到CD-ROM的内置功能（请参见下面的屏幕截图）。但是，它还允许将DICOM图像导出为JPEG，TIFF和QuickTime电影格式，从而可以更轻松地进行传输。

其他DICOM服务

尽管OsiriX具有许多DICOM功能，但它不提供DICOM中指定的其他更高级的服务，例如“模态工作清单”服务或“模态执行过程步骤”服务（也称为“ MPPS”）。通常仅在需要实现与RIS或PACS系统交互时发生的复杂工作流方案时才需要这些服务。

当您希望最大程度地减少手动键入的信息量时，模态工作列表服务非常有用。例如，它允许进行MRI的技术人员将所请求的过程中包含的信息自动传输到作为扫描一部分收集的图像上。这种方法不仅提高了信息传输的效率，而且还提高了患者安全性，因为减少了错误信息的可能性。

MPPS服务用于在执行扫描的设备与RIS和/或PACS之间传达与正在执行的成像步骤有关的消息。基本上有两种类型的消息被使用。在过程步骤开始时会发送一个称为“ N-CREATE”的消息，而在过程步骤完成后会发送一个“ N-SET”消息。作为步骤完成的一部分获取的任何图像也将作为此消息的一部分进行传输。

DICOM文件格式

除了图像像素数据之外，DICOM文件还包含其他信息，例如患者身份信息，研究和图像采集的系列信息等。所有这些信息都以数据集的形式存储在DICOM文件中。这些数据集本质上是数据对象的集合，而它们又由名称/值表示形式的几个属性组成。有关图像的信息（包括患者信息，模态信息，图像的像素数据）存储在这些属性中，这些属性通过DICOM词典进行维护/管理。一个DICOM文件可以存储许多图像（也称为“帧”），以便以电影形式或“电影循环”的形式进行查看，因为它们在DICOM世界中经常被提及。属性内的图像像素数据可以根据存储和传输要求以压缩或未压缩格式存储。图像查看器应用程序可以读取图像数据并将其显示在高分辨率打印机上，从而可以对结果进行准确的诊断。下面的屏幕截图显示了OsiriX中如何显示DICOM图像的“元信息”。

DICOM结构化报告

DICOM标准内的结构化报告（SR）支持在医疗设备之间交换诊断报告。这些报告以与任何其他DICOM对象相同的格式存储。为SR定义的特殊SOP类提供了一种简便的方法来基于研究中的图像存储基本诊断信息，例如可以无缝存储过程日志，观察值，测量值，波形，并允许我们链接这些报告到任何对应的图像。根据报告中包含的编码信息的复杂性，有两种类型：基本文本SR；和增强型SR。

符合DICOM

尽管不是强制性的，但声称其产品符合DICOM标准的供应商通常会提供一份一致性声明，说明其设备或软件如何支持该标准。一致性声明中的信息包括如何处理关联（例如，是否能够启动关联以及并行并行的数量等），受支持的SOP类以及其他信息（例如表示上下文）和通讯资料。客户可以使用这些文档中包含的信息来确定供应商的产品是否可以与他们网络中其他兼容DICOM的设备或软件成功通信。如果您对如何编写/构造这些文件感到好奇，请在此处查看OsiriX的一致性声明示例。

DICOM与其他标准的互操作性

与仅使用DICOM标准相比，在医疗保健信息网络中实施有效的工作流程需要更多的组件。例如，使用HL7处理医疗系统的许多复杂交易。但是，如果要无缝集成DICOM和HL7，则仍然需要解决一些差距。为此，制定了IHE（整合医疗保健企业）计划，以帮助改善DICOM，HL7和许多其他现有医疗保健标准机构之间的合作。以后，我将在单独的教程中介绍IHE。有关HL7标准的教程，请参阅我的HL7文章系列。

结论

我希望您发现此入门教程对深入了解DICOM标准很有用。Internet上还有许多其他资源，还有许多不错的书，它们对我在本教程的更高层次上介绍的领域进行了更深入的研究。我的建议是，如果可能的话，还请您进行培训，以帮助您提高对使用此标准的熟悉度和信心。如果您对此处提供的信息有任何疑问或批评，请随时给我发送电子邮件。请注意，由于工作和其他承诺，我可能不会立即与您联系。

Introduction to the DICOM Standard using OsiriX

CONTENTS

1. Introduction
2. What is DICOM
3. Image Transmission within Hospital Systems
4. Understanding DICOM Services
5. DICOM Services Offered by OsiriX
6. Other DICOM Services
7. DICOM File Format
8. DICOM Structured Reporting
9. Conformance in DICOM
10. DICOM Interoperability with Other Standards
11. Conclusion

Introduction

This is part of my series of articles on the DICOM standard, and provides a quick overivew of the DICOM standard.

DICOM is a healthcare standard responsible for governing nearly all aspects of medical imaging such as image transmission, image interpretation, print management, procedure management and off-line storage, and is used in nearly all healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. Nearly all clinical imaging workflows around the world are based on the DICOM standard. Learning this standard is vital if you work or want to work in the healthcare informatics industry. My hope in writing this series is to help a person entering the “DICOM world” to be able to learn the various aspects and parts of the standard faster by looking at short but focused code examples. In this article, we will look at at all major parts of the standard from a very high level, and in the subsequent articles of this series, we will look at each of those aspects in more detail using code examples that help tie the theory of DICOM to practical implementation.

To illustrate many of the core concepts within this standard, I decided to use a freely available and yet powerful tool called “OsiriX” which has many DICOM capabilities right out of the box. However, please keep in mind that this software runs on the Mac OS X operating system only. So, my apologies if you are running a different operating system. However, simply reading the material here as well as viewing the screenshots shown should help you take in the concepts and apply it to any other DICOM software that you choose to utilize. Also, please keep in mind that this is not a programming tutorial, although much like the approach that I took with my earlier HL7 articles, I plan to use this tutorial as a foundation for some of my DICOM programming tutorials in which I will illustrate how to write custom software applications using the DICOM standard.

What is DICOM

DICOM stands for “Digital Imaging and Communications in Medicine” and was developed jointly by the National Electrical Manufacturers Association (NEMA) as well as the American College of Radiology (ACR) to permit interoperability between imaging equipment as well as with other devices. This standard is responsible for governing both the image format as well as the various network protocols required for transmission of medical image information generated during the many healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. The DICOM standard has existed in one form or the other since 1983 and continues to evolve every year.

Image Transmission within Hospital Systems

I feel that the best way to explain the standard is by first describing an imaging-related workflow that occurs very frequently in clinics, hospitals, or large health networks. Later, I will use this scenario as the basis for explaining the “nuts and bolts” of the standard.

Let us say a patient was admitted to a hospital with some chest pains. The attending physician may order an MRI scan, and when this request is recorded on the Hospital Information System (HIS), an electronic request is often transmitted to the Radiology Information System (RIS) located in the imaging centre. This request typically comprises of information about where the request came from, who ordered it, the details of the patient, the type of imaging modality requested, etc. Once the booking is done, the patient then is sent for the scan to the imaging centre. After a scan has been completed, a set of DICOM-compliant images are created from the raw data and is referred to as a “Study”. A study may itself consist of several acquisitions depending on the scan configurations, and each of these acquisitions is referred to as a “Series”. Each series will consist of several images, and each of these images are individually referred to as a “DICOM Information Object”.

After the scanning procedure has been completed, all the images are transmitted for archival to a PACS system (Picture Archival and Communication System). The scanned images may be reviewed for quality before being transmitted to a PACS system, and the reviewing technologist may order a scan again if they are not satisfactory. The archived images can then be retrieved from the PACS system to a workstation for viewing by a radiologist. The radiologist may either view the images directly on the screen or print these images on film. Later, she may add additional comments about her observations on a report. Once she completes this process, the changes are merged with the original study on the PACS system. An electronic message is also transmitted back to the RIS indicating that the modality request has been completed. Information may also be transmitted back to the originating HIS along with some of the key images to assist in intervention by a cardiologist if necessary.

“We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” Frank Tibolt

Before you continue reading my article any further, you may want to take a pause and watch this excellent video by Marc Kohli explaining the typical workflow in radiology including how the DICOM standard (along with other standards such as HL7) fits within it. I feel that this video really explains the big picture of how DICOM integrates into the larger healthcare workflow within any hospital network.

Understanding DICOM Services

The seamless flow of images and image-related information between the many types of hardware and software involved in the workflow described in the earlier section could not be easily achieved without the use of DICOM (and HL7). Let us now dive a little bit into the details to see how the DICOM standard enables this type of information flow to occur.

At its very core, DICOM standard is based on the concept of service providers (also referred to as “Service Class Providers” or “SCP”), service consumers (also referred to as “Service Class Users” or “SCU”) and information objects that are acted upon by the providers and consumers. For example, the printer described in the earlier section is an example of a service provider and is referred to as having a “C-PRINT SCP” capability. The application requesting the print activity is acting as a service consumer and has “C-PRINT SCU” capability. The combination of a service class along with the information object template that it acts upon is referred to as “Service-Object Pair” class, also referred to as “SOP”. SOPs form the foundation for DICOM-related compliance (or “conformance”) and allow vendors to disclose what DICOM-related capabilities their software and hardware support. Each SOP class has an unique identification number issued by the DICOM committee. The list of SOP classes is very long already and continues to grow as more modalities are supported.

The goal of the DICOM standard is to enable a “plug-n-play” architecture within any healthcare information network. The standard therefore stipulates that all DICOM-capable devices electronically disclose their capabilities during an initial “handshake” that occurs that occurs between DICOM-compliant devices. This handshaking is often referred to as an “Association Establishment”. Depending on the capabilities supported, this association can be successful or fail. If the association is successful, instances of the SOP classes are exchanged between the consumers and providers of a service in the format negotiated during the handshake. The SOP instance in the print example described previously may carry information such as the patient information, pixel data of the images to be printed as well as any annotations that are required to be printed along with the images. Let us look at the various services offered by DICOM-compliant devices a little further using OsiriX.

DICOM Services Offered by OsiriX

OsiriX software has a “C-STORE SCP” capability and is therefore capable of storing incoming DICOM images into a local database. This allows the software to operate as a rudimentary PACS server. In order to be able to use this feature, you will have configured the settings in the “Preferences” screen to enable OsiriX to run as a DICOM listener. This software has many capabilities including being able to receive images through the HTTP protocol using the “WADO” specification of the DICOM standard (WADO stands for “Web Access to DICOM Objects”). It also offers web service integration through SOAP-based messaging. Another storage-related capability that OsiriX offers is the “C-STORE SCU”. This capability permits us to send DICOM information from OsiriX to other DICOM storage service providers such as PACS systems. The “Local Database” screen (shown below) shows how the images for a patient are organized within OsiriX. The images are always stored in a hierarchy consisting of patients, their studies, and the images in the study (or “series”).

Often, when DICOM images are pushed from a viewing workstation to a PACS system for long-term archival on hard disk, or on backup media such as CD, it is essential that the storage device provides some acknowledgement that information has been successfully received and stored before the images are deleted at the sender. This feature is possible within DICOM using the Storage Commitment Service which is typically achieved using a combination of other services such as “C-MOVE SCU”, “C-MOVE SCP”, “N-ACTION” and “N-EVENT”. This capability is provided by OsiriX.

Another DICOM capability that OsiriX offers is the query/retrieval of DICOM images. This enables users to search a remote PACS system, and later retrieve images that are of interest to them for viewing locally. The querying capabilities are specified as “C-FIND SCU” and “C-FIND SCP”, and the retrieval capabilities are specified through “C-GET SCU” and “C-GET SCP” as well as by using “C-MOVE SCU” and “C-MOVE SCP” operations. The C-GET operation works very much like a HTTP GET request used in the HTTP protocol that most software developers should be familiar with, and is often used when communicating from outside a hosptial setting such as a clinic to pull radiological images from a server running within a hospital network. The C-MOVE operation is used mostly within a hospital network to both retrieve images and also send images to a completely different destination. Please see screenshot above showing how some of query/retrieval features are implemented within the OsiriX software.

DICOM printing services enable image acquisition devices as well as viewing workstations to share DICOM-compliant printers similar to how normal printers are often utilized within an information network. DICOM printing enables the use of standard calibration (encoded within the DICOM images themselves) to ensure that there is consistency between various display devices as well as hard copy printouts on which the images are seen. The print capabilities of devices are specified either as “C-PRINT SCU” or “C-PRINT SCP”. There are many types of DICOM printers available, and their capabilities are described through the SOP classes they claim to support. Basic support always includes grayscale printing, colour printing, grayscale printing with lookup table enhancement, and colour printing with lookup table enhancement. Optional features include annotation, image overlays, and print job execution status reporting. OsiriX supports all the basic printing capabilities specified in the standard.

“The smallest act of kindness is worth more than the greatest intention.” ~ Kahlil Gibran

DICOM off-line storage services enable users to exchange DICOM files on removable storage media such as diskettes, CD-ROMs, and optical disks. Different storage mechanisms are preferred based on the imaging context such as coronary angiography, general diagnostic ultrasonography, or gastrointestinal endoscopy. OsiriX provides a built-in feature to burn DICOM images onto CD-ROMs (see screenshot below). However, it also permits the ability to export the DICOM images to JPEG, TIFF and QuickTime movie formats which can transferred more easily.

Other DICOM Services

Although OsiriX has many DICOM capabilities, it does not offer other more advanced services specified within the DICOM such as the “Modality Worklist” service or the “Modality Performed Procedure Step” service (also known as “MPPS”). These services are typically only required when needing to implement complex workflow scenarios that occur when interacting with a RIS or PACS system.

The modality worklist service is useful when you want to minimize the amount of information that is keyed in manually. For example, it allows the technologist conducting an MRI to automatically transfer the information contained within the requested procedure onto the images collected as part of the scan. This approach not only increases the efficiency of information transfer, but also increases the level of patient safety as there is a reduced chance for incorrect patient information.

The MPPS service is used to communicate messages pertaining to the imaging steps being performed between the device performing a scan and the RIS and/or PACS. There are fundamentally two types of messages that are utilized. There is something called a “N-CREATE” message which is sent at the start of a procedure step, as well as a “N-SET” message is which is transmitted after a procedure step has been completed. Any images acquired as part of the step completion are also transferred as part of this message.

DICOM File Format

In addition to the image pixel data, the DICOM file contains other information such as patient identification information, study and series information of the image acquisition, etc. All this information is stored inside a DICOM file in the form of data sets. These data sets are essentially a collection of data objects, and these in return consist of several attributes in the form of name/value representations. Information about the image (including patient information, modality information, pixel data for the images) are stored in these attributes which are maintained/managed through a DICOM Dictionary. A single DICOM file can store many images (also known as “frames”) to enable for viewing in the form of a movie or as “cine loop” as they are often referred to in the DICOM world. Image pixel data inside the attributes may be stored in either compressed or uncompressed formats depending on the storage and transmission requirements. Image viewer applications can read and display the image data onto high resolution printers permitting accurate diagnosis of the results. The screenshot below shows how the “meta information” of a DICOM image is displayed within OsiriX.

DICOM Structured Reporting

Structured Reports (SR) within DICOM standard enables the exchange of diagnostic reporting between medical devices. These reports are stored in the same format as any other DICOM object. The special SOP classes defined for SR permit an easy way to store the essential diagnostic information based on the images in a study, such as procedure logs, observations, measurements, waveforms can be stored in a seamless manner, and allow us to link these reports to any corresponding images. Based on the complexity of the encoded information contained in the report, there are two types: a Basic Text SR; and an Enhanced SR.

Conformance in DICOM

Although not mandatory, vendors who claim that their products adhere to the DICOM standard typically provide a Conformance Statement describing how their device or software supports the standard. The information in the conformance statement include how the associations are handled (for example, whether it is capable of initiating associations, and how many in parallel, etc.), the SOP classes that are supported, as well as other information such as presentation contexts and communication profiles. Customers can use the information contained in these documents to decide whether the vendor product can successfully communicate with other DICOM-compliant devices or software within their network. If you are curious how these are written/structured, see an example of a conformance statement for OsiriX here.

DICOM Interoperability with Other Standards

There are many more components required to implement an effective workflow within an healthcare information network than is possible using the DICOM standard alone. For example, many complex transactions with a healthcare system are handled using HL7. However, if DICOM and HL7 are to seamlessly integrate, some gaps are still required to be addressed. For this purpose, IHE (Integrating the Healthcare Enterprise) initiative was developed to help improve the cooperation between DICOM, HL7 and many other existing healthcare standards agencies. I will cover IHE in a separate tutorial in the future. For a tutorial on the HL7 standard, see my HL7 article series.

Conclusion

I hope you found this introductory tutorial useful for gaining a high-level understanding of the DICOM standard. There are many additional resources on the Internet as well as many good books that delve much deeper into the areas that I covered at a high level in this tutorial. My recommendation is also that you also take hands on training if possible, to help boost your familiarity and confidence in using this standard. If you have any questions or criticisms on the information presented here, please feel free to send me an email. Please note that I may not get back to you right away due to work and other commitments.