A Module is a group of DICOM attributes which provide information for related data, such as the “Patient” or the “Equipment”. Use of modules make the writing of the DICOM standard easier, as Part 3 re-uses the same modules in multiple SOP Class definitions, but they are not a structural component of a DataSet, as this is instead sorted according to numerical order of the individual attributes.
Every DICOM Association starts with a process of negotiation whereby the Application Entities involved exchange sufficient information about themselves to allow proper communication. The information passed in the initial request includes: The AETs of the two applications The list of Presentation Contexts request, each containing a list of Transfer Syntaxes Any Reverse Role Negotiation requests Any Extended Negotiation requests Miscellaneous “User Information” including The name and UID of the software The maximum data packet size that may be received The acceptance packet contains mostly the same information but each Presentation Context is either accepted or rejected, and if accepted, only a single Transfer Syntax” per Presentation Context is specified.
lilatac Normalised objects are like Composite Objects in that they persist from one operation to another (normally in an SCP) but unlike Composite Objects, they only make sense in the context of other objects around them. Common examples of Normalised Object are: In Printing Basic Film Session Basic Film Box Basic Grayscale Image Box Basic Color Image Box In Modality Performed Procedure Step Service Performed Procedure Step Object
How overlay data is stored There are two ways to store overlays in DICOM Image: Overlay data stored in unused bit planes of the Pixel Data (7FE0,0010) with Samples Per Pixel (0028,0002) of 1. This usage has now retired. Overlay data stored in separate “Overlay pixel data” attribute (60xx,3000). Repeating Groups Multiple overlay planes are represented by standard data elements with even group numbers (ranging from 6000H to 601EH).
PACS, picture archiving and communication systems, is a term used for a set of computers connected by a network, and dedicated to the storage, retrieval, distribution, and presentation of medical images. A PACS is independent of the format of the information. Some vendors use the term VNA (Vendor Neutral Archive), but in most respects, the terms are synonymous. The Digital Imaging and Communications in Medicine (DICOM) standard format is the most common format for medical image data found in PACS.
This is a Normalised Instance which represents the state of a procedure step, and is: Created by the SCU using N-CREATE with a status of “IN PROGESS” Updated as necessary by the SCU using N-SET operations The final status must (updated by the N-SET) must be “COMPLETED” or “DISCONTINUED”
DICOM allows various relationships between the pixel data and how the image should be displayed. The values here are found in element 0028,0004 and every image should have that value.
The Planar Configuration attribute (0028,0006) is only used in DICOM colour images, and specifies how the pixel data are arranged.
A Presentation Context may be considered as a negotiated “sub-channel” with a DICOM Association through which the Application Entities have agreed to exchange information. A proposed presentation context consists of A presentation context ID (an odd integer <= 255, and unique within the association) A SOP Class or Meta SOP Class A list of proposed Transfer Syntaxes This is considered by the requesting Application Entity which either rejects it completely or accepts, in which case the list of proposed transfer syntaxes is replaced by a single accepted transfer syntax which is then used for all communications using that presentation context.
A Presentation State is an independent DICOM SOP Instance that contains information on how a particular image should be displayed. The Presentation State may contain label information(types of Label and Positions), windowing values, zoom value, scrolling (panning) values, rotations or any other visual display element that is defined within the DICOM standard. However Presentation States contain no Pixel Data as they are intended for use with an existing Dicom Image.
Annotations DICOM Printing contains a specification for ‘Annotations’, but the terminology is very confusing, so this page is designed to explain the facility, and avoid misunderstandings. When a FilmBox is created, it has 3 types of area, as in this diagram: Black Areas where pixel data can be printed (Using N-SET) Green ‘Annotations’ Yellow nothing can be printed here In general, the arrangement of the pixel data areas is defined by the Format string (e.
We are often asked how to persuade a DICOM printer to print images (normally plain radiographs) “TRUE” size. This is normally possible (depending on the capabilities of the printer) but is harder than expected, as the DICOM standard requires most of the relevant attributes (pixel size etc.) to be removed from an image before it is sent to the printer :-( The problem is compounded by the fact that the default behaviour of almost all printers is “scale to fit” - fitting the image as best they can into the space available on the film.
A Private SOP Class is an object constructed and transmitted in the same basic way as an official DICOM SOP Class but with the contents defined by the creator of the private SOP class, rather than by DICOM. Typically a piece of equipment which uses a private SOP class will try to negotiate both a Private SOP class and an official DICOM SOP Class for the images they send to a PACS, on the basis that only a PACS from the same manufacturer will accept the private one, with everyone else accepting only the DICOM one.
A “normal” DICOM Query, as part of the Query/Retrieve service, is used to ask about the patients, studies, series or images known to a Q/R SCP (normally a PACS). It uses the C-FIND operation (and was originally the only service using that operation, so this query service is often called just C-FIND, despite that fact that the C-FIND operation is also used for other services such as Modality Worklist).
Medical Connections supplies software toolkits and consultancy for healthcare integration with primary focus on DICOM & XDS
Company Number: 3680043
© 2019 Medical Connections Ltd
