FFF.2 Application Cases

This chapter describes different scenarios and application cases organized by domains of application. Each application case is basically structured in four sections:

  1. User Scenario : Describes the user needs in a specific clinical context, and/or a particular system configuration and equipment type.

  2. Encoding Outline : Describes the specificities of the XA SOP Class and the Enhanced XA SOP Class related to this scenario, and highlights the key aspects of the Enhanced XA SOP Class to address it.

  3. Encoding Details : Provides detailed recommendations of the key attributes of the object(s) to address this particular scenario.

  4. Example : Presents a typical example of the scenario, with realistic sample values, and gives details of the encoding of the key attributes of the object(s) to address this particular scenario. In the values of the attributes, the text in bold face indicates specific attribute values; the text in italic face gives an indication of the expected value content.

FFF.2.1 Acquisition

FFF.2.1.1 ECG Recording at Acquisition Modality

This application case is related to the results of an X-Ray acquisition and parallel ECG data recording on the same equipment.

FFF.2.1.1.1 User Scenario

The image acquisition system records ECG signals simultaneously with the acquisition of the Enhanced XA multi-frame image. All the ECG signals are acquired at the same sampling rate.

The acquisition of both image and ECG data are not triggered by an external signal.

The information can be exchanged via Offline Media or Network.

Synchronization between the ECG Curve and the image frames allows synchronized navigation in each of the datasets.

[pic]

Figure FFF.2.1-1Scenario of ECG Recording at Acquisition Modality

FFF.2.1.1.2 Encoding outline

The General ECG IOD is used to store the waveform data recorded in parallel to the image acquisition encoded as Enhanced XA IOD.

The Synchronization Module is used to specify a common time-base.

The option of encoding trigger information is not recommended by this case.

The solution assumes implementation on a single imaging modality and therefore the mutual UID references between the General ECG and Enhanced XA objects is recommended. This will allow faster access to the related object.

FFF.2.1.1.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

FFF.2.1.1.3.1 Enhanced XA Image

Table FFF.2.1-1ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Series General Series C.7.3.1 The General Series Module Modality (0008,0060) attribute description in PS 3.3 enforces the storage of waveform and pixel data in different Series IE.
Frame of Reference Synchronization C.7.4.2 Specifies that the image acquisition is synchronized. Will have the same content as the General ECG SOP Instance.
Equipment General Equipment C.7.5.1 Same as in the General ECG SOP Instance.
Image Cardiac Synchronization C.7.6.18.1 Contains information of the type of relationship between the ECG waveform and the image.
Enhanced XA/XRF Image C.8.19.2 Contains UID references to the related General ECG SOP Instance.

Table FFF.2. 1- 2 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame Content C.7.6.16.2.2 Provides timing information to correlate each frame to the recorded ECG samples.
Cardiac Synchronization C.7.6.16.2.7 Provides time relationships between the angiographic frames and the cardiac cycle.

FFF.2.1.1.3.1.1 Synchronization Module Recommendations

The usage of this Module is recommended to encode a “synchronized time” condition.

The specialty of Synchronization Triggers is not part of this scenario.

Table FFF.2.1-3 SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Synchronization Frame of Reference UID (0020,0200) Same UID as in the related General ECG SOP Instance.
Synchronization Trigger (0018,106A) In this scenario with no external trigger signal, the value “NO TRIGGER” is used.
Acquisition Time Synchronized (0018,1800) The value “Y” is used in this scenario.

FFF.2.1.1.3.1.2 General Equipment Module Recommendations

The usage of this Module is recommended to assure that the image contains identical equipment identification information as the referenced General ECG SOP Instance.

FFF.2.1.1.3.1.3 Cardiac Synchronization Module Recommendations

The usage of this module is recommended to indicate that the ECG is not used to trig the X-Ray acquisition, rather to time relate the frames to the ECG signal.

Table FFF.2.1-4 CARDIAC SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Cardiac Synchronization Technique (0018,9037) The value “REAL TIME” is used in this scenario.
Cardiac Signal Source (0018,9085) In this scenario, the value “ECG” is used to indicate that the cardiac waveform is an electrocardiogram.

FFF.2.1.1.3.1.4 Enhanced XA/XRF Image Module Recommendations

The usage of this module is recommended to reference from the image object to the related General ECG SOP Instance that contains the ECG data recorded simultaneously.

Table FFF.2.1-5 ENHANCED XA/XRF IMAGE MODULE Recommendations

Attribute Name Tag Comment
Referenced Instance Sequence (0008,114A) Reference to “General ECG SOP Instance” acquired in conjunction with this image. Contains a single item.
>Referenced SOP Class UID (0008,1150) 1.2.840.10008.5.1.4.1.1.9.1.2” i.e. reference to an General ECG SOP Instance
>Referenced SOP Instance UID (0008,1155) Instance UID of referenced waveform
>Purpose of Reference Code Sequence (0040,A170) CID 7004 is used; identify clear reason for the Reference.

FFF.2.1.1.3.1.5 Cardiac Synchronization Macro Recommendations

If there is a specific ECG analysis that determines the time between the R-peaks and the angiographic frames, the usage of this macro is recommended.

As the frames are acquired at a frame rate independent of cardiac phases, this macro is used in a “per frame functional group” to encode the position of each frame relative to its prior R-peak.

FFF.2.1.1.3.1.6 Frame Content Macro Recommendations

In this scenario the timing information is important to correlate each frame to the recorded ECG.

If there is a specific ECG analysis, this macro allows the encoding of the position in the cardiac cycle that is most representative of each frame.

The following table gives recommendations for usage in this scenario.

Table FFF.2.1-6 FRAME CONTENT MACRO Recommendations

Attribute Name Tag Comment
Frame Content Sequence (0020,9111)
>Frame Reference Datetime (0018,9151) Exact Time taken from the internal clock.
>Frame Acquisition Datetime (0018,9074) Exact Time taken from the internal clock.
>Cardiac Cycle Position (0018,9236) Optional, if ECG analysis is available.

FFF.2.1.1.3.2 General ECG Object

This IOD will encode the recorded ECG waveform data, which is done by the image acquisition system. Since this is not a dedicated waveform modality device, appropriate defaults for most of the data have to be recommended to fulfill the requirements according to PS 3.3.

Table FFF.2. 1-7 General ECG IOD Modules

IE Module PS 3.3 Reference Usage
Series General Series C.7.3.1 The General Series Module Modality (0008,0060) attribute description in PS 3.3 enforces the storage of waveform and pixel data in different Series IE.
Frame of Reference Synchronization C.7.4.2 Specifies that the waveform acquisition is synchronized. Will have the same content as the image.
Equipment General Equipment C.7.5.1 Same as in the image.
Waveform Waveform Identification C.10.8 Contains references to the related image object.
Waveform C.10.9 Contains one multiplex group with the same sampling rate.

FFF.2.1.1.3.2.1 General Series Module Recommendations

A new Series is created to set the modality “ECG” for the waveform.

Most of the attributes are aligned with the contents of the related series level attributes in the image object.

The Related Series Sequence (0008,1250) is not recommended because instance level relationship can be applied to reference the image instances.

Table FFF.2. 1-8 GENERAL SERIES MODULE Recommendations

Attribute Name Tag Comment
Modality (0008,0060) “ECG”
Series Instance UID (0020,000E) Different from the one of the image object.
Series Date (0008,0021) Identical to the contents of related image object
Series Time (0008,0031) Identical to the contents of related image object.
Other attributes of General Series Module Match contents of related image object, if set there.

FFF.2.1.1.3.2.2 Synchronization Module Recommendations

The usage of this Module is recommended to encode a “synchronized time” condition, which was previously implicit when using the curve module.

Table FFF.2.1-9 SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Synchronization Frame of Reference UID (0020,0200) Same UID as in the related image object.
Synchronization Trigger (0018,106A) The value “NO TRIGGER” is used in this scenario with no external trigger signal.
Acquisition Time Synchronized (0018,1800) The value “Y” is used to allow synchronized navigation.

FFF.2.1.1.3.2.3 General Equipment Module Recommendations

The usage of this Module is recommended to assure that the General ECG SOP Instance contains identical equipment identification information as the referenced image objects.

FFF.2.1.1.3.2.4 Waveform Identification Recommendations

The usage of this module is recommended to relate the acquisition time of the waveform data to the image acquired simultaneously.

The module additionally includes an instance level reference to the related image.

Table FFF.2.1-10 WAVEFORM IDENTIFICATION MODULE Recommendations

Attribute Name Tag Comment
Acquisition Datetime (0008,002A) Exact start of the waveform acquisition taken from common (or synchronized) clock. Note: In case the ECG acquisition started before the image acquisition itself, the given datetime value is not the same as for the image.
Referenced Instance Sequence (0008,114A) Only one item used in this application case.
>Referenced SOP Class UID (0008,1150) 1.2.840.10008.5.1.4.1.1.12.1.1” i.e. Enhanced XA
>Referenced SOP Instance UID (0008,1155) Instance UID of Enhanced XA Image Object to which this parallel ECG recording is related.
>Purpose of Reference Code Sequence (0040,A170) The referenced image is related to this ECG.

FFF.2.1.1.3.2.5 Waveform Module Recommendations

The usage of this module is a basic requirement of the General ECG IOD.

Any application displaying the ECG is recommended to scale the ECG contents to its output capabilities (esp. the amplitude resolution).

If more than one ECG signal needs to be recorded, the grouping of the channels in multiplex groups depends on the ECG sampling rate. All the channels encoded in the same multiplex group have identical sampling rate.

Table FFF.2.1-11 WAVEFORM MODULE Recommendations

Attribute Name Tag Comment
Waveform Sequence (5400,0100) Only one item is used in this application case, as all the ECG signals have the same sampling rate.
> Multiplex Group Time Offset (0018,1068) If needed, specify the Group Offset from the Acquisition Datetime.
> Waveform Originality (003A,0004) The value “ORIGINAL” is used in this scenario.

FFF.2.1.1.4 Examples

In the two following examples, the Image Modality acquires a multi-frame image of the coronary arteries lasting 4 seconds, at 30 frames per second.

Simultaneously, the same modality acquires two channels of ECG from a 2-Lead ECG (the first channel on Lead I and the second on Lead II) starting one second before the image acquisition starts, and lasting 5 seconds, with a sampling frequency of 300 Hz on 16 bits signed encoding, making up a number of 1500 samples per channel. The first ECG sample is 10 ms after the nominal start time of the ECG acquisition. Both ECG channels are sampled simultaneously. The time skew of both channels is 0 ms.

[pic]

Figure FFF.2.1-2Example of ECG Recording at Acquisition Modality

FFF.2.1.1.4.1 Enhanced XA image without cardiac synchronization

In this example, the Enhanced XA image does not contain information of the cardiac cycle phases.

The attributes that define the two different SOP Instances (Enhanced XA and General ECG) of this example are described in the following figures:

ENHANCED XA SOP INSTANCE

Study Instance UID (0020,000D) = UID “A”
Modality (0008,0060) = XA
Synchronization Trigger (0018,106A) = NO TRIGGER
Acquisition Time Synchronized (0018,1800) = Y
Referenced Instance Sequence (0008,114A)
Item 1
>Referenced SOP Class UID (0008,1150)
Series Instance UID (0020,000E) = UID “F”
Modality (0008,0060) = ECG
Synchronization Frame of Reference UID (0020,0200) = UID “C”
Synchronization Trigger (0018,106A) = NO TRIGGER
Acquisition Time Synchronized (0018,1800) = Y
SOP Instance UID (0008,0018) = UID “E”
Referenced Instance Sequence (0008,114A)
Item 1
>Referenced SOP Class UID (0008,1150) = 1.2.840.10008.5.1.4.1.1.12.1.1
>Referenced SOP Instance UID (0008,1155) = UID “D”
>Purpose of Reference Code Sequence (0040,A170)
Item 1
Item 1 Only one ECG Multiplex Group
>Multiplex Group Time Offset (0018,1068) = 10
>Waveform Originality (003A,0004) = ORIGINAL
>Number of Waveform Channels (003A,0005) = 2
>Number of Waveform Samples (003A,0010) = 1500
>Sampling Frequency (003A,001A) = 300
>Channel Definition Sequence (003A,0200)
Item 1
>Waveform Sample Interpretation (5400,1006) = SS

Figure FFF.2.1-3Attributes of ECG Recording at Acquisition Modality

FFF.2.1.1.4.2 Enhanced XA image with cardiac synchronization

In this example, the heart rate is 75 beats per minute. As the image is acquired during a period of four seconds, it contains five heartbeats.

The ECG signal is analyzed to determine the R-peaks and to relate them to the angiographic frames. Thus the Enhanced XA image contains information of this relationship between the ECG signal and the frames.

[pic]

Figure FFF.2.1- 4 Example of ECG information in the Enhanced XA image

The attributes that define the two different SOP Instances (Enhanced XA and General ECG) of this example are described in the figures of the previous example, in addition to the attributes described in the following figures:

ENHANCED XA SOP INSTANCE

Cardiac Synchronization Technique (0018,9037) = REALTIME
Cardiac Signal Source (0018,9085) = ECG
Cardiac RR Interval Specified (0018,9070) = 800
Intervals Acquired (0018,1083) = 5
Intervals Rejected (0018,1084) = 0
Per-Frame Functional Groups Sequence (5200,9230)    
  Item i     Frame “i”
    >Cardiac Synchronization Sequence (0018,9118)    
      Item 1      
       
Frame of Reference Synchronization C.7.4.2 Specifies that the image acquisition is time synchronized with the ECG acquisition. Will have the same content as the General ECG SOP Instance.
Image Enhanced XA/XRF Image C.8.19.2 Specifies the date and time of the image acquisition.

Table FFF.2. 1-13 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame Content C.7.6.16.2.2 Provides timing information to correlate each frame to any externally recorded waveform.

FFF.2.1.2.1.3.1.1 Synchronization Module Recommendations

This Module is used to document the synchronization of the two modalities.

Table FFF.2.1-14 SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Synchronization Frame of Reference UID (0020,0200) The UTC Synchronization UID “1.2.840.10008.15.1.1” is used in this case.
Synchronization Trigger (0018,106A) The value “NO TRIGGER” is used for the case of time synchronization via NTP.
Acquisition Time Synchronized (0018,1800) The value “Y” is used in this scenario.
Time Source (0018,1801) The same value as in the related General ECG SOP Instance is used in this scenario.
Time Distribution Protocol (0018,1802) The value “NTP” is used in this scenario.
NTP Source Address (0018,1803) The same value as in the related General ECG SOP Instance is used in this scenario.

FFF.2.1.2.1.3.1.2 Enhanced XA/XRF Image Module Recommendations

This module includes the acquisition date and time of the image, which is in the same time basis as the acquisition date and time of the ECG in this scenario.

FFF.2.1.2.1.3.1.3 Frame Content Macro Recommendations

In this scenario the timing information is important to correlate each frame to any externally recorded waveform.

Table FFF.2.1-15 FRAME CONTENT MACRO Recommendations

Attribute Name Tag Comment
Frame Content Sequence (0020,9111)
>Frame Reference Datetime (0018,9151) Exact date and time taken from the synchronized clock.
>Frame Acquisition Datetime (0018,9074) Exact date and time taken from the synchronized clock.

FFF.2.1.2.1.3.2 Waveform Object

The ECG recording system will take care of filling in the waveform-specific contents in the General ECG SOP Instance. This section will address only the specifics for attributes related to synchronization.

Table FFF.2. 1-16 Waveform IOD Modules

IE Module PS 3.3 Reference Usage
Frame of Reference Synchronization C.7.4.2 Specifies that the ECG acquisition is time synchronized with the image acquisition. Will have the same content as the Enhanced XA SOP Instance. See section FFF.2.1.2.1.3.1.1.
Waveform Waveform Identification C.10.8 Provides timing information to correlate the waveform data to any externally recorded image.

FFF.2.1.2.1.3.2.1 Waveform Identification Recommendations

The usage of this module is recommended to relate the acquisition time of the waveform data to the related image(s).

Table FFF.2.1-18 WAVEFORM IDENTIFICATION MODULE Recommendations

Attribute Name Tag Comment
Acquisition Datetime (0008,002A) Exact start of the waveform acquisition: taken from synchronized clock.

FFF.2.1.2.1.4 Example

In this example, there are two modalities that are synchronized with an external clock via NTP. The Image Modality acquires three multi-frame images within the same Study and same Series. Simultaneously, the Waveform Modality acquires the ECG non-stop during the same period, leading to one single Waveform SOP Instance on a different Study.

In this example, there is no UID referencing capability between the two modalities.

[pic]

Figure FFF.2.1-7Example of Multi-modality Waveform Synchronization

The attributes that define the relevant content in the two different SOP Instances (Enhanced XA and General ECG) are described in the following figure:

ENHANCED XA SOP INSTANCES

Study Instance UID (0020,000D) = UID “A”
Series Instance UID (0020,000E) = UID “B”
Modality (0008,0060) = XA
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = NO TRIGGER
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “D1”, “D2” and “D3” resp.

GENERAL ECG SOP INSTANCE

Study Instance UID (0020,000D) = UID “E”
Series Instance UID (0020,000E) = UID “F”
Modality (0008,0060) = ECG
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = NO TRIGGER
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “H”

Figure FFF.2.1-8Attributes of Multi-modality Waveform NTP Synchronization

FFF.2.1.2.2 One Modality Sends Trigger to the other Modality

FFF.2.1.2.2.1 User Scenario

Image runs are taken by the image acquisition modality. Waveforms are recorded by waveform recording modality. Both modalities are time synchronized via NTP. The acquisition in one modality is triggered by the other modality. The resulting objects will include the time synchronization and trigger synchronization concepts.

There are two cases depending on the triggering modality:

  1. At X-Ray start, the image modality sends a trigger signal to the waveform modality.

  2. The waveform modality sends trigger signals to the image modality to start the acquisition of each frame.

[pic]

Figure FFF.2.1- 9 Scenario of Multi-modality Waveform Synchronization

FFF.2.1.2.2.2 Encoding outline

Dedicated Waveform IODs exist to store captured waveforms. In this case, General ECG IOD is used to store the waveform data.

With the Synchronization Module information, the method to implement the triggers can be documented.

The Enhanced XA IOD provides per-frame encoding of the timing information related to each frame.

FFF.2.1.2.2.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

FFF.2.1.2.2.3.1 Enhanced XA Image

Table FFF.2. 1- 19 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Frame of Reference Synchronization C.7.4.2 Specifies that the image acquisition triggers (or is triggered by) the ECG acquisition, and that they are time synchronized.
Image Enhanced XA/XRF Image C.8.19.2 Specifies the date and time of the image acquisition. .

Table FFF.2. 1-20 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame Content C.7.6.16.2.2 Provides timing information of each frame.

FFF.2.1.2.2.3.1.1 Synchronization Module Recommendations

The usage of this Module is recommended to document the triggering role of the image modality.

Table FFF.2.1-21 SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Synchronization Frame of Reference UID (0020,0200) The UTC Synchronization UID “1.2.840.10008.15.1.1” is used in this case.
Synchronization Trigger (0018,106A) The value “SOURCE” is used when the image modality sends a trigger signal to the waveform modality. The value “EXTERNAL” is used when the image modality receives a trigger signal from the waveform modality.
Trigger Source or Type (0018,1061) If Synchronization Trigger (0018,106A) equals SOURCE, then ID of image equipment. If Synchronization Trigger (0018,106A) equals EXTERNAL, then ID of waveform equipment if it is known.
Acquisition Time Synchronized (0018,1800) The value “Y” is used in this scenario.
Time Source (0018,1801) The same value as in the related General ECG SOP Instance is used in this scenario.
Time Distribution Protocol (0018,1802) The value “NTP” is used in this scenario.
NTP Source Address (0018,1803) The same value as in the related General ECG SOP Instance is used in this scenario.

FFF.2.1.2.2.3.1.2 Enhanced XA/XRF Image Module Recommendations

This module includes the acquisition date and time of the image.

Table FFF.2.1-22 ENHANCED XA/XRF IMAGE MODULE Recommendations

Attribute Tag Comment
Acquisition DateTime (0008,002A) Exact date and time taken from the synchronized clock.

FFF.2.1.2.2.3.1.3 Frame Content Macro Recommendations

In this scenario the timing information does not allow relating each frame to any externally recorded waveform.

Table FFF.2.1-23 FRAME CONTENT MACRO Recommendations

Attribute Name Tag Comment
Frame Content Sequence (0020,9111)
>Frame Reference Datetime (0018,9151) Exact date and time taken from the synchronized clock.
>Frame Acquisition Datetime (0018,9074) Exact date and time taken from the synchronized clock.

FFF.2.1.2.2.3.2 Waveform Object

The recording system will take care of filling in the waveform-specific contents, based on the IOD relevant for the type of system (e.g., EP, Hemodynamic, etc.). This section will address only the specifics for attributes related to synchronization.

Table FFF.2. 1-24 Waveform IOD Modules

IE Module PS 3.3 Reference Usage
Frame of Reference Synchronization C.7.4.2 Specifies that the ECG acquisition triggers (or is triggered by) the image acquisition, and that they are time synchronized.
Waveform Waveform Identification C.10.8 Specifies the date and time of the ECG acquisition.
Waveform C.10.9 Specifies the time relationship between the trigger signal and the ECG samples.

FFF.2.1.2.2.3.2.2 Synchronization Module Recommendations

The usage of this Module is recommended to document the triggering role of the waveform modality.

Table FFF.2.1-25 SYNCHRONIZATION MODULE Recommendations

Attribute Name Tag Comment
Synchronization Frame of Reference UID (0020,0200) The UTC Synchronization UID “1.2.840.10008.15.1.1” is used in this case.
Synchronization Trigger (0018,106A) The value “EXTERNAL” is used when the waveform modality receives a trigger signal from the image modality. The value “SOURCE” is used when the waveform modality sends a trigger signal to the image modality.
Trigger Source or Type (0018,1061) If Synchronization Trigger (0018,106A) equals SOURCE, then ID of Waveform equipment. If Synchronization Trigger (0018,106A) equals EXTERNAL, then ID of image equipment if it is known.
Synchronization Channel (0018,106C) Number or ID of Synchronization channel recorded in this waveform.
Acquisition Time Synchronized (0018,1800) The value “Y” is used in this scenario.
Time Source (0018,1801) The same value as in the related image SOP Instance is used in this scenario.
Time Distribution Protocol (0018,1802) The value “NTP” is used in this scenario.
NTP Source Address (0018,1803) The same value as in the related image SOP Instance is used in this scenario.

FFF.2.1.2.2.3.2.3 Waveform Identification Module Recommendations

This module includes the acquisition date and time of the waveform, which may be different than the acquisition date and time of the image in this scenario.

Table FFF.2.1-26 WAVEFORM IDENTIFICATION MODULE Recommendations

Attribute Name Tag Comment
Acquisition Datetime (0008,002A) Exact date and time taken from the internal clock of the Waveform modality. It may be different from the acquisition datetime of the Enhanced XA SOP instance.

FFF.2.1.2.2.3.2.4 Waveform Module Recommendations

The usage of this module is recommended to encode the time relationship between the trigger signal and the ECG samples.

Table FFF.2.1-27 WAVEFORM MODULE Recommendations

Attribute Name Tag Comment
Waveform Sequence (5400,0100) Only one item is used in this application case, as all the ECG signals have the same sampling rate.
>Multiplex Group Time Offset (0018,1068) If needed, specify the Group Offset from the Acquisition Datetime.
>Waveform Originality (003A,0004) The value “ORIGINAL” is used in this scenario.
>Trigger Time Offset (0018,1069) In case the waveform recording started with a synchronization trigger from the image modality, this value allows specifying the time relationship between the trigger and the ECG samples.
>Trigger Sample Position (0018,106E) In case the waveform recording started with a synchronization trigger from the image modality, this value allows specifying the waveform sample corresponding to the trigger sent from the image modality.

FFF.2.1.2.2.4 Examples

FFF.2.1.2.2.4.1 Image modality sends trigger to the waveform modality

In this example, there are two modalities that are synchronized with an external clock via NTP. The Image Modality acquires three multi-frame images within the same Study and same Series. Simultaneously, the Waveform Modality acquires the ECG non-stop during the same period, leading to one single Waveform SOP Instance on a different Study. The ECG sampling frequency is 300 Hz on 16 bits signed encoding, making up a number of 1500 samples per channel. The first ECG sample is acquired at nominal start time of the ECG acquisition.

The image modality sends a trigger to the waveform modality at the start time of each of the three images. This signal is stored in one channel of the waveform modality, together with the ECG signal.

In this example, there is no UID referencing capability between the two modalities.

[pic]

Figure FFF.2.1-10Example of Image Modality as Source of Trigger

The attributes that define the relevant content in the two different SOP Instances (Enhanced XA and General ECG) are described in the following figure:

ENHANCED XA SOP INSTANCES

Study Instance UID (0020,000D) = UID “A”
Series Instance UID (0020,000E) = UID “B”
Modality (0008,0060) = XA
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = SOURCE
Trigger Source or Type (0018,1061) = Imaging System ID
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “D1”, “D2” and “D3” resp.

GENERAL ECG SOP INSTANCE

Study Instance UID (0020,000D) = UID “E”
Series Instance UID (0020,000E) = UID “F”
Modality (0008,0060) = ECG
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = EXTERNAL
Trigger Source or Type (0018,1061) = Imaging System ID
Synchronization Channel (0018,106C) = 1\2
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “H”

Waveform Sequence (5400,0100)
Item 1 Only one ECG Multiplex Group
>Multiplex Group Time Offset (0018,1068) = 0
>Waveform Originality (003A,0004) = ORIGINAL
>Number of Waveform Channels (003A,0005) = 2
>Number of Waveform Samples (003A,0010) = 1500
>Sampling Frequency (003A,001A) = 300
>Channel Definition Sequence (003A,0200)
Item 1
>Waveform Sample Interpretation (5400,1006) = SS

Figure FFF.2.1-11Attributes when Image Modality is the Source of Trigger

FFF.2.1.2.2.4.2 Waveform modality sends trigger to the image modality

In this example, there are two modalities that are synchronized with an external clock via NTP.

The Image Modality starts the X-Ray image acquisition and simultaneously the Waveform Modality acquires the ECG and analyzes the signal to determine the phases of the cardiac cycles. At each cycle, the waveform modality sends a trigger to the image modality to start the acquisition of a frame. This trigger is stored in one channel of the waveform modality, together with the ECG signal.

The ECG sampling frequency is 300 Hz on 16 bits signed encoding, making up a number of 1500 samples per channel. The first ECG sample is acquired 10 ms after the nominal start time of the ECG acquisition.

In this example, there is no UID referencing capability between the two modalities.

[pic]

Figure FFF.2.1-12Example of Waveform Modality as Source of Trigger

The attributes that define the relevant content in the two different SOP Instances (Enhanced XA and General ECG) are described in the following figure:

ENHANCED XA SOP INSTANCES

Study Instance UID (0020,000D) = UID “A”
Series Instance UID (0020,000E) = UID “B”
Modality (0008,0060) = XA
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = EXTERNAL
Trigger Source or Type (0018,1061) = ECG Equipment ID
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “D”

GENERAL ECG SOP INSTANCE

Study Instance UID (0020,000D) = UID “E”
Series Instance UID (0020,000E) = UID “F”
Modality (0008,0060) = ECG
Synchronization Frame of Reference UID (0020,0200) = 1.2.840.10008.15.1.1
Synchronization Trigger (0018,106A) = SOURCE
Trigger Source or Type (0018,1061) = ECG Equipment ID
Synchronization Channel (0018,106C) = 1\2
Acquisition Time Synchronized (0018,1800) = Y
Time Source (0018,1801) = Clock System ID
Time Distribution Protocol (0018,1802) = NTP
NTP Source Address (0018,1803) = aaa.bbb.ccc.ddd
SOP Instance UID (0008,0018) = UID “H”

Waveform Sequence (5400,0100)
Item 1 Only one ECG Multiplex Group
>Multiplex Group Time Offset (0018,1068) = 10
>Waveform Originality (003A,0004) = ORIGINAL
>Number of Waveform Channels (003A,0005) = 2
>Number of Waveform Samples (003A,0010) = 1500
>Sampling Frequency (003A,001A) = 300
>Channel Definition Sequence (003A,0200)
Item 1
>Waveform Sample Interpretation (5400,1006) = SS

Figure FFF.2.1-13Attributes when Waveform Modality is the Source of Trigger

FFF.2.1.3 Mechanical Movement

FFF.2.1.3.1 Rotational Acquisition

This section provides information on the encoding of the movement of the X-Ray Positioner during the acquisition of a rotational angiography.

The related image presentation parameters of the rotational acquisition that are defined in the Enhanced XA SOP Class, such as the mask information of subtracted display, are described in further sections of this annex.

FFF.2.1.3.1.1 User Scenario

The multi-frame image acquisition is performed during a continuous rotation of the X-Ray Positioner, starting from the initial incidence and acquiring frames in a given angular direction at variable angular steps and variable time intervals.

Typically such rotational acquisition is performed with the purpose of further 3D reconstruction. The rotation axis is not necessarily the patient head-feet direction, which may lead to images where the patient is not heads-up oriented.

There may be one or more rotations of the X-Ray Positioner during the same image acquisition, performed by following different patterns, such as:

  1. One rotation for non-subtracted angiography;

  2. Two rotations in the same or in opposite angular directions, for subtracted angiography;

  3. Several rotations at different time intervals for cardiac triggered acquisitions.

FFF.2.1.3.1.2 Encoding outline

The XA SOP Class encodes the absolute positioner angles as the sum of the angle of the first frame and the increments relative to the first frame. The Enhanced XA SOP Class encodes per-frame absolute angles.

In the XA SOP Class, the encoding of the angles is always with respect to the patient, so-called anatomical angles, and the image is assumed to be patient-oriented (i.e. heads-up display). In case of positioner rotation around an axis oblique to the patient, not aligned with the head-feet axis, it is not possible to encode the rotation of the image necessary for 3D reconstruction.

The Enhanced XA SOP Class encodes the positioner angles with respect to the patient as well as with respect to a fixed coordinate system of the equipment.

FFF.2.1.3.1.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 1-28 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image XA/XRF Acquisition C.8.19.3 Specifies the type of positioner.

Table FFF.2. 1-29 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
X-Ray Positioner C.8.19.6.10 Specifies the anatomical angles per-frame.
X-Ray Isocenter Reference System C.8.19.6.13 Specifies the angles of the positioner per-frame in equipment coordinates for further applications based on the acquisition geometry (e.g., 3D reconstruction, registration…).

FFF.2.1.3.1.3.1 XA/XRF Acquisition Module Recommendations

The usage of this module is recommended to define the type of positioner.

Table FFF.2.1-30 XA/XRF ACQUISITION MODULE Example

Attribute Name Tag Comment
Positioner Type (0018,1508) The value CARM is used in this scenario.
C-arm Positioner Tabletop Relationship (0018,9474) Both values YES and NO are applicable to this scenario. Note: On mobile systems where this attribute equals NO, it is possible to do rotation and 3D reconstruction. In such case, the table is assumed to be static during the acquisition.

FFF.2.1.3.1.3.2 X-Ray Positioner Macro Recommendations

This macro is used in the per-frame context in this scenario.

Table FFF.2.1-31 X-RAY POSITIONER MACRO Example

Attribute Name Tag Comment
Positioner Position Sequence (0018,9405)
>Positioner Primary Angle (0018,1510) Angle with respect to the patient coordinate system.
>Positioner Secondary Angle (0018,1511) Angle with respect to the patient coordinate system.

FFF.2.1.3.1.3.3 X-Ray Isocenter Reference System Macro Recommendations

If the value of the C-arm Positioner Tabletop Relationship (0018,9474) is NO, the following macro may not be provided by the acquisition modality. This macro is used in the per-frame context in this scenario.

Table FFF.2.1-32 X-RAY ISOCENTER REFERENCE SYSTEM MACRO Example

Attribute Name Tag Comment
Isocenter Reference System Sequence (0018,9462)
>Positioner Isocenter Primary Angle (0018,9463) Angle with respect to the Isocenter coordinate system, independent of table angulations and how the patient is positioned on the table.
>Positioner Isocenter Secondary Angle (0018,9464) Angle with respect to the Isocenter coordinate system, independent of table angulations and how the patient is positioned on the table.
>Positioner Isocenter Detector Rotation Angle (0018,9465) Angle with respect to the Isocenter coordinate system, independent of table angulations and how the patient is positioned on the table.

FFF.2.1.3.1.4 Example

In this example, the patient is on the table, in position “Head First Prone”. The table horizontal, tilt and rotation angles are equal to zero.

The positioner performs a rotation of 180 deg from the left to the right side of the patient, with the image detector going above the back of the patient, around an axis parallel to the head-feet axis of the patient.

[pic]

Figure FFF.2.1-14Detector Trajectory during Rotational Acquisition

Below are the encoded values of the key attributes of this example:

Positioner Type (0018,1508) = CARM
C-arm Positioner Tabletop Relationship (0018,9474) = YES
Per-Frame Functional Groups Sequence (5200,9230)    
  Item 1     Frame 1
    >Positioner Position Sequence (0018,9405)    
      Item 1      
        >>Positioner Primary Angle (0018,1510)
      Item 1    
        >>Positioner Isocenter Primary Angle (0018,9463) =
  Item "N/2"   Frame "N/2"
    >Positioner Position Sequence (0018,9405)  
      Item 1    
        >>Positioner Primary Angle (0018,1510)
      Item 1    
        >>Positioner Isocenter Primary Angle (0018,9463) =
  Item "N"   Frame "N"
    >Positioner Position Sequence (0018,9405)  
      Item 1    
        >>Positioner Primary Angle (0018,1510)
      Item 1    
       
Image XA/XRF Acquisition C.8.19.3 Specifies the relationship between the table and the positioner.

Table FFF.2. 1-34 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
X-Ray Table Position C.8.19.6.11 Specifies the table position per-frame in three dimensions.
X-Ray Isocenter Reference System C.8.19.6.13 Specifies the position and the angles of the table per-frame in equipment coordinates, for further applications based on the acquisition geometry (e.g., registration…).

FFF.2.1.3.2.3.1 XA/XRF Acquisition Module Recommendations

The usage of this module is recommended to specify the relationship between the table and the positioner.

Table FFF.2.1-35 XA/XRF ACQUISITION MODULE Example

Attribute Name Tag Comment
C-arm Positioner Tabletop Relationship (0018,9474) Both values YES and NO are applicable to this scenario. Note: On mobile systems where this attribute equals NO, it is possible to do table stepping. In such case, the system is not able to determine the absolute table position relative to the Isocenter, which is necessary for 2D-2D registration.

FFF.2.1.3.2.3.2 X-Ray Table Position Macro Recommendations

This macro is used in the per-frame context in this scenario.

Table FFF.2.1-36 X-RAY TABLE POSITION MACRO Example

Attribute Name Tag Comment
Table Position Sequence (0018,9406)
>Table Top Vertical Position (300A,0128) The same value for all frames.
>Table Top Longitudinal Position (300A,0129) The same value for all frames.
>Table Top Lateral Position (300A,012A) Different values per frame, corresponding to the “stepping” intervals in the table plane.
>Table Horizontal Rotation Angle (0018,9469) The same value for all frames.
>Table Head Tilt Angle (0018,9470) The same value for all frames.
>Table Cradle Tilt Angle (0018,9471) The same value for all frames.

FFF.2.1.3.2.3.3 X-Ray Isocenter Reference System Macro Recommendations

If the value of the C-arm Positioner Tabletop Relationship (0018,9474) is NO, the following macro may not be provided by the acquisition modality. This macro is used in the per-frame context in this scenario.

Table FFF.2.1-37 X-RAY ISOCENTER REFERENCE SYSTEM MACRO Example

Attribute Name Tag Comment
Isocenter Reference System Sequence (0018,9462)
>Table X Position to Isocenter (0018,9466) X-position of a fixed point in the table top, it changes per-frame if table horizontal rotation is not zero
>Table Y Position to Isocenter (0018,9467) Vertical position of a fixed point in the table top, it changes per-frame if table head tilt is not zero
>Table Z Position to Isocenter (0018,9468) Z-position of a fixed point in the table top, it changes per-frame
>Table Horizontal Rotation Angle (0018,9469) The same value for all frames.
>Table Head Tilt Angle (0018,9470) The same value for all frames.
>Table Cradle Tilt Angle (0018,9471) The same value for all frames.

FFF.2.1.3.2.4 Example

In this example, the patient is on the table in position “Head First Supine”. The table is tilted of -10 degrees, with the head of the patient below the feet, and the image detector is parallel to the tabletop plane. The table cradle and rotation angles are equal to zero.

The image acquisition is performed during a movement of the X-Ray Table in the tabletop plane, at constant speed and of one meter of distance, acquiring frames from the abdomen to the feet of the patient in one stepping movement for non-subtracted angiography.

The table is related to the C-arm positioner so that the coordinates of the table position are known in the isocenter reference system. This allows determining the projection magnification of the table top plane with respect to the detector plane.

[pic]

Figure FFF.2.1-16Table Trajectory during T able Stepping

[pic]

Figure FFF.2.1-17Example of table positions per-frame during table stepping

Below are the encoded values of the key attributes of this example:

Positioner Type (0018,1508) = CARM
C-arm Positioner Tabletop Relationship (0018,9474) = YES
Per-Frame Functional Groups Sequence (5200,9230)  
  Item 1   Frame 1
    >Table Position Sequence (0018,9406)  
      Item 1    
        >>Table Top Vertical Position (300A,0128)
      Item 1    
        >>Table X Position to Isocenter (0018,9466)
  Item "N"   Frame "N"
    >Table Position Sequence (0018,9406)  
      Item 1    
        >>Table Top Vertical Position (300A,0128)
      Item 1    
     
X-Ray Exposure Control Sensing Regions C.8.19.6.3 Specifies the shape and size of the sensing regions in pixels, as well as their position relative to the top left pixel of the image.

FFF.2.1.4.1.3.1 X-Ray Exposure Control Sensing Regions Macro Recommendations

This macro is recommended to encode details about sensing regions.

If the position of the sensing regions is fixed during the multi-frame acquisition, the usage of this macro is shared.

If the position of the sensing regions was changed during the multi-frame acquisition, this macro is encoded per-frame to reflect the individual positions.

The same number of regions is typically used for all the frames of the image. However it is technically possible to activate or deactivate some of the regions during a given range of frames, in which case this macro is encoded per-frame.

Table FFF.2.1-39 X-RAY EXPOSURE CONTROL SENSING REGIONS MACRO Recommendations

Attribute Name Tag Comment
Exposure Control Sensing Regions Sequence (0018,9434) As many items as number of regions.

FFF.2.1.4.1.4 Example

In this section, two examples are given.

The first example shows how three sensing regions are encoded: 1) central (circular), 2) left (rectangular) and 3) right (rectangular).

[pic]

Figure FFF.2.1-19Example of X-Ray Exposure Control Sensing Regions inside the Pixel Data matrix

Below are the encoded values of the key attributes of this example:

Shared Functional Group Sequence (5200,9229)
Item 1 All frames
Other functional groups
>Exposure Control Sensing Regions Sequence (0018,9434)
Item 1

Figure FFF.2.1-20Attributes of first the example of the X-Ray Exposure Control Sensing Regions

The second example shows the same regions, but the field of view region encoded in the Pixel Data matrix has been shifted of 240 pixels right and 310 pixels down, thus the left rectangular sensing region is outside the Pixel Data matrix as well as both rectangular regions overlap the top row of the image matrix.

[pic]

Figure FFF.2.1-21Example of X-Ray Exposure Control Sensing Regions partially outside the Pixel Data matrix

Below are the encoded values of the key attributes of this example:

Shared Functional Group Sequence (5200,9229)
Item 1 All frames
Other functional groups
>Exposure Control Sensing Regions Sequence (0018,9434)
Item 1

Figure FFF.2.1-22Attributes of the second example of the X-Ray Exposure Control Sensing Regions

FFF.2.1.5 Image Detector and Field of View

This section provides information on the encoding of the image detector parameters and field of view applied during the X-Ray acquisition.

FFF.2.1.5.1 User Scenario

The user selects a given size of the field of view before starting the acquisition. This size can be smaller than the size of the Image Detector.

The position of the field of view in the detector area changes during the acquisition in order to focus on an object of interest.

Acquired image is networked or stored in offline media, then the image is:

  1. Displayed and reviewed in cine mode, and the field of view area needs to be displayed on the viewing screen;

  2. Used for quality assurance, to relate the pixels of the stored image to the detector elements, for instance to understand the image artifacts due to detector defects;

  3. Used to measure the dimension of organs or other objects of interest;

  4. Used to determine the position in the 3D space of the projection of the objects of interest.

FFF.2.1.5.2 Encoding outline

The XA SOP Class does not encode some information to fully characterize the geometry of the conic projection acquisition, such as the position of the Positioner Isocenter on the FOV area. Indeed, the XA SOP Class assumes that the isocenter is projected in the middle of the FOV.

The Enhanced XA SOP Class encodes the position of the Isocenter on the detector, as well as specific FOV attributes (origin, rotation, flip) per-frame or shared. It encodes some existing attributes from DX to specify information of the Digital Detector and FOV. It also allows differentiating the image intensifier vs. the digital detector and then defines conditions on attributes depending on image intensifier or digital detector.

FFF.2.1.5.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 1-40 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image XA/XRF Acquisition C.8.19.3 Specifies the type of detector.
X-Ray Image Intensifier C.8.19.4 Conditional to type of detector. Applicable in case of IMG_INTENSIFIER.
X-Ray Detector C.8.19.5 Conditional to type of detector. Applicable in case of DIGITAL_DETECTOR.

Table FFF.2. 1-41 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
X-Ray Field of View C.8.19.6.2 Specifies the field of view.
XA/XRF Frame Pixel Data Properties C.8.19.6.4 Specifies the Imager Pixel Spacing.

FFF.2.1.5.3.1 XA/XRF Acquisition Module Recommendations

The usage of this module is recommended to specify the type and details of the receptor.

Table FFF.2.1-42 XA/XRF ACQUISITION MODULE Recommendations

Attribute Name Tag Comment
X-Ray Receptor Type (0018,9420) Two values are applicable to this scenario: IMG_INTENSIFIER or DIGITAL_DETECTOR
Distance Receptor Plane to Detector Housing (0018,9426) Applicable to this scenario, regardless the type of receptor.

Distance Receptor Plane to Detector Housing (0018,9426) is a positive value except in the case of an image intensifier where the receptor plane is a virtual plane located outside the detector housing, which depends on the magnification factor of the intensifier.

The Distance Receptor Plane to Detector Housing (0018,9426) may be used to calculate the pixel size of the plane in the patient when markers are placed on the detector housing.

FFF.2.1.5.3.2 X-Ray Image Intensifier Module Recommendations

When the X-Ray Receptor Type (0018,9420) equals “IMG_INTENSIFIER” this module specifies the type and characteristics of the image intensifier.

[pic]

Figure FFF.2.1-23Schema of the Image Intensifier

The Intensifier Size (0018,1162) is defined as the physical diameter of the maximum active area of the image intensifier. The active area is the region of the input phosphor screen that is projected on the output phosphor screen. The image intensifier device may be configured for several predefined active areas to allow different levels of magnification.

The active area is described by the Intensifier Active Shape (0018,9427) and the Intensifier Active Dimension(s) (0018,9428).

The field of view area is a region equal to or smaller than the active area, and is defined as the region that is effectively irradiated by the X-Ray beam when there is no collimation. The stored image is the image resulting from digitizing the field of view area.

There is no attribute that relates the FOV origin to the intensifier. It is commonly assumed that the FOV area is centered in the intensifier.

The position of the projection of the isocenter on the active area is undefined. It is commonly understood that the X-Ray positioner is calibrated so that the isocenter is projected in the approximate center of the active area, and the field of view area is centered in the active area.

FFF.2.1.5.3.3 X-Ray Detector Module Recommendations

When the X-Ray Receptor Type (0018,9420) equals “DIGITAL_DETECTOR” this module specifies the type and characteristics of the image detector.

The size and pixel spacing of the digital image generated at the output of the digital detector are not necessarily equal to the size and element spacing of the detector matrix. The detector binning is defined as the ratio between the pixel spacing of the detector matrix and the pixel spacing of the digital image.

If the detector binning is higher than 1.0 several elements of the detector matrix contribute to the generation of one single digital pixel.

The digital image may be processed, cropped and resized in order to generate the stored image. The schema below shows these two steps of the modification of the pixel spacing between the detector physical elements and the stored image:

[pic]

Figure FFF.2.1-24Generation of the Stored Image from the Detector Matrix

Table FFF.2.1-43 X-RAY DETECTOR MODULE Recommendations

Attribute Name Tag Comment
Detector Binning (0018,701A) The ratio between the pixel spacing of the detector matrix and the pixel spacing of the digital image. It does not describe any further post-processing to resize the pixels to generate the stored image.
Detector Element Spacing (0018,7022) Pixel spacing of the detector matrix.
Position of Isocenter Projection (0018,9430) Relates the position of the detector elements to the isocenter reference system. It is independent from the detector binning and from the field of view origin. This attribute is defined if the Isocenter Reference System Sequence (0018,9462) is present.

FFF.2.1.5.3.4 X-Ray Field of View Macro Recommendations

The usage of this macro is recommended to specify the characteristics of the field of view.

When the field of view characteristics change across the multi-frame image, this macro is encoded on a per-frame basis.

The field of view region is defined by a shape, origin and dimension. The region of irradiated pixels corresponds to the interior of the field of view region.

When the X-Ray Receptor Type (0018,9420) equals “IMG_INTENSIFIER”, the intensifier TLHC is undefined. Therefore the field of view origin cannot be related to the physical area of the receptor. It is commonly understood that the field of view area corresponds to the intensifier active area, but there is no definition in the DICOM standard that forces a manufacturer to do so. As a consequence, it is impossible to relate the position of the pixels of the stored area to the isocenter reference system.

Table FFF.2.1-44 X-RAY FIELD OF VIEW MACRO Recommendations

Attribute Name Tag Comment
Field of View Sequence (0018,9432)
>Field of View Shape (0018,1147) Applicable in this scenario.
>Field of View Dimension(s) in Float (0018,9461) Applicable in this scenario.
>Field of View Origin (0018,7030) Applicable only in the case of digital detector.
>Field of View Rotation (0018,7032) Applicable regardless the type of receptor.
>Field of View Horizontal Flip (0018,7034) Applicable regardless the type of receptor.
>Field of View Description (0018,9433) Free text defining the type of field of view as displayed by the manufacturer on the acquisition system. For display purposes.

FFF.2.1.5.3.5 XA/XRF Frame Pixel Data Properties Macro Recommendations

The usage of this macro is recommended to specify the Imager Pixel Spacing.

When the field of view characteristics change across the multi-frame image, this macro is encoded on a per-frame basis.

Table FFF.2.1-45 XA/XRF FRAME PIXEL DATA PROPERTIES MACRO Recommendations

Attribute Name Tag Comment
Frame Pixel Data Properties Sequence (0028,9443)
>Imager Pixel Spacing (0018,1164) Applicable regardless the type of receptor.

In case of image intensifier, the Imager Pixel Spacing (0018,1164) may be non-uniform due to the pincushion distortion, and this attribute corresponds to a manufacturer-defined value (e.g., average, or value at the center of the image).

FFF.2.1.5.4 Examples

FFF.2.1.5.4.1 Field of View on Image Intensifier

This example illustrates the encoding of the dimensions of the intensifier device, the intensifier active area and the field of view in case of image intensifier.

In this example, the diameter of the maximum active area is 410 mm. The image acquisition is performed with an electron lens that focuses the photoelectron beam inside the intensifier so that an active area of 310 mm of diameter is projected on the output phosphor screen.

The X-Ray beam is projected on an area of the input phosphor screen of 300 mm of diameter, and the corresponding area on the output phosphor screen is digitized on a matrix of 1024 x1024 pixels. This results on a pixel spacing of the digitized matrix of 0.3413 mm.

The distance from the Receptor Plane to the Detector Housing in the direction from the intensifier to the X-Ray tube is 40 mm.

Below are the encoded values of the key attributes of this example:

         
Columns   (0028,0011) = 1024
X-Ray Receptor Type (0018,9420) = IMG_INTENSIFIER
Distance Receptor Plane to Detector Housing (0018,9426) = 40.0
Intensifier Size (0018,1162) = 410.0
Intensifier Active Shape (0018,9427) = ROUND
Intensifier Active Dimension(s) (0018,9428) = 310.0
     
  Item 1  
         
    >Field of View Sequence (0018,9432)  
      Item 1    
        >>Field of View Shape (0018,1147)
      Item 1    
        >>Imager Pixel Spacing (0018,1164)

Figure FFF.2.1-25 Attributes of the example of Field of View on Image Intensifier

FFF.2.1.5.4.2 Field of View on Digital Detector

The following examples show three different ways to create the stored image from the same detector matrix.

In the figures below:

Note that the detector active dimension is not necessarily the FOV dimension.

In all the examples,

In the first example, there is neither binning nor resizing between the detector matrix and the stored image.

Below are the encoded values of the key attributes of this example:

Rows       (0028,0010) = 8
Columns   (0028,0011) = 8
X-Ray Receptor Type (0018,9420) = DIGITAL_DETECTOR
Detector Binning (0018,701A) = 1.0\1.0
Detector Element Spacing (0018,7022) = 0.2\0.2
Position of Isocenter Projection (0018,9430) = 5\7
Per-Frame Functional Groups Sequence (5200,9230)    
           
  Item i    
    >Field of View Sequence (0018,9432)    
      Item 1      
        >>Field of View Shape (0018,1147)
      Item 1      
        >>Imager Pixel Spacing (0018,1164) =

[pic]

Figure FFF.2.1-26Attributes of the first example of Field of View on Digital Detector

In the second example, there is a binning factor of 2 between the detector matrix and the digital image. There is no resizing between the digital image (binned) and the stored image.

Below are the encoded values of the key attributes of this example:

Rows       (0028,0010) = 4
Columns   (0028,0011) = 4
X-Ray Receptor Type (0018,9420) = DIGITAL_DETECTOR
Detector Binning (0018,701A) = 2.0\2.0
Detector Element Spacing (0018,7022) = 0.2\0.2
Position of Isocenter Projection (0018,9430) = 5\7
Per-Frame Functional Groups Sequence (5200,9230)  
         
  Item i  
    >Field of View Sequence (0018,9432)
      Item 1  
        >>Field of View Shape (0018,1147)
      Item 1    
        >>Imager Pixel Spacing (0018,1164) =

[pic]

Figure FFF.2.1-27 Attributes of the second example of Field of View on Digital Detector

In the third example, in addition to the binning factor of 2 between the detector matrix and the digital image, there is a resizing of 0.5 (downsizing) between the digital image (binned) and the stored image.

Below are the encoded values of the key attributes of this example:

Rows       (0028,0010) = 2
Columns   (0028,0011) = 2
X-Ray Receptor Type (0018,9420) = DIGITAL_DETECTOR
Detector Binning (0018,701A) = 2.0\2.0
Detector Element Spacing (0018,7022) = 0.2\0.2
Position of Isocenter Projection (0018,9430) = 5\7
Per-Frame Functional Groups Sequence (5200,9230)    
           
  Item i    
    >Field of View Sequence (0018,9432)    
      Item 1      
        >>Field of View Shape (0018,1147)
      Item 1    
        >>Imager Pixel Spacing (0018,1164) =

[pic]

Figure FFF.2.1-28 Attributes of the third example of Field of View on Digital Detector

Note that the description of the field of view attributes (dimension, origin) is the same in these three examples. The field of view definition is independent from the binning and resizing processes.

FFF.2.1.6 Acquisitions with Contrast

This section provides information on the encoding of the presence and type of contrast bolus administered during the X-Ray acquisition.

FFF.2.1.6.1 User Scenario

The user performs image acquisition with injection of contrast agent during the X-Ray acquisition. Some frames are acquired without contrast, some others with contrast.

The type of contrast agent can be radio-opaque (e.g., iodine) or radio-transparent (e.g., CO2).

The information of the type of contrast and its presence or absence in the frames can be used by post-processing applications to set up e.g., vessel detection or image quality algorithms automatically.

FFF.2.1.6.2 Encoding outline

The Enhanced XA SOP Class encodes the characteristics of the contrast agent(s) used during the acquisition of the image, including the type of absorption (radio-opaque or radio-transparent).

The Enhanced XA SOP Class also allows encoding the presence of contrast in a particular frame or set of frames, by encoding the Contrast/Bolus Usage per-frame.

FFF.2.1.6.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 1-46 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image Enhanced Contrast/Bolus C.7.6.4b Specifies the characteristics of the contrast agent(s) administered.

Table FFF.2. 1-47 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Contrast/Bolus Usage C.7.6.16.2.12 Specifies the presence of contrast in the frame(s).

FFF.2.1.6.3.1 Enhanced Contrast/Bolus Module Recommendations

The usage of this module is recommended to specify the type and characteristics of the contrast agent administered.

FFF.2.1.6.3.2 Contrast/Bolus Usage Macro Recommendations

The usage of this macro is recommended to specify the characteristics of the contrast per-frame.

Table FFF.2.1-48 CONTRAST/BOLUS USAGE MACRO Recommendations

Attribute Name Tag Comment
Contrast/Bolus Usage Sequence (0018,9341) One item per contrast agent used in this frame.
>Contrast/Bolus Agent Number (0018,9337) Contains the internal number of the agent administered as specified in the Enhanced Contrast/Bolus Module.
>Contrast/Bolus Agent Administered (0018,9342) The value “YES” indicates that the contrast may be visible on the frame, but not necessarily if the frame is acquired before the contrast reaches the imaged region.
>Contrast/Bolus Agent Detected (0018,9343) The value “YES” is used if the contrast is visible on that particular frame. Note that it is not expected to be YES if Contrast/Bolus Agent Administered (0018,9342) equals NO.

FFF.2.1.6.4 Example

In this example, the user starts the X-Ray acquisition at 4 frames per second at 3:35pm. After one second the user starts the injection of 45 milliliters of contrast media Iodipamide (350 mg/ml Cholographin (Bracco)) at a flow rate of 15 ml/sec during three seconds, in intra-arterial route. When the injection of contrast agent is finished, the user continues the X-Ray acquisition for two seconds until wash out of the contrast agent.

There could be two ways to determine the presence of contrast agent on the frames:

  1. The injector is connected to the X-Ray acquisition system, the presence of contrast agent is determined based on the injector start/stop signals and a preconfigured delay to allow the contrast to reach the artery of interest, or

  2. The X-Ray system processes the images in real time and detects the presence or absence of contrast agent on the images.

In this example, the image acquired contains 25 frames: From frames 5 to 17, the contrast is being injected. From frames 8 to 23, the contrast is visible on the pixel data.

The figure below shows the attributes of this example in a graphical representation of the multi-frame acquisition.

[pic]

Figure FFF.2.1-29Example of contrast agent injection

Below are the encoded values of the key attributes of this example:

Contrast/Bolus Agent Sequence (0018,0012)    
  Item 1     Contrast agent 1
    >Code Value (0008,0100) = C-B0318
    >Coding Scheme Designator (0008,0102) = SRT
    >Code Meaning (0008,0104) = Iodipamide
    >Contrast/Bolus Agent Number (0018,9337) = 1
    >Contrast/Bolus Administration Route Sequence (0018,0014)  
      Item 1    
        >>Code Value (0008,0100)
      Item 1    
        >>Code Value (0008,0100)
    >Contrast/Bolus Ingredient Concentration (0018,1049) = 350
    >Contrast/Bolus Ingredient Opaque (0018,9425) = YES
    >Contrast Administration Profile Sequence (0018,9340)  
      Item 1   Administered phase 1
       
  Items 1 to 4     Frames 1 to 4
    >Contrast/Bolus Usage Sequence (0018,9341)    
      Item 1    
        >>Contrast/Bolus Agent Number
    >Contrast/Bolus Usage Sequence (0018,9341)  
      Item 1    
        >>Contrast/Bolus Agent Number
    >Contrast/Bolus Usage Sequence (0018,9341)  
      Item 1    
        >>Contrast/Bolus Agent Number
    >Contrast/Bolus Usage Sequence (0018,9341)  
      Item 1    
       
Image XA/XRF Acquisition C.8.19.3 Specifies average values for the X-Ray generation techniques.

Table FFF.2. 1-50 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame Content C.7.6.16.2.2 Specifies the frame duration.
X-Ray Frame Acquisition C.8.19.6.8 Specifies the kVp and mA per frame.

FFF.2.1.7.3.1 XA/XRF Acquisition Module Recommendations

The usage of this module is recommended to specify the average values of time, voltage and current applied during the acquisition of the multi-frame image.

It gives general information of the X-Ray radiation during the acquisition of the image. In case of dynamic acquisitions, this module is not sufficient to estimate the radiation per body area and additional per-frame information is needed.

Table FFF.2.1-51 XA/XRF ACQUISITION MODULE Recommendations

Attribute Name Tag Comment
KVP (0018,0060) Recommended in this scenario.
Radiation Setting (0018,1155) The values “SC” and “GR” give a rough indication of the level of the dose such as “low” or “high”, nevertheless they are used more for quality assurance and/or display purposes, not for estimation of radiation values.
X-Ray Tube Current in mA (0018,9330) Recommended in this scenario.
Exposure Time in ms (0018,9328) Recommended in this scenario.
Exposure in mAs (0018,9332) Recommended in this scenario.
Average Pulse Width (0018,1154) Recommended in this scenario.
Radiation Mode (0018,115A) The value of this attribute is used more for quality assurance and/or display purposes, not for estimation of radiation values.

Note that the three attributes X-Ray Tube Current in mA (0018,9330), Exposure Time in ms (0018,9328) and Exposure in mAs (0018,9332) are mutually conditional to each other but all three may be present. In this scenario it is recommended to include the three attributes.

FFF.2.1.7.3.2 Frame Content Macro Recommendations

The usage of this macro is recommended to specify the duration of each frame of the multi-frame image.

Note that this macro is allowed to be used only in a per-frame context, even if the pulse duration is constant for all the frames.

FFF.2.1.7.3.3 X-Ray Frame Acquisition Macro Recommendations

The usage of this macro is recommended to specify the values of voltage (kVp) and current (mA) applied for the acquisition of each frame of the multi-frame image.

If the system can provide only average values of kVp and mA, the usage of the X-Ray Frame Acquisition macro is not recommended, only the XA/XRF Acquisition Module is recommended.

If the system predefines the values of the kVp and mA to be constant during the acquisition, the usage of the X-Ray Frame Acquisition macro in a shared context is recommended in order to indicate that the value of kVp and mA is identical for each frame.

If the system is able to change dynamically the kVp and mA during the acquisition, the usage of the X-Ray Frame Acquisition macro in a per-frame context is recommended.

Table FFF.2.1-52 X-RAY FRAME ACQUISITION MACRO Recommendations

Attribute Name Tag Comment
Frame Acquisition Sequence (0018,9417) Recommended in this scenario if both values kVp and mA are known for each frame.

FFF.2.1.7.4 Example

For more details, refer to the section FFF.1.4

FFF.2.2 Review

FFF.2.2.1 Variable Frame-rate acquisition with Skip Frames

This application case provides information on how X-Ray acquisitions with variable time between frames can be organized by groups of frames to be reviewed with individual group settings.

FFF.2.2.1.1 User Scenario

The image acquisition system performs complex acquisition protocols with groups of frames to be displayed at different frame rates and others to be skipped.

Allow frame-rates in viewing applications to be different than acquired rates.

FFF.2.2.1.2 Encoding Outline

The XA IOD provides only one group of frames between start and stop trim.

The Enhanced XA/XRF IOD allows encoding of multiple groups of frames (frame collections) with dedicated display parameters.

The Enhanced XA IOD provides an exact acquisition time for each frame.

FFF.2.2.1.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 2-1 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image XA/XRF Multi-frame Presentation C.8.19.7 Specifies the groups of frames and their display parameters.

FFF.2.2.1.3.1 XA/XRF Multi-frame Presentation Module Recommendations

The usage of this module is recommended to encode the grouping of frames (one or more groups) for display purposes and the related parameters for each group.

Table FFF.2.2-2 XA/XRF MULTI-FRAME PRESENTATION MODULE Recommendations

Attribute Name Tag Comment
Preferred Playback Sequencing (0018,1244) Specifies the direction of the playback.
Frame Display Sequence (0008,9458) Specifies the details on how frames are grouped for display purposes.

FFF.2.2.1.4 Example

An example of a 4 position peripheral stepping acquisition with different frame-rates is provided. One group is only 2 Frames (e.g., due to fast contrast bolus) and will be skipped for display purposes.

The whole image is reviewed in looping mode:

Below are the encoded values of the key attributes of this example:

Preferred Playback Sequencing (0018,1244) = 0
Frame Display Sequence (0008,9458)
Item 1
>Start Trim (0008,2142) = 1
>Stop Trim (0008,2143) = 17
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Display Frame Rate in Float (0008,9459) = 4.0
Item 2
>Start Trim (0008,2142) = 18
>Stop Trim (0008,2143) = 25
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Display Frame Rate in Float (0008,9459) = 2.0
Item 3
>Start Trim (0008,2142) = 26
>Stop Trim (0008,2143) = 27
>Skip Frame Range Flag (0008,9460) = SKIP
>Recommended Display Frame Rate in Float (0008,9459) = 2.0
Item 4
>Start Trim (0008,2142) = 28
>Stop Trim (0008,2143) = 36
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Display Frame Rate in Float (0008,9459) = 1.5

Figure FFF.2.2-1Attributes of the example of the Variable Frame-rate acquisition with Skip Frames

FFF.2.3 Display

FFF.2.3.1 Standard Pipeline with Enhanced XA

This section provides information on the encoding of the density and geometry characteristics of the stored pixel data and the ways to display it.

FFF.2.3.1.1 User Scenario

The image acquisition may be performed with a variety of settings on the detector image pre-processing component which modifies the way the gray levels are stored in the pixel data.

In particular, it may impact the relationship between the X-Ray intensity and the gray level stored (e.g., non-linear function), as well as the geometry of the X-Ray beam (e.g., pincushion distortion).

Based on the characteristics of the stored pixel data, the acquisition system determines automatically an optimal way to display the pixel data on a frame-by-frame basis, which is expected to be applied by the viewing applications.

FFF.2.3.1.2 Encoding outline

The XA SOP Class encodes the VOI settings to be common to all the frames of the image. It also restricts the Photometric Interpretation (0028,0004) to MONOCHROME2.

The Enhanced XA SOP Class encodes per-frame VOI settings. Additionally it allows the Photometric Interpretation (0028,0004) to be MONOCHROME1 in order to display low pixel values in white while using window width and window center VOI. Other characteristics and settings can be defined, such as:

FFF.2.3.1.3 Encoding details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 3-1 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image Enhanced XA/XRF Image C.8.19.2 Specifies the sign of the slope of the VOI transformation to be applied during display.
XA/XRF Multi-frame Presentation C.8.19.7 Specifies the subtractive mode and the edge enhancement filter characteristics to be applied during display.

Table FFF.2. 3-2 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame VOI LUT C.7.6.16.2.10 Specifies the VOI transformation to be applied during display.
Pixel Intensity Relationship LUT C.7.6.16.2.13 Specifies the different LUTs to transform the stored pixel values to a given function of the X-Ray intensity.
XA/XRF Frame Pixel Data Properties C.8.19.6.4 Specifies geometrical characteristics of the pixel data.

FFF.2.3.1.3.1 Enhanced XA/XRF Image Module Recommendations

The usage of this module is recommended to specify the sign of the slope of the VOI transformation to be applied during display of the multi-frame image.

Table FFF.2.3-3 ENHANCED XA/XRF IMAGE MODULE Recommendations

Attribute Name Tag Comment
Photometric Interpretation (0028,0004) The value MONOCHROME1 indicates negative slope (i.e. minimum pixel value is intended to be displayed as white), and the value MONOCHROME2 indicates positive slope (i.e. minimum pixel value is intended to be displayed as black).
Presentation LUT Shape (2050,0020) The values IDENTITY and INVERSE are applicable.

FFF.2.3.1.3.2 XA/XRF Multi-frame Presentation Module Recommendations

The usage of this module is recommended to specify some presentation settings:

  1. Whether the viewing mode is subtracted or not by using the Recommended Viewing Mode (0028,1090), and

  2. The recommended edge enhancement filter as a percentage of subjective sensitivity by using the Display Filter Percentage (0028,9411).

The recommended filter percentage does not guaranty a full consistency of the image presentation across applications, rather gives an indication of the user sensitivity to such filtering to be applied consistently. To optimize the consistency of the filtering perception, the applications sharing the same images should be customized to calibrate the highest filtering (i.e. 100%) to similar perception by the users. Setting the application to the lowest filtering (i.e. 0%) means that no filter is applied at all.

FFF.2.3.1.3.3 Frame VOI LUT Macro Recommendations

The usage of this macro is recommended to specify the windowing to be applied to the pixel data in native mode, i.e. non-subtracted.

FFF.2.3.1.3.4 Pixel Intensity Relationship LUT Macro Recommendations

The usage of this macro is recommended to enable the applications to get the values of the stored pixel data back to a linear relationship with the X-Ray intensity.

When the value of Pixel Intensity Relationship (0028,1040) equals LOG, a LUT to get back to linear relationship (TO_LINEAR) is present to allow applications to handle linear pixel data.

Other LUTs can be added, for instance to transform to logarithmic relationship for subtraction (TO_LOG) in case the relationship of the stored pixel data is linear. Other LUTs with manufacturer-defined relationships are also allowed.

The LUTs of this macro are not used for the standard display pipeline.

FFF.2.3.1.3.5 XA/XRF Frame Pixel Data Properties Macro Recommendations

The usage of this macro is recommended to specify some properties of the values of the stored pixel data with respect to the X-Ray intensity (i.e. gray level properties) and with respect to the geometry of the detector (i.e. pixel geometrical properties).

FFF.2.3.1.4 Example

In this example, two different systems perform an X-Ray Acquisition of the coronary arteries injected with radio-opaque contrast agent.

The system A is equipped with a digital detector, and stores the pixel data with the lower level corresponding to the lower X-Ray intensity. Then the user creates two instances: one to display the injected vessels as black, and other to display the injected vessels as white.

The system B is equipped with an image intensifier configured to store the pixel data with the lower level corresponding to the higher X-Ray intensity. Then the user creates two instances: one to display the injected vessels as black, and other to display the injected vessels as white.

The figure below illustrates, for the two systems, the gray levels of the injected vessels on both the stored pixel data and the displayed pixels, which depend on the value of the attributes Pixel Intensity Relationship Sign (0028,1041), Photometric Interpretation (0028,0004), and Presentation LUT Shape (2050,0020).

[pic]

Figure FFF.2.3-1Example of usage of Photometric Interpretation

FFF.2.3.2 Mask Subtraction

This section provides information on the usage of attributes to encode an image acquisition in subtracted display mode.

FFF.2.3.2.1 User Scenario

A straightforward DSA acquisition is performed. The first few frames do not contain contrast, then the rest of frames contain contrast. An “averaged mask” may be selected to average some of the first frames without contrast.

A peripheral stepping DSA acquisition is performed. The acquisition is running in N steps and is timed to perform a mask run (e.g., from feet to abdomen) and then perform contrast runs at the positions of each mask, as triggered by the user.

One or more ranges of contrast frames will be used for subtraction from the mask for loop display. During the display, some ranges are to be fully subtracted, some others may be partially subtracted allowing a certain degree of visibility of the anatomical background visible on the mask, and finally some ranges are to be displayed un-subtracted.

FFF.2.3.2.2 Encoding Outline

The Enhanced XA SOP Class allows the encoding of the mask attributes similar to what the XA SOP Class provides.

The Enhanced XA SOP Class allows defining of specific display settings to be applied to a subset of frames, for instance the recommended viewing mode and the degree of visibility of the mask.

FFF.2.3.2.3 Encoding Details

This section provides detailed recommendations of the key attributes to address this particular scenario.

Table FFF.2. 3-4 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image Mask C.7.6.10 Specifies the subtraction parameters.
XA/XRF Multi-frame Presentation C.8.19.7 Specifies display settings of the groups of frames.

FFF.2.3.2.3.1 Mask Module Recommendations

This module is used to specify the subtraction parameters. The number of items depends on the number of Subtractions to be encoded. Typically, in case of AVG_SUB, the number of items is at least the number of ranges of contrast frames to be subtracted from a different mask.

Table FFF.2. 3-5 MASK MODULE Recommendations

Attribute Name Tag Comment
Recommended Viewing Mode (0028,1090) Recommended in this scenario, a value of “SUB” is used in this case.
Mask Subtraction Sequence (0028,6100) Recommended in this scenario. Items can be used to specify: - A range of contrast frames is to be subtracted from a generated mask; - A different set of pixel-shift pairs is to be applied to a range of contrast frames.

FFF.2.3.2.3.2 XA/XRF Multi-frame Presentation Module Recommendations

The frame ranges of this module typically include all the masks and contrast frames defined in the Mask Module, and their presentation settings are consistent with the Mask Module definitions.

The mask frames are typically displayed non-subtracted, i.e. Recommended Viewing Mode (0028,1090) equals NAT.

If there is a frame range without mask association, the value “NAT” is used for Recommended Viewing Mode (0028,1090) in the item of the Frame Display Sequence (0008,9458) of that frame range.

In case where Recommended Viewing Mode (0028,1090) equals “NAT”, the display is expected to be un-subtracted even if the Recommended Viewing Mode (0028,1090) of the Mask module equals “SUB”.

FFF.2.3.2.4 Examples

The user performs an X-Ray acquisition in three steps:

  1. First step of 5 frames for mask acquisition, without contrast agent injection;

  2. Second step of 20 frames to assess the arterial phase, with contrast agent injection, to be subtracted to the average of the 5 mask frames acquired in the first phase;

  3. Third step of 10 frames to assess the venous phase, without further contrast agent injection, to be subtracted to a new mask related to that phase and with a 20% of mask visibility.

In the three steps, the system automatically identifies the mask frame(s) to be associated with the contrast frames.

Below are the encoded values of the key attributes of this example:

Recommended Viewing Mode (0028,1090) = SUB
Mask Subtraction Sequence (0028,6100)
Item 1
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 1
>Applicable Frame Range (0028,6104) = 6\25
>Mask Frame Numbers (0028,6110) = 1\2\3\4\5
>Mask Selection Mode (0028,9454) = SYSTEM
Item 2
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 1
>Applicable Frame Range (0028,6104) = 27\35
>Mask Frame Numbers (0028,6110) = 26
>Mask Selection Mode (0028,9454) = SYSTEM
Frame Display Sequence (0008,9458)
Item 1
>Start Trim (0008,2142) = 1
>Stop Trim (0008,2143) = 5
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Viewing Mode (0028,1090) = NAT
Item 2
>Start Trim (0008,2142) = 6
>Stop Trim (0008,2143) = 25
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Viewing Mode (0028,1090) = SUB
>Mask Visibility Percentage (0028,9478) = 0
Item 3
>Start Trim (0008,2142) = 26
>Stop Trim (0008,2143) = 26
>Skip Frame Range Flag (0008,9460) = SKIP
>Recommended Viewing Mode (0028,1090) = NAT
Item 4
>Start Trim (0008,2142) = 27
>Stop Trim (0008,2143) = 35
>Skip Frame Range Flag (0008,9460) = DISPLAY
>Recommended Viewing Mode (0028,1090) = SUB
>Mask Visibility Percentage (0028,9478) = 20

Figure FFF.2.3-2Attributes of Mask Subtraction and display

FFF.2.3.3 Pixel-shift

This section provides information on the attribute encoding for use with image acquisitions that require subtracted display modes with multiple pixel shift ranges e.g., multiple subtracted views on a DSA acquisition.

FFF.2.3.3.1 User Scenario

When performing DSA acquisitions, the acquisition system may choose a default subtraction pixel-shift to allow review of the whole multi-frame, as acquired.

With advanced post-processing function the medical user may add further subtraction pixel-shifts to carve out certain details or improve contrast bolus visualization of a part of the anatomy that suffered from different movement during the acquisition.

FFF.2.3.3.2 Encoding Outline

The Mask Module is used to encode the various subtractions applicable to a multi-frame image.

The Enhanced XA IOD allows creating groups of mask-contrast pairs in the Mask Module, each group identified by a unique Subtraction Item ID within the multi-frame image.

The Enhanced XA IOD, with per frame macro encoding, supports multiple and different pixel-shift values per frame, each pixel-shift value is related to a given Subtraction Item ID.

It has to be assured that all the frames in the scope of a Subtraction Item ID have the pixel-shift values defined under that Subtraction Item ID.

In case a frame does not belong to any Subtraction Item ID, that frame does not necessarily have a pixel shift value encoded.

FFF.2.3.3.3 Encoding Details

This section provides detailed recommendations of the key attributes to address this particular scenario. The usage of the “Frame Pixel Shift” macro in a ‘per frame’ context is recommended. Only the usage of Mask Module and the Frame Pixel Shift Macro is further detailed.

Table FFF.2. 3-6 ENHANCED X-RAY ANGIOGRAPHIC IMAGE IOD MODULES

IE Module PS 3.3 Reference Usage
Image Mask C.7.6.10 Specifies the groups of mask-contrast pairs identified by a Subtraction Item ID.

Table FFF.2. 3-7 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Frame Pixel Shift C.7.6.16.2.14 Specifies the pixel shift associated with the Subtraction IDs.

FFF.2.3.3.3.1 Mask Module Recommendations

This module is recommended to specify the subtraction parameters. The number of items depends on the number of Subtractions to be applied (see section FFF.2.3.2).

Table FFF.2. 3-8 MASK MODULE Recommendations

Attribute Name Tag Comment
Recommended Viewing Mode (0028,1090) Recommended in this scenario, a value of “SUB” is used in this case.
Mask Subtraction Sequence (0028,6100) Recommended in this scenario. Item can be used to specify: - A range of contrast frames is to be subtracted from a generated mask; - A different set of pixel-shift pairs is to be applied to a range of contrast frames.

FFF.2.3.3.3.2 Frame Pixel Shift Macro Recommendations

The usage in this scenario is on a “per frame” context to allow individual pixel shift factors for each Subtraction Item ID.

The Subtraction Item ID specified in the Mask Subtraction Sequence (0028,6100) as well as in the Frame Pixel Shift Sequence (0028,9415) allows creating a relationship between the subtraction (mask and contrast frames) and a corresponding set of pixel shift values.

The Pixel Shift specified for a given frame in the Frame Pixel Shift Macro is the shift to be applied when this frame is subtracted to its associated mask for the given Subtraction Item ID.

Not all frames may have the same number of items in the Frame Pixel Shift Macro, but all frames that are in the scope of a Subtraction Item ID and identified as “contrast” frames in the Mask module are recommended to have a Frame Pixel Shift Sequence item with the related Subtraction Item ID.

Table FFF.2.3-9 FRAME PIXEL SHIFT MACRO Recommendations

Attribute Name Tag Comment
Frame Pixel Shift Sequence (0008,9415) Recommended in this scenario. The number of items may differ for each frame.

FFF.2.3.3.4 Examples

FFF.2.3.3.4.1 Usage of Pixel Shift Macro in Shared Context

In this example, the pixel shift –0.3\2.0 is applied to the frames 2 and 3 when they are subtracted to the mask frame 1 as defined in the Mask Subtraction Sequence.

Below are the encoded values of the key attributes of this example:

Mask Subtraction Sequence (0028,6100)
Item 1
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 100
>Applicable Frame Range (0028,6102) = 2\3
>Mask Frame Numbers (0028,6110) = 1
>Mask Operation Explanation (0028,6190) = Default Subtraction
Shared Functional Group Sequence (5200,9229)
Item 1 All the frames
>Frame Pixel Shift Sequence (0028,9415)
Item 1
Item 1
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 100
>Applicable Frame Range (0028,6102) = 2\3
>Mask Frame Numbers (0028,6110) = 1
>Mask Operation Explanation (0028,6190) = Left Leg
Per-Frame Functional Groups Sequence (5200,9230)
Item 1 Frame 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
Item 1
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 100
>Applicable Frame Range (0028,6102) = 2\3
>Mask Frame Numbers (0028,6110) = 1
>Mask Operation Explanation (0028,6190) = Left Leg
Item 2
>Mask Operation (0028,6101) = AVG_SUB
>Subtraction Item ID (0028,9416) = 101
>Applicable Frame Range (0028,6102) = 2\3
>Mask Frame Numbers (0028,6110) = 1
>Mask Operation Explanation (0028,6190) = Right Leg
Per-Frame Functional Groups Sequence (5200,9230)
Item 1 Frame 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
>Frame Pixel Shift Sequence (0028,9415)
Item 1
Image XA/XRF Acquisition C.8.19.3 Specifies system characteristics relevant for this scenario.

Table FFF.2. 4-2 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
XA/XRF Frame Pixel Data Properties C.8.19.6.4 Specifies the pixel spacing on the receptor plane.
X-Ray Projection Pixel Calibration C.8.19.6.9 Specifies the calibration-specific attributes.
X-Ray Geometry C.8.19.6.14 Specifies the distances of the conic projection.

FFF.2.4.1.3.1 XA/XRF Acquisition Module Recommendations

In order to check if a calibration is appropriate, certain values have to be set in the XA/XRF Acquisition Module.

Table FFF.2.4-3 XA/XRF ACQUISITION MODULE Recommendations

Attribute Name Tag Comment
X-Ray Receptor Type (0018,9420) Recommended in this scenario. The values IMG_INTENSIFIER or DIGITAL_DETECTOR can provide information about exactness of the image plane.
Positioner Type (0018,1508) Recommended in this scenario. The value of CARM is typically expected for equipment providing geometry information required for calibration.
C-arm Positioner Tabletop Relationship (0018,9474) A value of YES is recommended in this scenario, to allow use of related information for calibration because table and gantry are geometrically aligned.

FFF.2.4.1.3.2 XA/XRF Frame Pixel Data Properties Macro Recommendations

This macro is recommended to provide the Pixel Spacing in the receptor plane. Typically the Image Pixel Spacing is identical for all frames. Future acquisition system techniques may result in per frame individual values.

Table FFF.2.4-4 XA/XRF FRAME PIXEL DATA PROPERTIES MACRO Recommendations

Attribute Name Tag Comment
Frame Pixel Data Properties Sequence (0028,9443)
>Imager Pixel Spacing (0018,1164) Recommended for this scenario, regardless the type of receptor.

FFF.2.4.1.3.3 X-Ray Projection Pixel Calibration Macro Recommendations

This macro contains the core inputs and results of calibration.

When there is no movement of the gantry and table, the macro is typically used in shared functional group context.

The attribute Beam Angle (0018,9449) is supplementary for the purpose of calibration; it is derived from the Primary and Secondary Positioner Angles but is not intended to replace them as they provide information for other purposes.

Table FFF.2.4-5 X-RAY PROJECTION PIXEL CALIBRATION MACRO Recommendations

Attribute Name Tag Comment
Projection Pixel Calibration Sequence (0018,9401)
>Distance Object to Table Top (0018,9403) Recommended in this scenario.
>Object Pixel Spacing in Center of Beam (0018,9404) Recommended in this scenario. The value pair corresponds to the patient plane defined by the other parameters in this macro.
>Table Height (0018,1130) Recommended in this scenario.
>Beam Angle (0018,9449) Recommended in this scenario.

FFF.2.4.1.3.4 X-Ray Geometry Macro Recommendations

When there is no change of the geometry, the macro is used in shared functional group context.

FFF.2.4.1.4 Example

The user performs an X-Ray acquisition with movement of the positioner during the acquisition. The patient is in Head First Supine position. During the review of the multi-frame image, a measurement of the object of interest in the frame “i” needs to be performed, which requires the calculation of the pixel spacing at the object location for that frame.

For the frame “i”, the Positioner Primary Angle is -30.0 degrees, and the Positioner Secondary Angle is 20.0 degrees. According to the definition of the positioner angles and given the patient position, the Beam Angle is calculated as follows:

Beam Angle = arcos( |cos(-30.0)| * |cos(20.0)| ) = 35.53 degrees

The value of the other attributes defining the geometry of the acquisition for the frame “i” are the following:

ISO = 750 mm SID = 983 mm TH = 187 mm

(Px (Imager Pixel Spacing) = 0.2 mm/pix

The user provides, via the application interface, an estimated value of the distance from the object of interest to the tabletop: TO = 180 mm. This value can be encoded in the attribute Distance Object to Table Top (0018,9403) of the Projection Pixel Calibration Sequence (0018,9401) for further usage.

This results in an SOD of 741.4 mm (according to the equation SOD = 750mm - [(187mm-180mm) / cos(35.53°)] ), and in a magnification ratio of SID/SOD of 1.32587.

The resulting pixel spacing at the object location and related to the center of the X-Ray beam is calculated as (Px * SOD / SID = 0.150844 mm/pix. This value can be encoded in the attribute Object Pixel Spacing in Center of Beam (0018,9404) of the Projection Pixel Calibration Sequence (0018,9401) for further usage.

Below are the encoded values of the key attributes of this example:

Positioner Type (0018,1508) = CARM
X-Ray Receptor Type (0018,9420) = DIGITAL_DETECTOR
C-arm Positioner Tabletop Relationship (0018,9474) = YES
Shared Functional Group Sequence (5200,9229)
Item 1 For all frames
Item 1
Item 1
>Projection Pixel Calibration Sequence (0018,9401)
Item 1
Image Enhanced XA/XRF Image C.8.19.2 Specifies the image type: ORIGINAL or DERIVED.

Table FFF.2. 4-7 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
Derivation Image C.7.6.16.2.6 Specifies the different derivation steps (including the latest step) that led to this instance.
Pixel Intensity Relationship LUT C.7.6.16.2.13 Specifies the relationship between the stored pixel data values and the X-Ray intensity of the resulting derived instance.
XA/XRF Frame Characteristics C.8.19.6.1 Specifies the latest derivation step that led to this instance.
XA/XRF Frame Pixel Data Properties C.8.19.6.4 Specifies the characteristics of the derived pixel data, both geometric and densitometric.

FFF.2.4.2.3.1 Enhanced XA/XRF Image Module Recommendations

The usage of this module is recommended to specify the image type.

Table FFF.2.4-8 ENHANCED XA/XRF IMAGE MODULE Recommendations

Attribute Name Tag Comment
Image Type (0008,0008) The first value is DERIVED in this scenario.

FFF.2.4.2.3.2 Derivation Image Macro Recommendations

The usage of this macro is recommended to encode the information of the different derivation processes and steps, as well as the source SOP instance(s) when the image or frame are derived from other SOP Instance(s).

Table FFF.2.4-9 DERIVATION IMAGE MACRO Recommendations

Attribute Name Tag Comment
Derivation Image Sequence (0008,9124) Contains one item per derivation process that led to this SOP Instance.
>Derivation Description (0008,2111) Free text description of this derivation process, typically for display purposes.
>Derivation Code Sequence (0008,9215) Contains as many items as derivation steps in this derivation process.
>Source Image Sequence (0008,2112) Contains one item per source SOP Instance used in this derivation process.

If this image is not derived from source SOP Instances, the Derivation Image macro is not present, and the XA/XRF Frame Characteristics macro is used instead.

FFF.2.4.2.3.3 Pixel Intensity Relationship LUT Macro Recommendations

The usage of this macro is recommended to enable the applications to get the pixel values back to a linear relationship with the X-Ray intensity.

If readers of the image do not recognize the Pixel Intensity Relationship value, readers can use the value “OTHER” as default.

The number of bits in the LUT Data attribute (0028,3006) may be different from the value of Bits Stored attribute (0028,0101).

FFF.2.4.2.3.4 XA/XRF Frame Characteristics Macro Recommendations

The usage of this macro is recommended to specify the derivation characteristics

Table FFF.2.4-10 XA/XRF FRAME CHARACTERISTICS MACRO Recommendations

Attribute Name Tag Comment
XA/XRF Frame Characteristics Sequence (0018,9412)
>Derivation Description (0008,2111) Contains the description of the latest derivation process.
>Derivation Code Sequence (0008,9215) Contains as many items as derivation steps in this derivation process.
>Acquisition Device Processing Description (0018,1400) Specifies the derivation made at the acquisition system.
>Acquisition Device Processing Code (0018,1401) Specifies the derivation made at the acquisition system.

If the image is derived from one or more SOP Instances, the XA/XRF Frame Characteristics Sequence always contains the same values as the last item of the Derivation Image Sequence.

If the image is derived but not from other SOP Instances, it means that the derivation was performed on the Acquisition system, and the Acquisition Device Processing Description (0018,1400) and the Acquisition Device Processing Code (0018,1401) contain the information of that derivation.

An image derived from a derived image will change the Derivation Description but not the Acquisition Device Processing Description.

FFF.2.4.2.3.5 XA/XRF Frame Pixel Data Properties Macro Recommendations

The usage of this macro is recommended to specify the type of processing applied to the stored pixel data of the derived frames.

Table FFF.2.4-11 XA/XRF FRAME PIXEL DATA PROPERTIES MACRO Recommendations

Attribute Name Tag Comment
Frame Pixel Data Properties Sequence (0028,9443) Recommended in this scenario.
>Frame Type (0008,9007) The first value is DERIVED in this scenario
>Image Processing Applied (0028,9446) In case of derivation from a derived image, this attribute contains a concatenation of the previous values plus the new value(s) of the latest derivation process.

FFF.2.4.2.4 Examples

FFF.2.4.2.4.1 Various successive derivations

In this example, the acquisition modality creates two instances of the Enhanced XA object: the instance “A” with mask frames and the instance “B” with contrast frames. A temporal filtering has been applied by the modality before the creation of the instances.

The workstation 1 performs a digital subtraction of the frames of the instance “B” by using the frames of the instance “A” as mask, then the resulting subtracted frames are stored in a new instance “C”.

Finally the workstation 2 processes the instance “C” by applying a zoom and edge enhancement, and the resulting processed frames are stored in a new instance “D”.

[pic]

Figure FFF.2.4-2Example of various successive derivations

The following figure shows the values of the attributes of the instance “D” in the corresponding modules and macros related to derivation information. The Source Image Sequence (0008,2112) of the Derivation Image Sequence (0008,9124) does not contain the attribute Referenced Frame Number (0008,1160) because all the frames of the source images are used to generate the derived images.

Image Type (0008,0008) = DERIVED\ …
SOP Instance UID (0020,000E) = UID "D"
Shared Functional Groups Sequence (5200,9229)    
  item 1    
    >Derivation Image Sequence (0008,9124)    
      Item 1    
        >>Derivation Description (0008,2111)
        >>Derivation Description (0008,2111)
      Item 1    
        >>Derivation Description (0008,2111)
      Item 1    
        >>Frame Type

Figure FFF.2.4-3 Attributes of the example of various successive derivations

FFF.2.4.2.4.2 Derivation by applying a square root transformation

In this example, the acquisition modality creates the instance “A” of the Enhanced XA object with 14 bits stored where the relationship between the pixel intensity and the X-Ray intensity is linear.

A workstation reads the instance “A”, transforms the pixel values of the stored pixel data by applying a square root function and stores the resulting frames on the instance “B” with 8 bits stored.

[pic]

Figure FFF.2.4-4Example of derivation by square root transformation

The following figure shows the values of the attributes of the instance “B” in the corresponding modules and macros related to derivation information.

Note that the Derivation Code Sequence (0008,9215) is present when the Derivation Image Sequence (0008,9124) includes one or more items, even if the derivation code is not defined in the Context ID 7203.

The Pixel Intensity Relationship LUT Sequence (0028,9422) contains a LUT with the function “TO_LINEAR” to allow the calculation of the gray level intensity to be linear to the X-Ray intensity. Since the instance “B” has 8 bits stored, this LUT contains 256 entries (starting the mapping at pixel value 0) and is encoded in 16 bits.

The value of the Pixel Intensity Relationship (0028,1040) in the Frame Pixel Data Properties Sequence (0028,9443) could be “OTHER” as it is described in the defined terms. However, a more explicit term like “SQRT” is also allowed and will have the same effect in the reading application.

In the case of a modification of the pixel intensity relationship of an image, the value of the attribute Image Processing Applied (0028,9446) in the Frame Pixel Data Properties Sequence (0028,9443) can be “NONE” in order to indicate to the reading applications that there was no image processing applied to the original image that could modify the spatial or temporal characteristics of the pixels.

SOP Instance UID (0020,000E) = UID "B"
Bits Stored (0028,0101) = 8
item 1
Item 1
>>Derivation Code Sequence (0008,9215)
Item 1
Item 1
Item 1
>>LUT Data (0028,3006) = LUT data
>>LUT Function (0028,9474) = TO_LINEAR
>XA/XRF Frame Characteristics Sequence (0018,9412)
Item 1
>>Derivation Code Sequence (0008,9215)
Item 1
Item 1
>>Pixel Intensity Relationship (0028,1040) = SQRT
>>Pixel Intensity Relationship Sign (0028,1041) = 1
>>Geometrical Properties (0028,9444) = UNIFORM
>>Image Processing Applied (0028,9446) = NONE
Image Image Pixel C.7.6.3 Specifies the dimension of the pixel array of the frames.
XA/XRF Acquisition C.8.19.3 Describes some characteristics of the acquisition system that enables this scenario.
X-Ray Detector C.8.19.5 Specifies the type and characteristics of the image detector.

Table FFF.2. 5-2 ENHANCED XA IMAGE FUNCTIONAL GROUP MACROS

Functional Group Macro PS 3.3 Reference Usage
X-Ray Field of View C.8.19.6.2 Specifies the dimension of the Field of View as well as the flip and rotation transformations.
X-Ray Isocenter Reference System C.8.19.6.13 Specifies the acquisition geometry in a fixed reference system.
X-Ray Geometry C.8.19.6.14 Specifies the distances of the conic projection.
XA/XRF Frame Pixel Data Properties C.8.19.6.4 Specifies the dimensions of the pixels at the image reception plane.

FFF.2.5.1.3.1 Image Pixel Module Recommendations

The usage of this module is recommended to specify the number of rows and columns of the Pixel Data, as well as the aspect ratio.

FFF.2.5.1.3.2 XA/XRF Acquisition Module Recommendations

The usage of this module is recommended to give the necessary conditions to enable the calculations of this scenario.

Table FFF.2.5-3 XA/XRF ACQUISITION MODULE Recommendations

Attribute Name Tag Comment
X-Ray Receptor Type (0018,9420) DIGITAL_DETECTOR is used in this scenario.
Positioner Type (0018,1508) CARM is used in this scenario.
C-arm Positioner Tabletop Relationship (0018,9474) YES is necessary in this scenario.

In case of X-Ray Receptor Type (0018,9420) equals “IMG_INTENSIFIER”, there are some limitations that prevent the calculations described on this scenario:

As a consequence, in case of image intensifier it is impossible to relate the position of the pixels of the stored area to the isocenter reference system.

FFF.2.5.1.3.3 X-Ray Detector Module Recommendations

In case of X-Ray Receptor Type (0018,9420) equals “DIGITAL_DETECTOR” the usage of this module is recommended to specify the type and characteristics of the image detector.

FFF.2.5.1.3.4 X-Ray Field of View Macro Recommendations

The usage of this macro is recommended to specify the characteristics of the field of view.

The field of view characteristics may change per-frame across the multi-frame image.

FFF.2.5.1.3.5 X-Ray Isocenter Reference System Macro Recommendations

The usage of this macro is recommended to specify the fixed reference system of the acquisition geometry.

FFF.2.5.1.3.6 X-Ray Geometry Macro Recommendations

The usage of this macro is recommended to specify the distances between the X-Ray source, isocenter and X-Ray detector.

FFF.2.5.1.3.7 XA/XRF Frame Pixel Data Properties Macro Recommendations

The usage of this macro is recommended to specify the dimensions of the pixels at the image reception plane.

FFF.2.5.1.4 Example

In this example, the operator identifies the position (i, j) of an object of interest projected on the stored pixel data of an image A, and estimates the magnification of the conic projection by a calibration process.

The operator wants to know the position of the projection of such object of interest on a second image B acquired under different geometry.

The attributes that define the geometry of both images A and B are described in the following figure:

Image A Image B
Columns (0028,0011) = 850 = 1000
Positioner Type (0018,1508) = CARM = CARM
C-arm Positioner Tabletop Relationship (0018,9474) = YES = YES
Detector Binning (0018,701A) = 1.0\1.0 = 2.0\2.0
Detector Element Spacing (0018,7022) = 0.2\0.2 = 0.2\0.2
Detector Active Shape (0018,7024) = RECTANGLE = RECTANGLE
Detector Active Dimension(s) (0018,7026) = 400.0\400.0 = 400.0\400.0
Detector Active Origin (0018,7028) = 25.0\25.0 = 25.0\25.0
Physical Detector Size (0018,9429) = 410.0\410.0 = 410.0\410.0
Position of Isocenter Projection (0018,9430) = 1024.5\1024.5 = 1024.5\1024.5
>Field of View Sequence (0018,9432)
Item 1
Item 1
Item 1
Minimal Scheduler
Worklist Manager
Push Performer
Pull Performer X Self Scheduled Pull Performer X X A system that implements UPS Watch as an SCP will also need to implement UPS Event as an SCP to be able to send Event Reports to the systems from whom it accepts subscriptions. GGG.2.2 Typical Pull Workflow This example shows how a typical pull workflow could be used to manage the work of a 3D Lab. A group of 3D Workstations query a 3D Worklist Manager for work items which they perform and report their progress. In this example, the RIS would be a “Typical Scheduler”, the 3D Workstation is a “Pull Performer” as seen in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes. We will assume the RIS decides which studies require 3D views and puts them on the worklist once the acquiring modality has reported it’s MPPS complete. The RIS identifies the required 3D views and lists the necessary input objects in the UPS based on the image references recorded in the MPPS. Assume the RIS has subscribed globally for all UPS instances managed by the 3D Worklist Manager. [pic] Figure GGG.2-1 Diagram of Typical Pull Workflow GGG.2.3 Reporting Workflow with “Hand-off” This example shows a reporting workflow with a “hand-off”. Reporting Workstations query a RIS for work items to interpret/report. In this example, the RIS is a “Worklist Manager”, the Reporting Workstation is both a “Pull Performer” and a “Minimal Scheduler” as shown in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes. A reporting workstation claims Task X but can’t complete it and “puts it back on the worklist” by canceling Task X and creating Task Y as a replacement, recording Task X as the Replaced Procedure Step. Assume the RIS is picking up where example GGG.2.2 left off and was waiting for the 3D view generation task to be complete before putting the study on the reading worklist. The RIS identifies the necessary input objects in the UPS based on the image references recorded in the acquisition MPPS and the 3D UPS. [pic] Figure GGG.3-1 Diagram of Reporting Workflow You could also imagine the 3D workstation is a Mammo CAD workstation. If the first radiologist completed the report, the RIS could easily schedule Task Y as the over-read by another radiologist. For further discussion, refer to the Section GGG.2.7 material on Hand-offs, Fail-overs and Putting Tasks Back on the Worklist. GGG.2.4 Third Party Cancel Cancel requests are always directed to the system managing the UPS instance since it is the SCP. When the UPS is being managed by one system (for example a Treatment Management System) and performed by a second system (for example a Treatment Delivery System), a third party would send the cancel request to the TMS and cancellation would take place as shown below. Performing SCUs are not required to react to cancel requests, or even to listen for them, and in some situations would be unable to abort the task represented by the UPS even if they were listening. In the diagram below we assume the performing SCU is listening, willing, and able to cancel the task. If the User had sent the cancel request while the UPS was still in the SCHEDULED state, the SCP (i.e. the TMS) could simply have canceled the UPS internally. Since the UPS state was IN PROGRESS, it was necessary to send the messages as shown. Note that since the TDS has no need for the UPS instance to persist, it subscribed without setting a Deletion Lock, and so it didn’t need to bother unsubscribing later. [pic] Figure GGG.4-1 Diagram of Third Party Cancel GGG.2.5 Radiation Therapy Dose Calculation Push Workflow In this example, users schedule tasks to a shared dose calculation system and need to track progress. This example is intended as a demonstration of UPS and should not be taken as prescriptive of RT Therapy procedures. Pushing the tasks avoids problems with a pull workflow such as the server having to continually poll worklists on (a large number of) possible clients; needing to configure the server to know about all the clients; reporting results to a user who might be at several locations; and associating the results with clients automatically. Also, when performing machines each have unique capabilities, the scheduling must target individual machines, and there can be advantages for integrating the scheduling and performing activities like this. Although not shown in the diagram, the User could have gone to a User Terminal (“Watcher”) and monitored the progress from there by doing a C-FIND and selecting/subscribing to Task X. [pic] Figure GGG.5-1 Diagram of Radiation Therapy Planning Push Workflow In a second example, the User monitors progress from another User Terminal (“Watcher”) and decides to request cancellation after 3 beams. [pic] Figure GGG.5-2 Diagram of Remote Monitoring and Cancel GGG.2.6 X-Ray Clinic Push Workflow In this example, arriving patients are admitted at the RIS and sent to a specific X-Ray room for their exam. The RIS is shown here subscribing globally for events from each Room. Alternatively the RIS could subscribe individually to each Task right after the N-CREATE is requested. It is left open whether the patient demographics have been previously registered and the patients scheduled on the RIS or whether they are registered on the RIS when they arrive. [pic] Figure GGG.6-1 Diagram of X-Ray Clinic Push Workflow GGG.2.7 Other Examples A wide variety of workflow methods are possible using the UPS SOP Classes. In addition to those diagrammed in the previous sections, a few more are briefly described here. These include examples of ways to handle unscheduled tasks, grouped tasks, append cases, “event forwarding”, etc. Self-Scheduling Push & Pull : Unscheduled and Append Cases In radiation therapy a previously unscheduled ("emergency") procedure may be performed on a Treatment Delivery System. Normally a TDS performs scheduled procedures as a Performing SCU in a Typical Pull Workflow like that shown in GGG.2.2. A TDS that might need to perform unscheduled procedures could additionally implement UPS Push (as an SCU) and push the “unscheduled” procedure to the departmental worklist server then immediately set it IN PROGRESS as a UPS Pull SCU. The initial Push to the departmental server allows the rest of the departmental workflow to “sync up” normally to the new task on the schedule. A modality choosing to append some additional images after the original UPS was completed could use a similar method. Since the original UPS can no longer be modified, the modality could push a new UPS instance to the Worklist Manager and then immediately set it IN PROGRESS. Many of the attribute values in the new UPS would be the same as the original UPS. Note that for a Pull Performer that wants to handle unscheduled cases, this Push & Pull approach is pretty simple to implement. Becoming a UPS Push SCU just requires N-CREATE and N-ACTION (Request Cancel) which are quite similar to the N-SET and N-ACTION it already supports as a UPS Pull SCU. The alternative would be implementing both UPS Watch and UPS Event as an SCP which would be more work. Further, potential listeners would have to be aware of and monitor the performing system to track the unscheduled steps, instead of just monitoring the departmental Pull SCP. Self-Scheduling Performer An example of an alternative method for handling unscheduled procedures is a CAD workstation that decides for itself to perform processing on a study. By implementing UPS Watch as an SCP and UPS Event as an SCP, the workstation can create UPS instances internally and departmental systems such as the RIS can subscribe globally to the workstation to monitor its activities. The workstation might create the UPS tasks in response to having data pushed to it, or potentially the workstation could itself also be a Watch and Event SCU and subscribe globally to relevant modality or PACS systems and watch for appropriate studies. Push Daisy Chain Sometimes the performer of the current task is in the best position to decide what the next task should be. An alternative to centralized task management is daisy-chaining where each system pushes the next task to the next performer upon completion of the current task. Using a workflow similar to the X-Ray Clinic example in GGG.6, a modality could push a task to a CAD workstation to process the images created by the modality. The task would specify the necessary images and perhaps parameters relevant to the acquisition technique. The RIS could subscribe globally with the CAD workstation to track events. Another example of push daisy chain would be for the task completed at each step in a reporting process to be followed by scheduling the next logical task. Hand-offs, Fail-overs and Putting Tasks Back on the Worklist Sometimes the performer of the current task, after setting it to IN PROGRESS, may determine it cannot complete the task and would like the task performed by another system. It is not permitted to move the task backwards to the SCHEDULED state. One approach is for the performer to cancel the old UPS and schedule a new UPS to be pulled off the worklist by another system or by itself at some point in the future. The new UPS would be populated with details from the original. The details of the new UPS, such as the Input Information Sequence (0040,4021), the Scheduled Workitem Code Sequence (0040,4018), and the Scheduled Processing Parameters Sequence (0074,1210), might be revised to reflect any work already completed in the old UPS. By including the “Discontinued Procedure Step rescheduled” code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e) of the old UPS, the performer can allow watchers and other systems monitoring the task to know that there is a replacement for the old cancelled UPS. By referencing the UID of the old UPS in the Replaced Procedure Step Sequence (0074,1224) of the new UPS, the performer can allow watchers and other systems to find the new UPS that replaced the old. A proactive SCP might even subscribe watchers of the old UPS to the new UPS that replaces it. Alternatively, if the performer does not have the capability to create a new UPS, it could include the “Discontinued Procedure Step rescheduling recommended” code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e). A very smart scheduling system could observe the cancellation reason and create the new replacement UPS as described above on behalf of the performer. Another approach is for the performer to “sub-contract” to another system by pushing a new UPS onto that system and marking the original UPS complete after the sub-contractor finishes. Yet another approach would be for the performer to deliver the Locking UID (by some unspecified mechanism) to another system allowing the new system to continue the work on the existing UPS. Coordination and reconciliation would be very important since the new system would need to review the current contents of the UPS, understand the current state, update the performing system information, etc. GGG.3 Other Features GGG.3.1 What was Scheduled vs. What was Performed The performing system for a UPS instance determines what details to put in the attributes of the Performed Procedure Information Module. It is possible that the procedure performed may differ in some details from the procedure scheduled. It is up to the performing system to decide how much the performed procedure can differ from the scheduled procedure before it is considered a different procedure, or how much must be performed before the procedure is considered complete. In the case of cancellation, it is possible that some details of the situation may be undeterminable. Beyond meeting the Final State requirements, accurately reflecting in the CANCELED UPS instance the actual state of the task (e.g. reflecting partial work completed and/or any cleanup performed during cancellation), is at the discretion of the performing system. In general it is expected that: An SCU that completes a UPS differently than described in the scheduled details, but accomplishes the intended goal, would record the details as performed in the existing UPS and set it to COMPLETED. Interested systems may choose to N-GET the Performed Codes from the UPS and confirm whether they match the Scheduled Codes. An SCU that completes part of the work described in a UPS, but does not accomplish the intended goal, would set the Performed Protocol Codes to reflect what work was fully or partially completed, set the Output Sequence to reflect the created objects and set the UPS state to CANCELED since the goal was not completed. An SCU that completes a step with a different intent and scope in place of a scheduled UPS would cancel the original scheduled UPS, listing no work output products, and schedule a new UPS describing what was actually done, and reference the original UPS that it replaces in the Replaced Procedure Step Sequence to facilitate monitoring systems “closing the loop”. An SCU that completes multiple steps, scheduled as separate UPS instances (e.g. a dictation & a transcription & a verification), as a block would individually report each of them as completed. An SCU that completes additional unscheduled work in the course of completing a scheduled UPS would either report additional procedure codes in the completed UPS, or create one or more new UPS instances to record the unscheduled work. GGG.3.2 Complex Procedure Steps There are cases where it may be useful to schedule a complex procedure that is essentially a grouping of multiple workitems. Placing multiple workitem codes in the Scheduled Workitem Code Sequence is not permitted (partly due to the additional complexities that would result related to sequencing, dependency, partial completion, etc.) One approach is to schedule separate UPS instances for each of the component workitems and to identify the related UPS instances based on their use of a common Study UID or Order Number. Another approach is for the site to define a single workitem code that means a pre-defined combination of what would otherwise be separate workitems, along with describing the necessary sequencing, dependencies, etc. GGG.3.3 Gift Subscriptions The UPS Subscription allows the Receiving AE-Title to be different than the AE-Title of the SCU of the N-ACTION request. This allows an SCU to sign up someone else who would be interested for a subscription. For example, a reporting workflow manager could subscribe the RIS to UPSs the reporting workflow manager creates for radiology studies, and subscribe the CIS to UPSs it creates for cardiology studies. Or a RIS could subscribe the MPPS broker or the order tracking system to the high level UPS instances and save them from having independent business logic to determine which ones are significant. This can provide an alternative to systems using global subscriptions to stay on top of things. It also has the benefit of providing a way to avoid having to “forward” events. All interested SCUs get their events directly from the SCP. Instead of SCU A forwarding relevant events to SCU B, SCU A can simply subscribe SCU B to the relevant events.-----------------------
[pic] [pic] [pic] R Establish Baseline B L R R L Change Illumination and Filter L L L L L L L L L L R R ... Drug Injection Acquisition Information A Acquisition Information B Acquisition Information C and drug Information Stereometric Relationship SOP Instance Confirm Stereo Capture Short Term single Eye Angio Capture Long Term Angio Capture OP Sop Instances Stored for: B - Both eyes L - Left eye R - Right eye Pairs of images that are intended for stereo viewing Perfusion Analysis CT/MR Cardiovascular Analysis Report CONTAINER ... TID 1 001 Observation Context Patient Characteristics CONTAINER Patient History CONTAINER Procedure Summary CONTAINER Vascular Morphological Analysis CONTAINER Vascular Functional Analysis CONTAINER Ventricular Analysis CONTAINER Report Summary CONTAINERS Vessel CONTAINERS Vascular Measurements (Vessel Branch) CONTAINERS Lesion Finding CONTAINERS Vessel CONTAINERS Flow Quantification CONTAINER Left Ventricle Analysis CONTAINERS Right Ventricle Analysis CONTAINERS Thickening Analysis CONTAINERS Myocardial Perfusion Analysis CONTAINERS Ventricular Measurements - Absolute CONTAINER Ventricular Measurements - Normalized CONTAINERS Vascular Measurements (Vessel Branch) CONTAINERS Calcium Scoring CONTAINER Calcium Scoring CONTAINER Ventricular Measurements - Normalized CONTAINERS Ventricular Measurements - Absolute CONTAINER a b c d [pic] [pic] ROOT Stress Testing Measurements CONTAINER CONTAINS Patient Characteristics CONTAINER (TID 3602) CONTAINS Patient History CONTAINER (TID 3802) CONTAINS Test Conditions CONTAINER CONTAINS Temporal Phase Findings CONTAINER CONTAINS Procedure Summary CONTAINER CONTAINS Conclusions and Recommendations CONTAINER 1 0 - 1 1 1 - N 0 - 1 0 - 1 CONTAINS Observations NUM, TEXT CONTAINS Observations NUM, CODE, TEXT, DATE 1 - N CONTAINS Stress Monitoring Measurement Group CONTAINER 1 - N CONTAINS Observations NUM, TEXT, CODE 1 - N HAS CONCEPT MOD Phase CODE CONTAINS Comparison to Prior Study CONTAINER 0 - 1 CONTAINS Imaging Measurement Group CONTAINER 1 CONTAINS Observations NUM, TEXT, CODE 1 - N Right Eye Inner Inferior Subfield Outer Inferior Subfield Outer Temporal Subfield Inner Temporal Subfield Outer Superior Subfield Inner Superior Subfield Outer Nasal Subfield Inner Nasal Subfield Center Subfield Center Point Left Eye Inner Inferior Subfield Outer Inferior Subfield Outer Nasal Subfield Inner Nasal Subfield Outer Superior Subfield Inner Superior Subfield Outer Temporal Subfield Inner Temporal Subfield Center Subfield Center Point ROOT Document Title CONTAINER CONT HAS CONCEPT MOD Finding Site CODE CONTAINS Finding CONTAINER CONTAINS Image Entry IMAGE CONTAINS Image Library CONTAINER CONTAINS Measurement Group CONTAINER CONTAINS Observations NUM, CODE CONTAINS Patient Characteristics CONTAINER CONTAINS Observations NUM HAS CONCEPT MOD Target Site CODE HAS CONCEPT MOD Target Site = Cardiac Valve Annulus CONTAINS Cardiac Index NUM HAS CONCEPT MOD Cardiac Cycle Point = End Systole HAS CONCEPT MOD Target Site = Right Superior Pulmonary Vein HAS CONCEPT MOD Cardiac Cycle Point = End Diastole HAS CONCEPT MOD Image Mode = 2D Mode CONTAINS Internal Dimensions NUM CONTAINS A-Wave Duration NUM CONTAINS Tissue Velocity NUM CONTAINS Measurement Group CONTAINER HAS CONCEPT MOD Target Site Modifier = Medial HAS CONCEPT MOD Cardiac Cycle Point = Early Diastole HAS CONCEPT MOD Measurement Method = Teichholz HAS CONCEPT MOD Image Mode = 2D mode 20 30 40 50 60 52.20 mm 1 2 1 2 HPGL Document ID View Orientation
1 MEDIAL-LATERAL
2 ANTERIOR-POSTERIOR

Mating Feature ID: 1
2D Mating Feature Coordinates Sequence
Referenced HPGL Document ID 2D Mating Point 2D Mating Axes
1 6.87 / 44.91 1 / 0 / 0 / 1
2 44.24 / 16.7 0.6947 / 0.7193 / -0.7193 / 0.6947
Mating Feature ID: 2
2D Mating Feature Coordinates Sequence
Referenced HPGL Document ID 2D Mating Point 2D Mating Axes
1 6.87 / 44.23 1 / 0 / 0 / 1
2 43.58 / 16 0.6947 / 0.7193 / -0.7193 / 0.6947

Component Group 2 „Heads“ (Mandatory, Exclusive)

Component Group 1 „Stems“ (Mandatory, Exclusive)

1

2

3

4

5

6

Real-World Implant

Part Number

Implant Template A

ORIGINAL

Version 1

Implant Template A

Manufacturer

Replaced Implant Template

ORIGINAL

Version 2

Implant Template A1

DERIVED

Version 1

Derivation Implant Template

Original Implant Template

Implant Template A1

DERIVED

Version 2

Derivation Implant Template

Original Implant Template

Implant Template A2

DERIVED

Version 2

Derivation Implant Template

Original Implant Template

PACS System Integrator

Replaced Implant Template

issues

issues update

Software Vendor

issues

issues

Bite Plate

Patient(CT Image)

Implant

Dental Drilling Template

Spatial Relation

Spatial Relation

Spatial Relation

Archive

User

Treatment

Management

System (TMS)

Treatment Delivery

System (TDS)

1. ‘List Procedures for Delivery’ on TDS console

2. Query UPS (C-FIND)

3. Receive 0-n UPS

4. ‘Select Procedure’ on TDS console (optional if only one procedure in list)

RT Plan and any other reqd objects

(eg verification images, RT Beam Trmt Recs)

8. ‘Start Treatment Session’ on TDS console

9. Set UPS 0% complete, Beam '1' (N-SET)

13. Change UPS ‘COMPLETED’

(N-ACTION)

11. Store RT Treatment Rec and other result objects (C-STORE)

14. Indicate ‘Treatment Session Completed’ on TDS console

5a. Retrieve Archive objects (C-MOVE)

RT Beams Delivery Instruction

RT Treatment Record Summary

RT Beams Trmt Rec (if not in 5)

7. Retrieve TMS objects (C-MOVE)

DELIVER RADIATION

DELIVER RADIATION

Extract input UIDs from selected UPS

Display list to user

Verify

Verify

9. Set UPS 50% complete, Beam '2' (N-SET)

10. Set UPS 100% complete (N-SET)

Receive UPS details

5. Get UPS details (N-GET)

12. Set UPS to Final State (N-SET)

6. Change UPS ‘IN PROGRESS’(N-ACTION with Transaction UID)

Archive

User

Treatment

Management

System (TMS)

Treatment Delivery

System (TDS)

1. ‘List Procedures for Delivery’ on TDS console

2. Query UPS (C-FIND)

3. Receive 0-n UPS

4. ‘Select Procedure’ on TDS console (optional if only one procedure in list)

RT Plan and any other reqd objects

(e.g. verification images, RT Beam Trmt Recs)

8. ‘Start Treatment Session' on TDS console

9. Set UPS 0% complete, Beam '1' (N-SET)

13. Change UPS ‘COMPLETED’

(N-ACTION)

11. Store other result objects (C-STORE)

14. Indicate ‘Treatment Session Completed’ on TDS console

5a. Retrieve Archive objects (C-MOVE)

RT Beams Delivery Instruction

RT Treatment Record Summary

RT Beams Trmt Rec (if not in 5)

7. Retrieve TMS objects (C-MOVE)

Machine

Parameter

Verifier

External Verification

extensions shown in bold

7a. Communicate UPS and any required

delivery data using a non-specified mechanism

‘8a. Deliver Beam 1’ on TDS console

8b. Create RT Conv. Machine Verification

(N-CREATE)

9a. Set ‘Beam1’ RT Conv. Machine

Verification (N-SET)

9c. Notify Verification Status

(N-EVENT-REPORT, Event Type = ‘Done’,

TVS = VERIFIED)

DELIVER RADIATION

Verify

9e. Store ‘Beam1’ RT Beams Treatment Record (C-STORE)

‘8a. Deliver Beam 2’ on TDS console

DELIVER RADIATION

9e. Store ‘Beam2’ RT Beams Treatment Record (C-STORE)

Extract input UIDs from selected UPS

Display list to user

9. Set UPS 50% complete, Beam '2' (N-SET)

9a. Set ‘Beam2’ RT Conv. Machine

Verification (N-SET)

Verify

9f. Delete RT Conv. Machine Verification

(N-DELETE)

9b. Initiate verification (N-ACTION)

9b. Initiate verification (N-ACTION)

9c. Notify Verification Status

(N-EVENT-REPORT, Event Type = ‘Done’,

TVS = VERIFIED)

9d. Get RT Conv. Machine Verification

(N-GET) – optional instruction

9d. Get RT Conv. Machine Verification

(N-GET) – optional instruction

10. Set UPS 100% complete (N-SET)

Receive UPS details

5. Get UPS details (N-GET)

12. Set UPS to Final State (N-SET)

6. Change UPS ‘IN PROGRESS’(N-ACTION with Transaction UID)