Uploaded image for project: 'XNAT'
  1. XNAT
  2. XNAT-3267

Session XML is built in prearchive before project anon is applied (therefore: inserts fields blocked by project anon into the session's XML anyway)

    XMLWordPrintable

Details

    • Bug
    • Status: Open
    • Blocker
    • Resolution: Unresolved
    • None
    • Backlog
    • None
    • Sprint 1
    • Rank:
      0|100emn:i
    • Sprint 1

    Description

      That sounds like a bug. If you moved your anonymization script to the site-wide one, you wouldn’t see that one. We typically do are data anonymization in site wide scripts and not the project specific. So, we wouldn’t have caught that.

      Site wide anonymization is applied as files are received and before they ever reach the disk. So, if your goal is to prevent PHI from reaching your system (which is typically our goal) , site wide anon scripts are the place to do it.

      Project anonymization isn’t applied until the data is archived. Data is first written to the prearchive. Once in the prearchive, it is either auto-archived or left in the prearchive. If its left in the prearchive and a user realizes the wrong project was matched, data may be moved to another project within the prearchive (before archive). So, if we applied the project anonymization before the user changed the project, then it might mean the wrong anon is applied to the data (which can’t be undone). Moving data around in the preachive is common in some XNATs. So, we specifically don’t apply project anon scripts until the data is archived. If they decide it was the wrong project after they archive, well… that’s just to bad. Project anonymization is rerun when you change the project of an already archived session for the new project (but you can’t undo the anon that was run for the old project). We typically only use the project anon script for things like injecting the subject id, session id, etc into the DICOM. Dicom editing rather than Dicom anonymization. Though that’s a pretty fine line.

      So, I’m guessing the bug here is that the session xml (which gets stored to the database during archive) is actually built in the prearchive (before the project anon script is run). This won’t be trivial to fix. It means the session xml might need to be regenerated before archive, but that could lose any modifications that have been made to the metadata while in the prearchive (I think that’s possible).

      In the meantime, the ideal solution here might be to move the anon logic to the site wide script. Or use a system outside of XNAT to apply project specific anonymization to the data before it is sent to the server. It will take a few weeks to get a fix for the bug released (best case scenario).

      Tim


      From: Chris Fahim
      Sent: Friday, July 25, 2014 3:48 PM
      To: xnat_discussion@googlegroups.com
      Subject: Re: [XNAT Discussion] Dicom Header Anonymization and Acquisition Site

      project specific, i.e. not site wide.

      -Chris


      On Friday, July 25, 2014 2:34:01 PM UTC-6, Tim Olsen wrote:

      Is this anonymization in your site wide anonymization script or your project specific one?

      Tim


      From: Chris Fahim
      Sent: Friday, July 25, 2014 3:31 PM
      To: xnat_di...@googlegroups.com <javascript:>
      Subject: Re: [XNAT Discussion] Dicom Header Anonymization and Acquisition Site

      Thank you for the fast reply !

      I'm using the rest api via java and org.apache.httpcomponents.httpclient v4.3.4.

      Here are specifics to the post. My URL is myxnatserver.com/myxnat/data/services/import

      HttpPost httppost = new HttpPost(this.url);
      String credentials = this.user + ":" + this.pw;
      String encodedAuth = "Basic " + new String( Base64.encodeBase64( credentials.getBytes( "UTF-8" ) ), "UTF-8" );
      httppost.addHeader( "Authorization", encodedAuth );

      MultipartEntityBuilder builder = MultipartEntityBuilder.create();
      builder.setMode(HttpMultipartMode.BROWSER_COMPATIBLE);

      File importfile = new File("C:\\Users\\cfahim\\Desktop
      107064_MR1.zip");

      builder.addPart("dest", new StringBody("/prearchive/projects/MYPROJECT", ContentType.DEFAULT_TEXT));
      builder.addPart("import-handler", new StringBody("DICOM-zip", ContentType.DEFAULT_TEXT));
      builder.addBinaryBody("FILE", new FileInputStream(importfile), ContentType.create("application/zip"),
      "107064_MR1");

      httppost.setEntity(builder.build());

      try(CloseableHttpResponse response = httpClient.execute( httppost ))

      { response.getEntity().writeTo(System.out); }

      It's a zip file with the following structure:

      MYPROJECT
      107064
      107064_MR1
      scans
      1
      DICOM
      bunch of dcm files
      ....

      Let me know if you need anything else.

      -Chris


      On Friday, July 25, 2014 2:12:57 PM UTC-6, Tim Olsen wrote:

      Chris,

      How are you uploading the dicom data?

      Tim


      From: xnat_di...@googlegroups.com xnat_di...@googlegroups.com On Behalf Of Chris Fahim
      Sent: Friday, July 25, 2014 3:06 PM
      To: xnat_di...@googlegroups.com
      Subject: [XNAT Discussion] Dicom Header Anonymization and Acquisition Site

      Hello xnat group,

      I'm trying to anonymize almost everything in the dicom header, including the acquisition site, so the users do not know where the images came from. I am using the anonymization script:

      • (0008, 0080)

      I am guessing the Acquisition Site is populated using this tag right ? Everything works in removing that tag from the dicom header, but the value that used to be there is now in the Acquisition Site on the scan webpage ! Is there another tag I should be removing or is this a bug ?

      Below is a screen shot of my MR session page showing the Acquisition Site being populated even though it has been anonymized in the dicom header.

      Let me know.

      -Chris

      Attachments

        Issue Links

          Activity

            People

              jrherrick@wustl.edu Rick Herrick
              tim@deck5consulting.com Tim Olsen
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:

                Time Tracking

                  Estimated:
                  Original Estimate - 2 days
                  2d
                  Remaining:
                  Remaining Estimate - 2 days
                  2d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified