SNOMED and Slicer color tables

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

SNOMED and Slicer color tables

Andrey Fedorov
Hi,

Do we have any of the color tables in Slicer that were designed
specifically to contain a subset of SNOMED terms?
(http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html) If not,
does it make sense to add one?

We will probably need at least a subset of SNOMED terms for one of the
modules/projects, since SNOMED terms are used to refer to the
structures referenced in DICOM (see http://dabsoft.ch/dicom/16/8.1/).
Of course, we can add these SNOMED items as a list within the module
and keep it local. But I am thinking whether the concept of color
table can be extended to maintain association with a standardized
vocabulary and mapping to the vocabulary term IDs from the table
element ID? This would be yet another step towards improving
compatibility of 3D Slicer with the commercial and clinical systems.

AF
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: SNOMED and Slicer color tables

Halle, Michael Wilfred,Ph.D.
Andrily,

Aligning Slicer color tables with names from controlled vocabularies
such as SNOMED, RadLex (used by AIM, I believe), and FMA is one of the
primary research focuses of the computational clinical anatomy core in
NAC.  We have some brain binding to other ontologies you might be able
to use.

Here's the few things that make your specific request less that
straightforward:

* SNOMED is huge (Slicer distribution sized, as I recall).  Subsetting
isn't trivial.

* UMLS, which includes SNOMED, is under a license that prevents
re-distribution in whole and requires use reporting, which makes it
somewhat difficult to work with in a collaborative environment.

* UMLS is only one of the vocabularies available for naming structures.
It is highly detailed, but contains only limited relations to other
structures.  We've focused primarily on medical ontologies instead
because they provide richer context than thesauruses like UMLS.  Your
use case is a good counterexample, though.

* Slicer color tables are an imperfect mechanism for storing this kind
of information, as you hint.  We haven't come up with an obvious
alternative way to map metadata to labels and models inside Slicer that
would be both easy to use and not break everything.

* One of the challenges to anatomical labeling as you describe is that
Slicer labels are non-overlapping.  You can't, for instance, label
"brain" without unioning all the substructures.  I've got ideas for how
to do that, but it's different from the current labeling concept.

I've got some ideas in mind for helping people quickly search SNOMED to
find the terms they want, making interactive construction of LUTs or
LUT-like lists easier.

I'd be happy to talk with you more -- this is an area that's attracting
more and more interest.

--Mike


On 4/3/12 11:24 AM, Andriy Fedorov wrote:

> Hi,
>
> Do we have any of the color tables in Slicer that were designed
> specifically to contain a subset of SNOMED terms?
> (http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html) If not,
> does it make sense to add one?
>
> We will probably need at least a subset of SNOMED terms for one of the
> modules/projects, since SNOMED terms are used to refer to the
> structures referenced in DICOM (see http://dabsoft.ch/dicom/16/8.1/).
> Of course, we can add these SNOMED items as a list within the module
> and keep it local. But I am thinking whether the concept of color
> table can be extended to maintain association with a standardized
> vocabulary and mapping to the vocabulary term IDs from the table
> element ID? This would be yet another step towards improving
> compatibility of 3D Slicer with the commercial and clinical systems.
>
> AF
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: SNOMED and Slicer color tables

Andrey Fedorov
On Tue, Apr 3, 2012 at 11:48 AM, Michael Halle <[hidden email]> wrote:
> Aligning Slicer color tables with names from controlled vocabularies
> such as SNOMED, RadLex (used by AIM, I believe), and FMA is one of the
> primary research focuses of the computational clinical anatomy core in
> NAC.  We have some brain binding to other ontologies you might be able
> to use.
>

Of interest, DICOM is not restricted to using SNOMED. It can reference
Radlex, and also it supports custom code scheme designators, so it is
not unthinkable to have a customized Slicer vocabulary that can be
referenced from DICOM.

> Here's the few things that make your specific request less that
> straightforward:
>
> * SNOMED is huge (Slicer distribution sized, as I recall).  Subsetting
> isn't trivial.
>

I agree, but in a sense, subsetting has already happened in the Labels
color table and Slicer anatomical atlas color table. I am pretty sure
that each of the terms in these labels has a mapping in SNOMED. So the
missing piece is to review these two and *somehow* preserve entity
codes to the table entries, and *somehow* reference SNOMED as the code
scheme designator, if color table is appropriate place for this. Would
it be allowed by the licensing agreement of SNOMED to include those
codes in Slicer?

> * One of the challenges to anatomical labeling as you describe is that
> Slicer labels are non-overlapping.  You can't, for instance, label
> "brain" without unioning all the substructures.  I've got ideas for how
> to do that, but it's different from the current labeling concept.
>

As I just learned recently, the way labels are stored in DICOM
segmentation objects does not have this restriction. You can have
multiple labels that would overlap and would be stored as a collection
of bitmaps in a single DICOM object. It seems that existing support
for labels + hierarchies + linkage to the source DICOM series can map
well into DICOM seg object (and this is what we are trying to do in
our annotation/markup support project), so this should be one problem
less.

> I've got some ideas in mind for helping people quickly search SNOMED to
> find the terms they want, making interactive construction of LUTs or
> LUT-like lists easier.
>
> I'd be happy to talk with you more -- this is an area that's attracting
> more and more interest.
>

Yes, it would be great to discuss this with you. I will email you
outside the list to arrange a meeting. I am thinking we will have
somewhat similar, although hopefully simplified requirements compared
to NAC onthology goals.


> --Mike
>
>
> On 4/3/12 11:24 AM, Andriy Fedorov wrote:
>> Hi,
>>
>> Do we have any of the color tables in Slicer that were designed
>> specifically to contain a subset of SNOMED terms?
>> (http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html) If not,
>> does it make sense to add one?
>>
>> We will probably need at least a subset of SNOMED terms for one of the
>> modules/projects, since SNOMED terms are used to refer to the
>> structures referenced in DICOM (see http://dabsoft.ch/dicom/16/8.1/).
>> Of course, we can add these SNOMED items as a list within the module
>> and keep it local. But I am thinking whether the concept of color
>> table can be extended to maintain association with a standardized
>> vocabulary and mapping to the vocabulary term IDs from the table
>> element ID? This would be yet another step towards improving
>> compatibility of 3D Slicer with the commercial and clinical systems.
>>
>> AF
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: SNOMED and Slicer color tables

madanrao
Hello,

>* SNOMED is huge (Slicer distribution sized, as I recall).  Subsetting
> isn't trivial.

I think it is not that difficult to subset SNOMED concepts suitable for Slicer. Also, one can build the module as an internet application, like Protege which uses UMLS online.

>UMLS, which includes SNOMED, is under a license that prevents
>re-distribution in whole and requires use reporting, which makes it
>somewhat difficult to work with in a collaborative environment.....

I have been using both SNOMED,UMLS (and Slicer) for several years now from India and
It only requires some 15 mts of online filing of reports annually. On licensing UMLS with Slicer, one can choose a group of databases from UMLS and build a source data by subsetting those concepts suitable for Slicer.

Slicer already uses Graphviz. So it can be used to show these ontologies in a graphical fashion.

I hope this helps.

AM Mohan Rao


On Tue, Apr 3, 2012 at 10:05 PM, Andriy Fedorov <[hidden email]> wrote:
On Tue, Apr 3, 2012 at 11:48 AM, Michael Halle <[hidden email]> wrote:
> Aligning Slicer color tables with names from controlled vocabularies
> such as SNOMED, RadLex (used by AIM, I believe), and FMA is one of the
> primary research focuses of the computational clinical anatomy core in
> NAC.  We have some brain binding to other ontologies you might be able
> to use.
>

Of interest, DICOM is not restricted to using SNOMED. It can reference
Radlex, and also it supports custom code scheme designators, so it is
not unthinkable to have a customized Slicer vocabulary that can be
referenced from DICOM.

> Here's the few things that make your specific request less that
> straightforward:
>
> * SNOMED is huge (Slicer distribution sized, as I recall).  Subsetting
> isn't trivial.
>

I agree, but in a sense, subsetting has already happened in the Labels
color table and Slicer anatomical atlas color table. I am pretty sure
that each of the terms in these labels has a mapping in SNOMED. So the
missing piece is to review these two and *somehow* preserve entity
codes to the table entries, and *somehow* reference SNOMED as the code
scheme designator, if color table is appropriate place for this. Would
it be allowed by the licensing agreement of SNOMED to include those
codes in Slicer?

> * One of the challenges to anatomical labeling as you describe is that
> Slicer labels are non-overlapping.  You can't, for instance, label
> "brain" without unioning all the substructures.  I've got ideas for how
> to do that, but it's different from the current labeling concept.
>

As I just learned recently, the way labels are stored in DICOM
segmentation objects does not have this restriction. You can have
multiple labels that would overlap and would be stored as a collection
of bitmaps in a single DICOM object. It seems that existing support
for labels + hierarchies + linkage to the source DICOM series can map
well into DICOM seg object (and this is what we are trying to do in
our annotation/markup support project), so this should be one problem
less.

> I've got some ideas in mind for helping people quickly search SNOMED to
> find the terms they want, making interactive construction of LUTs or
> LUT-like lists easier.
>
> I'd be happy to talk with you more -- this is an area that's attracting
> more and more interest.
>

Yes, it would be great to discuss this with you. I will email you
outside the list to arrange a meeting. I am thinking we will have
somewhat similar, although hopefully simplified requirements compared
to NAC onthology goals.


> --Mike
>
>
> On 4/3/12 11:24 AM, Andriy Fedorov wrote:
>> Hi,
>>
>> Do we have any of the color tables in Slicer that were designed
>> specifically to contain a subset of SNOMED terms?
>> (http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html) If not,
>> does it make sense to add one?
>>
>> We will probably need at least a subset of SNOMED terms for one of the
>> modules/projects, since SNOMED terms are used to refer to the
>> structures referenced in DICOM (see http://dabsoft.ch/dicom/16/8.1/).
>> Of course, we can add these SNOMED items as a list within the module
>> and keep it local. But I am thinking whether the concept of color
>> table can be extended to maintain association with a standardized
>> vocabulary and mapping to the vocabulary term IDs from the table
>> element ID? This would be yet another step towards improving
>> compatibility of 3D Slicer with the commercial and clinical systems.
>>
>> AF
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject