PN search - DICOM

This is a discussion on PN search - DICOM ; Hi everyone. I'm trying to clarify how PN searches should work for worklist management. I am writing a client and I am getting inconsistent results on the servers that I am testing against. I don't believe the standard is exceptionally ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: PN search

  1. PN search

    Hi everyone. I'm trying to clarify how PN searches should work for
    worklist management. I am writing a client and I am getting
    inconsistent results on the servers that I am testing against. I don't
    believe the standard is exceptionally clear on how to perform matching
    for PN fields, so that may be part of the issue.

    Let me give some examples of patient name queries, and my
    interpretation of what the results should be. I'm interested in
    hearing anyone else's interpretations as the 2 worklist management
    servers that I have tested against (including CONQUEST) do not meet my
    expected results.

    1. Query for "DOE"
    Should match "DOE^JOHN" and "DOE^JANE".
    Should not match "DOETH^JOHN" (because no wild cards were used) or
    "SMITH^DOE" (because it was only searching last name).

    2. Query for "DOE^JOHN"
    Should match "DOE^JOHN" and "DOE^JOHN^PETER"
    Should not match "DOETH^JOHN" or "DOE^JOHNATHON"

    3. Query for "DOE*" or "*DOE*"
    Should match "DOE^JOHN" and "DOETH^JOHN"
    Should not match "SMITH^DOE"

    4. Query for "DOE*TH*"
    Should match "DOETH^JOHN"
    Should not match "DOE^THOMAS"

    5. Query for "*^JOHN"
    Should match "DOE^JOHN" and "SMITH^JOHN"
    Should not match "DOE^JOHNATHON"

    Basically my interpretation is that each component (separated by the
    "^" delimiter) should be matched as if it were an individual attribute.
    The behavior that I am seeing with the two systems I have tested is
    the entire PN attribute is being treated as one attribute for the
    match, disregarding carets. In fact, carets typically are causing
    nothing to match.

    For example.

    1. Query for "DOE^JOHN"
    Does NOT match "DOE^JOHN"

    2. Query for "DOE^*"
    Does NOT match "DOE^JOHN"

    3. Query for "DOE*TH"
    DOES match "DOE^THOMAS"

    4. Query for "*DOE*"
    DOES match "SMITH^DOE"

    Our application allows the user to enter first and last names
    (including wildcards), which we are combining with a "^". With the 2
    systems we have tested against, entering anything in the first name
    field (which adds a "^") causes nothing to be returned by either
    system. I do not believe this is correct, what is your interpretation?

    Beyond what is correct, there is also the reality of what is
    implemented in the field. If there are a lot of systems that disregard
    the delimiters, is it a good idea to make our system configurable so
    that it could use "*" in place of "^"?

    Thanks,
    Jon Sayer


  2. Re: PN search

    Jon

    >
    > 1. Query for "DOE"
    > Should match "DOE^JOHN" and "DOE^JANE".

    ....
    > 2. Query for "DOE^JOHN"
    > Should match "DOE^JOHN" and "DOE^JOHN^PETER"
    > Should not match "DOETH^JOHN" or "DOE^JOHNATHON"

    ....

    I apparently missed something you saw. It appears you are assuming an
    implicit wildcard in cases involving exact matches of the query string
    to individual name subcomponents.
    What is the basis for this assumption? Do you have a standard citation
    for this?


  3. Re: PN search

    Hi Eric, long time no see. Yes, I am assuming an implicit wildcard to
    the subcomponents that are left blank. This follows my assumption that
    each subcomponent is treated as an individual attribute, which would
    mean that blank subcomponents are subject to universal matching. Maybe
    I'm way offbase, but these are my interpretations which is why I am
    trying to see if there is a group consensus.


    eric.goodall@gmail.com wrote:
    > Jon
    >
    > >
    > > 1. Query for "DOE"
    > > Should match "DOE^JOHN" and "DOE^JANE".

    > ...
    > > 2. Query for "DOE^JOHN"
    > > Should match "DOE^JOHN" and "DOE^JOHN^PETER"
    > > Should not match "DOETH^JOHN" or "DOE^JOHNATHON"

    > ...
    >
    > I apparently missed something you saw. It appears you are assuming an
    > implicit wildcard in cases involving exact matches of the query string
    > to individual name subcomponents.
    > What is the basis for this assumption? Do you have a standard citation
    > for this?



  4. Re: PN search


    jonsayer@gmail.com wrote:
    > Hi Eric, long time no see. Yes, I am assuming an implicit wildcard to
    > the subcomponents that are left blank. This follows my assumption that
    > each subcomponent is treated as an individual attribute, which would
    > mean that blank subcomponents are subject to universal matching. Maybe
    > I'm way offbase, but these are my interpretations which is why I am
    > trying to see if there is a group consensus.


    You cannot make such implicit assumptions.

    By default, the entire PN string is matched as a whole - there is no
    special
    treatment of name components unless you ask for it with wildcards.

    Wildcards must be explicitly present.

    So for example:

    DOE*

    would match DOETH as well as DOE^JOHN

    DOE^*

    would match DOE^JOHN but it would not match DOE alone
    nor DOE JOHN or DOE, JOHN.

    David

    PS. Since it might be useful to have semantic or phonetic name
    matching, I have in the past submitted a CP to allow for extended
    negotiation of additional matching features. For example I have
    found using Soundex or Metaphone matching very helpful, as
    well as swapping the name components to account for this
    common error, as well as looking for non-caret name component
    separators. See:

    ftp://medical.nema.org/medical/dicom/cp/cp601_01.pdf

    There is an implementation of the different matching patterns
    that can be turned on in the pixelmed code for experimenting
    with this on the SCP side (though it doesn't yet look for the
    proposed extended negotiation).


  5. Re: PN search

    I was kind of afraid that this might be the case. I think it is a
    little unfortunate because I believe it requires excessive use of
    wildcards which invites unwanted search results (DOETH^JOHN when
    looking for DOE^JOHN, JOHNSON^BOB when searching for people with first
    name JOHN, etc). Thanks for the clarification though.


  6. Re: PN search

    The DICOM standard just defines a very simple search. This is
    approbiate for a standard because it is the minimum feature everyone
    has to support.
    In a real application the searching feature can be much more
    comfortable for the user. If the basic DICOM functionality is not
    enough it is always possible to do a broader search in the background
    and then do a "local" search to narrow down the Query results to what
    the user was looking for.


  7. Re: PN search

    That's a good point, I hadn't thought of that. Thanks for the
    suggestion.

    Thomas Freier wrote:
    > The DICOM standard just defines a very simple search. This is
    > approbiate for a standard because it is the minimum feature everyone
    > has to support.
    > In a real application the searching feature can be much more
    > comfortable for the user. If the basic DICOM functionality is not
    > enough it is always possible to do a broader search in the background
    > and then do a "local" search to narrow down the Query results to what
    > the user was looking for.



+ Reply to Thread