Consider adding the Relative Table Position information

[po09i]

Background

The relative table position is essential to convert from the "patient" coordinate system to the "scanner" coordinate system. For our application in MRI, it would allow to know the location of the isocenter in every acquisition, not just in acquisitions where the table was not moved, which would be the origin when converted to RAS+ using the qform affine matrix. This has been a requested feature in an issue opened in Dcm2niix for another application; to perform offline gradwarp correction.

The different vendors have different ways of encoding this information in the DICOMs. So there would need to be a discussion about how to unify it.

I have gathered some relevant information here: From @neurolabusc (comment)

(0043,10b2) LO [956.1\320.1\-17.3125\0\75.3604\58.0479] # GE MR Table Position Information
(0019,1014) IS [0\0\0]                                  # Siemens V* TablePosition
(0021,1005) IS [0\0\0]                                  # Siemens XA TablePosition
(2005,143c) FL 0                                        # Philips MRStackTablePosLong
(2005,143d) FL 0                                        # Philips MRStackTablePosLat
(0065,1023) LO [0]                                      # UIH TablePosition

From @mr-jaemin (comment): GE Private tag (0043,10b2) MR Table Position Information consists of

• isoVectorZ (Distance from ISO to ALIGN)
• landmark
• tablePosition
• dzPETMR
• topOfHead
• distanceFromTopOfHead Ex) (0043,10b2) LO [956.1\320.1-17.3125\0\75.3604\58.0479]

Proposition

All manufacturers include information in the Inferior/Superior direction but others also allow some Posterior/Anterior and Left/Right information. I therefore suggest to have a tag, possibly "RelativeTablePosition" that would be a 3 value vector containing the relative table displacement in RAS+ coordinates from when it was first set to isocenter.

"TablePosition": [x, y, z]

Let me know what you think :)

[po09i]

I would appreciate any guidance on how to proceed from here?

[jcohenadad]

Hi @effigies, would you be able to ping the appropriate contact for this? Thanks!

[effigies]

@yarikoptic Since you commented on the original issue, do you have a sense of what should be done here?

[yarikoptic]

well, I only provided a generic idea on how to approach such or any other similar issue. But it seems

• there is demand for such metadata
• multiple people (@neurolabusc @imalone @mharms @mr-jaemin) expressed analysis and/or knowledge of how such metadata expressed across different manufacturers, and that amount varies a lot across manufacturers

So it seems that ideally we

• need to distill some optimal sufficient representation to bring metadata into and ask @neurolabusc to implement harmonization from different manufacture specific ones within dcm2niix

but before that - may be worth checking with DICOM WG-16 on what they know/think about this lack of agreement? (I will drop a quick question)

[dclunie]

What about the standard data element Slice Location (0020,1041) which is defined to be the "Relative position of the image plane expressed in mm" but relative to an unspecified origin (i.e,, is not required to be table position relative to isocenter, but could be). This is used in MR, though not by all vendors. See for example the result of running this query on IDC data:

SELECT SliceLocation, Manufacturer
FROM canceridc-data.idc_current.dicom_all
WHERE Modality = 'MR'
LIMIT 10

[dclunie]

Also, the Enhanced CT IOD in DICOM added a specific Table Position (0018,9327) data element, with the definition "Relative longitudinal position of acquisition location of this frame in mm from an implementation specific reference point. Shall be relative to the same reference point for all frames in this SOP Instance, but may be different from the reference point in other SOP Instances. Positions as the table moves into the gantry viewed from the front are more negative." but this has never been officially retrofitted to MR. There is no reason it cannot be added as Standard Extended SOP Class though, and I have seen it one vendor's MR images (do a similar query for it in IDC).

[po09i]

but before that - may be worth checking with DICOM WG-16 on what they know/think about this lack of agreement? (I will drop a quick question)

@yarikoptic Any news from DICOM WG-16? :)

[yarikoptic]

they are above . someone needs to wrap their head around the situation here

[po09i]

@yarikoptic thanks, I did not realize that.

What about the standard data element Slice Location (0020,1041)

I believe this element is what allows to correctly register images that are acquired during the same imaging session (change of tablePosition, change of FOV, translation along a direction). However, it does not say where the table was when the scans were acquired. Here is some data to back this up:

First scan acquired at -20mm FH, slice1:

(0020,1041) -- SliceLocation: 78
(2005,143c) -- Philips MRStackTablePosLong: 0

Second scan acquired with the same parameters acquired at -60mm FH ($\Delta$-40 mm), slice 1:

(0020,1041) -- SliceLocation: 118
(2005,143c) -- Philips MRStackTablePosLong: -60.3

Third scan acquired with the same parameters acquired at +20 FH, slice 1:

(0020,1041) -- SliceLocation: 38
(2005,143c) -- Philips MRStackTablePosLong: 0

The SliceLocation follows the location of the slice with respect to an origin (with an opposite polarity coordinate system in the FH direction in this case). However, the table does not necessarily follow that. I believe the table only moves if the center of the FOV is outside of a specified range from the origin (I think ~50mm for Philips by default). I believe that to know where isocenter is, we need both the sliceLocation (given by the qform/sliceLocation) and the table position.

In any case, this shows the importance of the tablePosition as it gives different information from the SliceLocation tag. I'm all for having a Standard Extended SOP Class, it would standardize the information. For now, I think the information is available in the private tags.