1. OpenREM Avatar OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Add high total dose at RP and total DAP alerts for fluoroscopy

Issue #665 resolved
David Platten created an issue

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)

  1. David Platten reporter

    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>>

  3. David Platten 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>>

  6. David Platten 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>>

  7. David Platten 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.

  8. David Platten 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.

  9. David Platten 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?

  10. Ed McDonagh

    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

  11. David Platten 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>>

  12. David Platten 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?

  13. Ed McDonagh

    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 :(

  14. David Platten 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>>

  15. David Platten 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>>

  16. David Platten 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?

  17. Ed McDonagh

    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.

  18. David Platten 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>>

  19. David Platten 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>>

  20. David Platten 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>>

  21. David Platten 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>>

  25. David Platten 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).

  26. David Platten 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>>

  27. David Platten 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>>

  28. David Platten 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.

  29. David Platten 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>>

  31. David Platten 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>>

  33. David Platten 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>>

  34. David Platten 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>>

  35. David Platten 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>>

  40. David Platten 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>>

  41. David Platten 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>>

  45. David Platten 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
  46. Ed McDonagh

    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?

  49. David Platten 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?

  50. Ed McDonagh

    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?

  51. David Platten 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.

  52. David Platten 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>>

  53. David Platten 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>>

  60. Ed McDonagh

    We must remember to do a new config menu image when this branch and the RabbitMQ branch are both merged.

  61. Ed McDonagh

    Are you aiming at 0.8.2 or beyond that @dplatten ?

    I'm trying to tie things up for a beta release.

  65. David Platten 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>>

  67. David Platten 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>>

  75. David Platten 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>>

  76. David Platten 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'
  77. Ed McDonagh

    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?

  81. David Platten 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>>

  84. David Platten 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>>

  89. Ed McDonagh

    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)

  93. David Platten 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?

  94. Ed McDonagh

    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?

  95. David Platten 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.

  96. Ed McDonagh

    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?

  99. David Platten 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 #665 and issue #697

    → <<cset 64c258f20b69>>

  102. Ed McDonagh

    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?

  103. Log in to comment
Assignee
Type
enhancement
Priority
minor
Status
resolved
Component
Interface
Milestone
0.9.0
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!