White Paper

DICOM Frame of Reference: issues and proposal

Original version: Sven Floßmann (Brainlab), Christof Schadt (Brainlab), Katrin Stedele (Brainlab), Heinz Blendinger (Siemens), Thomas Möller (Siemens)

Updated by DICOM WG-02: Heinz Blendinger (Siemens), Donald Peck (Henry Ford Health, Detroit), Bas Revet (Philips), Francisco Sureda (GE), Annalisa Trianni (University Hospital Udine)

Draft

November 21, 2012

Contents

Introduction

Detailed Description

Example

Solutions

1) Reference Instances

2) Create a new FOR for each image acquisition

3) Specify that a frame-of-reference is “trustful”

4) Create a new “Frame of Reference content” attribute

Discussion

Discussion within WG-02

Angiography Scenarios

Scenario #1: Multiple reconstructions from same rotational acquisition

Scenario #2: Multiple rotational acquisitions within the same procedure

Scenario #3: Multiple rotational acquisitions within the same procedure, plus segmentation

Proposed Solutions

Use cases

Proposed solution

Example

Appendix

Introduction

The Frame-of Reference (FOR) is a well-defined and widely used concept in DICOM. It is used for defining spatial or temporal spaces and its relation to each other (see also PS 3.3 A.1.2.5).

Several IODs make use of the FOR concept. Examples are:

  • multiple image IODs
  • ultrasound volume
  • spatial registration
  • deformable spatial registration
  • surface segmentation
  • segmentation
  • raw data.

More applications are creating other DICOM objects than images and problems regarding the usage of the FOR have been observed. Depending on the application domain these problems have critical impact on patient treatments.

This white paper summarizes the status-quo of this discussion.

Detailed Description

The usage of the FOR in the DICOM standard assumes that the FOR is always accurate and well-defined. In fact, this is correct for e.g. spatial positions of DICOM objects, such as image positions.

However, since the content of e.g. images is the relevant information, it may happen that although the spatial / temporal relation is correctly defined, the spatial or temporal content is not well defined and therefore not correctly related.

The following example illustrates this issue:

Example

A modality creates the following image series which share the same FOR (FOR 1): Set 1 andSet 2. However, the content of the images slightly differ (because the patient might have moved in-between scans).

A contourer creates a segmentation object Object 1 based on the images in Set 1. The Object 1 uses the FOR of Set 1 to define the spatial position of Object 1.

Another system displays the Object 1 together with Set 2. Since the content of Set 1 and Set 2 slightly differ in spatial position the Object 1 is displayed on a wrong position in Set 2.

Further, different applications have different requirements on the FOR. For example if the FOR is used for synchronized scrolling, the current definition is suitable enough. It does not matter if the real content is shifted by small values (e.g. 5mm). However, if such DICOM content is used for radiotherapy or brain surgery, accuracy is very important. In that case the user of the FOR must rely on its "correctness".

Root causes for "incorrect" FOR might be:

  • Patient movement during image acquisition
  • Combined PET/CT scanners
  • Manual reset of the FOR on the modality

Taking this into account, the semantics of existing DICOM IODs like Spatial Registration is not well-defined and can be misinterpreted which might lead to patient harm.

Solutions

There are several solutions that try to solve the issues described above:

1) Reference Instances

A potential solution or even a workaround that solves the issues above is to reference real DICOM instances in addition to the FOR.

By directly referencing instances (e.g. a segmentation object references the images out of which it has been created) one can be absolutely sure that the object is spatially or temporally correct with respect to the explicitly referenced instances.

Taken the example from above:

  • The segmentation object Object 1 does not only reference the FOR 1, but also the image instances of Set 1.
  • If an application displays Object 1 and the images of Set 1, the application can determine that they share the same FOR and the same image instances and can therefore be absolutely sure the Object 1 can be displayed within the image of Set 1 with a correct spatial position.
  • If an application displays Object 1 and the images of Set 2, the application can be aware that Object 1 and Set 2 share the same frame-of-reference, but since they do not share the same image instances it is not safe to display Object 1 together with images of Set 2 without further approval.

2) Create a new FORfor each image acquisition

On a first view, the following might be a solution as well. If the sources of potential inaccuracies can be eliminated, the FOR can be made safe.

One way to do this is that modalities always use a new FORfor each scan that is performed.

However, this has several drawbacks:

a)There are still existing images available that cannot be fixed in that way. Even though they might be used for applications that rely on an exactly defined spatial position.

b)On cannot determine if a modality always creates new FORs for each image acquisition.

c)Well-established features based on the FOR like synchronized scrolling will not work anymore.

3) Specify that a frame-of-reference is “trustful”

Another way of solving the issue might be to add the information that a FOR is "safe". For example one can add an additional flag for expressing that a frame-of-reference is safe. This flag has to be added to each occurrence of the FOR, not only to the image instance.

This solution has also several disadvantages:

a)What is the definition of a "safe" FOR?

If the definition is too strict, again well-established feature like scrolling might not work anymore.

If the definition is too lose, the same situation as now will arise.

b)How to define the "trustful"? Is it a flag? Who defines if a FOR is "trustful"?

4) Create a new “Frameof Referencecontent”attribute

Introduce a new FORfor the content, not the objects itself.

As potential solutions above showed, it is difficult, if not impossible, to redefine the FOR. One main reason is that the FOR is used for at least two different applications with different accuracies. It will not be possible to define both requirements with one concept.

Therefore, a solution could be to create a new type of FOR that explicitly defines the correct correlation of the referenced content.

That would mean the following:

a)It is only allowed to use the same "Frameof ReferenceContent" if the content is exactly at the same position (e.g. an object is exactly defined within some other instances or images have been re-sampled and are exactly at a specific position).

b)Since modalities cannot guarantee that the content's spatial / temporal position didn't change between successive scans, modalities always have to create new "Frame of Reference Content" but can continue to create the "standard" FOR.

Discussion

It is obvious that solution 2 (Create a new FOR for each image acquisition) and 3 (Specify that a frame-of-reference is “trustful”) will not solve the issues permanently or without creating a new problem.

Solution 1 (Reference Instances) solves the problem itself, but is cumbersome. It has the advantage that almost no changes on the DICOM standard are necessary[1].

Although solution 1 solves the issue itself a more convenient solution is appreciated. Solution 4 would combine both use-cases in a convenient way:

a)The existing FOR can be used as it has been used in the past. Well established features will continue to work.

b)Applications that rely on exact spatial / temporal position will have a mechanism to define that relation.

Discussion within WG-02

In the following sections are the results of the discussions held in Munich April’12, Udine June’12 and Paris October’12 within the WG-02 and based on discussions/emails withSven Floßmann,

Angiography Scenarios

In the scenarios involving rotational angiography acquisitions and their subsequent X-Ray 3D reconstructions, the FOR is used with different accuracy.

Scenario #1: Multiple reconstructions from same rotational acquisition

In this scenario, the reconstruction application generates several instances of the 3D model from the same rotational acquisition, for example by applying different settings like slice thickness, noise reduction algorithm, filtering algorithm etc…. The reconstruction application uses the same patient origin to relate all the 3D models; therefore the 3D models share the same FOR.

In this case the spatial content of both 3D models is accurately related (i.e. FOR is trustful).

Scenario #2: Multiple rotational acquisitions within the same procedure

In this scenario, the rotational acquisitions are performed within the same procedure but at different times, typically before and after the treatment. The X-Ray equipment controls the positioning of the X-Ray beam and its relationship with the table and patient along the procedure. Assuming that the equipment defines the patient origin to be common to all the acquisitions (e.g patient origin located at a fixed point with respect to the table), and that all the 3D models reconstructed during the same procedure are related to the same patient origin, one could say that all these 3D models share the same FOR.

From this perspective, the FOR allows the registration of these 3D models in the same 3D space. On the other hand the equipment might not control perfectly whether the patient moved or not between the acquisitions, and consequently a small patient movement would lead to misregistration of two 3D models.

In this case the spatial content of both 3D models is not accurately related (FOR is not trustful).

Note: if the operator knows that the patient position and orientation have really changed during the procedure, the equipment typically would allow defining a different FOR for different acquisitions, because the patient origin cannot be common to all the acquisitions.

In the figure below, the instances with the same color do share a trustful FOR.

Scenario #3: Multiple rotational acquisitions within the same procedure, plus segmentation

In this scenario, there is an additional segmentation of the first 3D model. The segmentation instance does share the same FOR as the 3D model where the segmentation was performed. The spatial content of the 3D models and its segmentation object is accurately related, while the spatial content of the segmentation instance and the second 3D model are not accurately related.

In the figure below, the instances with the same color do share a trustful FOR.

Proposed Solutions

From the previous chapters, the end goal is to know whether or not two images (or volumes) with the same FOR UID are accurately related in the same 3D coordinate system (i.e. if they share a trustful FOR).

Use cases

The following list contains some use cases to consider. This list may not be complete.

1-CT/MR: two different scans of different body parts while the patient is still on the table

2-Angiography: two different rotational acquisitions of the same body part while the patient is still on the table

3-PET and CT acquired simultaneously on the same equipment

4-CT and MR registration and creation of a new FOR

5-Angiography: two 3D reconstructions from the same 2D rotational acquisition

6-Any modality: Segmentation of an existing 3D model

Proposed solution

The proposed solution is based on the solution #1above. It consists in the definition of new DICOM attributes to allow knowing whether or not two instances with the same FOR UID are accurately (trustfully) related in the same 3D coordinate system.Therefore, each newly created instance that uses the FOR of the source instance shall document the Instance UID(s) of the source only if they share a trustful FOR.

Attribute Name / Group, Element
FOR UID / (0020,0052)
FOR Instance Sequence / (0020,xxxx)
FOR Source Instance UID / (xxxx,xxxx)

Notes:

1-The FOR Instance Sequencewill be absent if the instance is generated from equipment internal data (e.g. first CT reconstruction, 2D rotational acquisition…).

2-The FOR Instance Sequence will be absent if the new generated instance does not share a trustful FOR with any of the sources.

3-Equipment will have the ability to decide whether or not the FOR of two consecutive acquisitions is trustful.

4-Each new generated instance that shares a trustful FOR with the source(s) shall copy all the items of the FOR Instance Sequenceof the source(s) and add a new item for thesource(s) Instance UID.

5-If only the FOR UID attribute is present in two instances (e.g. legacy instances), an application cannot decide whether or not they share a trustful FOR.

Note that there could be a better way to reference the sources instead of the FOR Source Instance UID. For example by using the Source Instance Sequence (0042,0013), the Referenced Series Sequence (0008,1115), or the SOP Instance Reference Macro (10-11).

Example

The following is an example of a complexworkflow of FOR generation in Rotational Angiography. In the figures below, the instances with the same color do share a trustful FOR.

The chain of FOR generation can be represented as a graph. Each node is an instance, all the nodes of the graph share the same FOR UID. The nodes are linked two-by-two with an FOR relationship that can be trustful or not. A solid-line link indicates a trustful FOR relationship; a dotted-line link indicatesa non-trustful FOR relationship. The first node (white) indicates the entity or application that created the FOR UID (e.g. acquisition equipment, registration application…).

The following table shows the values of the attributes of the instances in this example:

Instances with the same FOR UID
2D Rotational Acquisition / 3D Reconstruction / Segmentation
2D Instance #1:
Instance UID = 2D_1 / 3D Instance #1:
Instance UID = 3D_1
FOR Instance Sequence
>FOR Source Instance UID = 2D_1 / SEG Instance #1:
Instance UID = SEG_1
FOR InstanceSequence
>FOR Source Instance UID = 2D_1
>FOR Source Instance UID = 3D_1
3D Instance #2:
Instance UID = 2D_2 / 3D Instance #2:
Instance UID = 3D_2
FOR InstanceSequence
>FOR Source Instance UID = 2D_2 / SEG Instance #2:
Instance UID = SEG_2
FOR InstanceSequence
>FOR Source Instance UID = 2D_2
>FOR Source Instance UID = 3D_2
3D Instance #3:
Instance UID = 3D_3
FOR InstanceSequence
>FOR Source Instance UID = 2D_2
3D Instance #4:
Instance UID = 3D_4 / SEG Instance #4:
Instance UID = SEG_4
FOR InstanceSequence
>FOR Source Instance UID = 3D_4

Two instances A and B share a trustful FOR if they have the same FOR UID and in the FOR Instance Sequence of A (B) there is at least one item that references either the SOP instance B (A)or one of the items of the FOR Instance Sequence of B (A).

Notes:

  • If this proposal is compared with the first four solutions, one notices that the proposal is pretty close to solution #1. However, the main difference is that the FOR Instance Sequence provides a more clearly semantic on why a SOP Instance is referenced. In the solution #1, there is no further specification on which attribute shall reference the images. The referencing must be done on existing attributes that “sound suitable enough” for making the FOR safe, like Segment Surface Source Instance Sequence (0066,002E) or Derivation Image Sequence (0008,9124).
  • With referencing instances, it is further possible to construct the following situation:
    Instance X, referencing A, B, C
    Instance Y, referencing D, E, F
    Instance Z, referencing A, B, C, D, E, F
    Assumed that A, B and C are in the same trustful FOR 1 and D, E, F are in another trustful FOR 1’, the Instance Z will make the FOR 1 and 1’ “transitively” trustful, although they aren’t.This scenario cannot happen with the solution #1.
    If this scenario would be modeled with a new FOR-Attribute (solution #4), then the following would happen:
    Instance X in the “FOR-Content” F1
    Instance Y in the “FOR Content” F2
    Instance Z in the “FOR Content” F1 or F2
    One has to decide whether to use F1 or F2. It is not possible to use both.

Appendix

A.1.2.5 FRAME OF REFERENCE IE

The Frame of Reference IE identifies the coordinate system that conveys spatial and/or temporal information of composite instances in a series.

When present, a Frame of Reference IE may be related to one or more series. In this case, it provides the ability to spatially or temporally relate multiple series to each other. In such cases, the series may share the UID of the Frame of Reference, or alternatively, a Registration SOP Instance may specify the spatial relationship explicitly, as a spatial transformation. A Frame of Reference IE may also spatially register a Frame of Reference to an atlas.

White Paper: DICOM Frame of ReferencePage 1November 21, 2012

[1]CP 1166 is a pre-requisite.