How to make a new modality DICOM compliant? - DICOM

This is a discussion on How to make a new modality DICOM compliant? - DICOM ; Hi, all: I posted this question yesterday but I don't see it, so I post it again. We developed a new modality for breast imaging and want to make it DICOM compliant in some level, e.g. transfering image for viewing ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: How to make a new modality DICOM compliant?

  1. How to make a new modality DICOM compliant?

    Hi, all:
    I posted this question yesterday but I don't see it, so I post it
    again.

    We developed a new modality for breast imaging and want to make it
    DICOM compliant in some level, e.g. transfering image for viewing or
    archive, importing modality worklist, DICOM printing, etc. The problem
    is at present time, our modality name is unknown to the industry yet
    and of course not included in the DICOM standard. Even if we can send
    out the DICOM message to the netwotk anyway, since the modality name
    won't be identified by the recipient, the message will be discarded.
    How do people usually do to introduce a NEW modality to DICOM
    community?

    My understanding is that we can do the followings initially:
    1. Send our image over DICOM network as secondary capture (maybe
    multi-frame) with modality attribute filled as OT (other). This way,
    at least those DICOM viewing workstations that support Secondary
    Capture can diaplay our image.
    2. Build our own private SOP class, implement whatever functionalities
    we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    in our DICOM conformance statement and hoping venders in the industry
    will support our private SOP later someday when our new modality
    becomes popular. By that time we can expect that our modality and SOP
    specification will be adopted in the DICOM standard.

    Am I in the right track? Please give me your thought. Thanks,

    -Jie

  2. Re: How to make a new modality DICOM compliant?

    jie wrote:

    > We developed a new modality for breast imaging and want to make it
    > DICOM compliant in some level, e.g. transfering image for viewing or
    > archive, importing modality worklist, DICOM printing, etc. The problem
    > is at present time, our modality name is unknown to the industry yet
    > and of course not included in the DICOM standard. Even if we can send
    > out the DICOM message to the netwotk anyway, since the modality name
    > won't be identified by the recipient, the message will be discarded.
    > How do people usually do to introduce a NEW modality to DICOM
    > community?
    >
    > My understanding is that we can do the followings initially:
    > 1. Send our image over DICOM network as secondary capture (maybe
    > multi-frame) with modality attribute filled as OT (other). This way,
    > at least those DICOM viewing workstations that support Secondary
    > Capture can display our image.


    This is the mechanism that will allow the majority of PACS and
    viewers to display your images, as long as they are encoded with
    a reasonable set of pixel parameters (bit depth, etc.).

    You can use ANY value for Modality you like ... it does not have
    to be OT ... for example if your modality was Optical Coherence
    Tomography you could make up and use your own Modality term of
    "OCT". This would be much more useful than using "OT" which is
    completely useless to anyone. The Secondary Capture IODs are
    very flexible in terms of what you can encode in the Modality
    attribute.

    If you need to encode additional information (e.g. cross-sectional
    image positioning with the Image Plane and Frame of Reference
    modules), you can add standard attributes to the SC SOP Class
    as a "Standard Extended" SOP Class ... this is harmless to ordinary
    standard implementations and may gain you additional functionality
    in standard viewers.

    To add additional information that is not in the standard yet,
    you can add private attributes or coded entries in Acquisition
    Context.

    > 2. Build our own private SOP class, implement whatever functionalities
    > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    > in our DICOM conformance statement and hoping venders in the industry
    > will support our private SOP later someday when our new modality
    > becomes popular. By that time we can expect that our modality and SOP
    > specification will be adopted in the DICOM standard.


    You should avoid a private image SOP class if you can, because then
    many archives won't store it and many viewers won't display it, since
    they won't be able to recognize the SOP Class or that it is an image
    (as opposed to another kind of SOP Class like a query or whatever).

    In the interim, you should approach the DICOM Committee with a proposal
    to create a new standard object for your modality.

    What is the new modality by the way ?

    If it has to do with the breast, then WG 15 is the appropriate group
    to work with on this.

    David




  3. Re: How to make a new modality DICOM compliant?

    David: Thanks for replying to my post.

    Our modality is called Computed Tomography Laser Mammography. The
    system utilizes near-infra red laser and proprietary CT reconstruction
    algorithms to create vascular images of breast without the use of
    x-rays.

    If I add our acquisition context and data (different from any other
    modality) to the SC object as private attributes, then the SOP becomes
    a specialized SOP and we need to use a private UID for it. This causes
    it unrecognizable to others. We need to make a decision on whether or
    not to keep most, if not all, of the acquisition context and raw data.
    If not, then the standard or extended SC IOD will be enough to hold
    all necessary information. Question here is does CT or MRI keeps its
    acquisition context and raw data in its IOD? It seems not.

    Our image is best viewed in 3-D. We have 3-D visualization software
    built in the modality. Most frequently we handle a stack of slices as
    a volume or a 3-D data set, so multi-frame IODs make more sense for
    us. Secondary Capture can be multi-frame. How about Supplement 63
    Multi-Dimensional Interchange (ND IOD)? I noticed it is modality
    independent too. It seems a good candidate for us too. The current
    status of this draft is Public Comment. When will it be finalized and
    formally released? Any major change expected?

    Besides SC and ND, is there any other image IOD that is modality
    neutral?

    Also, thanks for pointing out the WG15 to me. We'll make inquiry on
    that too.

    -Jie


    David Clunie wrote in message news:<416FE271.7000002@dclunie.com>...
    > jie wrote:
    >
    > > We developed a new modality for breast imaging and want to make it
    > > DICOM compliant in some level, e.g. transfering image for viewing or
    > > archive, importing modality worklist, DICOM printing, etc. The problem
    > > is at present time, our modality name is unknown to the industry yet
    > > and of course not included in the DICOM standard. Even if we can send
    > > out the DICOM message to the netwotk anyway, since the modality name
    > > won't be identified by the recipient, the message will be discarded.
    > > How do people usually do to introduce a NEW modality to DICOM
    > > community?
    > >
    > > My understanding is that we can do the followings initially:
    > > 1. Send our image over DICOM network as secondary capture (maybe
    > > multi-frame) with modality attribute filled as OT (other). This way,
    > > at least those DICOM viewing workstations that support Secondary
    > > Capture can display our image.

    >
    > This is the mechanism that will allow the majority of PACS and
    > viewers to display your images, as long as they are encoded with
    > a reasonable set of pixel parameters (bit depth, etc.).
    >
    > You can use ANY value for Modality you like ... it does not have
    > to be OT ... for example if your modality was Optical Coherence
    > Tomography you could make up and use your own Modality term of
    > "OCT". This would be much more useful than using "OT" which is
    > completely useless to anyone. The Secondary Capture IODs are
    > very flexible in terms of what you can encode in the Modality
    > attribute.
    >
    > If you need to encode additional information (e.g. cross-sectional
    > image positioning with the Image Plane and Frame of Reference
    > modules), you can add standard attributes to the SC SOP Class
    > as a "Standard Extended" SOP Class ... this is harmless to ordinary
    > standard implementations and may gain you additional functionality
    > in standard viewers.
    >
    > To add additional information that is not in the standard yet,
    > you can add private attributes or coded entries in Acquisition
    > Context.
    >
    > > 2. Build our own private SOP class, implement whatever functionalities
    > > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    > > in our DICOM conformance statement and hoping venders in the industry
    > > will support our private SOP later someday when our new modality
    > > becomes popular. By that time we can expect that our modality and SOP
    > > specification will be adopted in the DICOM standard.

    >
    > You should avoid a private image SOP class if you can, because then
    > many archives won't store it and many viewers won't display it, since
    > they won't be able to recognize the SOP Class or that it is an image
    > (as opposed to another kind of SOP Class like a query or whatever).
    >
    > In the interim, you should approach the DICOM Committee with a proposal
    > to create a new standard object for your modality.
    >
    > What is the new modality by the way ?
    >
    > If it has to do with the breast, then WG 15 is the appropriate group
    > to work with on this.
    >
    > David


  4. Re: How to make a new modality DICOM compliant?

    Supplement 63 looks like a good choice for this.
    It avoids creating an arbitrary slice representation
    that may have little or no utility for clinical display.

    Eventually there will be a complementary
    Presentation State standard to enable specifying
    preferred 3D views of the multidimensional array
    with Supplement 63 SOP instances.

    - Doug

    "jie" wrote in message
    news:c6ac7482.0410190610.20609729@posting.google.c om...
    > David: Thanks for replying to my post.
    >
    > Our modality is called Computed Tomography Laser Mammography. The
    > system utilizes near-infra red laser and proprietary CT reconstruction
    > algorithms to create vascular images of breast without the use of
    > x-rays.
    >
    > If I add our acquisition context and data (different from any other
    > modality) to the SC object as private attributes, then the SOP becomes
    > a specialized SOP and we need to use a private UID for it. This causes
    > it unrecognizable to others. We need to make a decision on whether or
    > not to keep most, if not all, of the acquisition context and raw data.
    > If not, then the standard or extended SC IOD will be enough to hold
    > all necessary information. Question here is does CT or MRI keeps its
    > acquisition context and raw data in its IOD? It seems not.
    >
    > Our image is best viewed in 3-D. We have 3-D visualization software
    > built in the modality. Most frequently we handle a stack of slices as
    > a volume or a 3-D data set, so multi-frame IODs make more sense for
    > us. Secondary Capture can be multi-frame. How about Supplement 63
    > Multi-Dimensional Interchange (ND IOD)? I noticed it is modality
    > independent too. It seems a good candidate for us too. The current
    > status of this draft is Public Comment. When will it be finalized and
    > formally released? Any major change expected?
    >
    > Besides SC and ND, is there any other image IOD that is modality
    > neutral?
    >
    > Also, thanks for pointing out the WG15 to me. We'll make inquiry on
    > that too.
    >
    > -Jie
    >
    >
    > David Clunie wrote in message
    > news:<416FE271.7000002@dclunie.com>...
    >> jie wrote:
    >>
    >> > We developed a new modality for breast imaging and want to make it
    >> > DICOM compliant in some level, e.g. transfering image for viewing or
    >> > archive, importing modality worklist, DICOM printing, etc. The problem
    >> > is at present time, our modality name is unknown to the industry yet
    >> > and of course not included in the DICOM standard. Even if we can send
    >> > out the DICOM message to the netwotk anyway, since the modality name
    >> > won't be identified by the recipient, the message will be discarded.
    >> > How do people usually do to introduce a NEW modality to DICOM
    >> > community?
    >> >
    >> > My understanding is that we can do the followings initially:
    >> > 1. Send our image over DICOM network as secondary capture (maybe
    >> > multi-frame) with modality attribute filled as OT (other). This way,
    >> > at least those DICOM viewing workstations that support Secondary
    >> > Capture can display our image.

    >>
    >> This is the mechanism that will allow the majority of PACS and
    >> viewers to display your images, as long as they are encoded with
    >> a reasonable set of pixel parameters (bit depth, etc.).
    >>
    >> You can use ANY value for Modality you like ... it does not have
    >> to be OT ... for example if your modality was Optical Coherence
    >> Tomography you could make up and use your own Modality term of
    >> "OCT". This would be much more useful than using "OT" which is
    >> completely useless to anyone. The Secondary Capture IODs are
    >> very flexible in terms of what you can encode in the Modality
    >> attribute.
    >>
    >> If you need to encode additional information (e.g. cross-sectional
    >> image positioning with the Image Plane and Frame of Reference
    >> modules), you can add standard attributes to the SC SOP Class
    >> as a "Standard Extended" SOP Class ... this is harmless to ordinary
    >> standard implementations and may gain you additional functionality
    >> in standard viewers.
    >>
    >> To add additional information that is not in the standard yet,
    >> you can add private attributes or coded entries in Acquisition
    >> Context.
    >>
    >> > 2. Build our own private SOP class, implement whatever functionalities
    >> > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    >> > in our DICOM conformance statement and hoping venders in the industry
    >> > will support our private SOP later someday when our new modality
    >> > becomes popular. By that time we can expect that our modality and SOP
    >> > specification will be adopted in the DICOM standard.

    >>
    >> You should avoid a private image SOP class if you can, because then
    >> many archives won't store it and many viewers won't display it, since
    >> they won't be able to recognize the SOP Class or that it is an image
    >> (as opposed to another kind of SOP Class like a query or whatever).
    >>
    >> In the interim, you should approach the DICOM Committee with a proposal
    >> to create a new standard object for your modality.
    >>
    >> What is the new modality by the way ?
    >>
    >> If it has to do with the breast, then WG 15 is the appropriate group
    >> to work with on this.
    >>
    >> David




  5. Re: How to make a new modality DICOM compliant?

    A couple of issues you should be aware of if you decide to use the
    approach in Supplement 63 are that since it is not standard, you would
    have to use a Private SOP Class, thus affecting your interoperability.
    Also, since it is only in Public Comment, the contents could change
    significantly, depending on the comments.

    What about using the Enhanced CT IOD (Supplement 58, now standard)?
    It is already multi-frame, and inherently 3D, and you could just pull
    in other standard tags as needed, or add your own Private tags...
    And, by the way, if you and new tags to an IOD that are either Private
    or Standard, it does not automatically mean a Private SOP Class. Many
    vendors do this already, using the existing SOP Classes.

    "Doug Sluis" wrote in message news:...
    > Supplement 63 looks like a good choice for this.
    > It avoids creating an arbitrary slice representation
    > that may have little or no utility for clinical display.
    >
    > Eventually there will be a complementary
    > Presentation State standard to enable specifying
    > preferred 3D views of the multidimensional array
    > with Supplement 63 SOP instances.
    >
    > - Doug
    >
    > "jie" wrote in message
    > news:c6ac7482.0410190610.20609729@posting.google.c om...
    > > David: Thanks for replying to my post.
    > >
    > > Our modality is called Computed Tomography Laser Mammography. The
    > > system utilizes near-infra red laser and proprietary CT reconstruction
    > > algorithms to create vascular images of breast without the use of
    > > x-rays.
    > >
    > > If I add our acquisition context and data (different from any other
    > > modality) to the SC object as private attributes, then the SOP becomes
    > > a specialized SOP and we need to use a private UID for it. This causes
    > > it unrecognizable to others. We need to make a decision on whether or
    > > not to keep most, if not all, of the acquisition context and raw data.
    > > If not, then the standard or extended SC IOD will be enough to hold
    > > all necessary information. Question here is does CT or MRI keeps its
    > > acquisition context and raw data in its IOD? It seems not.
    > >
    > > Our image is best viewed in 3-D. We have 3-D visualization software
    > > built in the modality. Most frequently we handle a stack of slices as
    > > a volume or a 3-D data set, so multi-frame IODs make more sense for
    > > us. Secondary Capture can be multi-frame. How about Supplement 63
    > > Multi-Dimensional Interchange (ND IOD)? I noticed it is modality
    > > independent too. It seems a good candidate for us too. The current
    > > status of this draft is Public Comment. When will it be finalized and
    > > formally released? Any major change expected?
    > >
    > > Besides SC and ND, is there any other image IOD that is modality
    > > neutral?
    > >
    > > Also, thanks for pointing out the WG15 to me. We'll make inquiry on
    > > that too.
    > >
    > > -Jie
    > >
    > >
    > > David Clunie wrote in message
    > > news:<416FE271.7000002@dclunie.com>...
    > >> jie wrote:
    > >>
    > >> > We developed a new modality for breast imaging and want to make it
    > >> > DICOM compliant in some level, e.g. transfering image for viewing or
    > >> > archive, importing modality worklist, DICOM printing, etc. The problem
    > >> > is at present time, our modality name is unknown to the industry yet
    > >> > and of course not included in the DICOM standard. Even if we can send
    > >> > out the DICOM message to the netwotk anyway, since the modality name
    > >> > won't be identified by the recipient, the message will be discarded.
    > >> > How do people usually do to introduce a NEW modality to DICOM
    > >> > community?
    > >> >
    > >> > My understanding is that we can do the followings initially:
    > >> > 1. Send our image over DICOM network as secondary capture (maybe
    > >> > multi-frame) with modality attribute filled as OT (other). This way,
    > >> > at least those DICOM viewing workstations that support Secondary
    > >> > Capture can display our image.
    > >>
    > >> This is the mechanism that will allow the majority of PACS and
    > >> viewers to display your images, as long as they are encoded with
    > >> a reasonable set of pixel parameters (bit depth, etc.).
    > >>
    > >> You can use ANY value for Modality you like ... it does not have
    > >> to be OT ... for example if your modality was Optical Coherence
    > >> Tomography you could make up and use your own Modality term of
    > >> "OCT". This would be much more useful than using "OT" which is
    > >> completely useless to anyone. The Secondary Capture IODs are
    > >> very flexible in terms of what you can encode in the Modality
    > >> attribute.
    > >>
    > >> If you need to encode additional information (e.g. cross-sectional
    > >> image positioning with the Image Plane and Frame of Reference
    > >> modules), you can add standard attributes to the SC SOP Class
    > >> as a "Standard Extended" SOP Class ... this is harmless to ordinary
    > >> standard implementations and may gain you additional functionality
    > >> in standard viewers.
    > >>
    > >> To add additional information that is not in the standard yet,
    > >> you can add private attributes or coded entries in Acquisition
    > >> Context.
    > >>
    > >> > 2. Build our own private SOP class, implement whatever functionalities
    > >> > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    > >> > in our DICOM conformance statement and hoping venders in the industry
    > >> > will support our private SOP later someday when our new modality
    > >> > becomes popular. By that time we can expect that our modality and SOP
    > >> > specification will be adopted in the DICOM standard.
    > >>
    > >> You should avoid a private image SOP class if you can, because then
    > >> many archives won't store it and many viewers won't display it, since
    > >> they won't be able to recognize the SOP Class or that it is an image
    > >> (as opposed to another kind of SOP Class like a query or whatever).
    > >>
    > >> In the interim, you should approach the DICOM Committee with a proposal
    > >> to create a new standard object for your modality.
    > >>
    > >> What is the new modality by the way ?
    > >>
    > >> If it has to do with the breast, then WG 15 is the appropriate group
    > >> to work with on this.
    > >>
    > >> David


  6. Re: How to make a new modality DICOM compliant? - Supplement 58

    DICOM p.s. 2 says if one add type 1, 1c, 2 or 3 attributes to a
    standard IOD, then the SOP with that IOD becomes a SPECIALIZED SOP
    which needs a private UID for it. Will this adversely affect my
    interoperability?

    How about the Modality name? If it's an Enhanced CT IOD, i assume the
    modality attribute has to be "CT", or Can I put a faked name "CTLM"
    (our new modality) instead? My guess is that if I add only standard
    tags, the resulting extended SOP still use the standard UID, then the
    modality attribute has to be "CT". If I add private tags, since the
    UID becomes private, the modality attribute can be something other
    than "CT".

    Which storage SCP is more frequently supported on a typical PACS
    system? Seconndary Capture, Seconndary Capture Multi-Frame or Enhanced
    CT IOD? We want images from our modality can be archived to and
    retrieved from the existing PASC system of the hospital if they buy
    our modality. That's our initial requirement. I'm thinking to go with
    the SC single image, since it must be more supported than others.
    - Jie


    dmcnamara@vitalimages.com (David McNamara) wrote in message news:...
    > A couple of issues you should be aware of if you decide to use the
    > approach in Supplement 63 are that since it is not standard, you would
    > have to use a Private SOP Class, thus affecting your interoperability.
    > Also, since it is only in Public Comment, the contents could change
    > significantly, depending on the comments.
    >
    > What about using the Enhanced CT IOD (Supplement 58, now standard)?
    > It is already multi-frame, and inherently 3D, and you could just pull
    > in other standard tags as needed, or add your own Private tags...
    > And, by the way, if you and new tags to an IOD that are either Private
    > or Standard, it does not automatically mean a Private SOP Class. Many
    > vendors do this already, using the existing SOP Classes.
    >
    > "Doug Sluis" wrote in message news:...
    > > Supplement 63 looks like a good choice for this.
    > > It avoids creating an arbitrary slice representation
    > > that may have little or no utility for clinical display.
    > >
    > > Eventually there will be a complementary
    > > Presentation State standard to enable specifying
    > > preferred 3D views of the multidimensional array
    > > with Supplement 63 SOP instances.
    > >
    > > - Doug
    > >
    > > "jie" wrote in message
    > > news:c6ac7482.0410190610.20609729@posting.google.c om...
    > > > David: Thanks for replying to my post.
    > > >
    > > > Our modality is called Computed Tomography Laser Mammography. The
    > > > system utilizes near-infra red laser and proprietary CT reconstruction
    > > > algorithms to create vascular images of breast without the use of
    > > > x-rays.
    > > >
    > > > If I add our acquisition context and data (different from any other
    > > > modality) to the SC object as private attributes, then the SOP becomes
    > > > a specialized SOP and we need to use a private UID for it. This causes
    > > > it unrecognizable to others. We need to make a decision on whether or
    > > > not to keep most, if not all, of the acquisition context and raw data.
    > > > If not, then the standard or extended SC IOD will be enough to hold
    > > > all necessary information. Question here is does CT or MRI keeps its
    > > > acquisition context and raw data in its IOD? It seems not.
    > > >
    > > > Our image is best viewed in 3-D. We have 3-D visualization software
    > > > built in the modality. Most frequently we handle a stack of slices as
    > > > a volume or a 3-D data set, so multi-frame IODs make more sense for
    > > > us. Secondary Capture can be multi-frame. How about Supplement 63
    > > > Multi-Dimensional Interchange (ND IOD)? I noticed it is modality
    > > > independent too. It seems a good candidate for us too. The current
    > > > status of this draft is Public Comment. When will it be finalized and
    > > > formally released? Any major change expected?
    > > >
    > > > Besides SC and ND, is there any other image IOD that is modality
    > > > neutral?
    > > >
    > > > Also, thanks for pointing out the WG15 to me. We'll make inquiry on
    > > > that too.
    > > >
    > > > -Jie
    > > >
    > > >
    > > > David Clunie wrote in message
    > > > news:<416FE271.7000002@dclunie.com>...
    > > >> jie wrote:
    > > >>
    > > >> > We developed a new modality for breast imaging and want to make it
    > > >> > DICOM compliant in some level, e.g. transfering image for viewing or
    > > >> > archive, importing modality worklist, DICOM printing, etc. The problem
    > > >> > is at present time, our modality name is unknown to the industry yet
    > > >> > and of course not included in the DICOM standard. Even if we can send
    > > >> > out the DICOM message to the netwotk anyway, since the modality name
    > > >> > won't be identified by the recipient, the message will be discarded.
    > > >> > How do people usually do to introduce a NEW modality to DICOM
    > > >> > community?
    > > >> >
    > > >> > My understanding is that we can do the followings initially:
    > > >> > 1. Send our image over DICOM network as secondary capture (maybe
    > > >> > multi-frame) with modality attribute filled as OT (other). This way,
    > > >> > at least those DICOM viewing workstations that support Secondary
    > > >> > Capture can display our image.
    > > >>
    > > >> This is the mechanism that will allow the majority of PACS and
    > > >> viewers to display your images, as long as they are encoded with
    > > >> a reasonable set of pixel parameters (bit depth, etc.).
    > > >>
    > > >> You can use ANY value for Modality you like ... it does not have
    > > >> to be OT ... for example if your modality was Optical Coherence
    > > >> Tomography you could make up and use your own Modality term of
    > > >> "OCT". This would be much more useful than using "OT" which is
    > > >> completely useless to anyone. The Secondary Capture IODs are
    > > >> very flexible in terms of what you can encode in the Modality
    > > >> attribute.
    > > >>
    > > >> If you need to encode additional information (e.g. cross-sectional
    > > >> image positioning with the Image Plane and Frame of Reference
    > > >> modules), you can add standard attributes to the SC SOP Class
    > > >> as a "Standard Extended" SOP Class ... this is harmless to ordinary
    > > >> standard implementations and may gain you additional functionality
    > > >> in standard viewers.
    > > >>
    > > >> To add additional information that is not in the standard yet,
    > > >> you can add private attributes or coded entries in Acquisition
    > > >> Context.
    > > >>
    > > >> > 2. Build our own private SOP class, implement whatever functionalities
    > > >> > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    > > >> > in our DICOM conformance statement and hoping venders in the industry
    > > >> > will support our private SOP later someday when our new modality
    > > >> > becomes popular. By that time we can expect that our modality and SOP
    > > >> > specification will be adopted in the DICOM standard.
    > > >>
    > > >> You should avoid a private image SOP class if you can, because then
    > > >> many archives won't store it and many viewers won't display it, since
    > > >> they won't be able to recognize the SOP Class or that it is an image
    > > >> (as opposed to another kind of SOP Class like a query or whatever).
    > > >>
    > > >> In the interim, you should approach the DICOM Committee with a proposal
    > > >> to create a new standard object for your modality.
    > > >>
    > > >> What is the new modality by the way ?
    > > >>
    > > >> If it has to do with the breast, then WG 15 is the appropriate group
    > > >> to work with on this.
    > > >>
    > > >> David


  7. Re: How to make a new modality DICOM compliant?

    Hi Dave,
    Unfortunately the Enhanced CT IOD is CT specific.
    The pixel value interpretation is xray absorbance
    and therefore not appropriate.
    - Doug

    dmcnamara@vitalimages.com (David McNamara) wrote in message news:...
    > A couple of issues you should be aware of if you decide to use the
    > approach in Supplement 63 are that since it is not standard, you would
    > have to use a Private SOP Class, thus affecting your interoperability.
    > Also, since it is only in Public Comment, the contents could change
    > significantly, depending on the comments.
    >
    > What about using the Enhanced CT IOD (Supplement 58, now standard)?
    > It is already multi-frame, and inherently 3D, and you could just pull
    > in other standard tags as needed, or add your own Private tags...
    > And, by the way, if you and new tags to an IOD that are either Private
    > or Standard, it does not automatically mean a Private SOP Class. Many
    > vendors do this already, using the existing SOP Classes.
    >
    > "Doug Sluis" wrote in message news:...
    > > Supplement 63 looks like a good choice for this.
    > > It avoids creating an arbitrary slice representation
    > > that may have little or no utility for clinical display.
    > >
    > > Eventually there will be a complementary
    > > Presentation State standard to enable specifying
    > > preferred 3D views of the multidimensional array
    > > with Supplement 63 SOP instances.
    > >
    > > - Doug
    > >
    > > "jie" wrote in message
    > > news:c6ac7482.0410190610.20609729@posting.google.c om...
    > > > David: Thanks for replying to my post.
    > > >
    > > > Our modality is called Computed Tomography Laser Mammography. The
    > > > system utilizes near-infra red laser and proprietary CT reconstruction
    > > > algorithms to create vascular images of breast without the use of
    > > > x-rays.
    > > >
    > > > If I add our acquisition context and data (different from any other
    > > > modality) to the SC object as private attributes, then the SOP becomes
    > > > a specialized SOP and we need to use a private UID for it. This causes
    > > > it unrecognizable to others. We need to make a decision on whether or
    > > > not to keep most, if not all, of the acquisition context and raw data.
    > > > If not, then the standard or extended SC IOD will be enough to hold
    > > > all necessary information. Question here is does CT or MRI keeps its
    > > > acquisition context and raw data in its IOD? It seems not.
    > > >
    > > > Our image is best viewed in 3-D. We have 3-D visualization software
    > > > built in the modality. Most frequently we handle a stack of slices as
    > > > a volume or a 3-D data set, so multi-frame IODs make more sense for
    > > > us. Secondary Capture can be multi-frame. How about Supplement 63
    > > > Multi-Dimensional Interchange (ND IOD)? I noticed it is modality
    > > > independent too. It seems a good candidate for us too. The current
    > > > status of this draft is Public Comment. When will it be finalized and
    > > > formally released? Any major change expected?
    > > >
    > > > Besides SC and ND, is there any other image IOD that is modality
    > > > neutral?
    > > >
    > > > Also, thanks for pointing out the WG15 to me. We'll make inquiry on
    > > > that too.
    > > >
    > > > -Jie
    > > >
    > > >
    > > > David Clunie wrote in message
    > > > news:<416FE271.7000002@dclunie.com>...
    > > >> jie wrote:
    > > >>
    > > >> > We developed a new modality for breast imaging and want to make it
    > > >> > DICOM compliant in some level, e.g. transfering image for viewing or
    > > >> > archive, importing modality worklist, DICOM printing, etc. The problem
    > > >> > is at present time, our modality name is unknown to the industry yet
    > > >> > and of course not included in the DICOM standard. Even if we can send
    > > >> > out the DICOM message to the netwotk anyway, since the modality name
    > > >> > won't be identified by the recipient, the message will be discarded.
    > > >> > How do people usually do to introduce a NEW modality to DICOM
    > > >> > community?
    > > >> >
    > > >> > My understanding is that we can do the followings initially:
    > > >> > 1. Send our image over DICOM network as secondary capture (maybe
    > > >> > multi-frame) with modality attribute filled as OT (other). This way,
    > > >> > at least those DICOM viewing workstations that support Secondary
    > > >> > Capture can display our image.
    > > >>
    > > >> This is the mechanism that will allow the majority of PACS and
    > > >> viewers to display your images, as long as they are encoded with
    > > >> a reasonable set of pixel parameters (bit depth, etc.).
    > > >>
    > > >> You can use ANY value for Modality you like ... it does not have
    > > >> to be OT ... for example if your modality was Optical Coherence
    > > >> Tomography you could make up and use your own Modality term of
    > > >> "OCT". This would be much more useful than using "OT" which is
    > > >> completely useless to anyone. The Secondary Capture IODs are
    > > >> very flexible in terms of what you can encode in the Modality
    > > >> attribute.
    > > >>
    > > >> If you need to encode additional information (e.g. cross-sectional
    > > >> image positioning with the Image Plane and Frame of Reference
    > > >> modules), you can add standard attributes to the SC SOP Class
    > > >> as a "Standard Extended" SOP Class ... this is harmless to ordinary
    > > >> standard implementations and may gain you additional functionality
    > > >> in standard viewers.
    > > >>
    > > >> To add additional information that is not in the standard yet,
    > > >> you can add private attributes or coded entries in Acquisition
    > > >> Context.
    > > >>
    > > >> > 2. Build our own private SOP class, implement whatever functionalities
    > > >> > we want to have with this SOP, e.g. Storage SCU, SCP, etc. publish it
    > > >> > in our DICOM conformance statement and hoping venders in the industry
    > > >> > will support our private SOP later someday when our new modality
    > > >> > becomes popular. By that time we can expect that our modality and SOP
    > > >> > specification will be adopted in the DICOM standard.
    > > >>
    > > >> You should avoid a private image SOP class if you can, because then
    > > >> many archives won't store it and many viewers won't display it, since
    > > >> they won't be able to recognize the SOP Class or that it is an image
    > > >> (as opposed to another kind of SOP Class like a query or whatever).
    > > >>
    > > >> In the interim, you should approach the DICOM Committee with a proposal
    > > >> to create a new standard object for your modality.
    > > >>
    > > >> What is the new modality by the way ?
    > > >>
    > > >> If it has to do with the breast, then WG 15 is the appropriate group
    > > >> to work with on this.
    > > >>
    > > >> David


+ Reply to Thread