Consider offering one-way hash function for accession number and patient ID

Issue #183 resolved
Ed McDonagh
created an issue

In Norway, accession number is considered to be patient identifiable data. Without accession number, OpenREM becomes difficult to use for individual patient dose calculations or investigations.

A workaround could be to store a one-way hash of the accession number in the database instead. You can then never work out from the hashed accession number alone what the original exam accession number was. However, if you were needing to investigate a particular exam and were in possession of the accession number, this could be entered and hashed in the same way as originally to obtain the correct study.

The idea for this approach came from the description of the PerMoS solution used for the EPICT project, created by Andreas Jahnen of the Luxembourg Institute of Science and Technology (formerly the Centre de Recherche Public Henri Tudor, Luxembourg) and presented at the NFMF MedFys 2015 conference in Kvitfjell, Norway.

An extension of this would be to use the same method and store a hash of patient ID. This would have the following advantages:

  • Patient's studies can be easily found - radiographers like working with IDs and names, not accession numbers
  • Patient's history could be tracked where appropriate, for example linking interventional studies to estimate skin doses
  • A study cannot be attributed to any particular patient by knowledge of the ID hash
  • Height and weight information can be imported if the ID is known but not the height and weight. This might get complicated by the lack of knowledge as to which exam the details are valid for, but could be a very useful tool.

There are also disadvantages to consider:

  • It becomes trivial to look up an individual patient's dose. It has always been possible, by reviewing date/time/exam type/machine, but not trivial. However, authorisation levels might manage this risk. For example the ID lookup might be disabled for the 'view' level of access.

Comments (46)

  1. Ed McDonagh reporter
    • changed milestone to 0.7.0

    I want to have at least a basic version of this working in 0.7, as it is becoming increasingly important for us here.

    At the same time I want to get 0.7 out of the door, so it might not be a perfect solution!

  2. Ed McDonagh reporter

    Mammo csv export now available with name, ID or both, if you are in the PID group. Doesn't allow if not in group, even if know the URL. However, the export page allows anyone who can see that page to download anything... need to restrict. Refs #183

    → <<cset d94bd92daa5e>>

  3. Ed McDonagh reporter

    Added user and includes_pid to the export model, now users not in the pid group won't see exports that contain pid. User is now displayed in the export table - this could be changed in the future so that you can either filter (in which case the full name should be displayed instead of the username), or list mine vs all exports. Only mammo csv export has been updated to fill the new model fields. Refs #183

    → <<cset 76cc7f9fdf93>>

  4. Ed McDonagh reporter

    Prepared for pid and user information to come into rfxlsx, changed to filtering data using djangoo-filter, added patient sex to the standard export data (refs #235), changed column resize for date column, though will be wrong again if pid. Refs #183

    → <<cset 5a01cf531dc1>>

  5. Log in to comment