CTSC:ARRA.011910 - Revision history

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-02-09T16:26:25Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-02-09T16:18:21Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-02-09T16:17:41Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

RandyGollub at 16:10, 9 February 2010

2010-02-09T16:10:41Z

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-02-09T16:08:00Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

Valerie.humblet: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-01-25T21:46:31Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

Valerie.humblet: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

2010-01-25T21:37:51Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010

Valerie.humblet at 21:24, 25 January 2010

2010-01-25T21:24:39Z

Valerie.humblet: Created page with 'Back to CTSC:ARRA supplement
'''Agenda''' i2b2 to XNAT to DICOM architecture and workflow == Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 20…'

2010-01-22T16:17:14Z

Created page with 'Back to CTSC:ARRA supplement <br> '''Agenda''' i2b2 to XNAT to DICOM architecture and workflow == Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 20…'

New page

Back to [[CTSC:ARRA supplement]]
<br>

'''Agenda'''

i2b2 to XNAT to DICOM architecture and workflow

== Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 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
* Charles McGow
* Paul Lamonica
* Gordon Harris
* Dan Marcus
* Charles Guttmann
* Bruce Rosen
* Ron Kikinis
* Diane Keough
* Jesse Wei
* Bill Hanlon

<br>

@@ Line 55: / Line 55: @@
 *** When we don't have the accession number but we know that there is a patient with images that are interested. The STAR software will interact with the PACS to get the list of images, then i2b2 will communicate with STAR.
 ** Dan mentioned that one challenge will be to implement STAR-D so that there is portability to the different institutions (security etc vary by institution)
-** DCM4che:
+** dmc4chee:
-*** The first goal is to try to get the STAR-D software to work through the PACS-dcm4che model: DICOM-PACS query-retrieve system but without any sensitive patient data.
+*** The first goal is to try to get the STAR-D software to work through the PACS-dcm4chee model: DICOM-PACS query-retrieve system but without any sensitive patient data.
 *** Having DICOM data and clinical data together will be good as a test.
-*** RSNA has a couple of data sets with different modalities and vendors, so does ACRIN. There are also DICOM data on Osirix. Steve already tried to send them form Osirix to dcm4che but the system crashed, it needs to be repeated.
+*** RSNA has a couple of data sets with different modalities and vendors, so does ACRIN. There are also DICOM data on Osirix. Steve already tried to send them form Osirix to dcm4chee but the system crashed, it needs to be repeated.
 *** In i2b2 there is a fake dataset, we could match images with it for example by taking good data sets and replicate them. Dan mentioned a useful software: scriptable DICOM browser to replicate studies.
 *** Another possibility would be to use phantoms from the different modalities at the different institutions, that we we avoid any HIPAA problem. Each institution has phantoms or other QC data stored in the PACS (ex: BIDMC has frogs pictures).

@@ Line 65: / Line 65: @@
 * Actions for next week meeting:
-** Get a couple of phantoms and push them to DCM4che (through Steve or by yourselves)
+** Get a couple of phantoms and push them to dmc4che (through Steve or by yourselves)
 ** Learning how the users of i2b2 communicate with the STAR software
 ** User's permission structure in i2b2, STAR-D and XNAT

@@ Line 56: / Line 56: @@
 ** Dan mentioned that one challenge will be to implement STAR-D so that there is portability to the different institutions (security etc vary by institution)
 ** DCM4che:
-*** The first goal is to try to get the STAR-D software to work through the PACS-DCM4chee model: DICOM-PACS query-retrieve system but without any sensitive patient data.
+*** The first goal is to try to get the STAR-D software to work through the PACS-dcm4che model: DICOM-PACS query-retrieve system but without any sensitive patient data.
 *** Having DICOM data and clinical data together will be good as a test.
-*** RSNA has a couple of data sets with different modalities and vendors, so does ACRIN. There are also DICOM data on Osirix. Steve already tried to send them form Osirix to DCM4che but the system crashed, it needs to be repeated.
+*** RSNA has a couple of data sets with different modalities and vendors, so does ACRIN. There are also DICOM data on Osirix. Steve already tried to send them form Osirix to dcm4che but the system crashed, it needs to be repeated.
 *** In i2b2 there is a fake dataset, we could match images with it for example by taking good data sets and replicate them. Dan mentioned a useful software: scriptable DICOM browser to replicate studies.
 *** Another possibility would be to use phantoms from the different modalities at the different institutions, that we we avoid any HIPAA problem. Each institution has phantoms or other QC data stored in the PACS (ex: BIDMC has frogs pictures).

@@ Line 42: / Line 42: @@
 * i2b2 to XNAT to DICOM:
 **i2b2 can generate a list of patients who have images that a PI wants to acquire from the PACS (and then send to XNAT)
-** The jobs of the STAR software are:
+** The jobs of the STAR-D software are:
 *** understand how to communicate using DICOM messages.
 *** understand the restrictions to the PACS so it does not bring down the PACS.
@@ Line 54: / Line 54: @@
 ***From an accession number (also known by others systems of hospitals), one can get access to a study.
 *** When we don't have the accession number but we know that there is a patient with images that are interested. The STAR software will interact with the PACS to get the list of images, then i2b2 will communicate with STAR.
-** Dan mentioned that one challenge will be to implement STAR so that there is portability to the different institutions (security etc vary by institution)
+** Dan mentioned that one challenge will be to implement STAR-D so that there is portability to the different institutions (security etc vary by institution)
 ** DCM4che:
-*** The first goal is to try to get the STAR software to work through the PACS-DCM4che model: DICOM-PACS query-retrieve system but without any sensitive patient data.
+*** The first goal is to try to get the STAR-D software to work through the PACS-DCM4chee model: DICOM-PACS query-retrieve system but without any sensitive patient data.
 *** Having DICOM data and clinical data together will be good as a test.
 *** RSNA has a couple of data sets with different modalities and vendors, so does ACRIN. There are also DICOM data on Osirix. Steve already tried to send them form Osirix to DCM4che but the system crashed, it needs to be repeated.
 *** In i2b2 there is a fake dataset, we could match images with it for example by taking good data sets and replicate them. Dan mentioned a useful software: scriptable DICOM browser to replicate studies.
-*** Another possibility would be to use phantoms from the different modalities at the different institutions, that we we avoy any HIPAA problem. Each institution has phantoms or other QC data stored in the PACS (ex: BIDMC has frogs pictures).
+*** Another possibility would be to use phantoms from the different modalities at the different institutions, that we we avoid any HIPAA problem. Each institution has phantoms or other QC data stored in the PACS (ex: BIDMC has frogs pictures).
 <br>
@@ Line 67: / Line 67: @@
 ** Get a couple of phantoms and push them to DCM4che (through Steve or by yourselves)
 ** Learning how the users of i2b2 communicate with the STAR software
-** User's permission structure in i2b2, STAR and XNAT
+** User's permission structure in i2b2, STAR-D and XNAT
 ** Reporting use to the Radiology departments
 ** Throttling volume (model of archival system of PACS)
 ** What kind of data are useful (ex: what is good enough to be used with Freesurfer)

@@ Line 18: / Line 18: @@
 * Yong Gao
 * Paul Lamonica
-* Steve Piper
+* Steve Pieper
 * Wendy Plesniak
 * Alex Zeitsev
@@ Line 36: / Line 36: @@
 * Summary of last week meeting:
 ** Our goal is to create a new cell for i2b2 to allow the PACS of each institution to communicate with i2b2 and XNAT.
-** This new application is called the STAR software.
+** This new application is called the STAR-D software.
 <br>

@@ Line 44: / Line 44: @@
 ** The jobs of the STAR software are:
 *** understand how to communicate using DICOM messages.
-*** understand the restrictions to the PACS so it does not bring the down PACS.
+*** understand the restrictions to the PACS so it does not bring down the PACS.
 *** to satisfy Radiology department apprehensions about a software getting access to their PACS.
 *** make sure only authorized people can get access to the data.
@@ Line 51: / Line 51: @@
 * Workflow:
-**How do we get images out? From an accession number (also known by others systems of hospitals), one can get access to a study.
+**How do we get images out?

← Older revision		Revision as of 21:24, 25 January 2010
Line 33:		Line 33:

	<br>		<br>
		+
		+	* Summary of last week meeting:
		+	** Our goal is to create a new cell for i2b2 to allow the PACS of each institution to communicate with i2b2 and XNAT.
		+	** This new application is called the STAR software.
		+
		+	<br>
		+
		+	* i2b2 to XNAT to DICOM:
		+	**i2b2 can generate a list of patients who have images that a PI wants to acquire from the PACS (and then send to XNAT)
		+	** The jobs of the STAR software are:
		+	*** understand how to communicate using DICOM messages.
		+	*** understand the restrictions to the PACS so it does not bring the down PACS.
		+	*** to satisfy Radiology department apprehensions about a software getting access to their PACS.
		+	*** make sure only authorized people can get access to the data.
		+
		+	<br>
		+
		+	* Workflow:
		+	**How do we get images out? From an accession number (also known by others systems of hospitals), one can get access to a study.

CTSC:ARRA.011910 - Revision history

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

RandyGollub at 16:10, 9 February 2010

RandyGollub: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

Valerie.humblet: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

Valerie.humblet: /* Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 2010 */

Valerie.humblet at 21:24, 25 January 2010

Valerie.humblet: Created page with 'Back to CTSC:ARRA supplement '''Agenda''' i2b2 to XNAT to DICOM architecture and workflow == Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 20…'

Valerie.humblet: Created page with 'Back to CTSC:ARRA supplement
'''Agenda''' i2b2 to XNAT to DICOM architecture and workflow == Harvard Catalyst Medical Informatics group Meeting Minutes January 19, 20…'