Avoiding accepting private SOP classes

Many pieces of equipment 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. It is important that this behavior is maintained at the PACS in order to avoid accidentally accepting the private class(es).

The following pseudo-code (which will vary slightly from one development language to another) shows the principles:

Geometric Magnification

For plain radiographs (conventional x-rays), the size recorded on the film is always larger than the size of the object being imaged, due to an effect called geometric magnification. Moreover, as shown in the diagram below, the amount of magnification varies for different objects, depending on their distance from the film, so it is NOT in general possible to "correct" for such magnification without knowing the distance of the object from the film.

Hanging Protocols

Hanging protocols are a means of defining how images should initially be displayed to a user. They are otherwise known as "user display profiles" or "default display profiles", and have existed as proprietary systems for many years, but there is now a vendor-neutral DICOM method for creating, storing, and retrieving them.

What they use

Hanging protocols are actually quite complicated, as there are so many variables to consider:

Create Overlays

Does DicomObjects have functions to create Overlays?

DicomObjects does not have direct, simple ways to create DICOM overlays. This is because most people regard them as pretty obsolete, having been replaced since 1998 or so by DICOM Presentation_states, which we do fully support, using CurrentToPresentationState method.

Print 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:


DICOM DateTime Format

The Standard DICOM DateTime Format

The standard DateTime format (YYYYMMDD) is explained in Table 6.2-1 of Part 5 of the DICOM standard.

Root & Level

The ROOT is the overall data model, and there are two main roots in DICOM, STUDY and PATIENT. A third root model also exists called PATIENTSTUDY but it is very rarely used in DICOM.
Within each root structure, operations (find or GET or MOVE) are done at a particular LEVEL. The allowed combinations are:

Requirements for StudyUID in Modality Worklist Results

There are strict rules for UID formatting and usage. If these are not followed, then some modality equipment may refuse to accept MWL results containing "bad" UIDs. Not all equipment is equally "fussy", and in particular, most equipment will not check for leading zeros, but GE equipment nearly always does (there is sound logic for this, as they would be "outputting" faulty UIDs themselves is they accepted your bad UID).

The most common reasons for StudyUIDs not being accepted by modalities in Modality Worklist return results are:

Manual Editing of MWL data

It is a very bad and dangerous idea to let users (radiographers/techs) edit the data received through Modality_Worklist.

Here is a scenario:

There are 2 patients scheduled:


Subscribe to RSS - General-DICOM