Narrowing a QR Results Set
greggy
matter.
We are manufacturing a device that according to Herman Oosterwijk
should have its own modality from the committee, but probably won't
get one until another vendor has the same need. So we are forced to
classify the device as a VL type, such as endoscopic, microscopic,
photographic, or secondary capture. None of these properly describe
the device, but ES seems to be the best match.
Our query is always hierarchical, from patient to image objects. When
I perform a query for image objects, I can narrow the search to those
of ES class (assuming that the device is configured as ES). But I get
back in my result set all image objects that are of ES type. It is not
until I perform the MOVE of any one image object that I can look at it
and decide if it is really the image type that was generated by the
device.
I was thinking of narrowing the result set by using the prefix of our
UID in the series UID field. But I have not seen that work right.
Should I be able to use a wild card '*' after the prefix in the series
UID field when performing the search at the image object level?
Is there a better approach that I am missing?
David Clunie
UIDs are never to be parsed ... their only characteristic that
can be relied upon is their uniqueness.
There is no wildcard matching on UIDs in DICOM for that reason
(if it ever works it is only by accident and because the SCP
implementer didn't bother treating UID matching specially).
If you need to narrow your query results at the SCP end, you
need to a) choose the right attribute and b) assure yourself
that enough SCPs support matching on it (since most of these
will be optional). The set required by IHE beyond the DICOM
required keys is a good start.
Even if the SCP does not support matching, it might return
the keys, and then you can filter the list at the SCU end
rather than retrieving them.
Note also that for a novel modality that produces color images,
one can use a secondary capture object (single or multiframe),
and set Modality to anything you want that isn't used by the
standard; nor does it have to be two letters (e.g., "EXOTIC").
So, you could do that and use Modality (or Modalities in Study)
as the query keys (matching and/or return) and perhaps achieve
your objective that way.
There is really nothing in the VL Endoscopy object beyond what
is in the SC objects anyway, and the multi-frame SC true color
object is fairly well constrained and quite interoperable.
David
Peter B Schmidt
a good practice is to query the Worklist SCP for the Scheduled Station
only.
Another implementation, query all for the specific modality type, is
useful if you have a pool of similar modalities collocated and pick
whatever fits best - e. g. if you have a pool of 2 MRs, and one is set
up with the head coil, the operator may chose the next head exam for his
MR so she does not have to change coils.
But I am sure the latter will not suit your use case, so decide on the
Scheduling System by assigning the exam to the device there and query
only for the specific AE or Station. Please note, this is staging
specific, nothing you can do in the software.
Or did I miss a point?
Parsing UIDs is the straight road to hell, any semantics applied to UID
formatting I saw always broke with the next update. Just don't do it.
Kind regards,
Peter
greggy
> Hello greggy,
>
> a good practice is to query the Worklist SCP for the Scheduled Station
> only.
>
> Another implementation, query all for the specific modality type, is
> useful if you have a pool of similar modalities collocated and pick
> whatever fits best - e. g. if you have a pool of 2 MRs, and one is set
> up with the head coil, the operator may chose the next head exam for his
> MR so she does not have to change coils.
>
> But I am sure the latter will not suit your use case, so decide on the
> Scheduling System by assigning the exam to the device there and query
> only for the specific AE or Station. Please note, this is staging
> specific, nothing you can do in the software.
>
> Or did I miss a point?
I was referring to querying a PACS for a list of image objects.
>
> Parsing UIDs is the straight road to hell, any semantics applied to UID
> formatting I saw always broke with the next update. Just don't do it.
>
> Kind regards,
>
> Peter
According to the standard, the prefix of the UID is vendor specific,
at least in my case. So I was thinking that this would be reasonable.
As for parsing it further, only if it is our UID would I consider it -
for obvious reasons.
(I like the standard's approach to UID. It beats UUIDs/GUIDs by a
country mile. But if I had any input to the process, I would have
suggested it be alphanumeric rather than numeric. That way, one could
easily identify their business entity in it and people would
immediately recognize who generated it. Like name spaces / packages in
C#/Java.)
Robert Horn
> On Jun 26, 2:39 am, Peter B Schmidt <n...@PBSchmidt.de> wrote:
>
> > Parsing UIDs is the straight road to hell, any semantics applied to UID
> > formatting I saw always broke with the next update. Just don't do it.
>
> at least in my case. So I was thinking that this would be reasonable.
> As for parsing it further, only if it is our UID would I consider it -
> for obvious reasons.
>
UID is unique, but many vendors have multiple root UIDs, and many
devices incorporate software or components from other vendors. Then
there are mergers, acquisitions, divestitures, OEM relabeling, etc.
UIDs are not that useful for identifying a device vendor.
R Horn
David Clunie
> According to the standard, the prefix of the UID is vendor specific,
> at least in my case. So I was thinking that this would be reasonable.
> As for parsing it further, only if it is our UID would I consider it -
> for obvious reasons.
What if I take one of your instances, lossy compress it (and hence
as required by the standard change the UIDs to new ones I generate)
and then send it back to you ? What i de-identify them for a
teaching file or clinical trial ? Etc.
The behavior of your system should not change; i.e., it should still
find your class of object regardless of its instance UID.
Some PACS will just gratuitously change all UIDs on import anyway,
because they have learned from bitter experience that they cannot
trust modalities to behave properly.
DO NOT PARSE UIDs.
GIVE UP THIS ENTIRE IDEA OR YOU WILL BE SORRY.
LISTEN TO THOSE OF USE WHO HAVE BEEN DOING THIS FOR A DECADE AND A
HALF.
> (I like the standard's approach to UID. It beats UUIDs/GUIDs by a
> country mile.
I disagree. UUIDs are great. Vide infra.
> But if I had any input to the process, I would have
> suggested it be alphanumeric rather than numeric. That way, one could
> easily identify their business entity in it and people would
> immediately recognize who generated it. Like name spaces / packages in
> C#/Java.)
Your are not supposed to be able to recognize who generated UIDs. As
I stated before, their only characteristics is supposed to be that
they are unique only.
Increasingly, folks do not user a vendor root UID at all, but
rather a standard root for UUIDs ("2.25"), and then tack the
UUID (in integer form) on to that root.
See "http://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf".
This saves them from having to obtain/maintain a vendor-specific
root, which significantly reduces implementation complexity.
David
greggy
Ok, ok, you guys sold me...
So let me ask you about another approach to querying for specific
images. Someone suggested I do this and it seems to work for my test
PACS.
I can set type 8 to "ORIGINAL\PRIMARY\\PART4" (no third part). The
toolkit I use actually changes ORIGINAL to DERIVED, I believe because
I am compressing the image. I have tried querying against "*PART4"
using a wild card * in front of my fourth part and found that my test
PACS does indeed allow me to use this as a filtering mechanism. Is
using the fourth part of (0008,0008) a good approach to filtering the
query results?
BTW, what would be an example of the third part to this type? PS
3.3-2008-C.7.6.1.1.2 is not clear as to whether I can make this
anything I want or if there are values set aside for it within the
industry.
Greg