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

jie wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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

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 <dclunie@dclunie.com> wrote in message news:<416FE271.7000002@dclunie.com>...[color=blue]
> jie wrote:
>[color=green]
> > 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.[/color]
>
> 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.
>[color=green]
> > 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.[/color]
>
> 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[/color]

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" <jiemailbox2003@yahoo.com> wrote in message
news:c6ac7482.0410190610.20609729@posting.google.com...[color=blue]
> 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 <dclunie@dclunie.com> wrote in message
> news:<416FE271.7000002@dclunie.com>...[color=green]
>> jie wrote:
>>[color=darkred]
>> > 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.[/color]
>>
>> 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.
>>[color=darkred]
>> > 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.[/color]
>>
>> 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[/color][/color]

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" <dsluis@clinical-knowledge.com> wrote in message news:<xpadd.2722$EP4.758@trnddc06>...[color=blue]
> 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" <jiemailbox2003@yahoo.com> wrote in message
> news:c6ac7482.0410190610.20609729@posting.google.com...[color=green]
> > 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 <dclunie@dclunie.com> wrote in message
> > news:<416FE271.7000002@dclunie.com>...[color=darkred]
> >> 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[/color][/color][/color]

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


[email]dmcnamara@vitalimages.com[/email] (David McNamara) wrote in message news:<c7a39e47.0410210743.11d7670e@posting.google.com>...[color=blue]
> 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" <dsluis@clinical-knowledge.com> wrote in message news:<xpadd.2722$EP4.758@trnddc06>...[color=green]
> > 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" <jiemailbox2003@yahoo.com> wrote in message
> > news:c6ac7482.0410190610.20609729@posting.google.com...[color=darkred]
> > > 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 <dclunie@dclunie.com> 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[/color][/color][/color]

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

[email]dmcnamara@vitalimages.com[/email] (David McNamara) wrote in message news:<c7a39e47.0410210743.11d7670e@posting.google.com>...[color=blue]
> 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" <dsluis@clinical-knowledge.com> wrote in message news:<xpadd.2722$EP4.758@trnddc06>...[color=green]
> > 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" <jiemailbox2003@yahoo.com> wrote in message
> > news:c6ac7482.0410190610.20609729@posting.google.com...[color=darkred]
> > > 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 <dclunie@dclunie.com> 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[/color][/color][/color]