SRO Decoder Ring QA Worklist

And in the sledgehammer solution department--as mentioned in the previous post, the problem of mapping SRO meaning is insidious.  Confusion about patient positions (as in the this post) is bad enough.  So why not use machine learning here as well?

Given an SRO and an offset, train an ML model to recognize the input-output relationship.  Notebook link is here.

To turn the notebook in to a production service, we made the following adaptations:

• Fable ElmishFatline front end on IPFS
• Flask RESTful Web App on azure
• Train through notebook
• Weights in IPFS

A few contextual pieces of information that still need work:

•  what about association to site?
•  iView: Applying shift after first field--how to enter with TPO that won't associate with second field?

RT Image Review Worklist Triage

In  this previous post on better image review workflows, David Clunie's noted zombie apocalypse was imminent as we waited for better predictive models for image review behavior.  Well, the zombie apocalypse never happened.  But I have made some progress in sketching a basic model to analyze usage patterns.

The inputs are:

• Time of day of physician login / workstation location
• Time of day of image acquisition
• Time offfset of image approval
• Image feature vector, in some latent space of patient geometry

Then these are regressed to get a prediction of likelihood of image being opened on a workstation, at a given time.

What can be done with this prediction?  Caching on the local drive could be accomplished using:

• Windows Offline Files
• Dokan library, or similar
• BDS Storage for local drive

Additionally, memory caching could be used

• For a WCF-based SoA architectures, memory caching can be implemented either in the client (using a custom binding stack), or in the service as a custom IOperationInvoker.
• MSQ 3D IRW already implements a memory caching for AVS-based cone beam CTs.

So with some implementation for the actual caching, we can fit the model and produce predictions.  If only we had some test data...

Stay tuned for a demo of the model, possibly with only fake input data.

A picture of IEC Table rotations

I have always struggled with a mental picture to help understand how rotation directions work in IEC table coordinates.  As we were looking in to support for decubitus, it occurred to me that rotation directions could be understood in terms of the relationship between orientations that were separated by 90 degrees.

For instance, HFS > HFDL > HFP > HFDR are all related by a 90 degree table roll / transverse rotation, and that the direction corresponds to a positive rotation (clockwise when viewed from the foot of the table).  Likewise, HFS > FFS and HFP > FFP can be viewed as resulting from two 90 degree rotations, with an intermediate stop at a rotation that isn't typically used for treatment (but does generally correspond to stereotactive treatment mode on advanced linacs).

So I assembled this in to a single chart, that I have been checking over to see if it still makes sense: