Add high total dose at RP and total DAP alerts for fluoroscopy
Enable admin to define alert levels for total dose at RP and total DAP.
Then highlight studies in the summary fluoroscopy view that exceed either of these values (could be bold, could be red etc.)
Comments (102)
-
reporter -
reporter Correcting typo in url. References issue
#665→ <<cset 41e26ff2da5b>>
-
reporter Updated rf filter test file to prevent error when running tests due to HighDoseMetricAlertSettings not being created during the tests. References issue
#665→ <<cset 5d38d31215a0>>
-
reporter Fixing conflicts after merge of workload branch into develop. References issue
#665→ <<cset c595f06a53fe>>
-
reporter Removing duplicate line in forms.py left when fixing conflicts after merge of workload branch into develop. References issue
#665→ <<cset 7d78811208cc>>
-
reporter Added code to calculate the sum of DAP and dose at RP for the patient involved in each study over a period going back 6 weeks from the current study. At the moment the code calculates these values and populates the new database fields when the user first visits the rf summary page. On revisits the value is simply read from the database. This is not how I'd like this to work in practice: my intention is to have these values calculated at study import, and re-calculated if an OpenREM administrator changes the time period over which the doses are summed. Also, in each row of the rf summary table I'd like the user to see how many studies have contributed to the summed total and also be able to navigate to these - perhaps this should be on the summary details page? At the moment I'm writing the private keys of the associated studies to a string that is displayed on the summary page. There must be a better way of storing the related studies to make it easier for them to be retrieved by a Django template so that they can be used in hyperlinks. References issue
#665→ <<cset b72eebea2c27>>
-
reporter I also want to be able to let the OpenREM admin decide whether to sum using matching patient id or patient name. It's hard-written to use patient id at the moment.
-
reporter I've just put this on testing.openrem.org, but it doesn't really illustrate things because the patient ID data is not present in the test studies that we have.
-
reporter I should also say that I haven't tested this code with a bi-plane system. Not sure how they deal with total DAP and total dose to RP: do they store a single value for each x-ray tube, or just a single value?
-
There are totals for each plane. I'll email you an example. Filtered page and first details on study page list them separately, dose table has them combined... I've opened an issue about this: issue #669
-
reporter Created new table to store pks of RF studies that fall within delta weeks of each RF study. Changed how number of studies in previous delta weeks displayed on RF filtered page. Included info on studies in delta weeks on RF detail page, including hyperlinks to take the user to them. Haven't tried a bi-plane system yet, but do now have a bi-plane RSDR (thanks to Ed). References issue
#665→ <<cset f5fe581dddd5>>
-
reporter @edmcdonagh, for bi-plane I am of the opinion for the summed total DAP and summed dose at RP over a several week time period that I should just add all the totals together, and not separate into the two planes. Thoughts?
-
I think as we don't know where the dose is delivered (total DAP/Dose at RP rather than peak skin dose map), that would be the right thing to do. If we used peak skin dose map, we don't know if the patient has been put in the same place on the table, so would be invalid :(
-
reporter Altered code so that it works as expected for bi-plane systems as well as single-plane systems. Also moved the summed dose information to be after the dose table on the rf detail page. References issue
#665→ <<cset 0e57bacdd086>>
-
reporter Added button that can be used by an admin to recalculate all the summed total DAP and total dose at RP values. No calculation is done in the rf_summary view any more. Still need to add code to calculate these values when a new study is received. References issue
#665.→ <<cset 0386419822c8>>
-
reporter @edmcdonagh the recalculation of the summed total DAP and total dose at RP takes several minutes to carry out. As it stands, the admin user clicks on the button and then has to patiently wait, with no messages or progress reported. Any thoughts on how to make this a bit more user-friendly?
-
Do they need to wait? Should it be decoupled into a Celery task?
Then either some sort of mechanism in the function to update something that can be polled using AJAX?
Or I think there is some way to make one of those notification pop ups come up for a particular user, so the last act of the function could be to make that happen, but I can't remember how (normally you set it and then pass back a view, which you wouldn't be doing). Just found the issue referencing this: issue ref #115.
-
reporter Added calculation of summed total DAP and total dose at RP when a new RF study enters the system. Simplified code that does the calculations. References issue
#665→ <<cset 7aaef2593add>>
-
reporter (Hopefully) fixed the problem where my check for existence of HighDoseMetricAlertSettings did not work (spotted thanks to the failed pipeline). References issue
#665→ <<cset ebcb6a05631e>>
-
reporter (Hopefully) fixed the problem where my check for existence of HighDoseMetricAlertSettings did not work (spotted thanks to the failed pipeline). References issue
#665→ <<cset 40627e724e24>>
-
reporter Removed creation of the HighDoseMetricAlertSettings objects in the test files now that it should take place in the rdsr extractor. References issue
#665→ <<cset 7c164f590238>>
-
reporter Forced calculation of summed total DAP and total dose at RP when an admin changes the delta_weeks time period. References issue
#665→ <<cset 62a6625569e4>>
-
reporter Tidied up the high dose form. Added warning message and made recalc button look better. References issue
#665→ <<cset 45a37f571a3f>>
-
reporter Removed unrequred Button import. References issue
#665→ <<cset 633ec98b470e>>
-
reporter I may have broken something: the delta_weeks value isn't updated when submitting the form now (just tried it on the testing.openrem.org site).
-
reporter Fixed problem where delta weeks was not being updated: my redirection to another page stopped it from working. The 'Recalculate summed data' button now only appears if the user has changed the delta weeks value. References issue
#665→ <<cset 37eb27612916>>
-
reporter Removed unrequired HTML import and made default of changed_accum_dose_delta_weeks True so that users are prompted to update the data initially. References issue
#665→ <<cset 8cfdac93309c>>
-
reporter Note to self: make the display (and calculation on arrival of a new rf study) of summed DAP and dose at RP optional via an admin configuration option. The summed data only works if an OpenREM install is configured to store patient ID information. For these setups the additional columns on the rf filtered page simply take up space.
-
reporter Added admin setting to choose whether to display summed total DAP and total dose at RP in rf summary page. Added admin setting to choose whether to calculate this data during import of new fluoroscopy studies. Altered messages to inform user of which aspect of the settings have been changed by the form. References issue
#665→ <<cset 7670fec1da68>>
-
reporter Added code to hide or show summed dose information on rf detail page depending on the admin setting. References issue
#665→ <<cset c32f476d5eda>>
-
reporter Added a check for the existence of patient module attributes for the study before trying to access them. At least one of the studies in my database is missing this relationship which caused the previous code to fail. References issue
#665→ <<cset 9776d2632af9>>
-
reporter Added e-mail server settings. References issue
#665→ <<cset 8fa87adfd5c4>>
-
reporter Added ability to switch e-mail notification of high doses on and off. I haven't coded the actual e-mail sending yet. I've also added a new database table to enable OpenREM users to be marked as receiving these alerts; I've not coded this into a form yet. References issue
#665→ <<cset 85be2ba1bddb>>
-
reporter Added a method to create or save the high dose alert notification user setting and hooked it into saving of the user profile. I think that when I create the OpenREM admin form to choose which users to notify of high doses I should ensure that code checks for the existence of the high dose alert notification setting for each user, and if it does not exist it should be created. References issue
#665→ <<cset 17291ea99d9a>>
-
reporter I've added e-mail capability to OpenREM and set this up so that designated users are e-mailed when a new fluoroscopy study exceeds the dose alert levels. The code checks for the individual study exceeding these levels, and also accumulated DAP and dose at RP over a specified time period. Some things need sorting out and further testing: I don't know if bi-planar studies will break my new code; I'd like to add a 'send a test e-mail' function so that users can confirm that e-mail is working; I'd like to make the e-mails html; and finally, I'm not able to put the URL of OpenREM into the e-mails - I think this will require adding the 'Sites' app. References issue
#665→ <<cset 1f15d24b6285>>
-
reporter Replaced a specific e-mail address with a dummy one. References issue
#665→ <<cset 789a17dd66dd>>
-
reporter Added html e-mail content - needs smartening up. References issue
#665→ <<cset 1ade81a0d903>>
-
reporter I think I should use render_to_string for the e-mails:
https://stackoverflow.com/questions/2809547/creating-email-templates-with-django https://docs.djangoproject.com/en/1.8/topics/templates/ https://en.proft.me/2014/09/9/django-send-templated-email-text-and-html/
-
reporter Added code to check that highdosemetricalertrecipients exists for the user before trying to change values. References issue
#665→ <<cset d5cf9a97afa4>>
-
reporter Moved e-mail sending code to a new tools file - incomplete at the moment. Added test line into views.py to help me test the code. References issue
#665→ <<cset 92a3ca8c96cc>>
-
reporter Added text and html e-mail templates for high dose fluoro alert messages. Added a new setting in local_settings.py for the server URL. This could be added using the Sites app, but this would still require manual config and is really intended for when you are running multiple Django sites from one server. References issue
#665→ <<cset 9f0e92c997bf>>
-
reporter Removed sending test e-mail from homepage code. References issue
#665→ <<cset d6dc50bd7a44>>
-
reporter Recalculation of accumulated dose levels now uses Ajax. References issue
#665→ <<cset 8705e66f060c>>
-
reporter Removed unnecessary div and associated JavaScript. References issue
#665→ <<cset d7d73155383e>>
-
reporter Tasks already carried out:
- Enable OpenREM admin to define and change DAP and dose at RP alert levels
- In filtered and detail fluoro views highlight any fluoroscopy studies that exceed alert levels
- Enable OpenREM admin to define a time period to look for fluoro studies on the same patient ID
- Enable OpenREM admin to recalculate accumulated DAP and dose at RP over the time period - use Ajax
- In filtered and detail fluoro views display accumulated DAP and dose at RP over the time period and highlight any that exceed alert levels
- Enable calculation of accumulated DAP and dose at RP on fluoro study import
- Enable OpenREM to automatically send e-mail alerts to selected OpenREM users when an alert level is exceeded
Tasks still to be carried out:
- Update documentation to reflect these new features
-
Have you made the decision not to incorporate maximum skin incident dose in this? Obviously it can't be accumulated in the blunt way we can 'accumulate' DAP and dose at RP, but for individual exposures it is of interest?
-
reporter @edmcdonagh do you mean the values that are calculated by openSkin?
-
Yes
-
reporter OK. My thoughts on skin dose maps are that they can't be combined together into a single map due to lack of knowledge about where the patient was on the couch each time. The detail view contains hyperlinks to all the studies relating to that patient ID within the defined number of weeks, so it is easy for a user to open each of these studies in a new tab/window and compare the maps visually. I suppose it might be good to be able to display all the skin dose maps side-by-side on one page.
What are your thoughts on this?
-
I agree that we don't know where the patient is, so should not attempt to 'add' skin dose map information.
It is more to do with alert levels - we know from experience with the dose maps that large reference point doses can equate to small (distributed) skin doses. And conversely, smaller RP doses can equate to high peak skin doses due to single lateral positions with large patients.
Have you considered if you would like to be alerted on this?
-
reporter At the moment peak skin dose data calculated using openSkin code is not stored in the database. I am reluctant to start storing it because as it stands we only store data that is provided by the modalities. I have checked a number of cardiology studies with dose at RP of just less than 2.0 Gy. For all of these the openSkin calculated peak skin dose is well below the dose at RP. However, most studies do not have patient weight. This is therefore not a good test of whether some patients will have a dose at RP below 2.0 Gy, but a peak skin dose above.
-
reporter Added DAP and dose at RP for previous studies to the HTML e-mail template. Need to add to plain text one too. Also changed some wording and a little formatting. References issue
#665→ <<cset 8b748fe9dc41>>
-
reporter Added display of DAP and dose at RP for studies within delta weeks on rf detail page. Changed layout slightly. Checked that the code works for single and bi-plane systems. References issue
#665→ <<cset 645d2c181ba5>>
-
reporter Commented out unnecessary import. References issue
#665→ <<cset e6454591f23d>>
-
reporter Changed text associated with high dose alert field [skip ci]. References issue
#665→ <<cset 09429900af19>>
-
reporter Fixing conflicts following merge in of virtual env branch. References issue
#665→ <<cset 13eab9d1de9d>>
-
reporter Addressing some Codacy issues with duplicate imports or unrequired imports. References issue
#665→ <<cset 7fc9a22e5562>>
-
reporter Fixing conflict after merge of branch. References issue
#665→ <<cset 80381d579f30>>
-
reporter Adding screenshots for documentation; updated config menu image [skip ci]. References issue
#665→ <<cset 570be64d793c>>
-
We must remember to do a new config menu image when this branch and the RabbitMQ branch are both merged.
-
Are you aiming at 0.8.2 or beyond that @dplatten ?
I'm trying to tie things up for a beta release.
-
reporter I'm aiming for 0.8.2.
-
- changed milestone to 0.8.2
-
assigned issue to
-
reporter A start on documentation for the fluoro high-dose alerts [skip ci]. References issue
#665→ <<cset b0e6cf5c6a23>>
-
reporter Updated documentation for the fluoro high-dose alerts; added dummy e-mail settings to settings.py. I need to refine these instructions a little more, and also document how to configure e-mail [skip ci]. References issue
#665→ <<cset 9fc83df3aac4>>
-
reporter Updated documentation for the fluoro high-dose alerts [skip ci]. References issue
#665→ <<cset b28c033ecfe2>>
-
reporter Further documentation updates for the fluoro high-dose alerts. Added links so that clicking on figures should open the graphic for easier viewing; tried to fix bullet list [skip ci]. References issue
#665→ <<cset 701fdde6aa81>>
-
reporter Corrected link to patient id settings [skip ci]. References issue
#665→ <<cset bf9f2aad4282>>
-
reporter Fixing conflicts after merge. References issue
#665→ <<cset ef29315da634>>
-
reporter Initial e-mail configuration documentation written [skip ci]. References issue
#665→ <<cset c6d394e87d2a>>
-
reporter Updated e-mail configuration documentation [skip ci]. References issue
#665→ <<cset 211ca59572f8>>
-
reporter Fixing conflicts after merge of RabbitMQ branch. References issue
#665→ <<cset 3bd7a8cedcec>>
-
reporter Added correct documentation link [skip ci]. References issue
#665→ <<cset 71d162f9d174>>
-
reporter Added ability to send test e-mails to check that e-mail functionality is working. References issue
#665→ <<cset 80febf60370c>>
-
reporter Updated help doc link in the rfalertnofication page; updated release notes to reflect addition of fluoro high dose alerts and e-mail notification; removed dummy e-mail username and password from local_settings.py.example; tidied up the notification form a little. References issue
#665→ <<cset ef9771d0eb4a>>
-
reporter In case I forget how to do this later: python can be used to set up a dummy smtp server on port 1025 in a console:
python -m smtpd -n -c DebuggingServer localhost:1025
The e-mail settings to reflect this:
EMAIL_HOST = 'localhost' EMAIL_PORT = 1025 EMAIL_HOST_USER = '' EMAIL_HOST_PASSWORD = '' EMAIL_USE_TLS = False EMAIL_USE_SSL = False EMAIL_DOSE_ALERT_SENDER = 'an@address.com' EMAIL_OPENREM_URL = 'http://your.openrem.server'
-
Minor mod: currently says 'in which case the user and password settings below should not be required.', when the settings are above.
Another minor mod - in my install because there has never been any reason to do so, there are not many email addresses. Could you add a link to users in the text above the notifications table maybe?
-
reporter Missed a colon in the doc [skip ci]. References issue
#665→ <<cset 6b6ae1ebf010>>
-
reporter Re-ordered the release notes doc [skip ci]. References issue
#665→ <<cset aefd702d917d>>
-
reporter Removed email username and password in release notes [skip ci]. References issue
#665→ <<cset 31a6d5cbe3b8>>
-
reporter Added code to rfdetail.htm to show a message if patient ID is missing for the current study but the display of summed doses over time is switched on. References issue
#665→ <<cset 68492d55ba53>>
-
reporter Providing the user with e-mail error messages for various failure modes if the e-mail server is misconfigured. References issue
#665→ <<cset 773afb0320cf>>
-
reporter Simplified error messages. References issue
#665→ <<cset c81379812053>>
-
reporter There was an error when trying to send a test message; I've made the code that obtains the user e-mail address more robust. References issue
#665→ <<cset b127f20b13ee>>
-
reporter Only display Send test button if there is text in the email address field. References issue
#665→ <<cset 9da60c4068bf>>
-
@dplatten - do you object to having this link added? Refs
#665→ <<cset 1831ce608adc>>
-
reporter Changing example email server port to 25 (standard port for unencrypted email). References issue
#665→ <<cset 5d06abced842>>
-
reporter Merged in issue665fluoroHighDoseHighlight (pull request #237)
Issue665fluoroHighDoseHighlight
Approved-by: David Platten dplatten@gmail.com
References issue
#665→ <<cset b0516b9cf7ec>>
-
Well done - good bit of work here!
Stylistically, I like to include the phrase 'fixes
#665' in the merge message. As it is, if you read this before fixing the issue, can you reference the merge commit in the resolve? ( b0516b9cf7e) -
reporter - changed status to resolved
Updating changes files. References #b0516b9. Fixes issue
#665→ <<cset e86126102de8>>
-
Updating new numbers to use sigdig after ref
#665merge→ <<cset 4b242fe52502>>
-
- changed milestone to 0.9.0
-
reporter @edmcdonagh I’m wondering if it should be possible for an OpenREM administrator to customise the text included in the fluoroscopy high dose alert e-mail message. Thoughts?
-
I guess that depends on who the audience turns out to be, i.e. the system managers, or more general?
In one way, this and all the text needs to be extracted out or labeled or whatever it needs to make the system multilingual. But that's another issue! (Refs
#513, #514)I've yet to start using the emails in practice, so I think I'd have a more informed opinion when I do.
You presumably have already discovered you'd like to do this yourself?
-
reporter I am happy with the wording myself, but strongly suspect that other sites may like to be able to change it. I hadn't thought about the language issue.
-
Annoyingly, these tests fail if the user has a language encoding that uses the comma decimal notation. I wonder if we can override
LANGUAGE_CODE = 'en-us'
at the start of the test? -
reporter You can set the language in the tests. It may be a good idea to do a check of en-us and another that uses commas...
https://docs.djangoproject.com/en/2.1/topics/testing/tools/#setting-the-language
-
reporter I'll take a look at sorting out the language for these tests.
-
reporter Added language override to the fluoro high dose alert tests. The tests now work regardless of the language code set in local_settings.py. References issue
#665and issue#697→ <<cset 64c258f20b69>>
-
reporter Merged in issue697fluoroHighDoseTestsLanguageSetting (pull request #258)
Added language override to the fluoro high dose alert tests. The tests now work regardless of the language code set in local_settings.py. References issue
#665and issue#697Approved-by: David Platten dplatten@gmail.com Approved-by: Ed McDonagh ed@mcdonagh.org.uk
References issue
#665and issue#697, both of which are closed already.→ <<cset 07a6d38308d7>>
-
reporter Merged in issue697fluoroHighDoseTestsLanguageSetting (pull request #258)
Added language override to the fluoro high dose alert tests. The tests now work regardless of the language code set in local_settings.py. References issue
#665and issue#697Approved-by: David Platten dplatten@gmail.com Approved-by: Ed McDonagh ed@mcdonagh.org.uk
References issue
#665and issue#697, both of which are closed already.→ <<cset 07a6d38308d7>>
-
Hi @dplatten - I've had this running on my production system for several days now, and set the threshold low so that I would get some example messages. A few have breached my low threshold, but I haven't had any emails. I have sent emails to myself using the test function, which works fine.
Any idea how to troubleshoot?
- Log in to comment
Added feature that highlights fluoro total DAP or total dose to reference point that are above admin-defined levels. The values are highlighted in bold red on the summary fluoro view. I've included a form that an administrator can use to view and modify the results. I haven't written any docs yet. References issue
#665→ <<cset b0848d7ce59c>>