CTSC:ARRA.010510 - Revision history

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

2010-02-09T16:28:16Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-02-09T16:27:43Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-02-09T16:27:23Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-02-09T16:15:18Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-01-19T05:13:22Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-01-08T20:07:16Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

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

2010-01-08T19:49:25Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

Valerie.humblet at 19:12, 8 January 2010

2010-01-08T19:12:05Z

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

2010-01-08T19:09:29Z

Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010

Valerie.humblet at 19:08, 8 January 2010

2010-01-08T19:08:59Z

@@ Line 13: / Line 13: @@
 * Mike Mendis
 * Shawn Murphy
-* Bill Telier
+* Bill Tellier
 * Mark Anderson
 * Bill Hanlon

@@ Line 13: / Line 13: @@
 * Mike Mendis
 * Shawn Murphy
-* Bill Tellier
+* Bill Telier
 * Mark Anderson
 * Bill Hanlon

@@ Line 56: / Line 56: @@
 ** When requesting images, once the transfer is specified, the images will be sent to the target location. XNAT will be set up to receive images.
 ** We need a queue mechanism on the model we implement to lower the stress on the PACS (transfer at night, very slowly etc).
-** dcm4che:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
+** dcm4chee:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
 ** Jesse mentioned that the clinical workstations also support query/retrieve functions; raising the possibility that we could also use one instead of a PACS.
@@ Line 64: / Line 64: @@
 ** Understand the output of a general request for each site.
 ** Take a look at the navigation clients made to identify a study or an image.
-** Design the client that will request the images. Look at dcm4che and the clients at the different institutions.
+** Design the client that will request the images. Look at dcm4chee and the clients at the different institutions.

@@ Line 56: / Line 56: @@
 ** When requesting images, once the transfer is specified, the images will be sent to the target location. XNAT will be set up to receive images.
 ** We need a queue mechanism on the model we implement to lower the stress on the PACS (transfer at night, very slowly etc).
-** DCM4chee:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
+** dcm4che:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
 ** Jesse mentioned that the clinical workstations also support query/retrieve functions; raising the possibility that we could also use one instead of a PACS.
@@ Line 64: / Line 64: @@
 ** Understand the output of a general request for each site.
 ** Take a look at the navigation clients made to identify a study or an image.
-** Design the client that will request the images. Look at DCM4che and the clients at the different institutions.
+** Design the client that will request the images. Look at dcm4che and the clients at the different institutions.

@@ Line 30: / Line 30: @@
 * Architecture:
 ** i2b2: PI makes a query, requests images with medical record number (MRN) or accession number. We need to define what is a study at the different institutions. The MRN will probably not be enough, one will need to add the date or the modality etc.
-** PACS: Images are extracted and send to XNAT.
+** PACS: Images are extracted and sent to XNAT.
-** XNAT: new derived data send back to i2b2.
+** XNAT: new derived data sent back to i2b2.
 <br>
 * Accession number: if we send an accession number (acc.#), will we get a study or an image?
-** BWH and MGH: it leads to s study. For billing purpose, there are different acc.# for the same study (ex: if one order an MRI/MRA, 2 acc # are generated but they lead to the same study.
+** BWH and MGH: it leads to a study. For billing purposes, there could be multiple different acc.#s for the same study (example: if one orders an MRI/MRA, 2 acc #s are generated but they lead to the same study).
 ** CHB: acc.# leads to a study.
 ** BIDMC: one acc.# per patient encounter.
@@ Line 54: / Line 54: @@
 * Navigation client:
-** When requesting images, once the transfer is specified, the images will be send to the target location. XNAT will be set up to receive images.
+** When requesting images, once the transfer is specified, the images will be sent to the target location. XNAT will be set up to receive images.
 ** We need a queue mechanism on the model we implement to lower the stress on the PACS (transfer at night, very slowly etc).
-** DCM4che:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
+** DCM4chee:it will be used to simulate a PACS.  Its biggest advantage is that we can use it outside the firewall with the fake i2b2 instance also outside the firewall. But we have to make sure that it behaves like a PACS. We don't want to invest to much time working with it turns out to be very different.
-** Jesse mentioned that the workstations also have the function to do query/retrieve, we could also use one instead of a PACS.
+** Jesse mentioned that the clinical workstations also support query/retrieve functions; raising the possibility that we could also use one instead of a PACS.
 <br>
@@ Line 64: / Line 64: @@
 ** Understand the output of a general request for each site.
 ** Take a look at the navigation clients made to identify a study or an image.
-** Design the client that request the images. Look at DCM4che and the clients at the different institutions.
+** Design the client that will request the images. Look at DCM4che and the clients at the different institutions.

@@ Line 39: / Line 39: @@
 ** CHB: acc.# leads to a study.
 ** BIDMC: one acc.# per patient encounter.
 <br>
@@ Line 48: / Line 49: @@
 ** You don't need to know it to get data from the PACS, PACS works with acc.#
 ** UID is for internal accounting and unique identification. If you derived data, you need another UID.

← Older revision		Revision as of 19:49, 8 January 2010
Line 20:		Line 20:

	<br>		<br>
		+
		+	* The goals of the meetings were:
		+	** to review where we are in the mi2b2 architecture
		+	** to go through the workflow
		+	** to get a couple of assignments and output samples
		+
		+	<br>
		+
		+	* Architecture:
		+	** i2b2: PI makes a query, requests images with medical record number (MRN) or accession number. We need to define what is a study at the different institutions. The MRN will probably not be enough, one will need to add the date or the modality etc.
		+	** PACS: Images are extracted and send to XNAT.
		+	** XNAT: new derived data send back to i2b2.
		+
		+	<br>
		+
		+	* Accession number: if we send an accession number (acc.#), will we get a study or an image?
		+	** BWH and MGH: it leads to s study. For billing purpose, there are different acc.# for the same study (ex: if one order an MRI/MRA, 2 acc # are generated but they lead to the same study.
		+	** CHB: acc.# leads to a study.
		+	** BIDMC: one acc.# per patient encounter.
		+
		+	<br>
		+
		+	*UID:
		+	** In theory, no 2 images will ever have the same UID.
		+	** Each manufacturer is assigned numbers.
		+	** UID is created by the modality.
		+	** You don't need to know it to get data from the PACS, PACS works with acc.#
		+	** UID is for internal accounting and unique identification. If you derived data, you need another UID.

@@ Line 4: / Line 4: @@
 '''Agenda'''
-# Life image visit
+# DICOM query retrieve tool
 == Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010 ==

← Older revision		Revision as of 19:08, 8 January 2010
Line 7:		Line 7:

	== Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010 ==		== Harvard Catalyst Medical Informatics group Meeting Minutes January 5, 2010 ==
		+
		+	In attendance:
		+
		+	* Valerie Humblet
		+	* Mike Mendis
		+	* Shawn Murphy
		+	* Paul Lamonica
		+	* Bill Tellier
		+	* Mark Anderson
		+	* Bill Hanlon
		+	* Todd Perlstein
		+	* Jesse Wei
		+
		+	<br>