Terminologies and Segment Editor

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

Re: Terminologies and Segment Editor

Andrey Fedorov-2
Guys,

I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
this in a separate call.

Should we do it during Slicer weekly hangout?Is everyone ok for the
decisions to wait until then?

AF

On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]> wrote:

> Hi Fernando and Andrey,
>
> Easy things first:
> "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName, will my terminology still be valid?"
> Yes, at least in the scope of the current Slicer implementation.
>
> Now about the custom terminologies. With the proposed converter I quickly drafted, which falls in the second "easy" approach Andrey mentioned, we would probably further increase complexity and decrease interoperability. We talked with Andras, and I think we found a relatively easy-to-implement way for the "proper" approach, in the form of the quick lists that we have been planning all along, albeit a slightly different design.
>
> Basically instead of curating custom json dictionaries, we'd mainly use the default ones defined already in Slicer, and save the quick lists (presets/templates/etc.) to csv files, containing the detailed terminology information similarly to how it's already stored for each segment, see attached file to see its proposed structure. It would be these csv files that are read automatically from disk when starting Slicer, stored in a private scene (exactly for the analogy of the volume rendering presets). The easiest way to store these quick lists in the private scene are dummy segmentation nodes, with the segments being the quick list items storing all terminology information but no image or other data. The user could create new quick lists and edit existing ones in the Terminologies module, by selecting entries in the terminology navigator widget (which appears when double-clicking the color for a segment, and is basically the Terminologies module UI currently), and adding/setting the selection to the selected segment in the quick list table. After the quick list is defined, when the user double-clicks color in Segment editor or Segmentations, the quick list would pop up (under quick list selector combobox), with all terminology controls present but by default collapsed (in case he wants to select something that is not in the quick list). These details can be worked out later.
>
> Fernando's dog and cat use case could be accommodated by creating new Json dictionaries, that can also be used to populate a quick list.
>
> The advantage of this plan is that it addresses the use cases we already discussed, and would be relatively easy to implement. Also it wouldn't introduce new formats, and wouldn't create completely new dictionaries from every color table as my previous suggestion would have.
>
> Please let me know what you think.
>
> csaba
>
> -----Original Message-----
> From: Andrey Fedorov [mailto:[hidden email]]
> Sent: Friday, January 20, 2017 10:23
> To: Fernando Pérez-García <[hidden email]>
> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
> Subject: Re: [slicer-users] Terminologies and Segment Editor
>
> Fernando, Csaba,
>
> As the background, let me explain where existing segmentation contexts are coming from.
>
> The first context
> https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
> contains all (or most) of the segmentation category/type codes listed in DICOM part 16 as of some point in the past. It was created based on earlier work by David Clunie, who either manually or semi-automatically looked at the context groups in DICOM part 16, and extracted the information from the tables like this one [1] for example (and you can see many more CIDs with segmentation types here [2]), into the form we used for JSON.
>
> As you can see from [1], that table defines the mapping of the SRT coding scheme code into the other codes that are listed in the JSON context document. The purpose of this mapping is to enable cross-linking of the concepts across different terminologies/ontologies. So "contextGroupName", "UMLSConceptID", "cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition like [1].
>
> One challenge in this translation task is that you need to have domain knowledge and put manual effort into defining certain aspects, since for example, Modifier is applicable only for structures that have laterality, and that part is not explicitly reflected in the CID tables. This domain knowledge is what adds "Modifier" part of the segmentation context.
>
> Segmentation property categories are defined by this table [3], and "showAnatomy" flag assigned for each Category is also something that is not formalized by the standard, but is "domain knowledge" (or "black magic", depending how you want to call it!). That flag tells if it makes sense to give user an option to define anatomic location for the given segmentation, and those in turn are formalized by this anatomic context:
>
> The second, smaller segmentation context https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
> was created very painstakingly by going over the Slicer GenericAnatomyLUT [4] (which only containted freetext labels and
> colors) and mapping those one by one to either an existing concept in the standard, or finding the concept in SNOMED, which resulted in [5].
> The SNOMED concepts that were needed to describe labels in the Slicer GenericAnatomyLUT but were missing in DICOM were added in this correction proposal to the standard [6]. We kept "3dSlicerLabel"
> attribute to maintain the link to the LUT. RGB color in both contexts is mapped from that LUT.
>
> One more thing that you need to understand is what CodingSchemeDesignator means. These refer to lists of codes maintained by specific entities/organizations. You can find the list of coding schemes that are used in DICOM in [7].
>
> With that background, if you are still with me, let me get to your question. I think there are two approaches:
>
> 1. "Proper/painful" approach: follow the process we used to map Slicer LUT to DICOM/SNOMED codes. For each item you have in your list, look for the same/similar in DICOM part 16, and create something that looks similar to Slicer segmentation/category type JSON. This approach will take time (depending on the length of your list), but is your best shot at interoperability and helping other people make sense out of your data.
>
> 2. "Easy" approach: as defined in [7], you can establish your own coding scheme (pick your own name for CodingSchemeDesignator that starts with 99), and define unique codes for each of the items in your list under your coding scheme. This approach can be used to formalize data collection within your group, if you don't have time/expertise/desire to follow approach 1.
>
> Does this help at all?
>
> Sorry about very limited documentation. We are working on it. I should probably add the explanation above somewhere to the documentation of dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location for the documentation that maintains these segmentation contexts).
>
> You forgot to attach your LUT to your earlier email.
>
> AF
>
>
>
> [1] example of segmentation property type CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
> [2] DICOM part 16:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
> [3] segmentation property categories CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
> [4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
> [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
> [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
> [7] coding schemes:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>
> On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García <[hidden email]> wrote:
>>
>>
>> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>>
>>> Hi Fernando,
>>>
>>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>>> emitted when the item itself is changed, not the selection, but
>>> currentIndexChanged or itemSelectionChanged are good candidates.
>>> Unfortunately I hit a few problems and then we had to leave for the
>>> project week, but was planning to look into that again.
>>
>>
>> Right, I actually meant itemActivated().
>>
>>
>>>
>>> I wanted to wait for the RapidJson switch before I touch
>>> terminologies again, but as I see it was integrated last night, so I can start now.
>>>
>>> About the color table to terminology conversion, there could be a
>>> reasonable way of doing that automatically if this operation is
>>> expected to be needed frequently in the future. There are only three
>>> fields that are
>>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>>> are two more that are used: 3dSlicerLabel to automatically set the
>>> segment name (if absent, it is set, but it is assembled from the type
>>> and region information), and recommendedDisplayRGBValue to set the segment color.
>>
>>
>> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> contextGroupName, will my terminology still be valid?
>>
>>
>>>
>>> I think we could write a converter that takes a color table and
>>> creates the terminology context:
>>> - Context name to be the name of the color table
>>> - As there is no category information in the color table, there could
>>> be only one category with the same name as the context
>>> - Type entries from the colors
>>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>>   - recommendedDisplayRGBValue from the color
>>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>>> used, but naively I'd set the context name here as well)
>>> - No type modifiers
>>> - As region information comes from a different dictionary, it could
>>> be used as it is now. The only decision to make is whether the
>>> terminology enables region information at all. It can be done by
>>> setting the category element showAnatomy (true to enable).
>>>
>>> I can implement this converter option in the Terminologies module if
>>> others agree on its utility. The details are subject to discussion of
>>> course.
>>
>>
>> I think this + some documentation would be very useful!
>>
>> Fernando
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> csaba
>>>
>>> -----Original Message-----
>>> From: slicer-users [mailto:[hidden email]] On
>>> Behalf Of Fernando Pérez-García
>>> Sent: Friday, January 20, 2017 05:21
>>> To: SPL Slicer Users <[hidden email]>
>>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>>
>>> Hi again,
>>>
>>> I have created my terminology and I'm happy to see that it works as
>>> expected. The widget is very elegant.
>>>
>>> Yesterday was pretty much the first time in my life I opened a JSON
>>> file and I don't understand most of the fields in Slicer
>>> terminologies files, so I decided to just copy one of the defaults
>>> and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
>>> fields are wrong, but I guess it doesn't matter for my project. I
>>> have attached my little terminology.
>>>
>>> I have a larger color table I would like to transform into a
>>> terminology, but with all those codes I'm not sure how I'm going to do it.
>>>
>>>
>>> When there are many types, I think it would be useful to update the
>>> modifiers combo box when moving using the keyboard instead of
>>> clicking on the mouse. I don't know much about C++ either, but I've
>>> dug a bit and I guess the change would be using the "itemChanged"
>>> signal instead of "itemClicked" [1, 2].
>>>
>>>
>>> Fernando
>>>
>>>
>>> [1]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L218
>>> [2]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L1443
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>>> archive at Nabble.com.
>>> _______________________________________________
>>> 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
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Steve Pieper-2
Sounds like a great topic for the developer hangout if that's convenient for everyone.

-Steve

On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov <[hidden email]> wrote:
Guys,

I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
this in a separate call.

Should we do it during Slicer weekly hangout?Is everyone ok for the
decisions to wait until then?

AF

On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]> wrote:
> Hi Fernando and Andrey,
>
> Easy things first:
> "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName, will my terminology still be valid?"
> Yes, at least in the scope of the current Slicer implementation.
>
> Now about the custom terminologies. With the proposed converter I quickly drafted, which falls in the second "easy" approach Andrey mentioned, we would probably further increase complexity and decrease interoperability. We talked with Andras, and I think we found a relatively easy-to-implement way for the "proper" approach, in the form of the quick lists that we have been planning all along, albeit a slightly different design.
>
> Basically instead of curating custom json dictionaries, we'd mainly use the default ones defined already in Slicer, and save the quick lists (presets/templates/etc.) to csv files, containing the detailed terminology information similarly to how it's already stored for each segment, see attached file to see its proposed structure. It would be these csv files that are read automatically from disk when starting Slicer, stored in a private scene (exactly for the analogy of the volume rendering presets). The easiest way to store these quick lists in the private scene are dummy segmentation nodes, with the segments being the quick list items storing all terminology information but no image or other data. The user could create new quick lists and edit existing ones in the Terminologies module, by selecting entries in the terminology navigator widget (which appears when double-clicking the color for a segment, and is basically the Terminologies module UI currently), and adding/setting the selection to the selected segment in the quick list table. After the quick list is defined, when the user double-clicks color in Segment editor or Segmentations, the quick list would pop up (under quick list selector combobox), with all terminology controls present but by default collapsed (in case he wants to select something that is not in the quick list). These details can be worked out later.
>
> Fernando's dog and cat use case could be accommodated by creating new Json dictionaries, that can also be used to populate a quick list.
>
> The advantage of this plan is that it addresses the use cases we already discussed, and would be relatively easy to implement. Also it wouldn't introduce new formats, and wouldn't create completely new dictionaries from every color table as my previous suggestion would have.
>
> Please let me know what you think.
>
> csaba
>
> -----Original Message-----
> From: Andrey Fedorov [mailto:[hidden email]]
> Sent: Friday, January 20, 2017 10:23
> To: Fernando Pérez-García <[hidden email]>
> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
> Subject: Re: [slicer-users] Terminologies and Segment Editor
>
> Fernando, Csaba,
>
> As the background, let me explain where existing segmentation contexts are coming from.
>
> The first context
> https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
> contains all (or most) of the segmentation category/type codes listed in DICOM part 16 as of some point in the past. It was created based on earlier work by David Clunie, who either manually or semi-automatically looked at the context groups in DICOM part 16, and extracted the information from the tables like this one [1] for example (and you can see many more CIDs with segmentation types here [2]), into the form we used for JSON.
>
> As you can see from [1], that table defines the mapping of the SRT coding scheme code into the other codes that are listed in the JSON context document. The purpose of this mapping is to enable cross-linking of the concepts across different terminologies/ontologies. So "contextGroupName", "UMLSConceptID", "cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition like [1].
>
> One challenge in this translation task is that you need to have domain knowledge and put manual effort into defining certain aspects, since for example, Modifier is applicable only for structures that have laterality, and that part is not explicitly reflected in the CID tables. This domain knowledge is what adds "Modifier" part of the segmentation context.
>
> Segmentation property categories are defined by this table [3], and "showAnatomy" flag assigned for each Category is also something that is not formalized by the standard, but is "domain knowledge" (or "black magic", depending how you want to call it!). That flag tells if it makes sense to give user an option to define anatomic location for the given segmentation, and those in turn are formalized by this anatomic context:
>
> The second, smaller segmentation context https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
> was created very painstakingly by going over the Slicer GenericAnatomyLUT [4] (which only containted freetext labels and
> colors) and mapping those one by one to either an existing concept in the standard, or finding the concept in SNOMED, which resulted in [5].
> The SNOMED concepts that were needed to describe labels in the Slicer GenericAnatomyLUT but were missing in DICOM were added in this correction proposal to the standard [6]. We kept "3dSlicerLabel"
> attribute to maintain the link to the LUT. RGB color in both contexts is mapped from that LUT.
>
> One more thing that you need to understand is what CodingSchemeDesignator means. These refer to lists of codes maintained by specific entities/organizations. You can find the list of coding schemes that are used in DICOM in [7].
>
> With that background, if you are still with me, let me get to your question. I think there are two approaches:
>
> 1. "Proper/painful" approach: follow the process we used to map Slicer LUT to DICOM/SNOMED codes. For each item you have in your list, look for the same/similar in DICOM part 16, and create something that looks similar to Slicer segmentation/category type JSON. This approach will take time (depending on the length of your list), but is your best shot at interoperability and helping other people make sense out of your data.
>
> 2. "Easy" approach: as defined in [7], you can establish your own coding scheme (pick your own name for CodingSchemeDesignator that starts with 99), and define unique codes for each of the items in your list under your coding scheme. This approach can be used to formalize data collection within your group, if you don't have time/expertise/desire to follow approach 1.
>
> Does this help at all?
>
> Sorry about very limited documentation. We are working on it. I should probably add the explanation above somewhere to the documentation of dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location for the documentation that maintains these segmentation contexts).
>
> You forgot to attach your LUT to your earlier email.
>
> AF
>
>
>
> [1] example of segmentation property type CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
> [2] DICOM part 16:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
> [3] segmentation property categories CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
> [4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
> [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
> [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
> [7] coding schemes:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>
> On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García <[hidden email]> wrote:
>>
>>
>> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>>
>>> Hi Fernando,
>>>
>>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>>> emitted when the item itself is changed, not the selection, but
>>> currentIndexChanged or itemSelectionChanged are good candidates.
>>> Unfortunately I hit a few problems and then we had to leave for the
>>> project week, but was planning to look into that again.
>>
>>
>> Right, I actually meant itemActivated().
>>
>>
>>>
>>> I wanted to wait for the RapidJson switch before I touch
>>> terminologies again, but as I see it was integrated last night, so I can start now.
>>>
>>> About the color table to terminology conversion, there could be a
>>> reasonable way of doing that automatically if this operation is
>>> expected to be needed frequently in the future. There are only three
>>> fields that are
>>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>>> are two more that are used: 3dSlicerLabel to automatically set the
>>> segment name (if absent, it is set, but it is assembled from the type
>>> and region information), and recommendedDisplayRGBValue to set the segment color.
>>
>>
>> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> contextGroupName, will my terminology still be valid?
>>
>>
>>>
>>> I think we could write a converter that takes a color table and
>>> creates the terminology context:
>>> - Context name to be the name of the color table
>>> - As there is no category information in the color table, there could
>>> be only one category with the same name as the context
>>> - Type entries from the colors
>>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>>   - recommendedDisplayRGBValue from the color
>>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>>> used, but naively I'd set the context name here as well)
>>> - No type modifiers
>>> - As region information comes from a different dictionary, it could
>>> be used as it is now. The only decision to make is whether the
>>> terminology enables region information at all. It can be done by
>>> setting the category element showAnatomy (true to enable).
>>>
>>> I can implement this converter option in the Terminologies module if
>>> others agree on its utility. The details are subject to discussion of
>>> course.
>>
>>
>> I think this + some documentation would be very useful!
>>
>> Fernando
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> csaba
>>>
>>> -----Original Message-----
>>> From: slicer-users [mailto:[hidden email]] On
>>> Behalf Of Fernando Pérez-García
>>> Sent: Friday, January 20, 2017 05:21
>>> To: SPL Slicer Users <[hidden email]>
>>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>>
>>> Hi again,
>>>
>>> I have created my terminology and I'm happy to see that it works as
>>> expected. The widget is very elegant.
>>>
>>> Yesterday was pretty much the first time in my life I opened a JSON
>>> file and I don't understand most of the fields in Slicer
>>> terminologies files, so I decided to just copy one of the defaults
>>> and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
>>> fields are wrong, but I guess it doesn't matter for my project. I
>>> have attached my little terminology.
>>>
>>> I have a larger color table I would like to transform into a
>>> terminology, but with all those codes I'm not sure how I'm going to do it.
>>>
>>>
>>> When there are many types, I think it would be useful to update the
>>> modifiers combo box when moving using the keyboard instead of
>>> clicking on the mouse. I don't know much about C++ either, but I've
>>> dug a bit and I guess the change would be using the "itemChanged"
>>> signal instead of "itemClicked" [1, 2].
>>>
>>>
>>> Fernando
>>>
>>>
>>> [1]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L218
>>> [2]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L1443
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>>> archive at Nabble.com.
>>> _______________________________________________
>>> 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
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ


_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Andrey Fedorov-2

Hi Fernando,

 

I added keyboard support for the terminology widget (and fixed other minor bugs).

 

See you and the others tomorrow at the hangout!

 

csaba

 

From: Steve Pieper [mailto:[hidden email]]
Sent: Friday, January 20, 2017 11:17
To: Andrey Fedorov <[hidden email]>
Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

 

Sounds like a great topic for the developer hangout if that's convenient for everyone.

 

-Steve

 

On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov <[hidden email]> wrote:

Guys,

I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
this in a separate call.

Should we do it during Slicer weekly hangout?Is everyone ok for the
decisions to wait until then?

AF

On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]> wrote:
> Hi Fernando and Andrey,
>
> Easy things first:
> "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName, will my terminology still be valid?"
> Yes, at least in the scope of the current Slicer implementation.
>
> Now about the custom terminologies. With the proposed converter I quickly drafted, which falls in the second "easy" approach Andrey mentioned, we would probably further increase complexity and decrease interoperability. We talked with Andras, and I think we found a relatively easy-to-implement way for the "proper" approach, in the form of the quick lists that we have been planning all along, albeit a slightly different design.
>
> Basically instead of curating custom json dictionaries, we'd mainly use the default ones defined already in Slicer, and save the quick lists (presets/templates/etc.) to csv files, containing the detailed terminology information similarly to how it's already stored for each segment, see attached file to see its proposed structure. It would be these csv files that are read automatically from disk when starting Slicer, stored in a private scene (exactly for the analogy of the volume rendering presets). The easiest way to store these quick lists in the private scene are dummy segmentation nodes, with the segments being the quick list items storing all terminology information but no image or other data. The user could create new quick lists and edit existing ones in the Terminologies module, by selecting entries in the terminology navigator widget (which appears when double-clicking the color for a segment, and is basically the Terminologies module UI currently), and adding/setting the selection to the selected segment in the quick list table. After the quick list is defined, when the user double-clicks color in Segment editor or Segmentations, the quick list would pop up (under quick list selector combobox), with all terminology controls present but by default collapsed (in case he wants to select something that is not in the quick list). These details can be worked out later.
>
> Fernando's dog and cat use case could be accommodated by creating new Json dictionaries, that can also be used to populate a quick list.
>
> The advantage of this plan is that it addresses the use cases we already discussed, and would be relatively easy to implement. Also it wouldn't introduce new formats, and wouldn't create completely new dictionaries from every color table as my previous suggestion would have.
>
> Please let me know what you think.
>
> csaba
>
> -----Original Message-----
> From: Andrey Fedorov [mailto:[hidden email]]
> Sent: Friday, January 20, 2017 10:23
> To: Fernando Pérez-García <[hidden email]>
> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
> Subject: Re: [slicer-users] Terminologies and Segment Editor
>

> Fernando, Csaba,
>
> As the background, let me explain where existing segmentation contexts are coming from.
>
> The first context
> https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
> contains all (or most) of the segmentation category/type codes listed in DICOM part 16 as of some point in the past. It was created based on earlier work by David Clunie, who either manually or semi-automatically looked at the context groups in DICOM part 16, and extracted the information from the tables like this one [1] for example (and you can see many more CIDs with segmentation types here [2]), into the form we used for JSON.
>
> As you can see from [1], that table defines the mapping of the SRT coding scheme code into the other codes that are listed in the JSON context document. The purpose of this mapping is to enable cross-linking of the concepts across different terminologies/ontologies. So "contextGroupName", "UMLSConceptID", "cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition like [1].
>
> One challenge in this translation task is that you need to have domain knowledge and put manual effort into defining certain aspects, since for example, Modifier is applicable only for structures that have laterality, and that part is not explicitly reflected in the CID tables. This domain knowledge is what adds "Modifier" part of the segmentation context.
>
> Segmentation property categories are defined by this table [3], and "showAnatomy" flag assigned for each Category is also something that is not formalized by the standard, but is "domain knowledge" (or "black magic", depending how you want to call it!). That flag tells if it makes sense to give user an option to define anatomic location for the given segmentation, and those in turn are formalized by this anatomic context:
>
> The second, smaller segmentation context https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
> was created very painstakingly by going over the Slicer GenericAnatomyLUT [4] (which only containted freetext labels and
> colors) and mapping those one by one to either an existing concept in the standard, or finding the concept in SNOMED, which resulted in [5].
> The SNOMED concepts that were needed to describe labels in the Slicer GenericAnatomyLUT but were missing in DICOM were added in this correction proposal to the standard [6]. We kept "3dSlicerLabel"
> attribute to maintain the link to the LUT. RGB color in both contexts is mapped from that LUT.
>
> One more thing that you need to understand is what CodingSchemeDesignator means. These refer to lists of codes maintained by specific entities/organizations. You can find the list of coding schemes that are used in DICOM in [7].
>
> With that background, if you are still with me, let me get to your question. I think there are two approaches:
>
> 1. "Proper/painful" approach: follow the process we used to map Slicer LUT to DICOM/SNOMED codes. For each item you have in your list, look for the same/similar in DICOM part 16, and create something that looks similar to Slicer segmentation/category type JSON. This approach will take time (depending on the length of your list), but is your best shot at interoperability and helping other people make sense out of your data.
>
> 2. "Easy" approach: as defined in [7], you can establish your own coding scheme (pick your own name for CodingSchemeDesignator that starts with 99), and define unique codes for each of the items in your list under your coding scheme. This approach can be used to formalize data collection within your group, if you don't have time/expertise/desire to follow approach 1.
>
> Does this help at all?
>
> Sorry about very limited documentation. We are working on it. I should probably add the explanation above somewhere to the documentation of dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location for the documentation that maintains these segmentation contexts).
>
> You forgot to attach your LUT to your earlier email.
>
> AF
>
>
>
> [1] example of segmentation property type CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
> [2] DICOM part 16:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
> [3] segmentation property categories CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
> [4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
> [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
> [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
> [7] coding schemes:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>

> On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García <[hidden email]> wrote:
>>
>>
>> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>>
>>> Hi Fernando,
>>>
>>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>>> emitted when the item itself is changed, not the selection, but
>>> currentIndexChanged or itemSelectionChanged are good candidates.
>>> Unfortunately I hit a few problems and then we had to leave for the
>>> project week, but was planning to look into that again.
>>
>>
>> Right, I actually meant itemActivated().
>>
>>
>>>
>>> I wanted to wait for the RapidJson switch before I touch
>>> terminologies again, but as I see it was integrated last night, so I can start now.
>>>
>>> About the color table to terminology conversion, there could be a
>>> reasonable way of doing that automatically if this operation is
>>> expected to be needed frequently in the future. There are only three
>>> fields that are
>>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>>> are two more that are used: 3dSlicerLabel to automatically set the
>>> segment name (if absent, it is set, but it is assembled from the type
>>> and region information), and recommendedDisplayRGBValue to set the segment color.
>>
>>
>> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> contextGroupName, will my terminology still be valid?
>>
>>
>>>
>>> I think we could write a converter that takes a color table and
>>> creates the terminology context:
>>> - Context name to be the name of the color table
>>> - As there is no category information in the color table, there could
>>> be only one category with the same name as the context
>>> - Type entries from the colors
>>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>>   - recommendedDisplayRGBValue from the color
>>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>>> used, but naively I'd set the context name here as well)
>>> - No type modifiers
>>> - As region information comes from a different dictionary, it could
>>> be used as it is now. The only decision to make is whether the
>>> terminology enables region information at all. It can be done by
>>> setting the category element showAnatomy (true to enable).
>>>
>>> I can implement this converter option in the Terminologies module if
>>> others agree on its utility. The details are subject to discussion of
>>> course.
>>
>>
>> I think this + some documentation would be very useful!
>>
>> Fernando
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> csaba
>>>
>>> -----Original Message-----
>>> From: slicer-users [mailto:[hidden email]] On
>>> Behalf Of Fernando Pérez-García
>>> Sent: Friday, January 20, 2017 05:21
>>> To: SPL Slicer Users <[hidden email]>
>>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>>
>>> Hi again,
>>>
>>> I have created my terminology and I'm happy to see that it works as
>>> expected. The widget is very elegant.
>>>
>>> Yesterday was pretty much the first time in my life I opened a JSON
>>> file and I don't understand most of the fields in Slicer
>>> terminologies files, so I decided to just copy one of the defaults
>>> and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
>>> fields are wrong, but I guess it doesn't matter for my project. I
>>> have attached my little terminology.
>>>
>>> I have a larger color table I would like to transform into a
>>> terminology, but with all those codes I'm not sure how I'm going to do it.
>>>
>>>
>>> When there are many types, I think it would be useful to update the
>>> modifiers combo box when moving using the keyboard instead of
>>> clicking on the mouse. I don't know much about C++ either, but I've
>>> dug a bit and I guess the change would be using the "itemChanged"
>>> signal instead of "itemClicked" [1, 2].
>>>
>>>
>>> Fernando
>>>
>>>
>>> [1]
>>>

>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L218
>>> [2]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L1443
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list

>>> archive at Nabble.com.
>>> _______________________________________________
>>> 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
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

 


_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
Hi Csaba,

That's good, thanks. I have already generated my larger terminology from a csv file. I can share the Python code if someone wants to take a look.

I'm not sure if I'll make it tomorrow at the hangout. I'll read the conclusions later.


Fernando

2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:

Hi Fernando,

 

I added keyboard support for the terminology widget (and fixed other minor bugs).

 

See you and the others tomorrow at the hangout!

 

csaba

 

From: Steve Pieper [mailto:[hidden email]]
Sent: Friday, January 20, 2017 11:17
To: Andrey Fedorov <[hidden email]>
Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

 

Sounds like a great topic for the developer hangout if that's convenient for everyone.

 

-Steve

 

On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov <[hidden email]> wrote:

Guys,

I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
this in a separate call.

Should we do it during Slicer weekly hangout?Is everyone ok for the
decisions to wait until then?

AF

On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]> wrote:

> Hi Fernando and Andrey,
>
> Easy things first:
> "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and contextGroupName, will my terminology still be valid?"
> Yes, at least in the scope of the current Slicer implementation.
>
> Now about the custom terminologies. With the proposed converter I quickly drafted, which falls in the second "easy" approach Andrey mentioned, we would probably further increase complexity and decrease interoperability. We talked with Andras, and I think we found a relatively easy-to-implement way for the "proper" approach, in the form of the quick lists that we have been planning all along, albeit a slightly different design.
>
> Basically instead of curating custom json dictionaries, we'd mainly use the default ones defined already in Slicer, and save the quick lists (presets/templates/etc.) to csv files, containing the detailed terminology information similarly to how it's already stored for each segment, see attached file to see its proposed structure. It would be these csv files that are read automatically from disk when starting Slicer, stored in a private scene (exactly for the analogy of the volume rendering presets). The easiest way to store these quick lists in the private scene are dummy segmentation nodes, with the segments being the quick list items storing all terminology information but no image or other data. The user could create new quick lists and edit existing ones in the Terminologies module, by selecting entries in the terminology navigator widget (which appears when double-clicking the color for a segment, and is basically the Terminologies module UI currently), and adding/setting the selection to the selected segment in the quick list table. After the quick list is defined, when the user double-clicks color in Segment editor or Segmentations, the quick list would pop up (under quick list selector combobox), with all terminology controls present but by default collapsed (in case he wants to select something that is not in the quick list). These details can be worked out later.
>
> Fernando's dog and cat use case could be accommodated by creating new Json dictionaries, that can also be used to populate a quick list.
>
> The advantage of this plan is that it addresses the use cases we already discussed, and would be relatively easy to implement. Also it wouldn't introduce new formats, and wouldn't create completely new dictionaries from every color table as my previous suggestion would have.
>
> Please let me know what you think.
>
> csaba
>
> -----Original Message-----
> From: Andrey Fedorov [mailto:[hidden email]]
> Sent: Friday, January 20, 2017 10:23
> To: Fernando Pérez-García <[hidden email]>
> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users <[hidden email]>
> Subject: Re: [slicer-users] Terminologies and Segment Editor
>

> Fernando, Csaba,
>
> As the background, let me explain where existing segmentation contexts are coming from.
>
> The first context
> https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
> contains all (or most) of the segmentation category/type codes listed in DICOM part 16 as of some point in the past. It was created based on earlier work by David Clunie, who either manually or semi-automatically looked at the context groups in DICOM part 16, and extracted the information from the tables like this one [1] for example (and you can see many more CIDs with segmentation types here [2]), into the form we used for JSON.
>
> As you can see from [1], that table defines the mapping of the SRT coding scheme code into the other codes that are listed in the JSON context document. The purpose of this mapping is to enable cross-linking of the concepts across different terminologies/ontologies. So "contextGroupName", "UMLSConceptID", "cid", "CodeValue", "CodeMeaning", "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition like [1].
>
> One challenge in this translation task is that you need to have domain knowledge and put manual effort into defining certain aspects, since for example, Modifier is applicable only for structures that have laterality, and that part is not explicitly reflected in the CID tables. This domain knowledge is what adds "Modifier" part of the segmentation context.
>
> Segmentation property categories are defined by this table [3], and "showAnatomy" flag assigned for each Category is also something that is not formalized by the standard, but is "domain knowledge" (or "black magic", depending how you want to call it!). That flag tells if it makes sense to give user an option to define anatomic location for the given segmentation, and those in turn are formalized by this anatomic context:
>
> The second, smaller segmentation context https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
> was created very painstakingly by going over the Slicer GenericAnatomyLUT [4] (which only containted freetext labels and
> colors) and mapping those one by one to either an existing concept in the standard, or finding the concept in SNOMED, which resulted in [5].
> The SNOMED concepts that were needed to describe labels in the Slicer GenericAnatomyLUT but were missing in DICOM were added in this correction proposal to the standard [6]. We kept "3dSlicerLabel"
> attribute to maintain the link to the LUT. RGB color in both contexts is mapped from that LUT.
>
> One more thing that you need to understand is what CodingSchemeDesignator means. These refer to lists of codes maintained by specific entities/organizations. You can find the list of coding schemes that are used in DICOM in [7].
>
> With that background, if you are still with me, let me get to your question. I think there are two approaches:
>
> 1. "Proper/painful" approach: follow the process we used to map Slicer LUT to DICOM/SNOMED codes. For each item you have in your list, look for the same/similar in DICOM part 16, and create something that looks similar to Slicer segmentation/category type JSON. This approach will take time (depending on the length of your list), but is your best shot at interoperability and helping other people make sense out of your data.
>
> 2. "Easy" approach: as defined in [7], you can establish your own coding scheme (pick your own name for CodingSchemeDesignator that starts with 99), and define unique codes for each of the items in your list under your coding scheme. This approach can be used to formalize data collection within your group, if you don't have time/expertise/desire to follow approach 1.
>
> Does this help at all?
>
> Sorry about very limited documentation. We are working on it. I should probably add the explanation above somewhere to the documentation of dcmqi here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location for the documentation that maintains these segmentation contexts).
>
> You forgot to attach your LUT to your earlier email.
>
> AF
>
>
>
> [1] example of segmentation property type CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
> [2] DICOM part 16:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
> [3] segmentation property categories CID:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
> [4] https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
> [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
> [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
> [7] coding schemes:
> http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>

> On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García <[hidden email]> wrote:
>>
>>
>> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>>>
>>> Hi Fernando,
>>>
>>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>>> emitted when the item itself is changed, not the selection, but
>>> currentIndexChanged or itemSelectionChanged are good candidates.
>>> Unfortunately I hit a few problems and then we had to leave for the
>>> project week, but was planning to look into that again.
>>
>>
>> Right, I actually meant itemActivated().
>>
>>
>>>
>>> I wanted to wait for the RapidJson switch before I touch
>>> terminologies again, but as I see it was integrated last night, so I can start now.
>>>
>>> About the color table to terminology conversion, there could be a
>>> reasonable way of doing that automatically if this operation is
>>> expected to be needed frequently in the future. There are only three
>>> fields that are
>>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>>> are two more that are used: 3dSlicerLabel to automatically set the
>>> segment name (if absent, it is set, but it is assembled from the type
>>> and region information), and recommendedDisplayRGBValue to set the segment color.
>>
>>
>> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> contextGroupName, will my terminology still be valid?
>>
>>
>>>
>>> I think we could write a converter that takes a color table and
>>> creates the terminology context:
>>> - Context name to be the name of the color table
>>> - As there is no category information in the color table, there could
>>> be only one category with the same name as the context
>>> - Type entries from the colors
>>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>>>   - recommendedDisplayRGBValue from the color
>>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>>> used, but naively I'd set the context name here as well)
>>> - No type modifiers
>>> - As region information comes from a different dictionary, it could
>>> be used as it is now. The only decision to make is whether the
>>> terminology enables region information at all. It can be done by
>>> setting the category element showAnatomy (true to enable).
>>>
>>> I can implement this converter option in the Terminologies module if
>>> others agree on its utility. The details are subject to discussion of
>>> course.
>>
>>
>> I think this + some documentation would be very useful!
>>
>> Fernando
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> csaba
>>>
>>> -----Original Message-----
>>> From: slicer-users [mailto:[hidden email]] On
>>> Behalf Of Fernando Pérez-García
>>> Sent: Friday, January 20, 2017 05:21
>>> To: SPL Slicer Users <[hidden email]>
>>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>>
>>> Hi again,
>>>
>>> I have created my terminology and I'm happy to see that it works as
>>> expected. The widget is very elegant.
>>>
>>> Yesterday was pretty much the first time in my life I opened a JSON
>>> file and I don't understand most of the fields in Slicer
>>> terminologies files, so I decided to just copy one of the defaults
>>> and edit it. I deleted what I didn't need, edit the names and colors and voilà. All the "contextGroupName"
>>> fields are wrong, but I guess it doesn't matter for my project. I
>>> have attached my little terminology.
>>>
>>> I have a larger color table I would like to transform into a
>>> terminology, but with all those codes I'm not sure how I'm going to do it.
>>>
>>>
>>> When there are many types, I think it would be useful to update the
>>> modifiers combo box when moving using the keyboard instead of
>>> clicking on the mouse. I don't know much about C++ either, but I've
>>> dug a bit and I guess the change would be using the "itemChanged"
>>> signal instead of "itemClicked" [1, 2].
>>>
>>>
>>> Fernando
>>>
>>>
>>> [1]
>>>

>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L218
>>> [2]
>>>
>>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>>> vigatorWidget.cxx#L1443
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list

>>> archive at Nabble.com.
>>> _______________________________________________
>>> 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
>>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

 


_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ


_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
In reply to this post by Csaba Pinter-2
Fernando,

it is unfortunate you cannot join the call.

I looked at the file you shared. I don't know how you generated it,
but you should absolutely NOT use that file. I am afraid my
explanation was not clear.

I only checked few codes, and I see that you changed code meanings for
the existing codes. Example:

"CodeMeaning": "Anatomical structures"

Original CodeMeaning: "Anatomical Structure"

Second item in your file:

            "CodingSchemeDesignator": "SRT",
            "CodeValue": "T-D4000",
            "CodeMeaning": "Cerebral aqueduct"

Original values for that code:

            "CodingSchemeDesignator": "SRT",
            "CodeValue": "T-D4000",   <=== code is identical!
            "CodeMeaning": "Abdomen",

You absolutely cannot change the code meaning for the codes that
belong to an existing official coding scheme!

As I mentioned earlier, you can define your own coding scheme, and use
it as you wish, for example you could do

            "CodingSchemeDesignator": "99FERNANDO",
            "CodeValue": "T-D4000",
            "CodeMeaning": "Cerebral aqueduct"

and that would be fine ("easy" approach from my earlier suggestion).

Or you could search SNOMED and find a code that corresponds to
"Cerebral aqueduct".

But what you do right now is like taking rgb code (255,0,0) and
calling it "Blue"....

AF

On Mon, Jan 23, 2017 at 11:02 AM, Fernando Pérez-García
<[hidden email]> wrote:

> Hi Csaba,
>
> That's good, thanks. I have already generated my larger terminology from a
> csv file. I can share the Python code if someone wants to take a look.
>
> I'm not sure if I'll make it tomorrow at the hangout. I'll read the
> conclusions later.
>
>
> Fernando
>
> 2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:
>>
>> Hi Fernando,
>>
>>
>>
>> I added keyboard support for the terminology widget (and fixed other minor
>> bugs).
>>
>>
>>
>> See you and the others tomorrow at the hangout!
>>
>>
>>
>> csaba
>>
>>
>>
>> From: Steve Pieper [mailto:[hidden email]]
>> Sent: Friday, January 20, 2017 11:17
>> To: Andrey Fedorov <[hidden email]>
>>
>>
>> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> <[hidden email]>
>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>
>>
>>
>> Sounds like a great topic for the developer hangout if that's convenient
>> for everyone.
>>
>>
>>
>> -Steve
>>
>>
>>
>> On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov
>> <[hidden email]> wrote:
>>
>> Guys,
>>
>> I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
>> this in a separate call.
>>
>> Should we do it during Slicer weekly hangout?Is everyone ok for the
>> decisions to wait until then?
>>
>> AF
>>
>> On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]>
>> wrote:
>>
>> > Hi Fernando and Andrey,
>> >
>> > Easy things first:
>> > "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> > contextGroupName, will my terminology still be valid?"
>> > Yes, at least in the scope of the current Slicer implementation.
>> >
>> > Now about the custom terminologies. With the proposed converter I
>> > quickly drafted, which falls in the second "easy" approach Andrey mentioned,
>> > we would probably further increase complexity and decrease interoperability.
>> > We talked with Andras, and I think we found a relatively easy-to-implement
>> > way for the "proper" approach, in the form of the quick lists that we have
>> > been planning all along, albeit a slightly different design.
>> >
>> > Basically instead of curating custom json dictionaries, we'd mainly use
>> > the default ones defined already in Slicer, and save the quick lists
>> > (presets/templates/etc.) to csv files, containing the detailed terminology
>> > information similarly to how it's already stored for each segment, see
>> > attached file to see its proposed structure. It would be these csv files
>> > that are read automatically from disk when starting Slicer, stored in a
>> > private scene (exactly for the analogy of the volume rendering presets). The
>> > easiest way to store these quick lists in the private scene are dummy
>> > segmentation nodes, with the segments being the quick list items storing all
>> > terminology information but no image or other data. The user could create
>> > new quick lists and edit existing ones in the Terminologies module, by
>> > selecting entries in the terminology navigator widget (which appears when
>> > double-clicking the color for a segment, and is basically the Terminologies
>> > module UI currently), and adding/setting the selection to the selected
>> > segment in the quick list table. After the quick list is defined, when the
>> > user double-clicks color in Segment editor or Segmentations, the quick list
>> > would pop up (under quick list selector combobox), with all terminology
>> > controls present but by default collapsed (in case he wants to select
>> > something that is not in the quick list). These details can be worked out
>> > later.
>> >
>> > Fernando's dog and cat use case could be accommodated by creating new
>> > Json dictionaries, that can also be used to populate a quick list.
>> >
>> > The advantage of this plan is that it addresses the use cases we already
>> > discussed, and would be relatively easy to implement. Also it wouldn't
>> > introduce new formats, and wouldn't create completely new dictionaries from
>> > every color table as my previous suggestion would have.
>> >
>> > Please let me know what you think.
>> >
>> > csaba
>> >
>> > -----Original Message-----
>> > From: Andrey Fedorov [mailto:[hidden email]]
>> > Sent: Friday, January 20, 2017 10:23
>> > To: Fernando Pérez-García <[hidden email]>
>> > Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> > <[hidden email]>
>> > Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >
>>
>> > Fernando, Csaba,
>> >
>> > As the background, let me explain where existing segmentation contexts
>> > are coming from.
>> >
>> > The first context
>> >
>> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
>> > contains all (or most) of the segmentation category/type codes listed in
>> > DICOM part 16 as of some point in the past. It was created based on earlier
>> > work by David Clunie, who either manually or semi-automatically looked at
>> > the context groups in DICOM part 16, and extracted the information from the
>> > tables like this one [1] for example (and you can see many more CIDs with
>> > segmentation types here [2]), into the form we used for JSON.
>> >
>> > As you can see from [1], that table defines the mapping of the SRT
>> > coding scheme code into the other codes that are listed in the JSON context
>> > document. The purpose of this mapping is to enable cross-linking of the
>> > concepts across different terminologies/ontologies. So "contextGroupName",
>> > "UMLSConceptID", "cid", "CodeValue", "CodeMeaning",
>> > "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition
>> > like [1].
>> >
>> > One challenge in this translation task is that you need to have domain
>> > knowledge and put manual effort into defining certain aspects, since for
>> > example, Modifier is applicable only for structures that have laterality,
>> > and that part is not explicitly reflected in the CID tables. This domain
>> > knowledge is what adds "Modifier" part of the segmentation context.
>> >
>> > Segmentation property categories are defined by this table [3], and
>> > "showAnatomy" flag assigned for each Category is also something that is not
>> > formalized by the standard, but is "domain knowledge" (or "black magic",
>> > depending how you want to call it!). That flag tells if it makes sense to
>> > give user an option to define anatomic location for the given segmentation,
>> > and those in turn are formalized by this anatomic context:
>> >
>> > The second, smaller segmentation context
>> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
>> > was created very painstakingly by going over the Slicer
>> > GenericAnatomyLUT [4] (which only containted freetext labels and
>> > colors) and mapping those one by one to either an existing concept in
>> > the standard, or finding the concept in SNOMED, which resulted in [5].
>> > The SNOMED concepts that were needed to describe labels in the Slicer
>> > GenericAnatomyLUT but were missing in DICOM were added in this correction
>> > proposal to the standard [6]. We kept "3dSlicerLabel"
>> > attribute to maintain the link to the LUT. RGB color in both contexts is
>> > mapped from that LUT.
>> >
>> > One more thing that you need to understand is what
>> > CodingSchemeDesignator means. These refer to lists of codes maintained by
>> > specific entities/organizations. You can find the list of coding schemes
>> > that are used in DICOM in [7].
>> >
>> > With that background, if you are still with me, let me get to your
>> > question. I think there are two approaches:
>> >
>> > 1. "Proper/painful" approach: follow the process we used to map Slicer
>> > LUT to DICOM/SNOMED codes. For each item you have in your list, look for the
>> > same/similar in DICOM part 16, and create something that looks similar to
>> > Slicer segmentation/category type JSON. This approach will take time
>> > (depending on the length of your list), but is your best shot at
>> > interoperability and helping other people make sense out of your data.
>> >
>> > 2. "Easy" approach: as defined in [7], you can establish your own coding
>> > scheme (pick your own name for CodingSchemeDesignator that starts with 99),
>> > and define unique codes for each of the items in your list under your coding
>> > scheme. This approach can be used to formalize data collection within your
>> > group, if you don't have time/expertise/desire to follow approach 1.
>> >
>> > Does this help at all?
>> >
>> > Sorry about very limited documentation. We are working on it. I should
>> > probably add the explanation above somewhere to the documentation of dcmqi
>> > here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location
>> > for the documentation that maintains these segmentation contexts).
>> >
>> > You forgot to attach your LUT to your earlier email.
>> >
>> > AF
>> >
>> >
>> >
>> > [1] example of segmentation property type CID:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
>> > [2] DICOM part 16:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
>> > [3] segmentation property categories CID:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
>> > [4]
>> > https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
>> > [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
>> > [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
>> > [7] coding schemes:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>> >
>>
>> > On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >>>
>> >>> Hi Fernando,
>> >>>
>> >>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>> >>> emitted when the item itself is changed, not the selection, but
>> >>> currentIndexChanged or itemSelectionChanged are good candidates.
>> >>> Unfortunately I hit a few problems and then we had to leave for the
>> >>> project week, but was planning to look into that again.
>> >>
>> >>
>> >> Right, I actually meant itemActivated().
>> >>
>> >>
>> >>>
>> >>> I wanted to wait for the RapidJson switch before I touch
>> >>> terminologies again, but as I see it was integrated last night, so I
>> >>> can start now.
>> >>>
>> >>> About the color table to terminology conversion, there could be a
>> >>> reasonable way of doing that automatically if this operation is
>> >>> expected to be needed frequently in the future. There are only three
>> >>> fields that are
>> >>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>> >>> are two more that are used: 3dSlicerLabel to automatically set the
>> >>> segment name (if absent, it is set, but it is assembled from the type
>> >>> and region information), and recommendedDisplayRGBValue to set the
>> >>> segment color.
>> >>
>> >>
>> >> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> contextGroupName, will my terminology still be valid?
>> >>
>> >>
>> >>>
>> >>> I think we could write a converter that takes a color table and
>> >>> creates the terminology context:
>> >>> - Context name to be the name of the color table
>> >>> - As there is no category information in the color table, there could
>> >>> be only one category with the same name as the context
>> >>> - Type entries from the colors
>> >>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>> >>>   - recommendedDisplayRGBValue from the color
>> >>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>> >>> used, but naively I'd set the context name here as well)
>> >>> - No type modifiers
>> >>> - As region information comes from a different dictionary, it could
>> >>> be used as it is now. The only decision to make is whether the
>> >>> terminology enables region information at all. It can be done by
>> >>> setting the category element showAnatomy (true to enable).
>> >>>
>> >>> I can implement this converter option in the Terminologies module if
>> >>> others agree on its utility. The details are subject to discussion of
>> >>> course.
>> >>
>> >>
>> >> I think this + some documentation would be very useful!
>> >>
>> >> Fernando
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> csaba
>> >>>
>> >>> -----Original Message-----
>> >>> From: slicer-users [mailto:[hidden email]] On
>> >>> Behalf Of Fernando Pérez-García
>> >>> Sent: Friday, January 20, 2017 05:21
>> >>> To: SPL Slicer Users <[hidden email]>
>> >>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >>>
>> >>> Hi again,
>> >>>
>> >>> I have created my terminology and I'm happy to see that it works as
>> >>> expected. The widget is very elegant.
>> >>>
>> >>> Yesterday was pretty much the first time in my life I opened a JSON
>> >>> file and I don't understand most of the fields in Slicer
>> >>> terminologies files, so I decided to just copy one of the defaults
>> >>> and edit it. I deleted what I didn't need, edit the names and colors
>> >>> and voilà. All the "contextGroupName"
>> >>> fields are wrong, but I guess it doesn't matter for my project. I
>> >>> have attached my little terminology.
>> >>>
>> >>> I have a larger color table I would like to transform into a
>> >>> terminology, but with all those codes I'm not sure how I'm going to do
>> >>> it.
>> >>>
>> >>>
>> >>> When there are many types, I think it would be useful to update the
>> >>> modifiers combo box when moving using the keyboard instead of
>> >>> clicking on the mouse. I don't know much about C++ either, but I've
>> >>> dug a bit and I guess the change would be using the "itemChanged"
>> >>> signal instead of "itemClicked" [1, 2].
>> >>>
>> >>>
>> >>> Fernando
>> >>>
>> >>>
>> >>> [1]
>> >>>
>>
>> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >>> vigatorWidget.cxx#L218
>> >>> [2]
>> >>>
>> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >>> vigatorWidget.cxx#L1443
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>> >>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>>
>> >>> archive at Nabble.com.
>> >>> _______________________________________________
>> >>> 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
>> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Fernando Pérez-García
In reply to this post by Csaba Pinter-2
Hi Andrey,



2017-01-23 17:41 GMT+01:00 Andrey Fedorov <[hidden email]>:
Fernando,

it is unfortunate you cannot join the call.

​I will try to join you, but I don't think my presence would be too useful!

 

 
I looked at the file you shared. I don't know how you generated it,
but you should absolutely NOT use that file. I am afraid my
explanation was not clear.

​I manually edited one of the defaults, before having read your explanation.​ I have attached the new one, and the code I used to generate it from my CSV file.

 

 
You absolutely cannot change the code meaning for the codes that
belong to an existing official coding scheme!

I understand coherence is very important in QIICR, but ​I just needed something fast that worked within the scope of my project. Since this terminology file won't be distributed, I honestly didn't really care much about the codes. I tried an "easy" approach before receiving your message.




But what you do right now is like taking rgb code (255,0,0) and
calling it "Blue"....


​I hope my new approach is not so crazy :)


Fernando​




 
On Mon, Jan 23, 2017 at 11:02 AM, Fernando Pérez-García
<[hidden email]> wrote:
> Hi Csaba,
>
> That's good, thanks. I have already generated my larger terminology from a
> csv file. I can share the Python code if someone wants to take a look.
>
> I'm not sure if I'll make it tomorrow at the hangout. I'll read the
> conclusions later.
>
>
> Fernando
>
> 2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:
>>
>> Hi Fernando,
>>
>>
>>
>> I added keyboard support for the terminology widget (and fixed other minor
>> bugs).
>>
>>
>>
>> See you and the others tomorrow at the hangout!
>>
>>
>>
>> csaba
>>
>>
>>
>> From: Steve Pieper [mailto:[hidden email]]
>> Sent: Friday, January 20, 2017 11:17
>> To: Andrey Fedorov <[hidden email]>
>>
>>
>> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> <[hidden email]>
>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>>
>>
>>
>> Sounds like a great topic for the developer hangout if that's convenient
>> for everyone.
>>
>>
>>
>> -Steve
>>
>>
>>
>> On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov
>> <[hidden email]> wrote:
>>
>> Guys,
>>
>> I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
>> this in a separate call.
>>
>> Should we do it during Slicer weekly hangout?Is everyone ok for the
>> decisions to wait until then?
>>
>> AF
>>
>> On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter <[hidden email]>
>> wrote:
>>
>> > Hi Fernando and Andrey,
>> >
>> > Easy things first:
>> > "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> > contextGroupName, will my terminology still be valid?"
>> > Yes, at least in the scope of the current Slicer implementation.
>> >
>> > Now about the custom terminologies. With the proposed converter I
>> > quickly drafted, which falls in the second "easy" approach Andrey mentioned,
>> > we would probably further increase complexity and decrease interoperability.
>> > We talked with Andras, and I think we found a relatively easy-to-implement
>> > way for the "proper" approach, in the form of the quick lists that we have
>> > been planning all along, albeit a slightly different design.
>> >
>> > Basically instead of curating custom json dictionaries, we'd mainly use
>> > the default ones defined already in Slicer, and save the quick lists
>> > (presets/templates/etc.) to csv files, containing the detailed terminology
>> > information similarly to how it's already stored for each segment, see
>> > attached file to see its proposed structure. It would be these csv files
>> > that are read automatically from disk when starting Slicer, stored in a
>> > private scene (exactly for the analogy of the volume rendering presets). The
>> > easiest way to store these quick lists in the private scene are dummy
>> > segmentation nodes, with the segments being the quick list items storing all
>> > terminology information but no image or other data. The user could create
>> > new quick lists and edit existing ones in the Terminologies module, by
>> > selecting entries in the terminology navigator widget (which appears when
>> > double-clicking the color for a segment, and is basically the Terminologies
>> > module UI currently), and adding/setting the selection to the selected
>> > segment in the quick list table. After the quick list is defined, when the
>> > user double-clicks color in Segment editor or Segmentations, the quick list
>> > would pop up (under quick list selector combobox), with all terminology
>> > controls present but by default collapsed (in case he wants to select
>> > something that is not in the quick list). These details can be worked out
>> > later.
>> >
>> > Fernando's dog and cat use case could be accommodated by creating new
>> > Json dictionaries, that can also be used to populate a quick list.
>> >
>> > The advantage of this plan is that it addresses the use cases we already
>> > discussed, and would be relatively easy to implement. Also it wouldn't
>> > introduce new formats, and wouldn't create completely new dictionaries from
>> > every color table as my previous suggestion would have.
>> >
>> > Please let me know what you think.
>> >
>> > csaba
>> >
>> > -----Original Message-----
>> > From: Andrey Fedorov [mailto:[hidden email]]
>> > Sent: Friday, January 20, 2017 10:23
>> > To: Fernando Pérez-García <[hidden email]>
>> > Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> > <[hidden email]>
>> > Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >
>>
>> > Fernando, Csaba,
>> >
>> > As the background, let me explain where existing segmentation contexts
>> > are coming from.
>> >
>> > The first context
>> >
>> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
>> > contains all (or most) of the segmentation category/type codes listed in
>> > DICOM part 16 as of some point in the past. It was created based on earlier
>> > work by David Clunie, who either manually or semi-automatically looked at
>> > the context groups in DICOM part 16, and extracted the information from the
>> > tables like this one [1] for example (and you can see many more CIDs with
>> > segmentation types here [2]), into the form we used for JSON.
>> >
>> > As you can see from [1], that table defines the mapping of the SRT
>> > coding scheme code into the other codes that are listed in the JSON context
>> > document. The purpose of this mapping is to enable cross-linking of the
>> > concepts across different terminologies/ontologies. So "contextGroupName",
>> > "UMLSConceptID", "cid", "CodeValue", "CodeMeaning",
>> > "CodingSchemeDesignator", "SNOMEDConceptID" all come from the definition
>> > like [1].
>> >
>> > One challenge in this translation task is that you need to have domain
>> > knowledge and put manual effort into defining certain aspects, since for
>> > example, Modifier is applicable only for structures that have laterality,
>> > and that part is not explicitly reflected in the CID tables. This domain
>> > knowledge is what adds "Modifier" part of the segmentation context.
>> >
>> > Segmentation property categories are defined by this table [3], and
>> > "showAnatomy" flag assigned for each Category is also something that is not
>> > formalized by the standard, but is "domain knowledge" (or "black magic",
>> > depending how you want to call it!). That flag tells if it makes sense to
>> > give user an option to define anatomic location for the given segmentation,
>> > and those in turn are formalized by this anatomic context:
>> >
>> > The second, smaller segmentation context
>> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
>> > was created very painstakingly by going over the Slicer
>> > GenericAnatomyLUT [4] (which only containted freetext labels and
>> > colors) and mapping those one by one to either an existing concept in
>> > the standard, or finding the concept in SNOMED, which resulted in [5].
>> > The SNOMED concepts that were needed to describe labels in the Slicer
>> > GenericAnatomyLUT but were missing in DICOM were added in this correction
>> > proposal to the standard [6]. We kept "3dSlicerLabel"
>> > attribute to maintain the link to the LUT. RGB color in both contexts is
>> > mapped from that LUT.
>> >
>> > One more thing that you need to understand is what
>> > CodingSchemeDesignator means. These refer to lists of codes maintained by
>> > specific entities/organizations. You can find the list of coding schemes
>> > that are used in DICOM in [7].
>> >
>> > With that background, if you are still with me, let me get to your
>> > question. I think there are two approaches:
>> >
>> > 1. "Proper/painful" approach: follow the process we used to map Slicer
>> > LUT to DICOM/SNOMED codes. For each item you have in your list, look for the
>> > same/similar in DICOM part 16, and create something that looks similar to
>> > Slicer segmentation/category type JSON. This approach will take time
>> > (depending on the length of your list), but is your best shot at
>> > interoperability and helping other people make sense out of your data.
>> >
>> > 2. "Easy" approach: as defined in [7], you can establish your own coding
>> > scheme (pick your own name for CodingSchemeDesignator that starts with 99),
>> > and define unique codes for each of the items in your list under your coding
>> > scheme. This approach can be used to formalize data collection within your
>> > group, if you don't have time/expertise/desire to follow approach 1.
>> >
>> > Does this help at all?
>> >
>> > Sorry about very limited documentation. We are working on it. I should
>> > probably add the explanation above somewhere to the documentation of dcmqi
>> > here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main location
>> > for the documentation that maintains these segmentation contexts).
>> >
>> > You forgot to attach your LUT to your earlier email.
>> >
>> > AF
>> >
>> >
>> >
>> > [1] example of segmentation property type CID:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
>> > [2] DICOM part 16:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
>> > [3] segmentation property categories CID:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
>> > [4]
>> > https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
>> > [5] https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
>> > [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
>> > [7] coding schemes:
>> >
>> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>> >
>>
>> > On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
>> > <[hidden email]> wrote:
>> >>
>> >>
>> >> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >>>
>> >>> Hi Fernando,
>> >>>
>> >>> I fiddled with the key actions a bit a few weeks ago. itemChanged is
>> >>> emitted when the item itself is changed, not the selection, but
>> >>> currentIndexChanged or itemSelectionChanged are good candidates.
>> >>> Unfortunately I hit a few problems and then we had to leave for the
>> >>> project week, but was planning to look into that again.
>> >>
>> >>
>> >> Right, I actually meant itemActivated().
>> >>
>> >>
>> >>>
>> >>> I wanted to wait for the RapidJson switch before I touch
>> >>> terminologies again, but as I see it was integrated last night, so I
>> >>> can start now.
>> >>>
>> >>> About the color table to terminology conversion, there could be a
>> >>> reasonable way of doing that automatically if this operation is
>> >>> expected to be needed frequently in the future. There are only three
>> >>> fields that are
>> >>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning. There
>> >>> are two more that are used: 3dSlicerLabel to automatically set the
>> >>> segment name (if absent, it is set, but it is assembled from the type
>> >>> and region information), and recommendedDisplayRGBValue to set the
>> >>> segment color.
>> >>
>> >>
>> >> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> contextGroupName, will my terminology still be valid?
>> >>
>> >>
>> >>>
>> >>> I think we could write a converter that takes a color table and
>> >>> creates the terminology context:
>> >>> - Context name to be the name of the color table
>> >>> - As there is no category information in the color table, there could
>> >>> be only one category with the same name as the context
>> >>> - Type entries from the colors
>> >>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>> >>>   - recommendedDisplayRGBValue from the color
>> >>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>> >>> used, but naively I'd set the context name here as well)
>> >>> - No type modifiers
>> >>> - As region information comes from a different dictionary, it could
>> >>> be used as it is now. The only decision to make is whether the
>> >>> terminology enables region information at all. It can be done by
>> >>> setting the category element showAnatomy (true to enable).
>> >>>
>> >>> I can implement this converter option in the Terminologies module if
>> >>> others agree on its utility. The details are subject to discussion of
>> >>> course.
>> >>
>> >>
>> >> I think this + some documentation would be very useful!
>> >>
>> >> Fernando
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>> csaba
>> >>>
>> >>> -----Original Message-----
>> >>> From: slicer-users [mailto:[hidden email]] On
>> >>> Behalf Of Fernando Pérez-García
>> >>> Sent: Friday, January 20, 2017 05:21
>> >>> To: SPL Slicer Users <[hidden email]>
>> >>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >>>
>> >>> Hi again,
>> >>>
>> >>> I have created my terminology and I'm happy to see that it works as
>> >>> expected. The widget is very elegant.
>> >>>
>> >>> Yesterday was pretty much the first time in my life I opened a JSON
>> >>> file and I don't understand most of the fields in Slicer
>> >>> terminologies files, so I decided to just copy one of the defaults
>> >>> and edit it. I deleted what I didn't need, edit the names and colors
>> >>> and voilà. All the "contextGroupName"
>> >>> fields are wrong, but I guess it doesn't matter for my project. I
>> >>> have attached my little terminology.
>> >>>
>> >>> I have a larger color table I would like to transform into a
>> >>> terminology, but with all those codes I'm not sure how I'm going to do
>> >>> it.
>> >>>
>> >>>
>> >>> When there are many types, I think it would be useful to update the
>> >>> modifiers combo box when moving using the keyboard instead of
>> >>> clicking on the mouse. I don't know much about C++ either, but I've
>> >>> dug a bit and I guess the change would be using the "itemChanged"
>> >>> signal instead of "itemClicked" [1, 2].
>> >>>
>> >>>
>> >>> Fernando
>> >>>
>> >>>
>> >>> [1]
>> >>>
>>
>> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >>> vigatorWidget.cxx#L218
>> >>> [2]
>> >>>
>> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >>> vigatorWidget.cxx#L1443
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>> >>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>>
>> >>> archive at Nabble.com.
>> >>> _______________________________________________
>> >>> 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
>> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>>
>>
>>
>>
>> _______________________________________________
>> 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
>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>
>


_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ

makeTerminologyFromCSV.py (3K) Download Attachment
HumanBrainstemTerminology.json (100K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andrey Fedorov-2
In reply to this post by Csaba Pinter-2
> I manually edited one of the defaults, before having read your explanation. I have attached the new one, and the code I used to generate it from my CSV file.

Thanks, this makes more sense!

Note that your "coding scheme" is inconsistent - you have multiple
codes that are different, but have identical meaning (e.g., Left and
Right).

>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care much
> about the codes. I tried an "easy" approach before receiving your message.
>

The issue is not about QIICR, it is about generating inconsistent data
in the situation where it is trivial to make it at least more
consistent (what you did in the updated example you shared).

But I agree you do raise an important issue. It makes sense to have a
convenience script like the one you created to help with conversion
from CSV. The key question is what should be the input format of CSV
it should expect - should it be a flat list, or should it allow for
some hierarchy (specification of laterality, for example, but there
can be other situations where your modifier can be anterior/posterior,
for example, so it might need some flexibility). If there is some
consensus what that CSV should look like, then we could provide a
helper script to generate the terminology file with a "99" prefix
coding scheme designator generated "on the fly".

About the meeting tomorrow, I unfortunately developed a conflict and
most likely won't be able to join...


On Mon, Jan 23, 2017 at 12:23 PM, Fernando Pérez-García
<[hidden email]> wrote:

> Hi Andrey,
>
>
>
> 2017-01-23 17:41 GMT+01:00 Andrey Fedorov <[hidden email]>:
>>
>> Fernando,
>>
>> it is unfortunate you cannot join the call.
>
>
> I will try to join you, but I don't think my presence would be too useful!
>
>
>
>
>>
>> I looked at the file you shared. I don't know how you generated it,
>> but you should absolutely NOT use that file. I am afraid my
>> explanation was not clear.
>
>
> I manually edited one of the defaults, before having read your explanation.
> I have attached the new one, and the code I used to generate it from my CSV
> file.
>
>
>
>
>>
>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care much
> about the codes. I tried an "easy" approach before receiving your message.
>
>
>
>
>> But what you do right now is like taking rgb code (255,0,0) and
>> calling it "Blue"....
>
>
>
> I hope my new approach is not so crazy :)
>
>
> Fernando
>
>
>
>
>
>>
>> On Mon, Jan 23, 2017 at 11:02 AM, Fernando Pérez-García
>> <[hidden email]> wrote:
>> > Hi Csaba,
>> >
>> > That's good, thanks. I have already generated my larger terminology from
>> > a
>> > csv file. I can share the Python code if someone wants to take a look.
>> >
>> > I'm not sure if I'll make it tomorrow at the hangout. I'll read the
>> > conclusions later.
>> >
>> >
>> > Fernando
>> >
>> > 2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >>
>> >> Hi Fernando,
>> >>
>> >>
>> >>
>> >> I added keyboard support for the terminology widget (and fixed other
>> >> minor
>> >> bugs).
>> >>
>> >>
>> >>
>> >> See you and the others tomorrow at the hangout!
>> >>
>> >>
>> >>
>> >> csaba
>> >>
>> >>
>> >>
>> >> From: Steve Pieper [mailto:[hidden email]]
>> >> Sent: Friday, January 20, 2017 11:17
>> >> To: Andrey Fedorov <[hidden email]>
>> >>
>> >>
>> >> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> <[hidden email]>
>> >> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >>
>> >>
>> >>
>> >> Sounds like a great topic for the developer hangout if that's
>> >> convenient
>> >> for everyone.
>> >>
>> >>
>> >>
>> >> -Steve
>> >>
>> >>
>> >>
>> >> On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov
>> >> <[hidden email]> wrote:
>> >>
>> >> Guys,
>> >>
>> >> I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself) discuss
>> >> this in a separate call.
>> >>
>> >> Should we do it during Slicer weekly hangout?Is everyone ok for the
>> >> decisions to wait until then?
>> >>
>> >> AF
>> >>
>> >> On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter
>> >> <[hidden email]>
>> >> wrote:
>> >>
>> >> > Hi Fernando and Andrey,
>> >> >
>> >> > Easy things first:
>> >> > "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> > contextGroupName, will my terminology still be valid?"
>> >> > Yes, at least in the scope of the current Slicer implementation.
>> >> >
>> >> > Now about the custom terminologies. With the proposed converter I
>> >> > quickly drafted, which falls in the second "easy" approach Andrey
>> >> > mentioned,
>> >> > we would probably further increase complexity and decrease
>> >> > interoperability.
>> >> > We talked with Andras, and I think we found a relatively
>> >> > easy-to-implement
>> >> > way for the "proper" approach, in the form of the quick lists that we
>> >> > have
>> >> > been planning all along, albeit a slightly different design.
>> >> >
>> >> > Basically instead of curating custom json dictionaries, we'd mainly
>> >> > use
>> >> > the default ones defined already in Slicer, and save the quick lists
>> >> > (presets/templates/etc.) to csv files, containing the detailed
>> >> > terminology
>> >> > information similarly to how it's already stored for each segment,
>> >> > see
>> >> > attached file to see its proposed structure. It would be these csv
>> >> > files
>> >> > that are read automatically from disk when starting Slicer, stored in
>> >> > a
>> >> > private scene (exactly for the analogy of the volume rendering
>> >> > presets). The
>> >> > easiest way to store these quick lists in the private scene are dummy
>> >> > segmentation nodes, with the segments being the quick list items
>> >> > storing all
>> >> > terminology information but no image or other data. The user could
>> >> > create
>> >> > new quick lists and edit existing ones in the Terminologies module,
>> >> > by
>> >> > selecting entries in the terminology navigator widget (which appears
>> >> > when
>> >> > double-clicking the color for a segment, and is basically the
>> >> > Terminologies
>> >> > module UI currently), and adding/setting the selection to the
>> >> > selected
>> >> > segment in the quick list table. After the quick list is defined,
>> >> > when the
>> >> > user double-clicks color in Segment editor or Segmentations, the
>> >> > quick list
>> >> > would pop up (under quick list selector combobox), with all
>> >> > terminology
>> >> > controls present but by default collapsed (in case he wants to select
>> >> > something that is not in the quick list). These details can be worked
>> >> > out
>> >> > later.
>> >> >
>> >> > Fernando's dog and cat use case could be accommodated by creating new
>> >> > Json dictionaries, that can also be used to populate a quick list.
>> >> >
>> >> > The advantage of this plan is that it addresses the use cases we
>> >> > already
>> >> > discussed, and would be relatively easy to implement. Also it
>> >> > wouldn't
>> >> > introduce new formats, and wouldn't create completely new
>> >> > dictionaries from
>> >> > every color table as my previous suggestion would have.
>> >> >
>> >> > Please let me know what you think.
>> >> >
>> >> > csaba
>> >> >
>> >> > -----Original Message-----
>> >> > From: Andrey Fedorov [mailto:[hidden email]]
>> >> > Sent: Friday, January 20, 2017 10:23
>> >> > To: Fernando Pérez-García <[hidden email]>
>> >> > Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> > <[hidden email]>
>> >> > Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >
>> >>
>> >> > Fernando, Csaba,
>> >> >
>> >> > As the background, let me explain where existing segmentation
>> >> > contexts
>> >> > are coming from.
>> >> >
>> >> > The first context
>> >> >
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json
>> >> > contains all (or most) of the segmentation category/type codes listed
>> >> > in
>> >> > DICOM part 16 as of some point in the past. It was created based on
>> >> > earlier
>> >> > work by David Clunie, who either manually or semi-automatically
>> >> > looked at
>> >> > the context groups in DICOM part 16, and extracted the information
>> >> > from the
>> >> > tables like this one [1] for example (and you can see many more CIDs
>> >> > with
>> >> > segmentation types here [2]), into the form we used for JSON.
>> >> >
>> >> > As you can see from [1], that table defines the mapping of the SRT
>> >> > coding scheme code into the other codes that are listed in the JSON
>> >> > context
>> >> > document. The purpose of this mapping is to enable cross-linking of
>> >> > the
>> >> > concepts across different terminologies/ontologies. So
>> >> > "contextGroupName",
>> >> > "UMLSConceptID", "cid", "CodeValue", "CodeMeaning",
>> >> > "CodingSchemeDesignator", "SNOMEDConceptID" all come from the
>> >> > definition
>> >> > like [1].
>> >> >
>> >> > One challenge in this translation task is that you need to have
>> >> > domain
>> >> > knowledge and put manual effort into defining certain aspects, since
>> >> > for
>> >> > example, Modifier is applicable only for structures that have
>> >> > laterality,
>> >> > and that part is not explicitly reflected in the CID tables. This
>> >> > domain
>> >> > knowledge is what adds "Modifier" part of the segmentation context.
>> >> >
>> >> > Segmentation property categories are defined by this table [3], and
>> >> > "showAnatomy" flag assigned for each Category is also something that
>> >> > is not
>> >> > formalized by the standard, but is "domain knowledge" (or "black
>> >> > magic",
>> >> > depending how you want to call it!). That flag tells if it makes
>> >> > sense to
>> >> > give user an option to define anatomic location for the given
>> >> > segmentation,
>> >> > and those in turn are formalized by this anatomic context:
>> >> >
>> >> > The second, smaller segmentation context
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json
>> >> > was created very painstakingly by going over the Slicer
>> >> > GenericAnatomyLUT [4] (which only containted freetext labels and
>> >> > colors) and mapping those one by one to either an existing concept in
>> >> > the standard, or finding the concept in SNOMED, which resulted in
>> >> > [5].
>> >> > The SNOMED concepts that were needed to describe labels in the Slicer
>> >> > GenericAnatomyLUT but were missing in DICOM were added in this
>> >> > correction
>> >> > proposal to the standard [6]. We kept "3dSlicerLabel"
>> >> > attribute to maintain the link to the LUT. RGB color in both contexts
>> >> > is
>> >> > mapped from that LUT.
>> >> >
>> >> > One more thing that you need to understand is what
>> >> > CodingSchemeDesignator means. These refer to lists of codes
>> >> > maintained by
>> >> > specific entities/organizations. You can find the list of coding
>> >> > schemes
>> >> > that are used in DICOM in [7].
>> >> >
>> >> > With that background, if you are still with me, let me get to your
>> >> > question. I think there are two approaches:
>> >> >
>> >> > 1. "Proper/painful" approach: follow the process we used to map
>> >> > Slicer
>> >> > LUT to DICOM/SNOMED codes. For each item you have in your list, look
>> >> > for the
>> >> > same/similar in DICOM part 16, and create something that looks
>> >> > similar to
>> >> > Slicer segmentation/category type JSON. This approach will take time
>> >> > (depending on the length of your list), but is your best shot at
>> >> > interoperability and helping other people make sense out of your
>> >> > data.
>> >> >
>> >> > 2. "Easy" approach: as defined in [7], you can establish your own
>> >> > coding
>> >> > scheme (pick your own name for CodingSchemeDesignator that starts
>> >> > with 99),
>> >> > and define unique codes for each of the items in your list under your
>> >> > coding
>> >> > scheme. This approach can be used to formalize data collection within
>> >> > your
>> >> > group, if you don't have time/expertise/desire to follow approach 1.
>> >> >
>> >> > Does this help at all?
>> >> >
>> >> > Sorry about very limited documentation. We are working on it. I
>> >> > should
>> >> > probably add the explanation above somewhere to the documentation of
>> >> > dcmqi
>> >> > here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the main
>> >> > location
>> >> > for the documentation that maintains these segmentation contexts).
>> >> >
>> >> > You forgot to attach your LUT to your earlier email.
>> >> >
>> >> > AF
>> >> >
>> >> >
>> >> >
>> >> > [1] example of segmentation property type CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7152.html#table_CID_7152
>> >> > [2] DICOM part 16:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/PS3.16.html
>> >> > [3] segmentation property categories CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7150.html
>> >> > [4]
>> >> >
>> >> > https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/LookupTables/GenericAnatomyColors
>> >> > [5]
>> >> > https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporting
>> >> > [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
>> >> > [7] coding schemes:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_8.html
>> >> >
>> >>
>> >> > On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >>
>> >> >> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >> >>>
>> >> >>> Hi Fernando,
>> >> >>>
>> >> >>> I fiddled with the key actions a bit a few weeks ago. itemChanged
>> >> >>> is
>> >> >>> emitted when the item itself is changed, not the selection, but
>> >> >>> currentIndexChanged or itemSelectionChanged are good candidates.
>> >> >>> Unfortunately I hit a few problems and then we had to leave for the
>> >> >>> project week, but was planning to look into that again.
>> >> >>
>> >> >>
>> >> >> Right, I actually meant itemActivated().
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I wanted to wait for the RapidJson switch before I touch
>> >> >>> terminologies again, but as I see it was integrated last night, so
>> >> >>> I
>> >> >>> can start now.
>> >> >>>
>> >> >>> About the color table to terminology conversion, there could be a
>> >> >>> reasonable way of doing that automatically if this operation is
>> >> >>> expected to be needed frequently in the future. There are only
>> >> >>> three
>> >> >>> fields that are
>> >> >>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning.
>> >> >>> There
>> >> >>> are two more that are used: 3dSlicerLabel to automatically set the
>> >> >>> segment name (if absent, it is set, but it is assembled from the
>> >> >>> type
>> >> >>> and region information), and recommendedDisplayRGBValue to set the
>> >> >>> segment color.
>> >> >>
>> >> >>
>> >> >> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> >> contextGroupName, will my terminology still be valid?
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I think we could write a converter that takes a color table and
>> >> >>> creates the terminology context:
>> >> >>> - Context name to be the name of the color table
>> >> >>> - As there is no category information in the color table, there
>> >> >>> could
>> >> >>> be only one category with the same name as the context
>> >> >>> - Type entries from the colors
>> >> >>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>> >> >>>   - recommendedDisplayRGBValue from the color
>> >> >>>   - CodingSchemeDesignator TBD (I don't know enough about how it's
>> >> >>> used, but naively I'd set the context name here as well)
>> >> >>> - No type modifiers
>> >> >>> - As region information comes from a different dictionary, it could
>> >> >>> be used as it is now. The only decision to make is whether the
>> >> >>> terminology enables region information at all. It can be done by
>> >> >>> setting the category element showAnatomy (true to enable).
>> >> >>>
>> >> >>> I can implement this converter option in the Terminologies module
>> >> >>> if
>> >> >>> others agree on its utility. The details are subject to discussion
>> >> >>> of
>> >> >>> course.
>> >> >>
>> >> >>
>> >> >> I think this + some documentation would be very useful!
>> >> >>
>> >> >> Fernando
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> csaba
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: slicer-users [mailto:[hidden email]] On
>> >> >>> Behalf Of Fernando Pérez-García
>> >> >>> Sent: Friday, January 20, 2017 05:21
>> >> >>> To: SPL Slicer Users <[hidden email]>
>> >> >>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >>>
>> >> >>> Hi again,
>> >> >>>
>> >> >>> I have created my terminology and I'm happy to see that it works as
>> >> >>> expected. The widget is very elegant.
>> >> >>>
>> >> >>> Yesterday was pretty much the first time in my life I opened a JSON
>> >> >>> file and I don't understand most of the fields in Slicer
>> >> >>> terminologies files, so I decided to just copy one of the defaults
>> >> >>> and edit it. I deleted what I didn't need, edit the names and
>> >> >>> colors
>> >> >>> and voilà. All the "contextGroupName"
>> >> >>> fields are wrong, but I guess it doesn't matter for my project. I
>> >> >>> have attached my little terminology.
>> >> >>>
>> >> >>> I have a larger color table I would like to transform into a
>> >> >>> terminology, but with all those codes I'm not sure how I'm going to
>> >> >>> do
>> >> >>> it.
>> >> >>>
>> >> >>>
>> >> >>> When there are many types, I think it would be useful to update the
>> >> >>> modifiers combo box when moving using the keyboard instead of
>> >> >>> clicking on the mouse. I don't know much about C++ either, but I've
>> >> >>> dug a bit and I guess the change would be using the "itemChanged"
>> >> >>> signal instead of "itemClicked" [1, 2].
>> >> >>>
>> >> >>>
>> >> >>> Fernando
>> >> >>>
>> >> >>>
>> >> >>> [1]
>> >> >>>
>> >>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >> >>> vigatorWidget.cxx#L218
>> >> >>> [2]
>> >> >>>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe073c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTerminologyNa
>> >> >>> vigatorWidget.cxx#L1443
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> View this message in context:
>> >> >>>
>> >> >>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segment-Edi
>> >> >>> tor-tp4031210p4031631.html Sent from the slicer-users mailing list
>> >>
>> >> >>> archive at Nabble.com.
>> >> >>> _______________________________________________
>> >> >>> 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
>> >> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >
>> >
>
>
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Csaba Pinter-2
In reply to this post by Csaba Pinter-2
In that case I suggest we reschedule the terminology meeting to another time.

If we have a converter that creates non-standard terminologies (what I also suggested earlier as a quick&dirty solution), then supporting ctbl files would also be important I think.

csaba

-----Original Message-----
From: Andrey Fedorov [mailto:[hidden email]]
Sent: Monday, January 23, 2017 12:48
To: Fernando Pérez-García <[hidden email]>
Cc: Csaba Pinter <[hidden email]>; Steve Pieper <[hidden email]>; SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

> I manually edited one of the defaults, before having read your explanation. I have attached the new one, and the code I used to generate it from my CSV file.

Thanks, this makes more sense!

Note that your "coding scheme" is inconsistent - you have multiple codes that are different, but have identical meaning (e.g., Left and Right).

>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care
> much about the codes. I tried an "easy" approach before receiving your message.
>

The issue is not about QIICR, it is about generating inconsistent data in the situation where it is trivial to make it at least more consistent (what you did in the updated example you shared).

But I agree you do raise an important issue. It makes sense to have a convenience script like the one you created to help with conversion from CSV. The key question is what should be the input format of CSV it should expect - should it be a flat list, or should it allow for some hierarchy (specification of laterality, for example, but there can be other situations where your modifier can be anterior/posterior, for example, so it might need some flexibility). If there is some consensus what that CSV should look like, then we could provide a helper script to generate the terminology file with a "99" prefix coding scheme designator generated "on the fly".

About the meeting tomorrow, I unfortunately developed a conflict and most likely won't be able to join...


On Mon, Jan 23, 2017 at 12:23 PM, Fernando Pérez-García <[hidden email]> wrote:

> Hi Andrey,
>
>
>
> 2017-01-23 17:41 GMT+01:00 Andrey Fedorov <[hidden email]>:
>>
>> Fernando,
>>
>> it is unfortunate you cannot join the call.
>
>
> I will try to join you, but I don't think my presence would be too useful!
>
>
>
>
>>
>> I looked at the file you shared. I don't know how you generated it,
>> but you should absolutely NOT use that file. I am afraid my
>> explanation was not clear.
>
>
> I manually edited one of the defaults, before having read your explanation.
> I have attached the new one, and the code I used to generate it from
> my CSV file.
>
>
>
>
>>
>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care
> much about the codes. I tried an "easy" approach before receiving your message.
>
>
>
>
>> But what you do right now is like taking rgb code (255,0,0) and
>> calling it "Blue"....
>
>
>
> I hope my new approach is not so crazy :)
>
>
> Fernando
>
>
>
>
>
>>
>> On Mon, Jan 23, 2017 at 11:02 AM, Fernando Pérez-García
>> <[hidden email]> wrote:
>> > Hi Csaba,
>> >
>> > That's good, thanks. I have already generated my larger terminology
>> > from a csv file. I can share the Python code if someone wants to
>> > take a look.
>> >
>> > I'm not sure if I'll make it tomorrow at the hangout. I'll read the
>> > conclusions later.
>> >
>> >
>> > Fernando
>> >
>> > 2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >>
>> >> Hi Fernando,
>> >>
>> >>
>> >>
>> >> I added keyboard support for the terminology widget (and fixed
>> >> other minor bugs).
>> >>
>> >>
>> >>
>> >> See you and the others tomorrow at the hangout!
>> >>
>> >>
>> >>
>> >> csaba
>> >>
>> >>
>> >>
>> >> From: Steve Pieper [mailto:[hidden email]]
>> >> Sent: Friday, January 20, 2017 11:17
>> >> To: Andrey Fedorov <[hidden email]>
>> >>
>> >>
>> >> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> <[hidden email]>
>> >> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >>
>> >>
>> >>
>> >> Sounds like a great topic for the developer hangout if that's
>> >> convenient for everyone.
>> >>
>> >>
>> >>
>> >> -Steve
>> >>
>> >>
>> >>
>> >> On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov
>> >> <[hidden email]> wrote:
>> >>
>> >> Guys,
>> >>
>> >> I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself)
>> >> discuss this in a separate call.
>> >>
>> >> Should we do it during Slicer weekly hangout?Is everyone ok for
>> >> the decisions to wait until then?
>> >>
>> >> AF
>> >>
>> >> On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter
>> >> <[hidden email]>
>> >> wrote:
>> >>
>> >> > Hi Fernando and Andrey,
>> >> >
>> >> > Easy things first:
>> >> > "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> > contextGroupName, will my terminology still be valid?"
>> >> > Yes, at least in the scope of the current Slicer implementation.
>> >> >
>> >> > Now about the custom terminologies. With the proposed converter
>> >> > I quickly drafted, which falls in the second "easy" approach
>> >> > Andrey mentioned, we would probably further increase complexity
>> >> > and decrease interoperability.
>> >> > We talked with Andras, and I think we found a relatively
>> >> > easy-to-implement way for the "proper" approach, in the form of
>> >> > the quick lists that we have been planning all along, albeit a
>> >> > slightly different design.
>> >> >
>> >> > Basically instead of curating custom json dictionaries, we'd
>> >> > mainly use the default ones defined already in Slicer, and save
>> >> > the quick lists
>> >> > (presets/templates/etc.) to csv files, containing the detailed
>> >> > terminology information similarly to how it's already stored for
>> >> > each segment, see attached file to see its proposed structure.
>> >> > It would be these csv files that are read automatically from
>> >> > disk when starting Slicer, stored in a private scene (exactly
>> >> > for the analogy of the volume rendering presets). The easiest
>> >> > way to store these quick lists in the private scene are dummy
>> >> > segmentation nodes, with the segments being the quick list items
>> >> > storing all terminology information but no image or other data.
>> >> > The user could create new quick lists and edit existing ones in
>> >> > the Terminologies module, by selecting entries in the
>> >> > terminology navigator widget (which appears when double-clicking
>> >> > the color for a segment, and is basically the Terminologies
>> >> > module UI currently), and adding/setting the selection to the
>> >> > selected segment in the quick list table. After the quick list
>> >> > is defined, when the user double-clicks color in Segment editor
>> >> > or Segmentations, the quick list would pop up (under quick list
>> >> > selector combobox), with all terminology controls present but by
>> >> > default collapsed (in case he wants to select something that is
>> >> > not in the quick list). These details can be worked out later.
>> >> >
>> >> > Fernando's dog and cat use case could be accommodated by
>> >> > creating new Json dictionaries, that can also be used to populate a quick list.
>> >> >
>> >> > The advantage of this plan is that it addresses the use cases we
>> >> > already discussed, and would be relatively easy to implement.
>> >> > Also it wouldn't introduce new formats, and wouldn't create
>> >> > completely new dictionaries from every color table as my
>> >> > previous suggestion would have.
>> >> >
>> >> > Please let me know what you think.
>> >> >
>> >> > csaba
>> >> >
>> >> > -----Original Message-----
>> >> > From: Andrey Fedorov [mailto:[hidden email]]
>> >> > Sent: Friday, January 20, 2017 10:23
>> >> > To: Fernando Pérez-García <[hidden email]>
>> >> > Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> > <[hidden email]>
>> >> > Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >
>> >>
>> >> > Fernando, Csaba,
>> >> >
>> >> > As the background, let me explain where existing segmentation
>> >> > contexts are coming from.
>> >> >
>> >> > The first context
>> >> >
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/Segme
>> >> > ntationCategoryTypeModifier-DICOM-Master.json
>> >> > contains all (or most) of the segmentation category/type codes
>> >> > listed in DICOM part 16 as of some point in the past. It was
>> >> > created based on earlier work by David Clunie, who either
>> >> > manually or semi-automatically looked at the context groups in
>> >> > DICOM part 16, and extracted the information from the tables
>> >> > like this one [1] for example (and you can see many more CIDs
>> >> > with segmentation types here [2]), into the form we used for
>> >> > JSON.
>> >> >
>> >> > As you can see from [1], that table defines the mapping of the
>> >> > SRT coding scheme code into the other codes that are listed in
>> >> > the JSON context document. The purpose of this mapping is to
>> >> > enable cross-linking of the concepts across different
>> >> > terminologies/ontologies. So "contextGroupName",
>> >> > "UMLSConceptID", "cid", "CodeValue", "CodeMeaning",
>> >> > "CodingSchemeDesignator", "SNOMEDConceptID" all come from the
>> >> > definition like [1].
>> >> >
>> >> > One challenge in this translation task is that you need to have
>> >> > domain knowledge and put manual effort into defining certain
>> >> > aspects, since for example, Modifier is applicable only for
>> >> > structures that have laterality, and that part is not explicitly
>> >> > reflected in the CID tables. This domain knowledge is what adds
>> >> > "Modifier" part of the segmentation context.
>> >> >
>> >> > Segmentation property categories are defined by this table [3],
>> >> > and "showAnatomy" flag assigned for each Category is also
>> >> > something that is not formalized by the standard, but is "domain
>> >> > knowledge" (or "black magic", depending how you want to call
>> >> > it!). That flag tells if it makes sense to give user an option
>> >> > to define anatomic location for the given segmentation, and
>> >> > those in turn are formalized by this anatomic context:
>> >> >
>> >> > The second, smaller segmentation context
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/Segme
>> >> > ntationCategoryTypeModifier-SlicerGeneralAnatomy.json
>> >> > was created very painstakingly by going over the Slicer
>> >> > GenericAnatomyLUT [4] (which only containted freetext labels and
>> >> > colors) and mapping those one by one to either an existing
>> >> > concept in the standard, or finding the concept in SNOMED, which
>> >> > resulted in [5].
>> >> > The SNOMED concepts that were needed to describe labels in the
>> >> > Slicer GenericAnatomyLUT but were missing in DICOM were added in
>> >> > this correction proposal to the standard [6]. We kept
>> >> > "3dSlicerLabel"
>> >> > attribute to maintain the link to the LUT. RGB color in both
>> >> > contexts is mapped from that LUT.
>> >> >
>> >> > One more thing that you need to understand is what
>> >> > CodingSchemeDesignator means. These refer to lists of codes
>> >> > maintained by specific entities/organizations. You can find the
>> >> > list of coding schemes that are used in DICOM in [7].
>> >> >
>> >> > With that background, if you are still with me, let me get to
>> >> > your question. I think there are two approaches:
>> >> >
>> >> > 1. "Proper/painful" approach: follow the process we used to map
>> >> > Slicer LUT to DICOM/SNOMED codes. For each item you have in your
>> >> > list, look for the same/similar in DICOM part 16, and create
>> >> > something that looks similar to Slicer segmentation/category
>> >> > type JSON. This approach will take time (depending on the length
>> >> > of your list), but is your best shot at interoperability and
>> >> > helping other people make sense out of your data.
>> >> >
>> >> > 2. "Easy" approach: as defined in [7], you can establish your
>> >> > own coding scheme (pick your own name for CodingSchemeDesignator
>> >> > that starts with 99), and define unique codes for each of the
>> >> > items in your list under your coding scheme. This approach can
>> >> > be used to formalize data collection within your group, if you
>> >> > don't have time/expertise/desire to follow approach 1.
>> >> >
>> >> > Does this help at all?
>> >> >
>> >> > Sorry about very limited documentation. We are working on it. I
>> >> > should probably add the explanation above somewhere to the
>> >> > documentation of dcmqi
>> >> > here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the
>> >> > main location for the documentation that maintains these
>> >> > segmentation contexts).
>> >> >
>> >> > You forgot to attach your LUT to your earlier email.
>> >> >
>> >> > AF
>> >> >
>> >> >
>> >> >
>> >> > [1] example of segmentation property type CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > sect_CID_7152.html#table_CID_7152
>> >> > [2] DICOM part 16:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > PS3.16.html [3] segmentation property categories CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > sect_CID_7150.html
>> >> > [4]
>> >> >
>> >> > https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/
>> >> > LookupTables/GenericAnatomyColors
>> >> > [5]
>> >> > https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporti
>> >> > ng [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
>> >> > [7] coding schemes:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > chapter_8.html
>> >> >
>> >>
>> >> > On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >>
>> >> >> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >> >>>
>> >> >>> Hi Fernando,
>> >> >>>
>> >> >>> I fiddled with the key actions a bit a few weeks ago.
>> >> >>> itemChanged is emitted when the item itself is changed, not
>> >> >>> the selection, but currentIndexChanged or itemSelectionChanged
>> >> >>> are good candidates.
>> >> >>> Unfortunately I hit a few problems and then we had to leave
>> >> >>> for the project week, but was planning to look into that again.
>> >> >>
>> >> >>
>> >> >> Right, I actually meant itemActivated().
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I wanted to wait for the RapidJson switch before I touch
>> >> >>> terminologies again, but as I see it was integrated last
>> >> >>> night, so I can start now.
>> >> >>>
>> >> >>> About the color table to terminology conversion, there could
>> >> >>> be a reasonable way of doing that automatically if this
>> >> >>> operation is expected to be needed frequently in the future.
>> >> >>> There are only three fields that are
>> >> >>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning.
>> >> >>> There
>> >> >>> are two more that are used: 3dSlicerLabel to automatically set
>> >> >>> the segment name (if absent, it is set, but it is assembled
>> >> >>> from the type and region information), and
>> >> >>> recommendedDisplayRGBValue to set the segment color.
>> >> >>
>> >> >>
>> >> >> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> >> contextGroupName, will my terminology still be valid?
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I think we could write a converter that takes a color table
>> >> >>> and creates the terminology context:
>> >> >>> - Context name to be the name of the color table
>> >> >>> - As there is no category information in the color table,
>> >> >>> there could be only one category with the same name as the
>> >> >>> context
>> >> >>> - Type entries from the colors
>> >> >>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>> >> >>>   - recommendedDisplayRGBValue from the color
>> >> >>>   - CodingSchemeDesignator TBD (I don't know enough about how
>> >> >>> it's used, but naively I'd set the context name here as well)
>> >> >>> - No type modifiers
>> >> >>> - As region information comes from a different dictionary, it
>> >> >>> could be used as it is now. The only decision to make is
>> >> >>> whether the terminology enables region information at all. It
>> >> >>> can be done by setting the category element showAnatomy (true to enable).
>> >> >>>
>> >> >>> I can implement this converter option in the Terminologies
>> >> >>> module if others agree on its utility. The details are subject
>> >> >>> to discussion of course.
>> >> >>
>> >> >>
>> >> >> I think this + some documentation would be very useful!
>> >> >>
>> >> >> Fernando
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> csaba
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: slicer-users
>> >> >>> [mailto:[hidden email]] On Behalf Of
>> >> >>> Fernando Pérez-García
>> >> >>> Sent: Friday, January 20, 2017 05:21
>> >> >>> To: SPL Slicer Users <[hidden email]>
>> >> >>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >>>
>> >> >>> Hi again,
>> >> >>>
>> >> >>> I have created my terminology and I'm happy to see that it
>> >> >>> works as expected. The widget is very elegant.
>> >> >>>
>> >> >>> Yesterday was pretty much the first time in my life I opened a
>> >> >>> JSON file and I don't understand most of the fields in Slicer
>> >> >>> terminologies files, so I decided to just copy one of the
>> >> >>> defaults and edit it. I deleted what I didn't need, edit the
>> >> >>> names and colors and voilà. All the "contextGroupName"
>> >> >>> fields are wrong, but I guess it doesn't matter for my
>> >> >>> project. I have attached my little terminology.
>> >> >>>
>> >> >>> I have a larger color table I would like to transform into a
>> >> >>> terminology, but with all those codes I'm not sure how I'm
>> >> >>> going to do it.
>> >> >>>
>> >> >>>
>> >> >>> When there are many types, I think it would be useful to
>> >> >>> update the modifiers combo box when moving using the keyboard
>> >> >>> instead of clicking on the mouse. I don't know much about C++
>> >> >>> either, but I've dug a bit and I guess the change would be using the "itemChanged"
>> >> >>> signal instead of "itemClicked" [1, 2].
>> >> >>>
>> >> >>>
>> >> >>> Fernando
>> >> >>>
>> >> >>>
>> >> >>> [1]
>> >> >>>
>> >>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe07
>> >> >>> 3c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTermin
>> >> >>> ologyNa
>> >> >>> vigatorWidget.cxx#L218
>> >> >>> [2]
>> >> >>>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe07
>> >> >>> 3c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTermin
>> >> >>> ologyNa
>> >> >>> vigatorWidget.cxx#L1443
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> View this message in context:
>> >> >>>
>> >> >>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segm
>> >> >>> ent-Edi tor-tp4031210p4031631.html Sent from the slicer-users
>> >> >>> mailing list
>> >>
>> >> >>> archive at Nabble.com.
>> >> >>> _______________________________________________
>> >> >>> 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
>> >> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/F
>> >> >>> AQ
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FA
>> >> >> Q
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >
>> >
>
>
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Terminologies and Segment Editor

Andras Lasso-2
There are two kinds of files:
* terminology definition: list of all categories modifiers, etc. (they already exist, as multiple json files)
* segmentation preset files: containing a list of segment definitions, name, color, terminology (proposed new csv file; basically a ctbl file but in csv format and with terminology information)

Users will always have to create segmentation preset files, but they may also need to create new terminology definitions (if current terminologies in Slicer do not contain all the necessary terms). Preset files should be validated against terminology definition files. It's possible to create these files manually, as they are simple text files, but probably most users will not understand what rules have to be respected, so I think this is a short-term solution only. We will soon provide segmentation preset editor and (a bit later probably also a simple terminology editor) that offers a GUI that ensures the created files are valid.

Andras

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of Csaba Pinter
Sent: January 23, 2017 13:42
To: Andrey Fedorov <[hidden email]>; Fernando Pérez-García <[hidden email]>
Cc: SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

In that case I suggest we reschedule the terminology meeting to another time.

If we have a converter that creates non-standard terminologies (what I also suggested earlier as a quick&dirty solution), then supporting ctbl files would also be important I think.

csaba

-----Original Message-----
From: Andrey Fedorov [mailto:[hidden email]]
Sent: Monday, January 23, 2017 12:48
To: Fernando Pérez-García <[hidden email]>
Cc: Csaba Pinter <[hidden email]>; Steve Pieper <[hidden email]>; SPL Slicer Users <[hidden email]>
Subject: Re: [slicer-users] Terminologies and Segment Editor

> I manually edited one of the defaults, before having read your explanation. I have attached the new one, and the code I used to generate it from my CSV file.

Thanks, this makes more sense!

Note that your "coding scheme" is inconsistent - you have multiple codes that are different, but have identical meaning (e.g., Left and Right).

>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care
> much about the codes. I tried an "easy" approach before receiving your message.
>

The issue is not about QIICR, it is about generating inconsistent data in the situation where it is trivial to make it at least more consistent (what you did in the updated example you shared).

But I agree you do raise an important issue. It makes sense to have a convenience script like the one you created to help with conversion from CSV. The key question is what should be the input format of CSV it should expect - should it be a flat list, or should it allow for some hierarchy (specification of laterality, for example, but there can be other situations where your modifier can be anterior/posterior, for example, so it might need some flexibility). If there is some consensus what that CSV should look like, then we could provide a helper script to generate the terminology file with a "99" prefix coding scheme designator generated "on the fly".

About the meeting tomorrow, I unfortunately developed a conflict and most likely won't be able to join...


On Mon, Jan 23, 2017 at 12:23 PM, Fernando Pérez-García <[hidden email]> wrote:

> Hi Andrey,
>
>
>
> 2017-01-23 17:41 GMT+01:00 Andrey Fedorov <[hidden email]>:
>>
>> Fernando,
>>
>> it is unfortunate you cannot join the call.
>
>
> I will try to join you, but I don't think my presence would be too useful!
>
>
>
>
>>
>> I looked at the file you shared. I don't know how you generated it,
>> but you should absolutely NOT use that file. I am afraid my
>> explanation was not clear.
>
>
> I manually edited one of the defaults, before having read your explanation.
> I have attached the new one, and the code I used to generate it from
> my CSV file.
>
>
>
>
>>
>> You absolutely cannot change the code meaning for the codes that
>> belong to an existing official coding scheme!
>
>
> I understand coherence is very important in QIICR, but I just needed
> something fast that worked within the scope of my project. Since this
> terminology file won't be distributed, I honestly didn't really care
> much about the codes. I tried an "easy" approach before receiving your message.
>
>
>
>
>> But what you do right now is like taking rgb code (255,0,0) and
>> calling it "Blue"....
>
>
>
> I hope my new approach is not so crazy :)
>
>
> Fernando
>
>
>
>
>
>>
>> On Mon, Jan 23, 2017 at 11:02 AM, Fernando Pérez-García
>> <[hidden email]> wrote:
>> > Hi Csaba,
>> >
>> > That's good, thanks. I have already generated my larger terminology
>> > from a csv file. I can share the Python code if someone wants to
>> > take a look.
>> >
>> > I'm not sure if I'll make it tomorrow at the hangout. I'll read the
>> > conclusions later.
>> >
>> >
>> > Fernando
>> >
>> > 2017-01-23 16:58 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >>
>> >> Hi Fernando,
>> >>
>> >>
>> >>
>> >> I added keyboard support for the terminology widget (and fixed
>> >> other minor bugs).
>> >>
>> >>
>> >>
>> >> See you and the others tomorrow at the hangout!
>> >>
>> >>
>> >>
>> >> csaba
>> >>
>> >>
>> >>
>> >> From: Steve Pieper [mailto:[hidden email]]
>> >> Sent: Friday, January 20, 2017 11:17
>> >> To: Andrey Fedorov <[hidden email]>
>> >>
>> >>
>> >> Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> <[hidden email]>
>> >> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >>
>> >>
>> >>
>> >> Sounds like a great topic for the developer hangout if that's
>> >> convenient for everyone.
>> >>
>> >>
>> >>
>> >> -Steve
>> >>
>> >>
>> >>
>> >> On Fri, Jan 20, 2017 at 10:57 AM, Andrey Fedorov
>> >> <[hidden email]> wrote:
>> >>
>> >> Guys,
>> >>
>> >> I suggest 3 or 4 of us (Fernando, Csaba, Andras and myself)
>> >> discuss this in a separate call.
>> >>
>> >> Should we do it during Slicer weekly hangout?Is everyone ok for
>> >> the decisions to wait until then?
>> >>
>> >> AF
>> >>
>> >> On Fri, Jan 20, 2017 at 10:50 AM, Csaba Pinter
>> >> <[hidden email]>
>> >> wrote:
>> >>
>> >> > Hi Fernando and Andrey,
>> >> >
>> >> > Easy things first:
>> >> > "If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> > contextGroupName, will my terminology still be valid?"
>> >> > Yes, at least in the scope of the current Slicer implementation.
>> >> >
>> >> > Now about the custom terminologies. With the proposed converter
>> >> > I quickly drafted, which falls in the second "easy" approach
>> >> > Andrey mentioned, we would probably further increase complexity
>> >> > and decrease interoperability.
>> >> > We talked with Andras, and I think we found a relatively
>> >> > easy-to-implement way for the "proper" approach, in the form of
>> >> > the quick lists that we have been planning all along, albeit a
>> >> > slightly different design.
>> >> >
>> >> > Basically instead of curating custom json dictionaries, we'd
>> >> > mainly use the default ones defined already in Slicer, and save
>> >> > the quick lists
>> >> > (presets/templates/etc.) to csv files, containing the detailed
>> >> > terminology information similarly to how it's already stored for
>> >> > each segment, see attached file to see its proposed structure.
>> >> > It would be these csv files that are read automatically from
>> >> > disk when starting Slicer, stored in a private scene (exactly
>> >> > for the analogy of the volume rendering presets). The easiest
>> >> > way to store these quick lists in the private scene are dummy
>> >> > segmentation nodes, with the segments being the quick list items
>> >> > storing all terminology information but no image or other data.
>> >> > The user could create new quick lists and edit existing ones in
>> >> > the Terminologies module, by selecting entries in the
>> >> > terminology navigator widget (which appears when double-clicking
>> >> > the color for a segment, and is basically the Terminologies
>> >> > module UI currently), and adding/setting the selection to the
>> >> > selected segment in the quick list table. After the quick list
>> >> > is defined, when the user double-clicks color in Segment editor
>> >> > or Segmentations, the quick list would pop up (under quick list
>> >> > selector combobox), with all terminology controls present but by
>> >> > default collapsed (in case he wants to select something that is
>> >> > not in the quick list). These details can be worked out later.
>> >> >
>> >> > Fernando's dog and cat use case could be accommodated by
>> >> > creating new Json dictionaries, that can also be used to populate a quick list.
>> >> >
>> >> > The advantage of this plan is that it addresses the use cases we
>> >> > already discussed, and would be relatively easy to implement.
>> >> > Also it wouldn't introduce new formats, and wouldn't create
>> >> > completely new dictionaries from every color table as my
>> >> > previous suggestion would have.
>> >> >
>> >> > Please let me know what you think.
>> >> >
>> >> > csaba
>> >> >
>> >> > -----Original Message-----
>> >> > From: Andrey Fedorov [mailto:[hidden email]]
>> >> > Sent: Friday, January 20, 2017 10:23
>> >> > To: Fernando Pérez-García <[hidden email]>
>> >> > Cc: Csaba Pinter <[hidden email]>; SPL Slicer Users
>> >> > <[hidden email]>
>> >> > Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >
>> >>
>> >> > Fernando, Csaba,
>> >> >
>> >> > As the background, let me explain where existing segmentation
>> >> > contexts are coming from.
>> >> >
>> >> > The first context
>> >> >
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/Segme
>> >> > ntationCategoryTypeModifier-DICOM-Master.json
>> >> > contains all (or most) of the segmentation category/type codes
>> >> > listed in DICOM part 16 as of some point in the past. It was
>> >> > created based on earlier work by David Clunie, who either
>> >> > manually or semi-automatically looked at the context groups in
>> >> > DICOM part 16, and extracted the information from the tables
>> >> > like this one [1] for example (and you can see many more CIDs
>> >> > with segmentation types here [2]), into the form we used for
>> >> > JSON.
>> >> >
>> >> > As you can see from [1], that table defines the mapping of the
>> >> > SRT coding scheme code into the other codes that are listed in
>> >> > the JSON context document. The purpose of this mapping is to
>> >> > enable cross-linking of the concepts across different
>> >> > terminologies/ontologies. So "contextGroupName",
>> >> > "UMLSConceptID", "cid", "CodeValue", "CodeMeaning",
>> >> > "CodingSchemeDesignator", "SNOMEDConceptID" all come from the
>> >> > definition like [1].
>> >> >
>> >> > One challenge in this translation task is that you need to have
>> >> > domain knowledge and put manual effort into defining certain
>> >> > aspects, since for example, Modifier is applicable only for
>> >> > structures that have laterality, and that part is not explicitly
>> >> > reflected in the CID tables. This domain knowledge is what adds
>> >> > "Modifier" part of the segmentation context.
>> >> >
>> >> > Segmentation property categories are defined by this table [3],
>> >> > and "showAnatomy" flag assigned for each Category is also
>> >> > something that is not formalized by the standard, but is "domain
>> >> > knowledge" (or "black magic", depending how you want to call
>> >> > it!). That flag tells if it makes sense to give user an option
>> >> > to define anatomic location for the given segmentation, and
>> >> > those in turn are formalized by this anatomic context:
>> >> >
>> >> > The second, smaller segmentation context
>> >> >
>> >> > https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/Segme
>> >> > ntationCategoryTypeModifier-SlicerGeneralAnatomy.json
>> >> > was created very painstakingly by going over the Slicer
>> >> > GenericAnatomyLUT [4] (which only containted freetext labels and
>> >> > colors) and mapping those one by one to either an existing
>> >> > concept in the standard, or finding the concept in SNOMED, which
>> >> > resulted in [5].
>> >> > The SNOMED concepts that were needed to describe labels in the
>> >> > Slicer GenericAnatomyLUT but were missing in DICOM were added in
>> >> > this correction proposal to the standard [6]. We kept
>> >> > "3dSlicerLabel"
>> >> > attribute to maintain the link to the LUT. RGB color in both
>> >> > contexts is mapped from that LUT.
>> >> >
>> >> > One more thing that you need to understand is what
>> >> > CodingSchemeDesignator means. These refer to lists of codes
>> >> > maintained by specific entities/organizations. You can find the
>> >> > list of coding schemes that are used in DICOM in [7].
>> >> >
>> >> > With that background, if you are still with me, let me get to
>> >> > your question. I think there are two approaches:
>> >> >
>> >> > 1. "Proper/painful" approach: follow the process we used to map
>> >> > Slicer LUT to DICOM/SNOMED codes. For each item you have in your
>> >> > list, look for the same/similar in DICOM part 16, and create
>> >> > something that looks similar to Slicer segmentation/category
>> >> > type JSON. This approach will take time (depending on the length
>> >> > of your list), but is your best shot at interoperability and
>> >> > helping other people make sense out of your data.
>> >> >
>> >> > 2. "Easy" approach: as defined in [7], you can establish your
>> >> > own coding scheme (pick your own name for CodingSchemeDesignator
>> >> > that starts with 99), and define unique codes for each of the
>> >> > items in your list under your coding scheme. This approach can
>> >> > be used to formalize data collection within your group, if you
>> >> > don't have time/expertise/desire to follow approach 1.
>> >> >
>> >> > Does this help at all?
>> >> >
>> >> > Sorry about very limited documentation. We are working on it. I
>> >> > should probably add the explanation above somewhere to the
>> >> > documentation of dcmqi
>> >> > here: https://fedorov.gitbooks.io/dcmqi/content/ (this is the
>> >> > main location for the documentation that maintains these
>> >> > segmentation contexts).
>> >> >
>> >> > You forgot to attach your LUT to your earlier email.
>> >> >
>> >> > AF
>> >> >
>> >> >
>> >> >
>> >> > [1] example of segmentation property type CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > sect_CID_7152.html#table_CID_7152 [2] DICOM part 16:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > PS3.16.html [3] segmentation property categories CID:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > sect_CID_7150.html
>> >> > [4]
>> >> >
>> >> > https://www.slicer.org/wiki/Documentation/4.5/SlicerApplication/
>> >> > LookupTables/GenericAnatomyColors
>> >> > [5]
>> >> > https://www.slicer.org/wiki/Documentation/4.2/Extensions/Reporti
>> >> > ng [6] ftp://medical.nema.org/medical/dicom/cp/cp1258_01.pdf
>> >> > [7] coding schemes:
>> >> >
>> >> >
>> >> > http://dicom.nema.org/medical/dicom/current/output/chtml/part16/
>> >> > chapter_8.html
>> >> >
>> >>
>> >> > On Fri, Jan 20, 2017 at 9:42 AM, Fernando Pérez-García
>> >> > <[hidden email]> wrote:
>> >> >>
>> >> >>
>> >> >> 2017-01-20 15:07 GMT+01:00 Csaba Pinter <[hidden email]>:
>> >> >>>
>> >> >>> Hi Fernando,
>> >> >>>
>> >> >>> I fiddled with the key actions a bit a few weeks ago.
>> >> >>> itemChanged is emitted when the item itself is changed, not
>> >> >>> the selection, but currentIndexChanged or itemSelectionChanged
>> >> >>> are good candidates.
>> >> >>> Unfortunately I hit a few problems and then we had to leave
>> >> >>> for the project week, but was planning to look into that again.
>> >> >>
>> >> >>
>> >> >> Right, I actually meant itemActivated().
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I wanted to wait for the RapidJson switch before I touch
>> >> >>> terminologies again, but as I see it was integrated last
>> >> >>> night, so I can start now.
>> >> >>>
>> >> >>> About the color table to terminology conversion, there could
>> >> >>> be a reasonable way of doing that automatically if this
>> >> >>> operation is expected to be needed frequently in the future.
>> >> >>> There are only three fields that are
>> >> >>> mandatory: CodingSchemeDesignator, CodeValue, and CodeMeaning.
>> >> >>> There
>> >> >>> are two more that are used: 3dSlicerLabel to automatically set
>> >> >>> the segment name (if absent, it is set, but it is assembled
>> >> >>> from the type and region information), and
>> >> >>> recommendedDisplayRGBValue to set the segment color.
>> >> >>
>> >> >>
>> >> >> If I delete SNOMEDCTConceptID, cid, UMLSConceptUID and
>> >> >> contextGroupName, will my terminology still be valid?
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> I think we could write a converter that takes a color table
>> >> >>> and creates the terminology context:
>> >> >>> - Context name to be the name of the color table
>> >> >>> - As there is no category information in the color table,
>> >> >>> there could be only one category with the same name as the
>> >> >>> context
>> >> >>> - Type entries from the colors
>> >> >>>   - CodeMeaning, CodeValue, and 3dSlicerLabel from the color names
>> >> >>>   - recommendedDisplayRGBValue from the color
>> >> >>>   - CodingSchemeDesignator TBD (I don't know enough about how
>> >> >>> it's used, but naively I'd set the context name here as well)
>> >> >>> - No type modifiers
>> >> >>> - As region information comes from a different dictionary, it
>> >> >>> could be used as it is now. The only decision to make is
>> >> >>> whether the terminology enables region information at all. It
>> >> >>> can be done by setting the category element showAnatomy (true to enable).
>> >> >>>
>> >> >>> I can implement this converter option in the Terminologies
>> >> >>> module if others agree on its utility. The details are subject
>> >> >>> to discussion of course.
>> >> >>
>> >> >>
>> >> >> I think this + some documentation would be very useful!
>> >> >>
>> >> >> Fernando
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> csaba
>> >> >>>
>> >> >>> -----Original Message-----
>> >> >>> From: slicer-users
>> >> >>> [mailto:[hidden email]] On Behalf Of
>> >> >>> Fernando Pérez-García
>> >> >>> Sent: Friday, January 20, 2017 05:21
>> >> >>> To: SPL Slicer Users <[hidden email]>
>> >> >>> Subject: Re: [slicer-users] Terminologies and Segment Editor
>> >> >>>
>> >> >>> Hi again,
>> >> >>>
>> >> >>> I have created my terminology and I'm happy to see that it
>> >> >>> works as expected. The widget is very elegant.
>> >> >>>
>> >> >>> Yesterday was pretty much the first time in my life I opened a
>> >> >>> JSON file and I don't understand most of the fields in Slicer
>> >> >>> terminologies files, so I decided to just copy one of the
>> >> >>> defaults and edit it. I deleted what I didn't need, edit the
>> >> >>> names and colors and voilà. All the "contextGroupName"
>> >> >>> fields are wrong, but I guess it doesn't matter for my
>> >> >>> project. I have attached my little terminology.
>> >> >>>
>> >> >>> I have a larger color table I would like to transform into a
>> >> >>> terminology, but with all those codes I'm not sure how I'm
>> >> >>> going to do it.
>> >> >>>
>> >> >>>
>> >> >>> When there are many types, I think it would be useful to
>> >> >>> update the modifiers combo box when moving using the keyboard
>> >> >>> instead of clicking on the mouse. I don't know much about C++
>> >> >>> either, but I've dug a bit and I guess the change would be using the "itemChanged"
>> >> >>> signal instead of "itemClicked" [1, 2].
>> >> >>>
>> >> >>>
>> >> >>> Fernando
>> >> >>>
>> >> >>>
>> >> >>> [1]
>> >> >>>
>> >>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe07
>> >> >>> 3c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTermin
>> >> >>> ologyNa
>> >> >>> vigatorWidget.cxx#L218
>> >> >>> [2]
>> >> >>>
>> >> >>>
>> >> >>> https://github.com/Slicer/Slicer/blob/00f4d75d9695a97d5926fe07
>> >> >>> 3c48077
>> >> >>>
>> >> >>> 449130829/Modules/Loadable/Terminologies/Widgets/qSlicerTermin
>> >> >>> ologyNa
>> >> >>> vigatorWidget.cxx#L1443
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> View this message in context:
>> >> >>>
>> >> >>> http://slicer-users.65878.n3.nabble.com/Terminologies-and-Segm
>> >> >>> ent-Edi tor-tp4031210p4031631.html Sent from the slicer-users
>> >> >>> mailing list
>> >>
>> >> >>> archive at Nabble.com.
>> >> >>> _______________________________________________
>> >> >>> 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
>> >> >>> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/F
>> >> >>> AQ
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FA
>> >> >> Q
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >> http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
>> >
>> >
>
>
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
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
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
12