OHIF / Viewers

OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages
https://docs.ohif.org/
MIT License
3.13k stars 3.29k forks source link

Updating SUV parameters (time/injected dose) doesn't change the SUV[Bug] #3805

Open BrandonDatUHN opened 10 months ago

BrandonDatUHN commented 10 months ago

Describe the Bug

Using the SUV side panel to adjust the SUV calculation does not change the image SUV (except patient weight)

image

SUV is calculated as shown here: image

cimg (t), BW and ID all affect the calculation.

OHIF does it correctly image

cimg (t) needs to be decay corrected back to the injection time, so changing the injection time SHOULD change the SUV changing the injection time from 072100.00 to 012100.00 should change the SUV image

Changing the ID SHOULD affect the calculation changing dose from 588802304 to 10802304 does NOT change SUV image

Changing the BW DOES affect the calculation changing BW from 91 kg to 50 kg changes SUV image

Steps to Reproduce

1) On OHIF DEMO go to an PET-CT study 2) Draw an ellipse and get an SUV value 3) change the Injection time 4) SUV will not change 5) change injected dose 6) SUV will not change 7) change the body weight 8) SUV will change

The current behavior

Changing Injected dose and injected time does not change the SUV

The expected behavior

Changing injected dose and injected time should change the SUV

OS

Windows 10

Node version

OHIF Demo

Browser

Version 119.0.6045.160

salimkanoun commented 10 months ago

what's the manufacturer of your PET images? For instance if its philips, philips give a private tag to get suv values (a conversion factor) and in this case there's no decay correction to apply

BrandonDatUHN commented 10 months ago

The data I've referenced in the reported bug is on OHIF Demo and it appears to be a GE Discovery ST.

We have Siemens and GE scanners at UHN and I haven't dealt with the Phillips private tag myself. SUV should be able to be calculate without that tag if an image is provided in BQML and has the proper injection information included.

I presume the private tag in the siemens images include all the decay correction, patient weight and injected dose into one convenient factor which is great but I'm not sure how OHIF is handling the SUV conversion, I presume its not via the tag since that tag won't exist on GE and SIEMENS Images.

salimkanoun commented 10 months ago

In theory yes we shall be able to calculate SUV without Philips private tag but in practice it's a mess, if you apply the SUV calculation you land on different number than with the private tags. I even seen different SUVs on the same image on different Philips workstations, so i'm not even sure Philips knows how to calculate their own SUVs....

Also you have to which is the decay correction of the image, if the tag says ADMIN it means decay correction are already corrected from the administration time so you don't need to apply decay correction, if it's say START it means correction is aplyed only from acquisition time starting and so decay correction from administration shall be corrected.

In short to investigate the issue could you show which image you are referring to ?

salimkanoun commented 10 months ago

OK i found it, Humm I see it's a bug yes, the SUV shall change,

salimkanoun commented 10 months ago

Yes I confirm this bug is everywhere....

BrandonDatUHN commented 10 months ago

The important part is just that everything is taken from the same reference time. So yes depending on that tag you would need to correct it or not. But I'm referring to not just injection time but also the injected dose. Both numbers can be changed in the PET SUV panel in TMTV mode but when applied don't change the value.

I was looking at https://viewer.ohif.org/tmtv?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.7009.2403.871108593056125491804754960339

jenny-hm-lee commented 8 months ago

Hi @salimkanoun, what are your thoughts to address this issue?

salimkanoun commented 8 months ago

Didn't got the time to explore it but i think is more related to a bug in OHIF as the SUV calculation is properly tested

salimkanoun commented 6 months ago

@sedghi can we switch this bug as confirmed ? There is a problem here and SUV calculation issues are critical as a error here can change the way images are seen and quantified.

Injected dose and injected, acquisition date time doesn't update SUV value while it should have huge impact on it

sedghi commented 4 months ago

I tried in the basic viewer and it worked fine check this out

https://github.com/OHIF/Viewers/pull/4147

I also tried in latest tmtv and worked fine

sedghi commented 4 months ago

Oh I see it is the injection time change hmmmmmm

sedghi commented 4 months ago

Ok updated the PR, it was a silly bug since dcmjs has changed how get works

BrandonDatUHN commented 4 months ago

Just to confirm the SUV should change if any of Patient WT, Injection Time, Injection Dose, Half life or Acquisition time change. All of those will affect the calculated SUV.

sedghi commented 4 months ago

I can confirm after the PR, the suv change for all except the acquisition time, not sure why

salimkanoun commented 4 months ago

I didn't looked at the code yet, but the injection time has two flavors, originally the tag was injectionTime for old studies and this tag became deprecated in favor of injectionDateTime

So I think we made something to prioritize injectionDateTime and if not available use the deprecated injectionTime assuming the date identical to acquisition date

That special logic could be a bed for a bug

sedghi commented 4 months ago

Ok I think i know why the injection time does not really have an effect

it is here https://github.com/cornerstonejs/calculate-suv/blob/main/src/calculateScanTimes.ts#L78-L83

As you see if prefers earliestAcquisitionDateTime

if (
    seriesDateTime.getTimeInSec() <= earliestAcquisitionDateTime.getTimeInSec()
  ) {
    return results.fill(seriesDateTime);
  } else {

Could you please explain the logic and confirm if it makes sense?

BrandonDatUHN commented 4 months ago

Do you mean injection time has no effect or acquisition time has no effect? I kind of understand the logic of using the series time if acquisition time is missing, but if someone physically types in a new number than shouldn't it use that?

sedghi commented 4 months ago

Seems like the logic takes the earliest date and time if there are multiple options. I'm unsure about the rationale behind this approach. Perhaps we should consider removing it? but then what happens if there are multiple from start?

salimkanoun commented 4 months ago

The logic is correct see here : https://qibawiki.rsna.org/images/8/86/SUV_vendorneutral_pseudocode_20180626_DAC.pdf if Series Date (0x0008,0x0021) and Time (0x0008,0x0031) are not after Acquisition Date (0x0008,0x0022) and Time (0x0008,0x0032) { scan Date and Time = Series Date and Time } else { // else may be Siemens series with altered Series Date and Time // either check earliest of all images in series (for all bed positions) (wrong for case of PETsyngo 3.x multi-injection) scan Date and Time = earliest Acquisition Date (0x0008,0x0022) and Time (0x0008,0x0032) in all images of series If series time si later than the earliest acquisition time the earliest acquisition time should be used as reference, so the code is correct.

salimkanoun commented 4 months ago

So I guess we need to display SeriesTime in the SUVpanel ? I assume in the PET/CT example we display acquisition time but this one is used only if before the SeriesTime

BrandonDatUHN commented 4 months ago

I'm not sure I understand the logic of "If series time is not after acquisition time then use series time"

Shouldn't acquisition time be the target to decay correct to? On GE systems the series time is when the tech creates the series but the acquisition time is when the image is actually scanned.

Right now if I open a study the patient info panel shows me the series time in the box labelled acquisition time. So might be best to show both.

BrandonDatUHN commented 4 months ago

So playing with this on https://viewer-dev.ohif.org/tmtv?StudyInstanceUIDs=1.2.840.113619.2.290.3.3767434740.226.1600859119.501

This is a phantom scan so it has no sex. If that's left blank reload data won't change. If I enter M or F or O it will change.

Injection time doesn't change SUV. Still not sure I understand why that is based on the conversation above.

Acquisition time can't be changed (looks to be the same as series time for this study so not sure which its showing)

salimkanoun commented 4 months ago

Yes I agree we should display both Series Time and AcquisitionTime (the earliest one)

That's normal Sex doesn't change the SUV as SUV don't take care of Male or Female (Sex is used for SUL calculation)

Outside the phatom study Injection time update changes SUV, i think we are OK for injection time.

Yes also agree series / acquisition time should be editable as well.

BrandonDatUHN commented 4 months ago

Yes the problem I had with the empty sex field is that if you try and reload the SUV on that phantom study (ie change the weight from 6 to 12) it won't recalculate. Agree it is only used for SUL so it shouldn't affect it but it seems to prevent recalculating when blank.


From: Salim Kanoun @.> Sent: May 24, 2024 6:42 PM To: OHIF/Viewers @.> Cc: Driscoll, Brandon @.>; Author @.> Subject: [External] Re: [OHIF/Viewers] Updating SUV parameters (time/injected dose) doesn't change the SUV[Bug] (Issue #3805)

Yes I agree we should display both Series Time and AcquisitionTime (the earliest one)

That's normal Sex doesn't change the SUV as SUV don't take care of Male or Female (Sex is used for SUL calculation)

Outside the phatom study Injection time update changes SUV, i think we are OK for injection time.

Yes also agree series / acquisition time should be editable as well.

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/OHIF/Viewers/issues/3805*issuecomment-2130468111__;Iw!!CjcC7IQ!JvJZ96W0W8TPrvbX20rEY4C_c4nWMG3zMHYKrub6od65y9_BpwNh7HtNrZwZKF7JfhUe-cWeI9NmcqmPDgRvp5x0AFEPLA$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A257DJKULPYA2Y5QKTLORNLZD666NAVCNFSM6AAAAAA7YI4MM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZQGQ3DQMJRGE__;!!CjcC7IQ!JvJZ96W0W8TPrvbX20rEY4C_c4nWMG3zMHYKrub6od65y9_BpwNh7HtNrZwZKF7JfhUe-cWeI9NmcqmPDgRvp5yI5vT2zQ$. You are receiving this because you authored the thread.Message ID: @.***>

This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization.

If you feel you have received an email from UHN of a commercial nature and would like to be removed from the sender's mailing list please do one of the following: (1) Follow any unsubscribe process the sender has included in their email (2) Where no unsubscribe process has been included, reply to the sender and type "unsubscribe" in the subject line. If you require additional information please go to our UHN Newsletters and Mailing Lists page. Please note that we are unable to automatically unsubscribe individuals from all UHN mailing lists.

Patient Consent for Email:

UHN patients may provide their consent to communicate with UHN about their care using email. All electronic communication carries some risk. Please visit the UHN website and search “Using email to Communicate with Your UHN Health Care Team” to learn about the risks of electronic communication and how to protect your privacy. You may withdraw your consent to receive emails from UHN at any time. Please contact your care provider, if you do not wish to receive emails from UHN.

salimkanoun commented 4 months ago

Agreed there's a bug here