As part of our training, we want to encourage the use of terminology feature of Slicer to name segments. This will provide better data reuse for downstream tasks. As I am getting more familiar myself, I noticed a few issues:
Terminology is incomplete. I am not sure where the terms are coming from (it satys DICOM master list), but as it is it is incomplete, even for humans. (E.g., it is missing Maxilla, Mandible, Nasal, Sphenoid, Zygomatic bones in skull, includes none of the ossicles -stapes, incus, malleolus, none of the post-cranial bones femur, tibia etc are listed). While I am not a radiologist, it is hard for me to believe DICOM terminology does not include these human bones.
For slicermorph, the plan is to build a terminology that is usable across vertebrates using Uberon ontology. However, I believe, at the minimum core Slicer terminology should support the whole human skeleton.
Segment renaming doesnât encourage terminology usage. Currently terminology only pops up if the color of a segment is clicked. Since it is possible to rename the segment in the terminology module, I would suggest double clicking the segment name also brings the terminology window, with the Name field activated.
There are bugs in the behavior: Create an empty segment, double click color to bring the terminology window, search for Frontal and assign it and done, notice that even though Frontal is assigned a yellowish brown. The color shows up as gray.
I am also confused how these two panel supposed to work together. For example, if you search for sphenoid in the left panel no result is returned. There is a sphenoid bone in the right panel, but it cannot be used for selection (AFAIK tell).
Thanks for raising these issues @muratmaga . The use of consistent terms is also important for creating ground truth for machine learning. I donât know that anyone has dedicated funding to improve the current implementation.
I am not sure if the current implementation needs entirely revamped. The first thing to do is to bring a more complete set of human terms to the terminology. Then, as opposed to listing a huge list, may be breakdown down by the anatomical systems (skeleton, connective tissue, organs, vasculature etc), which is I think the intention of the right panel. And the rest, as I said is to encourage the use of terminology.
We (SlicerMorph) will take a crack at vertebrate skeletal terms as a list as a separate effort, but given the clinical imaging focus of Slicer, I thought a more complete human terms would be necessary to include from get go.
Hi @muratmaga and @all, happy to see that thereâs people around understanding the value of terminology as a way to improve communication. I have been worked in the field of Gross Anatomy for the last 15 years, and I would strongly suggest (and will be happy to support) to follow the last version of âTerminologia Anatomicaâ source. It addresses miscommunication problems through the implementation of common terms based on ~clear rules and practices. Hope this helps, and do not hesitate to ping me in case you want/need details/support.
I cannot comment on the incompleteness of the larger terminology. I also noticed that some basic looking objects are missing.
We have talked about this earlier (with @lassoan I think), but then havenât taken any further steps. It would make sense to use the terminology selector for renaming, I agree.
I noticed this as well, that the colors turn grey sometimes (like exactly in a comment I sent to you just now, coincidentally with one of these very terms). This seems to be a bug simply that needs to be fixed.
The right panel is to give an âanatomic contextâ to generic items like cyst or mass. You can specify the body part where it appears. At least this is how I understood the basic idea.
Interesting. I read it but didnât understand. I thought it is from higher organization to lower organization (systems on the left, specific names/organs on the right).
Yes it is a bit confusing, because there is the terminology context, and the anatomic context in its separate json file. In terminology you have categories and within them types (so this part of the higher to lower organization stands). Certain categories allow specifying anatomic context, while others donât (like optic lens only can occur in a specific place, unlike a tumor where you can and should give more details about where it is). This is stored in the showAnatomy tag of the category element.
As you see in the Slicer general anatomy list (I think btw this is a typo instead of generic which is the name of the corresponding color table), we have Tissue with show anatomy on, Anatomical Structure (off), Physical object (on), Morphologically Altered Structure (on), and Body Substance (off). So for Tissue, Physical object, and Morphologically Altered Structure you can specify the anatomic region, which I think makes sense.
Suggestions for improvements in the documentation are welcome if you have any concrete ideas how to make it more understandable.
Looks like instead of one grand terminology for skeletal terms for all vertebrates, we will probably opt out to organize for each class of vertebrates (mammals, birds, lizards/snakes etc) separatelyâŚ
For example, I am compiling a small list for lizards and snakes as a test in this manner:
So if I understand you correctly, my Lower Jaw, Braincase, Splanchnocranium, Forelimb, Vertebral Column are going to be equivalent of the Tissue, Anatomical Structure, Physical categories (so that I can turn them on/off as I choose). But I am still somewhat unclear where the terms associated with each of those categories go. Is the under the Type part thatâs collapsed in your screenshot, or is a separate json file?
Finally, do you have tool to build the json file correctly, or have a custom script?
Maybe I misunderstand the purpose of these terms but I think they should be types.
You can create a separate terminology json file (i.e. context) for each animal, but you can create one and organize them into categories.
Just for clarity in the expanded terminology widget the left column is category, middle one is type (with an optional modifier such as Left/Right), and the right one is anatomic context, enabled for the categories that have this flag on.
The anatomic context is independent of the terminology and is a different json file.
What I do personally for special cases where the main list does not cover the needs (cardiac, dental) is that I create a terminology context where I have just one category and within it all the types I need. Actually in the cardiac case we have multiple contexts for the different pediatric anatomy scenarios that may occur (see these as examples here). I hope this helps.
Thanks @cpinter. I am worried that a single category for all skeletal elements will be too long (100-300 depending on the organism). That;s why I am trying to create multiple categories for anatomical region.
I actually managed to generate valid JSON file (as indicated for the DCMQI validator), and can load it into Slicer, but for some reason contents of the 2nd category (Forelimb), doesnât get displayed.
and converts to a valid json that can be imported into terminologies
We are facing an issue with elements that has L and R modifiers. If en element has left and right modifiers specified, the "no type modifierâ state always shows as a gray box.
While designated colors are shown for Left modifier, Right modifier. A possible solution to this is to have a third state âL & R modifiersâ, and designated color indeed shows up. Although this is less than ideal solution.
I know this is not a bug with our own JSON file, because the issue is there with the terminologies provided by Slicer as well (e.g., from 3D Slicer general anatomy list, choose anatomical object and navigate to Frontal Bone. You can see that No type modifier state is grayed, as opposed to brownish yellow color it is being shown).
Is this a restriction of the JSON schema or a bug in the terminologies module?
I donât understand the problem. In the screenshots the âNo type modifierâ combobox seems enabled.
When I do what you describe in Slicer, I can select the modifier without problems.
Maybe itâs a confusion about the meaning of âNo type modifierâ. It means that none is currently selected. We want to allow the user to not select the modifier and leave it empty.
