TMTV hanging protocol doesn't ensure that PET and CT have the same Frame of Reference

[BrandonDatUHN]

Some PET-CT may have different Frame of Reference UIDs within the same study. This could be as a result of two scans being done hours apart or even a patient being repositioned.

Failure to address this issue could lead to an incorrect reading of a PET-CT reading as the PET and CT may appear aligned when in reality they are not

Using Drag and Drop to pull a CT and PET that do not have matching FoR also causes the drag and drop to no longer function in a predictable way. Sometimes it will fail to load the volume, sometimes it will only load in one of axial/coronal/sagital.

I can not currently replicate this issue on the OHIF 3.0 demo site as the 3 PET-CTs available do not have this issue but am providing a phantom scan which you are more than welcome to import include on the Demo website.

I have attached a downloadable link to a phantom data set which has two Frame of Reference UIDs within the same study so you can replicate the issue.

I have replaced this download link with a new one here as the old one had expired and also cleaned up the series descriptions so it's obvious which is in FoR 1 and which is in FoR 2.

https://fileshare.uhn.ca/download/8cfabe10-9aaf-4fc4-be88-3962da8c34f5 Please note that this file upload will expire in 30 days.

Repository URL https://github.com/OHIF/Viewers/tree/v3-stable Version number 3.3.0 Build number 0 UHN Version 2.0.0 (3/27/2023, 2:17:42 PM) OHIF Commit Hash d3200a63838a43f8b7b477ded36ca52a6e6ef85c Browser Chrome 111.0.0 OS Windows 10

If loading this dataset it will initially load and render properly (assuming the hanging protocol picks correctly which it sometimes does and sometimes doesn't)

If you try and drag the CT std FOR 2 image on the viewer won't load it at all.

And you get an error in the console. 3Synchronizer.js:139 Uncaught (in promise) TypeError: Cannot destructure property 'element' of '(0 , Bm.Pr)(...).getViewport(...)' as it is undefined. at Synchronizer.js:139:21 at Array.forEach () at _I._updateDisableHandlers (Synchronizer.js:138:19) at _I.addTarget (Synchronizer.js:61:14) at _I.add (Synchronizer.js:43:14) at SyncGroupService.ts:121:22 at Array.forEach () at mk.addViewportToSyncGroup (SyncGroupService.ts:106:21) at Object. (OHIFCornerstoneViewport.tsx:294:24) at Object.dispatchEvent (eventTarget.js:37:22) (anonymous) @ Synchronizer.js:139 _updateDisableHandlers @ Synchronizer.js:138 addTarget @ Synchronizer.js:61 add @ Synchronizer.js:43 (anonymous) @ SyncGroupService.ts:121 addViewportToSyncGroup @ SyncGroupService.ts:106 (anonymous) @ OHIFCornerstoneViewport.tsx:294 dispatchEvent @ eventTarget.js:37 a @ triggerEvent.js:10 addVtkjsDrivenViewport @ RenderingEngine.js:353 enableVTKjsDrivenViewport @ RenderingEngine.js:289 enableElement @ RenderingEngine.js:82 setViewportData @ CornerstoneViewportService.ts:282 (anonymous) @ OHIFCornerstoneViewport.tsx:412 await in (anonymous) (async) (anonymous) @ OHIFCornerstoneViewport.tsx:421 Fl @ react-dom.production.min.js:262 t.unstable_runWithPriority @ scheduler.production.min.js:18 Za @ react-dom.production.min.js:122 Nl @ react-dom.production.min.js:261 Sl @ react-dom.production.min.js:243 (anonymous) @ react-dom.production.min.js:123 t.unstable_runWithPriority @ scheduler.production.min.js:18 Za @ react-dom.production.min.js:122 Ya @ react-dom.production.min.js:123 Wa @ react-dom.production.min.js:122 gl @ react-dom.production.min.js:237 Oo @ react-dom.production.min.js:170 (anonymous) @ ViewportGridProvider.tsx:275 (anonymous) @ ViewportGridProvider.tsx:291 (anonymous) @ ViewportGridProvider.tsx:290 A @ ViewportGrid.tsx:290 drop @ ViewportPane.tsx:29 value @ DropTargetImpl.js:39 (anonymous) @ drop.js:38 (anonymous) @ drop.js:19 (anonymous) @ drop.js:18 Object.keys.reduce.r. @ DragDropManagerImpl.js:70 handleTopDrop @ HTML5BackendImpl.js:336 Synchronizer.js:139 Uncaught (in promise) TypeError: Cannot destructure property 'element' of '(0 , Bm.Pr)(...).getViewport(...)' as it is undefined. at Synchronizer.js:139:21 at Array.forEach () at _I._updateDisableHandlers (Synchronizer.js:138:19) at _I.addTarget (Synchronizer.js:61:14) at SyncGroupService.ts:126:22 at Array.forEach () at mk.addViewportToSyncGroup (SyncGroupService.ts:106:21) at Object. (OHIFCornerstoneViewport.tsx:294:24) at Object.dispatchEvent (eventTarget.js:37:22) at a (triggerEvent.js:10:15)

If you then select the PET from the other Frame of reference (AC256 FOR 2 the CT and PET will load but not the fused image. ) There is an error in the console as it appears cornerstone 3D knows it can't render the image sets because they don't have a matching frame of reference. Uncaught (in promise) Error: **Volumes being added to viewport viewport-5 do not share the same FrameOfReferenceUID. This is not yet supported** at v._isValidVolumeInputArray (BaseVolumeViewport.js:305:23) at async v.setVolumes (BaseVolumeViewport.js:237:63) BaseVolumeViewport.js:305 Uncaught (in promise) Error: Volumes being added to viewport viewport-6 do not share the same FrameOfReferenceUID. This is not yet supported at v._isValidVolumeInputArray (BaseVolumeViewport.js:305:23) at async v.setVolumes (BaseVolumeViewport.js:237:63) BaseVolumeViewport.js:305 Uncaught (in promise) Error: Volumes being added to viewport viewport-7 do not share the same FrameOfReferenceUID. This is not yet supported at v._isValidVolumeInputArray (BaseVolumeViewport.js:305:23) at async v.setVolumes (BaseVolumeViewport.js:237:63) The images also continue to sync scroll together which they really shouldn't as that makes the user believe they are in fact fused when they are not.  There needs be a check when picking the hanging protocol (and in drag and drop) such that images which don't share the same FoR a warning is displayed so the user would know why the fused view isn't there and so they don't accidentally mis-report. Additionally the behaviour of crashing and loading only one frame should be investigated. 

[jenny-hm-lee]

@sedghi Recall this problem is about there are series with different FoR within a study. We want to ensure user doesn't misinterpreted what the TMTV mode is showing. Currently, when the PET and CT have different FoR, the fusion viewport doesn't show anything, but the PET and CT viewport still permits sync scroll. This could be misleading.

I vaguely recall there is some difficulty in retrieving the FoR to use in hanging protocol. As an interim solution, could we prevent sync scrolling between the CT and PET viewport, when the fusion viewport is not showing.

[BrandonDatUHN]

@sedghi Hi again.

Just following up on this issue as the previous link I shared has expired.

I've recreated the issue on the latest version of the OHIF code and the issue persists and if anything might be worse as it seems to often crash or load viewports inconsistently once you load the first dataset with a different Frame of Reference.

We believe this is a critical issue as in my example you instead imagine that instead of a phantom that was instead a person's head that had got up mid scan to go to the washroom and then sat back down on the couch, this is a relatively common thing to have happen and so many users will have image sets with multiple frames of references in them.

You can also see by my example that since the images keep scrolling together a physician could probe an area of activity on the PET and believe it was in an incorrect location on the CT due to the mis-registration.

[sedghi]

@BrandonDatUHN Is this still an issue?

[BrandonDatUHN]

We have been working on a CT/PT picker to allow the user to pick a new CT and PET which will only allow image sets with matching FoR.

What I'm not sure about is what happens if the hanging protocol logic which selects the PET and CT by default inadvertently picks a CT and PET with different FoRs. I haven't found one yet that does but I'm not sure if it's been addressed in the hanging protocol default selection script.