DICOM (Digital Imaging and COmmunications in Medicine)
DICOM – это стандарт обработки, хранения, печати и передачи информации в системах медицинской визуализации. Он включает описание формата файлов и сетевой протокол. Сетевой протокол использует TCP/IP в своей основе для коммуникации между системами. Также, системы, поддерживающие чтение и запись файлов DICOM, могут обмениваться между собой файлами в формате DICOM. Владельцем стандарта является американская организация National Electrical Manufacturers Association (NEMA). Он разрабатывается комитетом стандарта DICOM, состоящим из нескольких рабочих групп (WG).
DICOM позволяет осуществлять интеграцию сканеров, серверов, рабочих станций, принтеров, и сетевого оборудования множества различных производителей в единую систему PACS (picture archiving and communication system, система архивации и передачи изображений). Различные устройства поставляются совместно с документом, называемым DICOM conformance statement (описание соответствия стандарту), который описывает, как и какие функции выполняет поставляемое устройство.
Стандарт DICOM разделен на несколько взаимосвязанных, но независимых частей:
История возникновения.
В начале 80-х годов декодировать изображения, генерируемые оборудованием, могли только производители оборудования – рентгеновских компьютерных и магнитно-резонансных томографов. Радиотерапевты хотели использовать изображения для планирования облучения пациента в радиотерапии. ACR и NEMA объединили усилия и создали комитет по стандарту в 1983-м году. Первый стандарт ACR/NEMA 300 был выпущен в 1985-м году. Очень скоро после первого выпуска стало понятно, что нужны доработки стандарта. Текст стандарта оказался неопределенным и внутренне противоречивым.
В 1988-м была выпущена вторая версия. Эту версию стандарта поддержали большее число производителей оборудования. Передача изображений осуществлялась по выделенной линии с 25-ю витыми парами (EIA-485). Первая демонстрация технологии взаимосвязи по ACR/NEMA 2.0 была продемонстрирована в университете Джоржтаун в мае 1990-го года. В событии участвовало 6 компаний: DeJarnette Research Systems, General Electric Medical Systems, Merge Technologies, Siemens Medical Systems, Vortech (приобретенный компанией Kodak в этом же году) и 3M. Вторая версия стандарта тоже требовала улучшений. Были созданы несколько расширений стандарта ACR/NEMA 2.0, например Papyrus (выпущенный University Hospital of Geneva, Швейцария) и SPI (Standard Product Interconnect, выпущенный Siemens Medical Systems и Philips Medical Systems).
Первое широкомасштабное развертывание технологии ACR/NEMA было сделано в 1992-м году Армией США и Воздушными Силами США как часть программы MDIS (Medical Diagnostic Imaging Support). Loral Aerospace и Siemens Medical Systems участвовали в разработке первого военного PACS’а США. DeJarnette Research Systems и Merge Technologies предоставляли возможность соединения нестандартных интерфейсов производителей оборудования с сетью Siemens SPI.
В 1993-м году была выпущена третья версия стандарта. Его название было изменено на DICOM, чтобы расширить возможность международного использования. Были добавлены новые служебные классы, добавлена поддержка локальных сетей и был стандартизован Conformance Statement (описание соответствия стандарту). Версия 3.0 официально остается последней версией стандарта, однако она постоянно обновляется и расширяется. Вместо использования номера версии используется год выпуска стандарта, как например ‘Стандарт DICOM 2007-го года’.
Структура данных DICOM.
В файлах DICOM одновременно содержатся и непосредственно изображения и дополнительная информация о пациенте, которому это исследование проводилось. Информация о пациенте и исследовании не может быть отделена от самого изображения. Это уменьшает число возможных ошибок. Похожим образом организован формат JPEG, который также может иметь в файле дополнительную информацию описывающую изображение.
Любой DICOM объект состоит из множества атрибутов, таких как имя пациента, его идентификатор, дата исследования и т.д. Также один, особенный, атрибут содержит данные изображения (pixel data). Таким образом, не существует какого-то отдельного заголовка у DICOM файла – только множество атрибутов, включающих и данные изображения. Атрибуты в стандарте называются тэгами (tags), каждому тэгу присвоен свой номер, состоящий из двух полей – номера группы и номера элемента. Например, в тэге с номером 0010, 0010 (номера тэгов записываются в шестнадцатеричной нотации) всегда содержатся данные об ФИО пациента. У каждого тэга есть стандартное название. 0010, 0010 называется ‘Patient’s Name’. Список всех стандартизованных тэгов можно посмотреть в 6-м разделе стандарта PS 3.6: Data Dictionarу.
Тэг 7FFE, 0010 ‘Pixel Data’ может содержать в себе одно или несколько изображений. В случае, когда Pixel Data содержит больше одного изображения, говорят, что файл содержит мультифреймовое изображение (multi-frame image). В случае мультифреймового изображения в одном файле будет содержаться трех- или четырех- (например, несколько последовательностей сканов томографа в нескольких местах, но в разное время) мерное изображение. Цифровые рентгеновские аппараты, цифровые считыватели кассет отдают информацию в виде однофреймового изображения. Аппараты УЗИ, ангиографы часто отдают мультифреймовые изображения. Старые рентгеновские и магнитно-резонансные томографы могли отдавать однофреймовые изображения. Современные томографы (после стандартизации расширенных форматов DICOM – CT Enhanced и MR Enhanced) могут отдавать как однофреймовые, так и мультифремовые изображения.
DICOM использует три различные схемы кодировки тэгов (transfer syntax). Кодировка файла помечается соответствующим тэгом в этом же файле (в мета информации, см. ниже). Схемы получаются из комбинаций двух параметров – представления данных и кодировки порядка байт.
Порядок байт может быть от старшего к младшему (big-endian, дословно: «тупоконечный»), запись начинается со старшего и заканчивается младшим, и от младшего к старшему (little-endian, «остроконечный»).
В DICOM используется три их четырех возможных комбинаций параметров: Implicit little endian, Explicit little endian и Explicit big endian.
Каждый тэг состоит из: номера группы (2 байта), номера элемента (2 байта), VR (2 байта, в явном представлении данных, в неявном не используется), длины тэга (2 или 4 байта, в зависимости от VR).
В дополнение к представлению данных (к Value Representation) существует понятие множественности значений (VM, Value Multiplicity). VM никак не помечается в реальных файлах, это только указание, сколько данных предполагает содержать конкретный тэг. Для данных, представленных строками, элементы разделены между собой знаком бэкслэша (‘\’). Числовые данные просто идут подряд побайтно – например, при VM = 2 тэг с VR = FL будет состоять из 8-ми байт – это два числа обычной точности. В таблицах со списками тэгов указывается VM каждого тэга. Например, тэг, содержащий в себе одну координату двумерной точки, будет иметь VM = 2. Содержащий координаты n точек будет иметь VM = 2 * n, n > 0 (в стандарте записывается 2-2n).
Формат тэгов одинаков и для сети и для файлов.
DICOM сервисы.
DICOM состоит из множества различных сервисов, большинство из которых подразумевает обмен данными по сети. Обмен файлами был добавлен в стандарт позже и является только небольшой частью стандарта.
Store
DICOM сервис ‘Store’ предназначен для передачи изображений или других объектов (например, structured reports – структурированных отчетов) между двумя устройствами DICOM.
Storage Commitment
Query/Retrieve
Сервис поиска и доставки целых исследований или отдельных объектов на удаленном DICOM устройстве. Позволяет найти по определенным фильтрам (например – дата исследования, ФИО пациента и т.д.) интересующее исследование или объект (чаще всего объекты в DICOM – это изображения, но не только) и запросить его пересылку на локальный компьютер.
Modality Worklist
Позволяет аппарату (часто аппараты в DICOM называют модальностями, однако один и тот же аппарат, например, литотрипсер, может иметь несколько модальностей – US, DX) получить список намеченных исследований. В данных о намеченных исследованиях содержится информация и о пациентах, это позволяет сократить повторный ввод одной и той же информации и сопутствующие ошибки.
Modality Performed Procedure Step
Дополнительный к Modality Worklist сервис, который позволяет модальности посылать отчет об успешности выполнения исследования, о полученных изображениях, времени начала и конца исследования, полученной пациентом дозе и т.д. Сервис позволяет получить управлению больницы более точные данные по использованию ресурсов аппарата. Сервис, так же называемый MPPS, позволяет улучшить взаимодействие модальности и системы PACS, предоставляя системе список объектов, которые будут посланы перед самой посылкой.
Printing
Этот сервис позволяет посылать изображения на печать на принтер DICOM, для получения твердой копии изображений, чаще всего на пленках. Существует способ стандартной калибровки (описанный в 14-й части стандарта) принтеров и мониторов, помогающий получить одинаковые изображения на разных мониторах и на твердой копии изображений.
Офлайновое сохранение (файлы DICOM)
Сохранение файлов DICOM описано в 10-й части стандарта. Она описывает, как сохранять информацию медицинской визуализации на извлекаемых устройствах (CD, DVD и т.д.). Кроме непосредственно данных пациента и исследования, данных точек изображения, файлы обязательно должны содержать т.н. мета-информацию (File Meta Information, группа тэгов 0002). В мета информации указано, как верно интерпретировать содержимое файла.
DICOM ограничивает длину имен файлов до 8-ми символов, расширения у файлов не допустимы. Сами имена файлов должны быть такими, что бы из них нельзя было получить никакой информации. Это исторически сложившиеся требования для поддержания обратной совместимости со старыми системами. На носителе, кроме файлов, в корневом каталоге должен быть размещен файл dicomdir. Dicomdir предоставляет общую индексированную информацию обо всех файлах DICOM, находящихся на носителе. Dicomdir предоставляет большую информацию о каждом файле, чем её возможно вместить в название файлов.
Некоторые распространенные модальности.
Наиболее часто взаимодействие по сети DICOM идет по порту номер 104. Многие операционные системы требуют дополнительных разрешений для работы с этим портом.
DICOM Conformance Statement
Azure Healthcare APIs is currently in PREVIEW. The Supplemental Terms of Use for Microsoft Azure Previews include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
The Azure API for DICOM service supports a subset of the DICOMwebв„ў Standard. This support includes:
Additionally, the following non-standard API(s) are supported:
Our service also makes use of REST API versioning. For information on how to specify the version when making requests visit the API Versioning for DICOM service Documentation.
Store (STOW-RS)
This transaction uses the POST method to store representations of studies, series, and instances contained in the request payload.
| Method | Path | Description |
|---|---|---|
| POST | ../studies | Store instances. |
| POST | ../studies/ | Store instances for a specific study. |
Parameter study corresponds to the DICOM attribute StudyInstanceUID. If it is specified, any instance that does not belong to the provided study will be rejected with a 43265 warning code.
The following Accept header(s) for the response are supported:
The following Content-Type header(s) are supported:
The Server will not coerce or replace attributes that conflict with existing data. All data will be stored as provided.
The following DICOM elements are required to be present in every DICOM file attempting to be stored:
All identifiers must be between 1 and 64 characters long, and only contain alpha numeric characters or the following special characters: ‘.’, ‘-‘.
Each file stored must have a unique combination of StudyInstanceUID, SeriesInstanceUID, and SopInstanceUID. The warning code 45070 will be returned if a file with the same identifiers already exists.
DICOM File Size Limit: there is a size limit of 2 GB for a DICOM file by default.
Store response status codes
| Code | Description |
|---|---|
| 200 (OK) | All the SOP instances in the request have been stored. |
| 202 (Accepted) | Some instances in the request have been stored but others have failed. |
| 204 (No Content) | No content was provided in the store transaction request. |
| 400 (Bad Request) | The request was badly formatted. For example, the provided study instance identifier did not conform to the expected UID format. |
| 401 (Unauthorized) | The client is not authenticated. |
| 403 (Forbidden) | The user is not authorized. |
| 406 (Not Acceptable) | The specified Accept header is not supported. |
| 409 (Conflict) | None of the instances in the store transaction request have been stored. |
| 415 (Unsupported Media Type) | The provided Content-Type is not supported. |
| 503 (Service Unavailable) | The service is unavailable or busy. Please try again later. |
Store response payload
The response payload will populate a DICOM dataset with the following elements:
| Tag | Name | Description |
|---|---|---|
| (0008, 1190) | RetrieveURL | The Retrieve URL of the study if the StudyInstanceUID was provided in the store request and at least one instance is successfully stored. |
| (0008, 1198) | FailedSOPSequence | The sequence of instances that failed to store. |
| (0008, 1199) | ReferencedSOPSequence | The sequence of stored instances. |
Each dataset in the FailedSOPSequence will have the following elements (if the DICOM file attempting to be stored could be read):
| Tag | Name | Description |
|---|---|---|
| (0008, 1150) | ReferencedSOPClassUID | The SOP class unique identifier of the instance that failed to store. |
| (0008, 1150) | ReferencedSOPInstanceUID | The SOP instance unique identifier of the instance that failed to store. |
| (0008, 1197) | FailureReason | The reason code why this instance failed to store. |
Each dataset in the ReferencedSOPSequence will have the following elements:
| Tag | Name | Description |
|---|---|---|
| (0008, 1150) | ReferencedSOPClassUID | The SOP class unique identifier of the instance that failed to store. |
| (0008, 1150) | ReferencedSOPInstanceUID | The SOP instance unique identifier of the instance that failed to store. |
| (0008, 1190) | RetrieveURL | The retrieve URL of this instance on the DICOM server. |
Below is an example response with Accept header application/dicom+json :
Store failure reason codes
| Code | Description |
|---|---|
| 272 | The store transaction did not store the instance because of a general failure in processing the operation. |
| 43264 | The DICOM instance failed the validation. |
| 43265 | The provided instance StudyInstanceUID did not match the specified StudyInstanceUID in the store request. |
| 45070 | A DICOM instance with the same StudyInstanceUID, SeriesInstanceUID, and SopInstanceUID has already been stored. If you wish to update the contents, delete this instance first. |
| 45071 | A DICOM instance is being created by another process, or the previous attempt to create has failed and the cleanup process has not had chance to clean up yet. Delete the instance first before attempting to create again. |
Retrieve (WADO-RS)
This Retrieve Transaction offers support for retrieving stored studies, series, instances, and frames by reference.
| Method | Path | Description |
|---|---|---|
| GET | ../studies/ | Retrieves all instances within a study. |
| GET | ../studies/ | Retrieves the metadata for all instances within a study. |
| GET | ../studies/| Retrieves all instances within a series. | |
| GET | ../studies/ | Retrieves the metadata for all instances within a series. |
| GET | ../studies/| Retrieves a single instance. | |
| GET | ../studies/ | Retrieves the metadata for a single instance. |
| GET | ../studies/| Retrieves one or many frames from a single instance. To specify more than one frame, use a comma to separate each frame to return. For example, /studies/1/series/2/instance/3/frames/4,5,6 | |
Retrieve instances within study or series
The following Accept header(s) are supported for retrieving instances within a study or a series:
Retrieve an instance
The following Accept header(s) are supported for retrieving a specific instance:
Retrieve frames
The following Accept headers are supported for retrieving frames:
Retrieve transfer syntax
When the requested transfer syntax is different from original file, the original file is transcoded to requested transfer syntax. The original file needs to be one of the formats below for transcoding to succeed; otherwise, transcoding may fail:
Retrieve metadata (for study, series, or instance)
The following Accept header(s) are supported for retrieving metadata for a study, a series, or an instance:
Retrieving metadata will not return attributes with the following value representations:
| VR Name | Description |
|---|---|
| OB | Other Byte |
| OD | Other Double |
| OF | Other Float |
| OL | Other Long |
| OV | Other 64-Bit Very Long |
| OW | Other Word |
| UN | Unknown |
Retrieve metadata cache validation for (study, series, or instance)
Cache validation is supported using the ETag mechanism. In the response to a metadata request, ETag is returned as one of the headers. This ETag can be cached and added as If-None-Match header in the later requests for the same metadata. Two types of responses are possible if the data exists:
Retrieve response status codes
| Code | Description |
|---|---|
| 200 (OK) | All requested data has been retrieved. |
| 304 (Not Modified) | The requested data has not been modified since the last request. Content is not added to the response body in such case. For more information, see the above section Retrieve Metadata Cache Validation (for Study, Series, or Instance). |
| 400 (Bad Request) | The request was badly formatted. For example, the provided study instance identifier did not conform to the expected UID format, or the requested transfer-syntax encoding is not supported. |
| 401 (Unauthorized) | The client is not authenticated. |
| 403 (Forbidden) | The user is not authorized. |
| 404 (Not Found) | The specified DICOM resource could not be found. |
| 406 (Not Acceptable) | The specified Accept header is not supported. |
| 503 (Service Unavailable) | The service is unavailable or busy. Please try again later. |
Search (QIDO-RS)
Query based on ID for DICOM Objects (QIDO) enables you to search for studies, series, and instances by attributes.
| Method | Path | Description |
|---|---|---|
| Search for Studies | ||
| GET | ../studies. | Search for studies |
| Search for Series | ||
| GET | ../series. | Search for series |
| GET | ../studies/ | Search for series in a study |
| Search for Instances | ||
| GET | ../instances. | Search for instances |
| GET | ../studies/ | Search for instances in a study |
| GET | ../studies/ | Search for instances in a series |
The following Accept header(s) are supported for searching:
Supported search parameters
The following parameters for each query are supported:
| Key | Support Value(s) | Allowed Count | Description | |||
|---|---|---|---|---|---|---|
| 0. N | Search for attribute/ value matching in query. | |||||
| includefield= | all | 0. N | The additional attributes to return in the response. Both, public and private tags are supported. When all is provided. Refer to Search Response for more information about which attributes will be returned for each query type. If a mixture of | |||
| limit= | 0..1 | Integer value to limit the number of values returned in the response. Value can be between the range 1 >= x offset= | 0..1 | Skip If an offset is provided larger than the number of search query results, a 204 (no content) response will be returned. | ||
| fuzzymatching= | true | false | 0..1 | If true fuzzy matching is applied to PatientName attribute. It will do a prefix word match of any name part inside PatientName value. For example, if PatientName is «John^Doe», then «joh», «do», «jo do», «Doe» and «John Doe» will all match. However, «ohn» will not match. |
Searchable attributes
We support searching the following attributes and search types.
| Attribute Keyword | Study | Series | Instance |
|---|---|---|---|
| StudyInstanceUID | X | X | X |
| PatientName | X | X | X |
| PatientID | X | X | X |
| AccessionNumber | X | X | X |
| ReferringPhysicianName | X | X | X |
| StudyDate | X | X | X |
| StudyDescription | X | X | X |
| SeriesInstanceUID | X | X | |
| Modality | X | X | |
| PerformedProcedureStepStartDate | X | X | |
| SOPInstanceUID | X |
Search matching
We support the following matching types.
Attribute ID
Tags can be encoded in many ways for the query parameter. We have partially implemented the standard as defined in PS3.18 6.7.1.1.1. The following encodings for a tag are supported:
| Value | Example |
|---|---|
| 0020000D | |
| StudyInstanceUID |
Example query searching for instances: ../instances?Modality=CT&00280011=512&includefield=00280010&limit=5&offset=0
Search response
The response will be an array of DICOM datasets. Depending on the resource, by default the following attributes are returned:
Default study tags
| Tag | Attribute Name |
|---|---|
| (0008, 0005) | SpecificCharacterSet |
| (0008, 0020) | StudyDate |
| (0008, 0030) | StudyTime |
| (0008, 0050) | AccessionNumber |
| (0008, 0056) | InstanceAvailability |
| (0008, 0090) | ReferringPhysicianName |
| (0008, 0201) | TimezoneOffsetFromUTC |
| (0010, 0010) | PatientName |
| (0010, 0020) | PatientID |
| (0010, 0030) | PatientBirthDate |
| (0010, 0040) | PatientSex |
| (0020, 0010) | StudyID |
| (0020, 000D) | StudyInstanceUID |
Default series tags
| Tag | Attribute Name |
|---|---|
| (0008, 0005) | SpecificCharacterSet |
| (0008, 0060) | Modality |
| (0008, 0201) | TimezoneOffsetFromUTC |
| (0008, 103E) | SeriesDescription |
| (0020, 000E) | SeriesInstanceUID |
| (0040, 0244) | PerformedProcedureStepStartDate |
| (0040, 0245) | PerformedProcedureStepStartTime |
| (0040, 0275) | RequestAttributesSequence |
Default instance tags
| Tag | Attribute Name |
|---|---|
| (0008, 0005) | SpecificCharacterSet |
| (0008, 0016) | SOPClassUID |
| (0008, 0018) | SOPInstanceUID |
| (0008, 0056) | InstanceAvailability |
| (0008, 0201) | TimezoneOffsetFromUTC |
| (0020, 0013) | InstanceNumber |
| (0028, 0010) | Rows |
| (0028, 0011) | Columns |
| (0028, 0100) | BitsAllocated |
| (0028, 0008) | NumberOfFrames |
If includefield=all, the below attributes are included along with default attributes. Along with the default attributes, this is the full list of attributes supported at each resource level.
Other study tags
| Tag | Attribute Name |
|---|---|
| (0008, 1030) | Study Description |
| (0008, 0063) | AnatomicRegionsInStudyCodeSequence |
| (0008, 1032) | ProcedureCodeSequence |
| (0008, 1060) | NameOfPhysiciansReadingStudy |
| (0008, 1080) | AdmittingDiagnosesDescription |
| (0008, 1110) | ReferencedStudySequence |
| (0010, 1010) | PatientAge |
| (0010, 1020) | PatientSize |
| (0010, 1030) | PatientWeight |
| (0010, 2180) | Occupation |
| (0010, 21B0) | AdditionalPatientHistory |
Other series tags
| Tag | Attribute Name |
|---|---|
| (0020, 0011) | SeriesNumber |
| (0020, 0060) | Laterality |
| (0008, 0021) | SeriesDate |
| (0008, 0031) | SeriesTime |
The following attributes are returned:
Search response codes
The query API returns one of the following status codes in the response:
| Code | Description |
|---|---|
| 200 (OK) | The response payload contains all the matching resources. |
| 204 (No Content) | The search completed successfully but returned no results. |
| 400 (Bad Request) | The server was unable to perform the query because the query component was invalid. Response body contains details of the failure. |
| 401 (Unauthorized) | The client is not authenticated. |
| 403 (Forbidden) | The user is not authorized. |
| 503 (Service Unavailable) | The service is unavailable or busy. Please try again later. |
Extra notes
Delete
This transaction is not part of the official DICOMwebв„ў Standard. It uses the DELETE method to remove representations of studies, series, and instances from the store.
| Method | Path | Description |
|---|---|---|
| DELETE | ../studies/ | Delete all instances for a specific study. |
| DELETE | ../studies/| Delete all instances for a specific series within a study. | |
| DELETE | ../studies/| Delete a specific instance within a series. | |
There are no restrictions on the request’s Accept header, Content-Type header or body content.
After a Delete transaction, the deleted instances won’t be recoverable.
Response Status Codes
| Code | Description |
|---|---|
| 204 (No Content) | When all the SOP instances have been deleted. |
| 400 (Bad Request) | The request was badly formatted. |
| 401 (Unauthorized) | The client is not authenticated. |
| 403 (Forbidden) | The user is not authorized. |
| 404 (Not Found) | When the specified series was not found within a study, or the specified instance was not found within the series. |
| 503 (Service Unavailable) | The service is unavailable or busy. Please try again later. |
Delete response payload
The response body will be empty. The status code is the only useful information returned.
Next Steps
For information about the DICOM service, see
