dicom3tools' pnmtodc - DICOM

This is a discussion on dicom3tools' pnmtodc - DICOM ; My thanks to David Clunie for his dicom3tools. I am trying to learn how to use the pnmtodc conversion tool. I am trying to see what fields can be populated with the '-r ' option. I've scanned through the newsgroup ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: dicom3tools' pnmtodc

  1. dicom3tools' pnmtodc

    My thanks to David Clunie for his dicom3tools.

    I am trying to learn how to use the pnmtodc conversion tool. I am
    trying to see what fields can be populated with the '-r ' option. I've
    scanned through the newsgroup and read the README and INSTALL and
    viewed the man page, but I must be missing something.

    Is there a way to find what patient information can be passed to
    pnmtodcm?

    Thanks again.

    Steve Poe
    Adobe Animal Hospital


  2. Re: dicom3tools' pnmtodc

    Hi Steve

    steve.poe@gmail.com wrote:

    > I am trying to learn how to use the pnmtodc conversion tool. I am
    > trying to see what fields can be populated with the '-r ' option. I've
    > scanned through the newsgroup and read the README and INSTALL and
    > viewed the man page, but I must be missing something.


    The -r option is common to the entire family of utilities
    that create or copy files, including pnmtodc.

    You can replace any attribute that you like, either specified
    by name or by numeric data element (e.g., if you need to insert
    a private tag).

    The list of names is in the dictionary (only, since it is way
    too long to document separately). Most of these are easily
    guessed from the names in the DICOM standard (by removing
    spaces and punctuation), but look in:

    libsrc/standard/elmdict/dicom3.tpl

    if you like.

    For example:

    % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'

    % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]

    David

  3. Re: dicom3tools' pnmtodc

    Hi David,

    Thanks for clarification. This helps place me in the right direction.

    Steve

    David Clunie wrote:
    > Hi Steve
    >
    > steve.poe@gmail.com wrote:
    >
    > > I am trying to learn how to use the pnmtodc conversion tool. I am
    > > trying to see what fields can be populated with the '-r ' option. I've
    > > scanned through the newsgroup and read the README and INSTALL and
    > > viewed the man page, but I must be missing something.

    >
    > The -r option is common to the entire family of utilities
    > that create or copy files, including pnmtodc.
    >
    > You can replace any attribute that you like, either specified
    > by name or by numeric data element (e.g., if you need to insert
    > a private tag).
    >
    > The list of names is in the dictionary (only, since it is way
    > too long to document separately). Most of these are easily
    > guessed from the names in the DICOM standard (by removing
    > spaces and punctuation), but look in:
    >
    > libsrc/standard/elmdict/dicom3.tpl
    >
    > if you like.
    >
    > For example:
    >
    > % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    >
    > % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    > (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    > (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    > (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    >
    > David



  4. Re: dicom3tools' pnmtodc

    Hi David,

    A follow-up question to the dicom attributes which can be passed. I
    found the libsrc/standard/elmdict/dicom3.tpl file and it is helpful. I
    want to be able to imprint the client's phone number in the image but
    pnmtodc did not recognize that parameter.

    How can I show all the parameters that pnmtodc will support of the
    dicom spec? I am probably doing something wrong.

    Thanks.

    Steve Poe


    David Clunie wrote:
    > Hi Steve
    >
    > steve.poe@gmail.com wrote:
    >
    > > I am trying to learn how to use the pnmtodc conversion tool. I am
    > > trying to see what fields can be populated with the '-r ' option. I've
    > > scanned through the newsgroup and read the README and INSTALL and
    > > viewed the man page, but I must be missing something.

    >
    > The -r option is common to the entire family of utilities
    > that create or copy files, including pnmtodc.
    >
    > You can replace any attribute that you like, either specified
    > by name or by numeric data element (e.g., if you need to insert
    > a private tag).
    >
    > The list of names is in the dictionary (only, since it is way
    > too long to document separately). Most of these are easily
    > guessed from the names in the DICOM standard (by removing
    > spaces and punctuation), but look in:
    >
    > libsrc/standard/elmdict/dicom3.tpl
    >
    > if you like.
    >
    > For example:
    >
    > % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    >
    > % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    > (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    > (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    > (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    >
    > David



  5. Re: dicom3tools' pnmtodc

    Did you try PatientTelephoneNumber ?

    Anything that is in the dictionary can be used with the -r
    option.

    Note that adding the telephone number to an image is non-standard,
    and adding non-standard things (be they private elements or
    standard elements as a so-called "Standard Extended SOP Class" is
    generally a bad thing to do, since DICOM applications may
    drop them).

    The dciodvfy utility now warns when you do naughty things like that.

    David

    steve.poe@gmail.com wrote:
    > Hi David,
    >
    > A follow-up question to the dicom attributes which can be passed. I
    > found the libsrc/standard/elmdict/dicom3.tpl file and it is helpful. I
    > want to be able to imprint the client's phone number in the image but
    > pnmtodc did not recognize that parameter.
    >
    > How can I show all the parameters that pnmtodc will support of the
    > dicom spec? I am probably doing something wrong.
    >
    > Thanks.
    >
    > Steve Poe
    >
    >
    > David Clunie wrote:
    >> Hi Steve
    >>
    >> steve.poe@gmail.com wrote:
    >>
    >>> I am trying to learn how to use the pnmtodc conversion tool. I am
    >>> trying to see what fields can be populated with the '-r ' option. I've
    >>> scanned through the newsgroup and read the README and INSTALL and
    >>> viewed the man page, but I must be missing something.

    >> The -r option is common to the entire family of utilities
    >> that create or copy files, including pnmtodc.
    >>
    >> You can replace any attribute that you like, either specified
    >> by name or by numeric data element (e.g., if you need to insert
    >> a private tag).
    >>
    >> The list of names is in the dictionary (only, since it is way
    >> too long to document separately). Most of these are easily
    >> guessed from the names in the DICOM standard (by removing
    >> spaces and punctuation), but look in:
    >>
    >> libsrc/standard/elmdict/dicom3.tpl
    >>
    >> if you like.
    >>
    >> For example:
    >>
    >> % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    >>
    >> % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    >> (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    >> (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    >> (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    >>
    >> David

    >


  6. Re: dicom3tools' pnmtodc

    Yes, I believe I did...I'll need to check that.

    I am confused, since I am new, I thought that all DICOM elements were
    standard and therefore accepted. Our internal veterinary application
    and PACS do not talk to each other natively, so I am adding
    client/patient information into the image so the doctors, and their
    technicians, do not have to go back-and-forth between screens. I
    thought embedding the client information into the DICOM headers. If we
    have to send off this image to a referring doctor, I understand that
    they may not import the phone number.

    Is there an easy way to determine what DICOM elements that will not get
    removed? Could I embed client information in other standard
    fields...like patient comments?

    Thanks.

    Steve Poe



    David Clunie wrote:
    > Did you try PatientTelephoneNumber ?
    >
    > Anything that is in the dictionary can be used with the -r
    > option.
    >
    > Note that adding the telephone number to an image is non-standard,
    > and adding non-standard things (be they private elements or
    > standard elements as a so-called "Standard Extended SOP Class" is
    > generally a bad thing to do, since DICOM applications may
    > drop them).
    >
    > The dciodvfy utility now warns when you do naughty things like that.
    >
    > David
    >
    > steve.poe@gmail.com wrote:
    > > Hi David,
    > >
    > > A follow-up question to the dicom attributes which can be passed. I
    > > found the libsrc/standard/elmdict/dicom3.tpl file and it is helpful. I
    > > want to be able to imprint the client's phone number in the image but
    > > pnmtodc did not recognize that parameter.
    > >
    > > How can I show all the parameters that pnmtodc will support of the
    > > dicom spec? I am probably doing something wrong.
    > >
    > > Thanks.
    > >
    > > Steve Poe
    > >
    > >
    > > David Clunie wrote:
    > >> Hi Steve
    > >>
    > >> steve.poe@gmail.com wrote:
    > >>
    > >>> I am trying to learn how to use the pnmtodc conversion tool. I am
    > >>> trying to see what fields can be populated with the '-r ' option. I've
    > >>> scanned through the newsgroup and read the README and INSTALL and
    > >>> viewed the man page, but I must be missing something.
    > >> The -r option is common to the entire family of utilities
    > >> that create or copy files, including pnmtodc.
    > >>
    > >> You can replace any attribute that you like, either specified
    > >> by name or by numeric data element (e.g., if you need to insert
    > >> a private tag).
    > >>
    > >> The list of names is in the dictionary (only, since it is way
    > >> too long to document separately). Most of these are easily
    > >> guessed from the names in the DICOM standard (by removing
    > >> spaces and punctuation), but look in:
    > >>
    > >> libsrc/standard/elmdict/dicom3.tpl
    > >>
    > >> if you like.
    > >>
    > >> For example:
    > >>
    > >> % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    > >>
    > >> % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    > >> (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    > >> (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    > >> (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    > >>
    > >> David

    > >



  7. Phone numbers and other extra stuff in images, was Re: dicom3tools'pnmtodc

    Hi Steve

    DICOM images are not just a list of data elements chosen
    arbitrarily from the data dictionary in Part 6.

    Every type of image has an "information object definition"
    (IOD), which lists which consists of a list of mandatory,
    conditional and optional modules, each of which defines
    a list of mandatory, conditional and optional attributes.

    For example, the MR IODs contain a Magnetic Field Strength
    attribute, whereas the CT IODs do not, etc.

    Devices may add extra attributes, beyond the IODs, but this
    is generally a "bad thing", since whether they are standard
    attributes but not in the IOD, or private attributes, their
    meaning within the scope of the IOD is undefined and hence
    not terribly inter-operable.

    DICOM storage devices are not required to pass these extras
    (see the definition of storage SOP class "level" in Annex
    B of Part 4).

    You are trying to solve a real-world problem, but the standard
    is not designed to solve it for you ... there are essentially
    no semantics in the standard for communicating phone numbers
    using image objects.

    The more information that you try to bury inside the images
    to achieve functionality that is not defined by the standard,
    the more problems you will have as additional devices get
    thrown into the mix.

    For example, an ordinary DICOM image viewer will certainly
    not go looking in the header for phone numbers and provide
    a way to view them.

    The patient information that is included in DICOM images
    is primarily intended to be of two classes - that needed for
    identification, and that which describes characteristics
    of the patient that might be relevant during image
    interpretation (e.g., sex, weight, etc.); it is not really
    intended to be a source of demographic and administrative
    information, since that is usually contained in and available
    from non-DICOM information systems that are usually
    communicating using HL7.

    As a matter of expediency, you can add the Patient's Telephone
    Number attribute to the images, and tweak your viewer to show
    it, and most of the time this will probably work just fine,
    but you really should think of finding a better way to extract
    that and other patient administrative information from where
    it is reliably stored (e.g., listening to an HL7 ADT feed
    and caching the information, or implementing the appropriate
    HL7 query).

    David

    steve.poe@gmail.com wrote:
    > Yes, I believe I did...I'll need to check that.
    >
    > I am confused, since I am new, I thought that all DICOM elements were
    > standard and therefore accepted. Our internal veterinary application
    > and PACS do not talk to each other natively, so I am adding
    > client/patient information into the image so the doctors, and their
    > technicians, do not have to go back-and-forth between screens. I
    > thought embedding the client information into the DICOM headers. If we
    > have to send off this image to a referring doctor, I understand that
    > they may not import the phone number.
    >
    > Is there an easy way to determine what DICOM elements that will not get
    > removed? Could I embed client information in other standard
    > fields...like patient comments?
    >
    > Thanks.
    >
    > Steve Poe
    >
    >
    >
    > David Clunie wrote:
    >> Did you try PatientTelephoneNumber ?
    >>
    >> Anything that is in the dictionary can be used with the -r
    >> option.
    >>
    >> Note that adding the telephone number to an image is non-standard,
    >> and adding non-standard things (be they private elements or
    >> standard elements as a so-called "Standard Extended SOP Class" is
    >> generally a bad thing to do, since DICOM applications may
    >> drop them).
    >>
    >> The dciodvfy utility now warns when you do naughty things like that.
    >>
    >> David
    >>
    >> steve.poe@gmail.com wrote:
    >>> Hi David,
    >>>
    >>> A follow-up question to the dicom attributes which can be passed. I
    >>> found the libsrc/standard/elmdict/dicom3.tpl file and it is helpful. I
    >>> want to be able to imprint the client's phone number in the image but
    >>> pnmtodc did not recognize that parameter.
    >>>
    >>> How can I show all the parameters that pnmtodc will support of the
    >>> dicom spec? I am probably doing something wrong.
    >>>
    >>> Thanks.
    >>>
    >>> Steve Poe
    >>>
    >>>
    >>> David Clunie wrote:
    >>>> Hi Steve
    >>>>
    >>>> steve.poe@gmail.com wrote:
    >>>>
    >>>>> I am trying to learn how to use the pnmtodc conversion tool. I am
    >>>>> trying to see what fields can be populated with the '-r ' option. I've
    >>>>> scanned through the newsgroup and read the README and INSTALL and
    >>>>> viewed the man page, but I must be missing something.
    >>>> The -r option is common to the entire family of utilities
    >>>> that create or copy files, including pnmtodc.
    >>>>
    >>>> You can replace any attribute that you like, either specified
    >>>> by name or by numeric data element (e.g., if you need to insert
    >>>> a private tag).
    >>>>
    >>>> The list of names is in the dictionary (only, since it is way
    >>>> too long to document separately). Most of these are easily
    >>>> guessed from the names in the DICOM standard (by removing
    >>>> spaces and punctuation), but look in:
    >>>>
    >>>> libsrc/standard/elmdict/dicom3.tpl
    >>>>
    >>>> if you like.
    >>>>
    >>>> For example:
    >>>>
    >>>> % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    >>>>
    >>>> % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    >>>> (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    >>>> (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    >>>> (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    >>>>
    >>>> David

    >


  8. Re: Phone numbers and other extra stuff in images, was Re: dicom3tools' pnmtodc

    David,

    I *think* I understand most of what you're saying. On one side, since I
    see that DICOM supports a particular attribute, so I should be able to
    plug in the information. On the other side, the information need to be
    relative. If I want to add a KVP value for a DR image, this would not
    apply (I think) to a Ultrasound.

    In regards to patient information, I am looking for a way to compensate
    for the Veterinary application lack of a DICOM tie-in and our digital
    radiograph unit being created from scratch (we're getting it for free
    as beta testers with no DICOM interface).

    So, it sounds like I should be looking in the IOD for digital
    radiograph

    "You are trying to solve a real-world problem, but the standard
    > is not designed to solve it for you ... there are essentially
    > no semantics in the standard for communicating phone numbers
    > using image objects"


    This is true even though the attribute is apart of DICOM,
    (0x0040,0x1103) LO Person's Telephone Numbers, but if the device does
    not call for it, then this is non-standard. Am I following this
    correctly?

    So, my first goal/challenge is to take an image (TIF) created by the DR
    plate then wrap patient information around it and push it to the review
    station. The next project is to make this work with our Ultrasound
    devices.

    I've heard about HL7 but since I am in veterinary medicine, I wasn't
    sure if this would apply to me. Plus, my mind is already swimming with
    all this DICOM information and trying to apply patient/animal
    client/owner information into the images.

    Regarding DICOM viewers, I new the functionality of them. I've looked
    at K-PACS and DicomWorks. I've not figured out if/how what DICOM
    headers can be displayed while viewing the image.

    Supposily sometime in 2007, Veterinary medicine will be added to the
    DICOM spec. Hopefully, when that time comes, my job will get a little
    easier.

    Steve


    David Clunie wrote:
    > Hi Steve
    >
    > DICOM images are not just a list of data elements chosen
    > arbitrarily from the data dictionary in Part 6.
    >
    > Every type of image has an "information object definition"
    > (IOD), which lists which consists of a list of mandatory,
    > conditional and optional modules, each of which defines
    > a list of mandatory, conditional and optional attributes.
    >
    > For example, the MR IODs contain a Magnetic Field Strength
    > attribute, whereas the CT IODs do not, etc.
    >
    > Devices may add extra attributes, beyond the IODs, but this
    > is generally a "bad thing", since whether they are standard
    > attributes but not in the IOD, or private attributes, their
    > meaning within the scope of the IOD is undefined and hence
    > not terribly inter-operable.
    >
    > DICOM storage devices are not required to pass these extras
    > (see the definition of storage SOP class "level" in Annex
    > B of Part 4).
    >
    > You are trying to solve a real-world problem, but the standard
    > is not designed to solve it for you ... there are essentially
    > no semantics in the standard for communicating phone numbers
    > using image objects.
    >
    > The more information that you try to bury inside the images
    > to achieve functionality that is not defined by the standard,
    > the more problems you will have as additional devices get
    > thrown into the mix.
    >
    > For example, an ordinary DICOM image viewer will certainly
    > not go looking in the header for phone numbers and provide
    > a way to view them.
    >
    > The patient information that is included in DICOM images
    > is primarily intended to be of two classes - that needed for
    > identification, and that which describes characteristics
    > of the patient that might be relevant during image
    > interpretation (e.g., sex, weight, etc.); it is not really
    > intended to be a source of demographic and administrative
    > information, since that is usually contained in and available
    > from non-DICOM information systems that are usually
    > communicating using HL7.
    >
    > As a matter of expediency, you can add the Patient's Telephone
    > Number attribute to the images, and tweak your viewer to show
    > it, and most of the time this will probably work just fine,
    > but you really should think of finding a better way to extract
    > that and other patient administrative information from where
    > it is reliably stored (e.g., listening to an HL7 ADT feed
    > and caching the information, or implementing the appropriate
    > HL7 query).
    >
    > David
    >
    > steve.poe@gmail.com wrote:
    > > Yes, I believe I did...I'll need to check that.
    > >
    > > I am confused, since I am new, I thought that all DICOM elements were
    > > standard and therefore accepted. Our internal veterinary application
    > > and PACS do not talk to each other natively, so I am adding
    > > client/patient information into the image so the doctors, and their
    > > technicians, do not have to go back-and-forth between screens. I
    > > thought embedding the client information into the DICOM headers. If we
    > > have to send off this image to a referring doctor, I understand that
    > > they may not import the phone number.
    > >
    > > Is there an easy way to determine what DICOM elements that will not get
    > > removed? Could I embed client information in other standard
    > > fields...like patient comments?
    > >
    > > Thanks.
    > >
    > > Steve Poe
    > >
    > >
    > >
    > > David Clunie wrote:
    > >> Did you try PatientTelephoneNumber ?
    > >>
    > >> Anything that is in the dictionary can be used with the -r
    > >> option.
    > >>
    > >> Note that adding the telephone number to an image is non-standard,
    > >> and adding non-standard things (be they private elements or
    > >> standard elements as a so-called "Standard Extended SOP Class" is
    > >> generally a bad thing to do, since DICOM applications may
    > >> drop them).
    > >>
    > >> The dciodvfy utility now warns when you do naughty things like that.
    > >>
    > >> David
    > >>
    > >> steve.poe@gmail.com wrote:
    > >>> Hi David,
    > >>>
    > >>> A follow-up question to the dicom attributes which can be passed. I
    > >>> found the libsrc/standard/elmdict/dicom3.tpl file and it is helpful. I
    > >>> want to be able to imprint the client's phone number in the image but
    > >>> pnmtodc did not recognize that parameter.
    > >>>
    > >>> How can I show all the parameters that pnmtodc will support of the
    > >>> dicom spec? I am probably doing something wrong.
    > >>>
    > >>> Thanks.
    > >>>
    > >>> Steve Poe
    > >>>
    > >>>
    > >>> David Clunie wrote:
    > >>>> Hi Steve
    > >>>>
    > >>>> steve.poe@gmail.com wrote:
    > >>>>
    > >>>>> I am trying to learn how to use the pnmtodc conversion tool. I am
    > >>>>> trying to see what fields can be populated with the '-r ' option. I've
    > >>>>> scanned through the newsgroup and read the README and INSTALL and
    > >>>>> viewed the man page, but I must be missing something.
    > >>>> The -r option is common to the entire family of utilities
    > >>>> that create or copy files, including pnmtodc.
    > >>>>
    > >>>> You can replace any attribute that you like, either specified
    > >>>> by name or by numeric data element (e.g., if you need to insert
    > >>>> a private tag).
    > >>>>
    > >>>> The list of names is in the dictionary (only, since it is way
    > >>>> too long to document separately). Most of these are easily
    > >>>> guessed from the names in the DICOM standard (by removing
    > >>>> spaces and punctuation), but look in:
    > >>>>
    > >>>> libsrc/standard/elmdict/dicom3.tpl
    > >>>>
    > >>>> if you like.
    > >>>>
    > >>>> For example:
    > >>>>
    > >>>> % dcsmpte /tmp/crap -r PatientName 'Smith^Mary' -r '(0x0029,0x0010)' 'Acme' -r '(0x0029,0x1010)' 'Private value'
    > >>>>
    > >>>> % dckey -describe /tmp/crap -k '(0x0029,0x0010)' -k '(0x0029,0x1010)' -k PatientName
    > >>>> (0x0010,0x0010) PN Patient's Name VR= VL=<0x000a>
    > >>>> (0x0029,0x0010) LO PrivateCreator VR= VL=<0x0004>
    > >>>> (0x0029,0x1010) ? VR= VL=<0x000e> [0x50,0x72,0x69,0x76,0x61,0x74,0x65,0x20,0x76,0x61, 0x6c,0x75,0x65,0x00]
    > >>>>
    > >>>> David

    > >



  9. Re: Phone numbers and other extra stuff in images, was Re: dicom3tools'pnmtodc

    Hi Steve

    steve.poe@gmail.com wrote:

    > This is true even though the attribute is apart of DICOM,
    > (0x0040,0x1103) LO Person's Telephone Numbers, but if the device does
    > not call for it, then this is non-standard. Am I following this
    > correctly?


    None of the modality-specific image IODs define the inclusion
    of the patient's telephone number or person's telephone number
    on a routine basis ... this attribute was defined to support
    other services in DICOM that are administrative in nature,
    or for identifying staff, not patients. If you look in PS 3.3,
    you will find that these attributes are included in a very
    limited number of places, including IODs and modules that
    support the worklist services.

    > So, my first goal/challenge is to take an image (TIF) created by the DR
    > plate then wrap patient information around it and push it to the review
    > station. The next project is to make this work with our Ultrasound
    > devices.


    You should then stick to the DX and US IODs respectively, ideally
    populating no more and no less than those IODs specify in terms
    of mandatory, conditional and optional attributes and values.

    > I've heard about HL7 but since I am in veterinary medicine, I wasn't
    > sure if this would apply to me. Plus, my mind is already swimming with
    > all this DICOM information and trying to apply patient/animal
    > client/owner information into the images.


    I am not sure to what extent HL7 has penetrated the veterinary
    IS market.

    > Regarding DICOM viewers, I new the functionality of them. I've looked
    > at K-PACS and DicomWorks. I've not figured out if/how what DICOM
    > headers can be displayed while viewing the image.


    They are certainly not going to be displaying Patient's Telephone
    Number; and they are not open source so you can't add that feature
    yourself. Osirix would be easy to modify in this regard but I don't
    know how many vets use Macs.

    > Supposily sometime in 2007, Veterinary medicine will be added to the
    > DICOM spec. Hopefully, when that time comes, my job will get a little
    > easier.


    Already done, see CP 643 final text at:

    ftp://medical.nema.org/medical/dicom/final/cp643_ft.pdf

    but it won't solve this particular problem, and in particular you
    will face the issue of common commercial and/or crippleware and/or
    open source viewers and PACS not yet supporting the extra veterinary
    tags.

    David

  10. Re: Phone numbers and other extra stuff in images, was Re: dicom3tools' pnmtodc

    David,

    > None of the modality-specific image IODs define the inclusion
    > of the patient's telephone number or person's telephone number
    > on a routine basis ... this attribute was defined to support
    > other services in DICOM that are administrative in nature,
    > or for identifying staff, not patients. If you look in PS 3.3,
    > you will find that these attributes are included in a very
    > limited number of places, including IODs and modules that
    > support the worklist services.


    Ahh..that's right. It did not say "Patient Phone Number" . I guess I
    could embed a phone number in "Other Patient Information" or "Patient
    Comments" since I've yet hear of an animal present noteworthy comments.


    > You should then stick to the DX and US IODs respectively, ideally
    > populating no more and no less than those IODs specify in terms
    > of mandatory, conditional and optional attributes and values.


    Less is more in these cases?
    >
    > They are certainly not going to be displaying Patient's Telephone
    > Number; and they are not open source so you can't add that feature
    > yourself. Osirix would be easy to modify in this regard but I don't
    > know how many vets use Macs.


    As much as I respect Macs, I don't wish to invest in another platform
    to support. Although, I've heard Osirix is very impressive.


    >
    > > Supposily sometime in 2007, Veterinary medicine will be added to the
    > > DICOM spec. Hopefully, when that time comes, my job will get a little
    > > easier.

    >
    > Already done, see CP 643 final text at:
    >
    > ftp://medical.nema.org/medical/dicom/final/cp643_ft.pdf


    Thanks! This is helpful.
    >
    > but it won't solve this particular problem, and in particular you
    > will face the issue of common commercial and/or crippleware and/or
    > open source viewers and PACS not yet supporting the extra veterinary
    > tags.


    True, but that's okay. I don't mind being on the forefront. I realize
    viewers will not display the extra tags. I'll teach the doctors here to
    view the DICOM headers if they need more information.

    Most of what I am looking for is for internal needs. If we need to send
    the xray out for referral, the information which is dropped may not be
    a major issue. On referrals, I could also allow doctors into our
    network via a Web-based PACS or send them a PDF with the image embedded
    with a patient report.

    Thanks.

    Steve


+ Reply to Thread