DICOM

DICOM (Digital Imaging and Communications in Medicine) standard can be very roughly divided in 2 parts:

1. The part specifying the DICOM file format

Similar to JPEG and besides the “pixel data” that encodes the image itself, a DICOM file also embeds medical information. The medical information encoded takes the form of a key-value pair . Each key is called a DICOM tag which is a two 16-bit hexadecimal numbers like (0x0010, 0x0030). A nickname is given for readability eg (StudyDate). Associates with each tag is its Value representation eg 20061201

2. The part specifying the DICOM network protocol

Actually, one of the earliest example of Web services. It allows the following DICOM operations:

a. Test the connection between two devices (C-Echo)

b. Send images from the local imaging device to a remote device (C-Store)

c. Search the content of a remote device (C-Find)

d. Retrieve images from a remote device (C-Move)

The connection of a DICOM client to a DICOM server is called an association. It starts with a handshake where the client and the server agree on which commands can be exchanged between them, and on which transfer syntaxes eg accept uncompressed/compressed or both formats. The IP address, the TCP port and the AET (Application Entity Title: a unique name given to a device inside this DICOM network) describe all the parameters of a DICOM server.

After the study has been created, the scanner needs to send the study to a remote archive, using the DICOM Storage Service (also called a DICOM Push). A DICOM Service, is a type of DICOM operation eg Storage, Query/Retrieve, Print, etc. For each operation, one device acts as Service Class User (SCU) and the other acts as Service Class Provider (SCP). In the case of storage, the device (the scanner) sending the data is the SCU, while the device receiving the data (the PACS) is the SCP. A device can act as an SCU for some operations and an SCP for others eg a scanner might be able to receive data from other sources, in which case it would be the Storage SCP.

DICOM operations use TCP/IP (Transmission Control Protocol/Internet Protocol) for communication with remote devices. DICOM SCPs will listen for incoming communication on a particular port. It will only hear messages that are sent to that port where a SCU would like to connect.

Before any data is sent, there is a negotiation phase. During this phase, the SCU (in this case the scanner console) will send:

• The Application Entity (AE) Title of the archive, referred to as the "called AE Title"

• Its own AE Title, referred to as the "calling AE Title"

• A list of the operations it wishes to perform (Abstract Syntaxes)

• A list of formats it supports (Transfer Syntaxes)

Every device in a DICOM network has an unique Application Entity title, which is used to identify a "DICOM service on a device" – some devices use a different AE Title for each DICOM operation. PS: a device can be: a Modality like CT, USG, MRI; PACS; Workstations for reporting /postprocessing; Printers etc. Archive may refuse the connection if the scanner’s AE Title is not in its list of remote devices. For this reason, most DICOM devices maintain a list of remote devices and for each remote device, it records its AE Title, IP address and port of the device and potentially a list of services the device supports.

1) A radiologist working on another station decides to pull up the study from the archive. He starts the query using patient ID, exam Date etc. This time, the PACS is acting as an Query/Find SCP, and is listening on a particular TCP/IP port. The workstation acts as a user (Query SCU) and initiates the connection. After negotiation (1st time), workstation sends a list of DICOM tags to the archive, and the archive searches its database and returns a list of studies that match all these tags.

2) The next step would be the workstation re-connect (2nd time) to PACS again. This time, the workstation acts as an SCU of the Move/Retrieve service, and the archive once again acts as a Move/Retrieve SCP. The workstation sends the archive the UID of the study to retrieve, and its AE Title to store this study (Move Destination).

3) If the archive finds that the Move Destination is in its remote device list, it will accept the query and push the study back to the workstation. In this case, the archive will start its own Storage SCU and connect back to the workstation’s Storage SCP, goes through the DICOM negotiation (3rd time) before sending the study across. The archive will continue updating the workstation on how many images have been sent and how many are remaining, finishes it all before closing the connection.

Unlike DICOM, HL7 is a closed commercialized standard maintained by the Health Level Seven International Organisation as at 2013. HL7 version 3 utilizes a more user friendly XML layout for adoption in newer fields like lab, GP EMR. Though it is newer BUT is less commonly used than V2 ("pipe and hats" format).

HL7 standard defines how to format text strings messages for communication among different devices in our medical system eg HIS RIS PACS LIS etc, analogous to formatting emails sending between peoples. HL7 messages are intended for machine use and comprise separate segments, each prefixed with a 3-letter code to indicate what type of information they hold eg The following segment contains message header information such as Message type (here, ADT) and trigger event (here, A01). MSH|^~\&|MegaReg|DSNHSFT|ImgOrdMgr|RadImgCtr|20170115090131- 0500||ADT^A01|01052901|P|2.8.2

Another segment start with PID contains current patient identification information. PID|||56782445^^^UAReg^PI~999855750^^^USSSA^SS||ATKINSONTEST^JAMES

HL7 messaging operates on a ‘read-back’ confirmation basis. As part of the message type, ADT (admit, discharge, or transfer) is an instruction to do something (the task where A0x code relates to). A01 shown above means admit a patient notification; A11, if used, would mean Cancel admission of patient. The prefx of ADT or ACK is appended depending on whether it is the original instruction from the requesting system (ADT), or the acknowledging response from the receiving system (ACK). eg MPI makes request to RIS using ADT-A04 instructing the RIS to register a patient. RIS completes the action requested and replies with an identical message, except replacing with an acknowledgement value in the message header: ACK-A04.

A PACS is a centralized computer system to manage healthcare images acquired by different modalities. It provides facility for storage, distribution, and display of its images. It can be used in any department (not just Radiology), including Cardiology, Pathology, Endoscopy etc. It consists of four discrete parts :

1. Short-term storage (local cache) - caters rapid viewing of new images
2. Longer term storage (archive) - store older images in online or offline media
3. Viewer application - basic/addon like 3D reconstruction; installable/web-based; cutdown/enhanced for dedicated workstation
4. Hierarchical database - all image files stored are populated and indexed in the form Patient > Study > Series > Images