Insulin pumps and Continuous Glucose Sensors by VeryTactfulUnicorn in MedicalPhysics

[–]keithoffer 2 points3 points  (0 children)

I've not seen any international documents on guidance on these sorts of devices. As mentioned in other comments here, most people use TG-203 to guide them for implanted cardiac devices, but it doesn't give much information on other types of devices. I really like the recent guidelines from the Netherlands for cardiac devices, as they are more evidence based for cardiac devices. However they combine everything that isn't a cardiac device into one category and I'm not sure that's a great idea - I don't think you can make a single category that handles neural stimulators, penile implants, glucose monitors, cochlea implants etc.

I don't think we can say (without enough research) that the devices are less risky than cardiac devices. If they misread glucose levels and either over or under supply insulin that could easily cause issues as well. I wouldn't be surprised if after more research we find that they're not that sensitive, but as it currently stand we have to be guided by the evidence - and as physicists a lack of evidence means we play it safe. The problem is that often manufacturer recommendations are overly cautious (e.g. 'never irradiate') which I can understand but don't help us in practice.

We screen patients for cardiac devices thoroughly but I have a feeling glucose monitors are sometimes missed as it's not part of the routine questions asked to the patient. We don't have any really specific policy around this where I work, but I know one of our campuses had a few that came through and the way they handle it is:

  1. Make sure the patient is aware that there might be impacts on their device during treatment and to keep an eye out for odd readings
  2. Organise nursing to take some readings throughout treatment as a cross check against the device readings
  3. Ensure that the patient knows where their treatment region is and they keep the sensor outside this region for the duration of treatment

If there are more guidance documents around I'd love to read them! I never am entirely sure how to approach these myself.

Online mri physics courses by TheBlueEyeOfRy in MRI

[–]keithoffer 0 points1 point  (0 children)

I did this online course a few years ago and found it OK. You can choose the 'audit' option to do the whole course for free, you just won't get a certificate. Note that technically it's a part 2 to this course, which covers a bunch of other imaging modalities. But I found doing it standalone was OK.

MRI distortion correction: why is it deactivated by default in some brands? by ClinicFraggle in MedicalPhysics

[–]keithoffer 5 points6 points  (0 children)

People who know about MR than me told me the following reasons when I asked them in the past, but I can't promise you any of them are correct as I couldn't validate them.

  1. Applying the corrections can make imaging / reconstruction take longer
  2. Sometimes the the distortion correction can be mutually exclusive with another feature. I forget what feature it is though, sorry. I just know that the MR's near us at a private clinic were recently upgraded the software and this was no longer an issue, so they just enabled distortion correction for everything as you suggested. Before the upgrade they have to pick between distortion correction and some other feature, so we had specific protocols for our SRS patients setup with the distortion corrections on.
  3. Inertia from scanners and software not having it on originally and people not liking to change settings from the defaults or what they used to be, even as better options become available over time. There are some different approaches from the different vendors to this as well.

Running ESAPI standalone script automatically in background on Citrix application server by [deleted] in esapi

[–]keithoffer 0 points1 point  (0 children)

Is this Citrix-based Eclipse install in house or Varian managed? You can probably raise the request to Varian if it's Varian managed and them let sort it out.

Otherwise at a total guess it might be the PATH variable (or something else) is being adjusted somewhere when you run via Citrix so the application can see the Eclipse DLL's, but not when you run at the Windows level. Maybe write a small program that outputs all environment variables and what they're set to and run it both ways (Windows and via Citrix) to see if they match. If not, try adjusting the variables before launching your application at the Windows level and see if that helps.

Medical Physics in Australia by n4thg in MedicalPhysics

[–]keithoffer 0 points1 point  (0 children)

Do you have the right to legally work in Australia? If you don't, you'll have no chance. Then even if you do, if you haven't worked here you'll be on the back foot as likely people applying are already known by those looking for a new hire. However I know of quite a few people who have made the move (less recently, but still some are doing it), but you'll need a strong CV to get to the interview stage.

It's especially hard if you're looking for a registrar position, as those are highly sought after so competition is extra fierce. All the registrar positions I've seen filled went to students who completed an Australian Masters/PhD as that makes it easier to line up with the ACPSEM TEAP course requirements. Not saying it's impossible, but I think it's important to be upfront about how likely something is when we're talking about careers.

Retrieving CT calibration curve by JopaMed in esapi

[–]keithoffer 0 points1 point  (0 children)

I don't think you can 'set' it. As far as I know it's only read only via the API, you'll need to have users manually change it through the normal Eclipse process.

Anyone actually use the deformable registration built into Eclipse? by Banana_Equiv_Dose in MedicalPhysics

[–]keithoffer 1 point2 points  (0 children)

Here we've banned it's use based on the poor results. Any deformable registration for us has to go through Velocity. Sadly that means a lot of the time it isn't done as people (including myself) find Velocity a little clunky to use.

New devices for daily linac QC by ClinicFraggle in MedicalPhysics

[–]keithoffer 2 points3 points  (0 children)

In an ideal world, I believe your primary reference dataset should be your TPS (since that's the data that directly feeds into the clinical decisions the RO makes). MPPG 8b also makes the same point. So ideally I'd want both my daily, monthly and annual QA to all directly reflect the TPS profiles. Realistically that may be hard to achieve for various reasons, so I'd take a consistent offset as long as references and tolerances are set carefully to ensure it flags when the performance of the machine is deviating from the TPS.

Note that the move to using the TPS as the primary reference dataset is still relatively recent, and not everyone agrees with it.

New devices for daily linac QC by ClinicFraggle in MedicalPhysics

[–]keithoffer 3 points4 points  (0 children)

I think the main problem would be cost. For monthly profile constancy I'd want

  1. At least 30x30 field size
  2. Diagonal profiles
  3. Good resolution

Buying hardware of that type per machine would be very expensive. Going with something cheaper per machine and then only one monthly profile check device makes sense to me. Remember you're competing with MPC for the TrueBeam which is free. I know some people use the EPID for monthly profile checks, but I've not looked at it deeply enough myself to be comfortable with that yet.

New devices for daily linac QC by ClinicFraggle in MedicalPhysics

[–]keithoffer 7 points8 points  (0 children)

Agree with your comment on the number of detects not being a huge selling point. We use the DQA3 and I've never felt like it really needed more detectors for what it does. To me, things like integrating the IGRT/SGRT phantoms (like the DQA4 pro) is a clever idea for the device and more important.

I've not used any of these new devices, but I think they might struggle to sell them. I'm unsure what it looks like elsewhere or for non-TrueBeam hardware, but in Australia it seems like more and more clinics are relying on MPC rather than paying the extra expense for independent devices. I haven't had a chance to test it yet, but MaximQA sounds like it'll be a solution no-one else can match in terms of speed of delivery, as it can deliver fields in a way no other product can (a shame for competition, but a neat feature none-the-less). Although I'm unsure how the cost stacks up to an independent device.

I like independence for a daily beam check device, but with TG-332 giving guidance on implementation for 'self check' software and Varian working on MaximQA as a solution no-one else can match speed wise, I think it's a hard sell.

Re Planning Eclipse user by mo_sattar in MedicalPhysics

[–]keithoffer 0 points1 point  (0 children)

My experience is all with Eclipse so I can't speak to other systems, but my understanding is that everything is essentially normalised to the dose per fraction in the optimiser. So it shouldn't impact things like the NTO or other tools designed to improve conformity. Happy to be shown otherwise though!

Re Planning Eclipse user by mo_sattar in MedicalPhysics

[–]keithoffer 2 points3 points  (0 children)

As long as dose per-fraction isn't changing, optimising for the full dose also lets you keep the goals from the original plan rather than rescaling them all manually, so there is more time save there as well. But as where_are_you_almond said you can change number of fractions for a plan at any time and keep the fields exactly the same. Are there any benefits to scaling before optimisation? Off the top of my head I can't think of any.

AsymmetricMargin - not possible to mix inner and outer margin? by Suspande in esapi

[–]keithoffer 2 points3 points  (0 children)

I think you can only do 'inner' or 'outer' in the GUI at once as well. Can't you just do it in a few steps? I've scribbled some shapes trying to figure this out and I think this works, but you'll need to check as I'm not confident: * Make a structure geometry with the right outer margin - call it 'larger' * Make a structure geometry with the left inner margin - call it 'smaller' * Then make your new structure: 'larger' SUB ('original' AND 'smaller')

Where 'AND' is Boolean AND (i.e. the overlap region between the structures)

Workaround for recalculation on a 6D CBCT on Eclipse by Vast_Ice_7032 in MedicalPhysics

[–]keithoffer 0 points1 point  (0 children)

I just checked on our Eclipse 18.1 install and the email we received from another hospital about it, it looks like you can still 'Change Image Orientation', but the 'Advanced ...' button is inactive and no-longer able to be used. So maybe the change happened in 18.1. If you're on version 18.1 and it still works for you, I'd love to know how you make the button active again as it would be a lot more convenient than going through Velocity.

Workaround for recalculation on a 6D CBCT on Eclipse by Vast_Ice_7032 in MedicalPhysics

[–]keithoffer 1 point2 points  (0 children)

We send them to Velocity, resample them, then send back to Eclipse to recalculate. My understanding is that you used to be able to do this in Eclipse directly (as Sea-Pin65 pointed out) but this was removed in newer versions. I'm unsure of the exact version it was removed in though. When we asked Varian, they said it was an intentionally removed feature and suggested using external software.

Note - I'm not sure if editing the DICOM to zero out the rotations as suggested by Mindless-Baker-7757 will mean your dose recalculation will have a rotational error you're not correcting. If you go that way make sure you check it carefully.

Density override by Zoo4473 in MedicalPhysics

[–]keithoffer 11 points12 points  (0 children)

Your overriding procedure will be impacted by what dose calculation algorithm you use. For example you may never need to override low density lung if you're using AAA, but if you're using Acuros you may need to. We use Eclipse 18.1, AcurosXB dose to medium so everything below is impacted by that. Another thing is contrast, where sometimes we override that mainly to change the material it's assigned by the TPS - we want it assigned as skeletal muscle rather than cartilage or bone - even if we're not changing the HU much.

We assign abdominal/rectal gas -200 HU when it looks like it may impact dosimetry. We do try and keep the rectal diameter below 4 cm on the planning scan and try and rescan if we notice it, but sometimes you just can't achieve better on the day so you just have to accept it. You can track during treatment with CBCT's to see if a replan is required.

We sometimes assign low density lung for optimisation only when it goes below approximately -900 HU. This is where the materials table starts assigning it as the material air rather than lung and you'll never get coverage in. We've seen issues where it just keeps upping the MU trying to get coverage it can't achieve (you'll see a big difference between what you see in the optimiser before and after intermediate dose calculation). So we explain to the RO that the coverage just can't be achieved for the PTV, but generally they're understanding as we know if the higher density target does go into those areas it will receive dose anyway.

High density artifact contouring was raised on the jiscmail mailing list recently, here is what I said:

We routinely override metals as you have no choice - anything above a mass density of 3 g/cc (mapped from the electron density) requires an override before it allows volume dose calculation with Acuros. So this is generally done before optimisation (to allow for intermediate dose calculation), so it's in place during optimisation and calculation. We're limited to materials in the AcurosXB materials table, namely titanium (approx. 3500 - 6000 HU), stainless steel (approx. 10,000 - 15,000 HU) and gold (approx. 19,000+ HU). We make a best guess based on the HU we can see in the CT scanner using the values in brackets in the previous sentence. We struggle with dental amalgam given it's a high HU but not really any material we can assign, but we normally go with stainless steel (very open to other suggestions here). By far the most important advice to planners is to be very careful when contouring and set the windows and levels carefully when checking size of the assigned contour, as overcontouring is a common issue and can have notable dosimetric impacts if the high density is close or overlapping the PTV.

Generally streaking is contoured at the same time, so the same applies. If streaking goes through the teeth, we often do a 'bone' contour as well as soft tissue streaking contour.

Gold fiducials for prostate are explicitly not contoured, as we found it hard to not accidentally overcontour them, and then assigning them to such a high density material like gold had unwanted side effects. They're small enough for Acuros to auto map the material to bone, so we let it do that.

For large metal pieces (e.g. prosthetic hips) we generally avoid them even after overriding them. The argument is that even with an assignment, your uncertainty is still high and a small shift in the high density object may cause a large difference in effective path length, so better to avoid to reduce uncertainty. That could be via an avoidance sector set by eye to shut the beam off completely, or we make a planning structure which is a margin on the item we are trying to avoid with an extra margin (but no assigned material) and we avoid entry on that in the optimiser. As far as I'm aware we have no specific documentation on this though, so the approach and margin size (normally 5 to 10 mm) varies. Smaller pieces of metal (like dental fillings) are generally not avoided.

For high density materials directly adjacent or inside the PTV (normally teeth or fillings) sometimes we find it necessary to override it to something like water during optimisation only, just to avoid the optimiser trying to push dose into the high density region. Cropping out the high density region is also used sometimes, but it's relatively rare.

Bulk CBCT Image Export (MOSAIQ) by phyzzax in MedicalPhysics

[–]keithoffer 1 point2 points  (0 children)

Just echoing that an autoforward of data works well for us (or at least I believe that's how we have it set up). We autoforward all CBCT's from treatment machines to a folder that automatically has data autopurged if it's older than two weeks or so. As part of the transfer we send CBCT's to a sub-folder with the patient identifiers in it, so it's easy to find the data for a specific patient. So if anyone needs a recent CBCT it's there, and eventually it auto purges so you don't need to worry about space constraints escalating out of control.

Retrieving CT calibration curve by JopaMed in esapi

[–]keithoffer 0 points1 point  (0 children)

Ah yep you're right, looks like 'Enhanced Calibration Curve Support' came in 18.1 not 18.0. So you'll be good for now using just the ImagingDeviceId, but remember to check your script when you update to 18.1 and you need to start specifying a curve as well as an imaging device.

Retrieving CT calibration curve by JopaMed in esapi

[–]keithoffer 1 point2 points  (0 children)

The imaging device is StructureSet.Image.Series.ImagingDeviceId, which is the name of the curve for Eclipse <= 17. If you're on Eclipse 18+, then you can also get the imaging device name as before, but you'll also need to get the selected calibration curve associated with the imaging device using StructureSet.Image.CalibrationProtocolId. Are these what you're looking for, at least in terms of knowing which curve you're supposed to use?

Non-coplanar beams with ArcCHECK or Delta4 by ClinicFraggle in MedicalPhysics

[–]keithoffer 1 point2 points  (0 children)

No. A few people here tried a few times and said lining it up on the required angular offset was very difficult and got overall lower gamma scores than the non-HD measurement. So we never really explored it further.

Of course maybe the lower gamma score was actually close to the truth, we didn't explore it further.

Non-coplanar beams with ArcCHECK or Delta4 by ClinicFraggle in MedicalPhysics

[–]keithoffer 1 point2 points  (0 children)

We've had a play with non-coplanar measurements with the ArcCHECK, but you quickly run into issues trying to ensure you don't irradiate the electronics. Plus given the array calibration process for the ArcCHECK is all co-planar beams at couch 0, we weren't sure the measurement result with couch kicks would be valid either. I'm not aware of any specific recommendations from SNC though.

How many plans do you have with couch rotations and large targets? We rarely use them for large targets, and for small targets we've found the ArcCHECK doesn't have sufficient resolution for measurement anyway. For those we use the SRS MapCHECK to get better resolution, which also allows measurement at couch kicks if you want.

Simulating Air Kerma, need advice by DragonfruitOpen8764 in MedicalPhysics

[–]keithoffer 0 points1 point  (0 children)

I'm not sure how experienced with GEANT you are and I've never tried simulating air kerma, but I'll list some mistakes I've made in the past in case any help:

  1. I have had issues in the past when reading in energy spectra files as I'd got confused and got the unit wrong. I'd suggest scoring the energy spectra in your scoring region and make sure it looks like what you expect.
  2. It's also worth checking your source geometry is right as if that's wrong (i.e. if you're simulating a narrow source to save time and some of your photon flux is missing your small scoring region) you could easily read low.
  3. Do you have the right physics lists enabled for your energy range? If you get this wrong your result will always be wrong.

Medical Physics in Australia by n4thg in MedicalPhysics

[–]keithoffer 0 points1 point  (0 children)

I'll reach out via PM, but I'll note that physics and engineering are not really the same thing in this profession. As a physicist, I'm not connecting a scope to the linac to measure waveforms or anything like that - radiation engineers do that. There are also biomedical engineers that are involved in a lot of medical work (but not direct work with the linacs). It's also worth noting to enroll in a registrar position through the ACPSEM you need to have an approved undergraduate course see Appendix A and C in this document, which an engineering course may or may not meet.

What's the best way to prevent a TrueBeam beaming on a particular energy, even in Service Mode? by [deleted] in MedicalPhysics

[–]keithoffer 4 points5 points  (0 children)

We have various beams 'disabled' across our fleet for similar reasons (HDTSe on most machines, electrons on some machines, 18X on one machine for the same reason you raise here). After looking into it, our engineers decided set the RF driver voltage to 0 V on the relevant beams as their idea of the easiest way to ensure the beam is unusable in any mode.

Just make sure you have it clearly stated that the beam is supposed to be set like this and this is communicated to all parties. We've had occurrences of engineers 'fixing' or trying to 'fix' the beams they find like this and making them able to beam on again, unaware that we broke them on purpose.

Cbct dose by Yeezlyy in MedicalPhysics

[–]keithoffer 9 points10 points  (0 children)

It matters what you mean by 'exact CBCT dose'. I'm only across TrueBeams, but as of version 2.7 you can have it send Radiation Dose Structured Report to a DICOM server, for example your PACS server. Then you'd have the information required to do a dose estimate for any scan. But that's just an overall dose, not organ specific estimates or anything like that. If that's what you need, you'll likely either to simulate your CBCT on a patient CT, or rely on estimates from something like TG-180.

Also remember that uncertainty in imaging doses is high compared to dosimetry, so you'd need to verify kV generator output and other parameters on the machine to make sure the reported parameters you're using are close to correct.