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

If available use Device Observer UID to identify system

Issue #688 resolved
Luuk created an issue

Currently OpenREM uses a combination of several tags to determine a unique system.

In RDSRs a "Device Observer UID" is present, which uniquely defines a system. I would suggest to use this UID if present for identifying a system. This UID is independent of the sometimes changing tags that currently are used.

In practise this UID can be used to automatically set the Display Name if the UID is already known in the database, but the data has a different combination of currently used tags.

Comments (30)

  2. Ed McDonagh

    Interesting idea. This would enable auto generation of the correct Display Name for systems that frequently change other tags (my Carestream systems for example that insert the patient ward location as department!)

    Have you checked if any of the difficult systems that that setup all their systems to be identical bother to generate a new UID for each system?

  3. Luuk reporter

    I didn't check for all our manufacturers, but for our Philips systems it does. And, according to the standard, it should: "Unique identifier of automated device that created the observations." So technically it is not the device that creates the x-rays, but the device that "observes" the x-rays. But I don't know a use-case for which that is a different device.

  4. David Platten

    I like the current display name arrangement, as it flags to me when a system has had a software update.

  5. Ed McDonagh

    I can see that as being useful. I've been thinking of how you could satisfy both, without making the system even more complicated.

    For example, if the version number changes but we know it's the same device from the observer UID, use the appropriate Display Name but with some sort of incremental suffix as a first guess.

  6. Luuk reporter

    So, I think we have two "demands/wishes"

    1. We (I) want to keep the display name the same if the device is the same without having to do that myself (and the Device Observer UID is telling us that it is the same device)
    2. We (David) want to be flagged if the software version changed (and the changing display name is currently used for that)
      • Actually this only works if you change the default display name

    Are there more changes you want to be noticed of? Should we built these notifications in the homepage? Personally I don't like a changing display name as an indicator for a possible software change. But I can imagine that you want to be notified if software version changes and I think this should be a separate feature. Although I don't know about a good implementation for this, yet.

  7. Luuk reporter

    Refs Issue #688

    Makes it possible to automatically set display name (and modality) to the display name of an already known system if the device observer UID matches.

    Default behaviour is not to apply this feature (backwards compatible)

    Setting can be made in "home page Options", as the user will see the changes in the home page

    If it is going to be implemented, the documentation has to be written.

    → <<cset 2f67d9faf052>>

  8. Luuk reporter

    As you can see above, I committed a change to implement this suggestion. But by default the current behaviour is applied. Let me know what you think, @edmcdonagh, @dplatten.

  9. Luuk reporter

    Seems I need to have a look at the code as "test_import_dual_rdsr" fails. But not today anymore...;-)

  10. Luuk reporter

    Interestingly the Device Observer UIDs are different for the 2 dual datasets (DX vs. RF). @edmcdonagh Are these really from the same device, or are these "created" to be from the same machine? According to the Siemens DICOM conformance statement the Device Observer UID should be: "Root UID including serial number". So I would expect it to be the same for the DX and RF object (if from the same machine).

  11. Ed McDonagh

    Can't remember now. But they might be one from a wall stand and one from a table detector, of the same unit.

  12. Luuk reporter

    I checked for our Siemens bucky system (no dual system), but here the Device Observer UID is the same for both detectors (indeed root + serial number). Could the de-identification process have replaced the UIDs independently in both test objects?

  14. Luuk reporter

    Refs Issue #688

    Makes it possible to automatically set display name (and modality) to the display name of an already known system if the device observer UID matches.

    Default behaviour is not to apply this feature (backwards compatible)

    Setting can be made in "home page Options", as the user will see the changes in the home page

    If it is going to be implemented, the documentation has to be written.

    → <<cset d2c34e2e05bf>>

  15. Luuk reporter

    Refs Issue #688 Use Device Observer UID for setting Display Name

    • Changed Device Observer UID of DUAL RF DICOM test object to match the one from DUAL DX object, after confirmation they should be the same
    • Updated documentation
    • PEP8 change in models.py (homepage options)
    • Updated changes files

    → <<cset 2817be3ae2d4>>

  16. Luuk reporter

    @edmcdonagh, @dplatten, what do you think? I made it a "home page option" to automatically apply a display name if Device Observer UID is the same. By default it is disabled. It also automatically sets the "user_defined_modality" for the (new) device.

  19. Luuk reporter

    Refs Issue #688

    Fixed some Codacy complains. Combined the messages for the admin settings into one message.

    Btw: The home page settings are not available in the menu for a normal user. So it can only be reached by typing the right URL. Should we place the menu option into the "user level config"?

    → <<cset 714c3bdd6b3e>>

  21. Luuk reporter

    Yes, it is.

    The home page settings options page has two user level settings (primary and secondary number of days to sum) and (including this change) two admin level settings (calculation/display of workload and observer UID usage). But a normal user can't set the first two as it is not reachable via the config menu. If a normal user types the url of the homepagesettings page it will get the first two options and information telling that the other two options can only be set by an administrator. So that's why I wonder if we should put the homepagesettings page on the "user level settings" (I can imagine we would like to personalise the home page more in a later stage)

  22. Ed McDonagh

    I have checked the code and refreshed my memory.

    As an admin, under 'User' settings you can determine whether the workload stats are on or off.

    As a non-admin, if workload stats are on, then the Home page options page is available. If not, it doesn't appear.

    In the future, when there are more options to be made, this distinction might not be right. But for now, the only user level options are only applicable if an administrator has enabled workload stats.

  24. Luuk reporter

    Refs issue #688

    • Reverted changes except for rdsr.py
    • Added singleton model for setting
    • changed rdsr to point to new singleton model

    [skip ci] for now (more changes are needed)

    → <<cset 65b6f06815be>>

  25. Luuk reporter

    Refs issue #688

    • Reverted changes except for rdsr.py
    • Added singleton model for setting
    • changed rdsr to point to new singleton model

    [skip ci] for now (more changes are needed)

    → <<cset 1d573bcf25b5>>

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