aeskulap-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Aeskulap-users] dicom issues


From: Alexander Pipelka
Subject: Re: [Aeskulap-users] dicom issues
Date: Fri, 13 Apr 2007 08:09:14 +0200
User-agent: Thunderbird 1.5.0.10 (X11/20070403)

Hi Mitchell,

It's nice to discuss about the interpretation of the DICOM standard ;-)
Thanks for the chapter numbers of the DICOM standard.

I just want to avoid a 2 phase query (patient root, patient level /
study root, study level).

Maybe the solution is quite simplier:
Just use a study root / study level query with patient attributes.
Conforming to the standard all patient attributes in the study root ql
are interpreted as study attributes (my interpretation).

In your last Email i think you wrote that "simple_storage" of the ctn
package (of your installation) also reports an error. Please let me know
which version of ctn you are using.

Alex


Mitchell Laks schrieb:
> Dear Alex,
>
> sorry i just got home ...
>
> I have very very little knowledge of dicom. However I have been lurking on 
> comp.protocol.dicom and forum.dcmtk.de
> etc.
>
> You are correct that at times you can use a universal matching on patid. 
>
> However it depends upon when you do it :)
>
> if you do a patient root query then it depends upon the level of your query. 
> If you   specify the patient root query and patient level, then sure.
>
> if you go beneath patient level, to study level say then you may not.
>
> must specify patid and MAY NOT SPECIFY NAME at the study level of a patient 
> root query.
>
> (I think).
>
> I had the same trouble till i pointed this out to the guys from osirix, and 
> they agreed and modified
> their client.
>
> to quote:
>       
>               
> Joerg Riesmeier       
> From: Joerg Riesmeier <address@hidden>
> Date: Tue, 02 Dec 2003 19:23:05 +0100
> Local: Tues, Dec 2 2003 2:23 pm
> Subject: Re: findscu
> Reply to author | Forward | Print | Individual message | Show original | 
> Report this message | Find messages by this author
> Romaric,
>
>   
>> I have a problem in the use of findscu command.
>>     
>
> I guess your problem is more related to the DICOM query/retrieve
> model and not to the findscu tool. Correct me if I'm wrong ...
>
>   
>> I want to built a hierarchy like this:
>>     
> [...]
>   
>> I need help to write the right command with arguments
>> because ,now, I m not capable to list all the series.
>>     
>
> The DICOM query/retrieve models typically used are strictly
> hierarchical, i.e. one has to specify the unique keys on the
> higher levels in order to query information on a lower level.
>
> Supposed you are using the Patient Root model, you first have
> to query all patient's (or the ones you are interested in) on
> PATIENT level, then all studies for each of these patients
> (using the Patient ID as the unique key) on the STUDY level,
> then all series for each of these studies (using the Study
> Instance UID as the unique key) on the SERIES level and so on.
>
> In case you want to read more about the different models, levels
> and keys I would suggest that you read the relevant part(s) of
> the DICOM standard (first of all PS3.4-2003 annex C).
>
> Regards,
> Joerg Riesmeier
> OFFIS
>
>
>
> ***********
>
>
>
>
> next take a look at this dialog:
>
>  
> http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/7c6e39f5947e6ee9/f8e402831f7d8f32?lnk=gst&q=findscu+patient+root&rnum=1&hl=en#f8e402831f7d8f32
>
> *************************
>
> [Click the star to watch this topic]          
> [Click the envelope to receive email updates]
>       
> flag
>               3 messages - Collapse all       
> The group you are posting to is a Usenet group. Messages posted to this group 
> will make your email address visible to anyone on the Internet.
> Your reply message has not been sent.
> Your post was successful
>       
>               
> Bernd Kuemmerlen      
> View profile
>        More options Sep 19 2003, 4:16 am
> Newsgroups: comp.protocols.dicom
> From: Bernd Kuemmerlen <address@hidden>
> Date: 19 Sep 2003 08:16:52 GMT
> Local: Fri, Sep 19 2003 4:16 am
> Subject: Query/Retrieve level question
> Reply to author | Forward | Print | Individual message | Show original | 
> Report this message | Find messages by this author
> I have a question about the query retrieve levels and the patient root
> and study root models, I tried to get the answer from the standard, but it
> seems a bit vague to me...
>
> The question is:
> Is it correct (as I assume) that a study level request works basically the
> same regardless if using the patient root or the study root level?
>
> I know that for a patient root query, I have to include the unique key for
> the patient level (i.e. the PatientID), but when I want to fetch
> information about studies for a specific patient, I would guess that
>
>   findscu -P -k 0008,0052=STUDY -k 0010,0010=PATNAME -aec QUERY_AET localhost 
> 104
>
> (patient root model, study level query, query key patient name PATNAME)
>
> and
>
>   findscu -S -k 0008,0052=STUDY -k 0010,0010=PATNAME -aec QUERY_AET localhost 
> 104
>
> (study root model, study level query, query key patient name PATNAME)
> are equivalent, but I fear that I am missing a basic distinction between
> these two.
>
> Could anybody shed some light on this issue?
>
> Thanks
>    Bernd
>
>   Reply Reply to author Forward     Rate this post: Text for clearing space
>               
>               
>               
>       
>               
> T Kantchev    
> View profile
>        More options Sep 22 2003, 4:06 pm
> Newsgroups: comp.protocols.dicom
> From: "T Kantchev" <address@hidden>
> Date: Mon, 22 Sep 2003 20:06:01 +0000 (UTC)
> Local: Mon, Sep 22 2003 4:06 pm
> Subject: Re: Query/Retrieve level question
> Reply to author | Forward | Print | Individual message | Show original | 
> Report this message | Find messages by this author
> Dear Bernd,
> These are not equivalent. In fact Patient Name is not allowed in Patient
> Root Study Level query, since Patient ID is a unique key at the root level,
> which selects a single patient. At Study level of Patient Root query you
> only select a subset of studies, belonging to that patient. Therefore, your
> second query identifier is invalid.
>
> See PS 3.4 Annex C, Section C.4.1.2.1:
>
> "The Identifier contained in a C-FIND request shall contain a single value
> in the Unique Key for each level above the Query/Retrieve level. No Required
> or Optional Keys shall be specified, which are associated with levels above
> the Query/Retrieve level."
>
> Todd
>
>   Reply Reply to author Forward     Rate this post:
>               
>       
>       
>               
> Bernd Kuemmerlen      
> View profile
>        More options Sep 23 2003, 3:21 am
> Newsgroups: comp.protocols.dicom
> From: Bernd Kuemmerlen <address@hidden>
> Date: 23 Sep 2003 07:21:53 GMT
> Local: Tues, Sep 23 2003 3:21 am
> Subject: Re: Query/Retrieve level question
> Reply to author | Forward | Print | Individual message | Show original | 
> Report this message | Find messages by this author
> address@hidden, who claims to be "T Kantchev", wrote:
>
>   
>> Dear Bernd,
>> These are not equivalent. In fact Patient Name is not allowed in Patient
>> Root Study Level query, since Patient ID is a unique key at the root level,
>> which selects a single patient. At Study level of Patient Root query you
>> only select a subset of studies, belonging to that patient. Therefore, your
>> second query identifier is invalid.
>>     
>
>   
>> See PS 3.4 Annex C, Section C.4.1.2.1:
>>     
>
>   
>> "The Identifier contained in a C-FIND request shall contain a single value
>> in the Unique Key for each level above the Query/Retrieve level. No Required
>> or Optional Keys shall be specified, which are associated with levels above
>> the Query/Retrieve level."
>>     
>
>   
>> Todd
>>     
>
> Ahh, I see, thanks for this clarification, I now begin to see the
> difference. Even though this is written down in the standard, it is
> sometimes very hard to grasp, so a more verbose description like you gave
> is very helpful.
>
> Cheers
>         Bernd
>
>   





reply via email to

[Prev in Thread] Current Thread [Next in Thread]