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

Make modality more flexible

Issue #445 resolved
Luuk created an issue

Would be nice to make it possible for the user to set modality and/or user definable category (e.g. angio suits / mobile fluoroscopy / mobile DR / ...). This could be made definable for the user with the setting of the display name.

Comments (24)

  1. Luuk reporter

    I would suggest to:

    • Add an extra field in models.UniqueEquipmentNames, called user_defined_modality_type.
    • Keep the logic the same in the extractor rdsr, except for the case this extra field is filled. If the extra field is filled, use user_defined_modality_type as GeneralStudyModuleAttr.modality_type during import of data
    • Add possibility in user interface to set modality (in same page as display name)
    • Add option to overwrite modality for already imported studies (I didn't check, what this would mean, but that seems useful from a user point of view).
    • Prevent user from setting a projection system (procedure reported) to a CT and vice versa (but MG, RF and DX would be possible to change).

    What do you think @edmcdonagh?

  2. Luuk reporter

    I made some small code changes to include the first two bullets and it seems to work fine (for the Siemens Mobilet Miramax). If imported without user_defined_modality_type it imports as RF, if set to DX, it imports as DX.

  3. Ed McDonagh

    Seems good. Will have to also think about whether the display name page will need some work for the kit to jump between tables when reconfigured.

    I look forward to seeing what you have put together.

  4. David Platten

    Refs #445 Make modality more flexible

    So far only implements changes needed in the extractor. Additional changes should be made to 1. make it possible for the user to set "user_defined_modality" 2. update already imported records 3. update "display name page" to get system in correct modality category

    Would also be a workaround for the "unsolvable" issue #444

    → <<cset d111f1004ab0>>

  5. David Platten

    Refs #445 Make modality more flexible

    Implements basic possibility to set a user defined modality type. Only changes from DX to RF and vice versa are allowed. Menu item caption might need to be updated.

    Would also be a workaround for the "unsolvable" issue #444

    → <<cset ae951ff4dd76>>

  10. Luuk reporter

    It seems from the documentation that it is advised to only use blank=true https://docs.djangoproject.com/en/dev/ref/models/fields/#null):

    #!

Field.null

If True, Django will store empty values as NULL in the database. Default is False.

Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data” the Django convention is to use the empty string, not NULL. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True is required to avoid unique constraint violations when saving multiple objects with blank values.

For both string-based and non-string-based fields, you will also need to set blank=True if you wish to permit empty values in forms, as the null parameter only affects database storage (see blank).
  11. David Platten

    @LuukO, thanks for that - I'll change it back to what you had written in the first place. @edmcdonagh, Luuk's original code didn't cause me any problems when I migrated the database. What was your concern with the database migration?

  13. David Platten

    @edmcdonagh, I can't imagine the table in question will ever be very large, so perhaps it won't be a real problem. Conversely, does it matter if we define the field as null to start with. I don't know the right answer to this one.

  19. Ed McDonagh

    Hi @LuukO , @dplatten. I've updated branch issue445MakeModalityFlexible with develop, then pushed it to http://testing.openrem.org/ by creating a new branch from it called issue445MakeModalitisFlexible-stage and pushing that in.

    Can you please take a look, push it around a bit and let me know if it is good for merging into develop?

    Thanks.

    @LuukO - I'll send you a login by email in a bit.

  20. David Platten

    This looks good to me. I've swapped a DX room to RF, and also an RF room to DX. This works fine: the resulting detail pages appear as I would expect, and no errors are encountered. I then swapped the two rooms back to their correct modality type. I also tried to change the modality of a mammography system and received an appropriate warning: the modality was left unchanged.

  24. Luuk reporter

    It seems a bit late, but my testing results are the same as David's. Thanks @edmcdonagh and @dplatten for making this change possible.

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