Difference between revisions of "CTSC:ARRA.011210"

From NAMIC Wiki
Jump to: navigation, search
Line 41: Line 41:
 
** (*) will need to be able to log into XNAT and send the images to the right place. The most difficult part will probably to send back the new data from XNAT to i2b2.
 
** (*) will need to be able to log into XNAT and send the images to the right place. The most difficult part will probably to send back the new data from XNAT to i2b2.
 
** patient: in i2b2 there is a structure to ensure that the access tho the HIPAA data is limited. There is a data management cell in i2b2 to deal with the medical record number (MRN).  (*) will need the MRN to retrieve data.  
 
** patient: in i2b2 there is a structure to ensure that the access tho the HIPAA data is limited. There is a data management cell in i2b2 to deal with the medical record number (MRN).  (*) will need the MRN to retrieve data.  
*** How is XNAT prepared to deal with MRN? According to Yong, XNAT does not allow you to stock any HIPAA controlled data.
+
** How is XNAT prepared to deal with MRN? According to Yong, XNAT does not allow you to stock any HIPAA controlled data.
 +
<br>
 +
 
 +
* i2b2 to XNAT to DICOM worflow
 +
 
 +
** Request is made from i2b2 client to look up:
 +
***By accession number: What are the nature of accessions for "studies" and "images" at the 4 sites
 +
***By patient: Assumed to always be and MRN
 +
** i2b2 enforce that the PI is asking only for the studies he is allowed to see.
 +
** How can we give access to only a couple of studies and not the whole PACS: the (*) will serve as a gatekeeper and the throttle to let know that one can not access everything (ex: images from the last 5 years are OK, older no because it takes too long to get access and download).

Revision as of 20:37, 15 January 2010

Home < CTSC:ARRA.011210

Back to CTSC:ARRA supplement

Agenda

  1. i2b2 to XNAT to DICOM workflow

Harvard Catalyst Medical Informatics group Meeting Minutes January 12, 2010

In attendance:

  • Valerie Humblet
  • Mike Mendis
  • Shawn Murphy
  • Bill Tellier
  • Mark Anderson
  • Randy Gollub
  • Yong Gao
  • Paul Lamonica
  • Steve Piper
  • Wendy Plesniak
  • Alex Zeitsev


Discussion

  • There are 3 components in this project:
    • the software development part.
    • the department engagement (Randy is working on setting up meetings with the different institutions to work on policy issues).
    • the studies: we need the science, it is essential to get a couple of publications to validate the project.


  • i2b2 to XNAT to DICOM architecture

Mi2b2.png

    • In the picture above, it is clear now that (*) will be an intermediary to the PACS and XNAT. i2b2 will not communicate directly with the PACS. Anything build in i2b2 will communicate with (*) and then (*) will communicate with the PACS.
    • i2b2 structure is made with projects and users. Every message from i2b2 always includes who the user is and information about the project (IRB etc). We have to understand how to coordinate the user/project structure from i2b2 in XNAT. Randy mentioned that Dan Marcus has just been asked to support communication between i2b2 and XNAT.
    • (*) will need to be able to log into XNAT and send the images to the right place. The most difficult part will probably to send back the new data from XNAT to i2b2.
    • patient: in i2b2 there is a structure to ensure that the access tho the HIPAA data is limited. There is a data management cell in i2b2 to deal with the medical record number (MRN). (*) will need the MRN to retrieve data.
    • How is XNAT prepared to deal with MRN? According to Yong, XNAT does not allow you to stock any HIPAA controlled data.

  • i2b2 to XNAT to DICOM worflow
    • Request is made from i2b2 client to look up:
      • By accession number: What are the nature of accessions for "studies" and "images" at the 4 sites
      • By patient: Assumed to always be and MRN
    • i2b2 enforce that the PI is asking only for the studies he is allowed to see.
    • How can we give access to only a couple of studies and not the whole PACS: the (*) will serve as a gatekeeper and the throttle to let know that one can not access everything (ex: images from the last 5 years are OK, older no because it takes too long to get access and download).