search

QIICR / dcmqi

dcmqi (DICOM for Quantitative Imaging) is a free, open source C++ library for conversion between imaging research formats and the standard DICOM representation for image analysis results
https://qiicr.gitbook.io/dcmqi-guide/
BSD 3-Clause "New" or "Revised" License
242 stars 61 forks source link

Missing items in Slicer general anatomy #388

Closed lassoan closed 4 years ago

lassoan commented 4 years ago

I've tried to use SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json terminology file but found that very basic structures are missing. So, I compared the json file to Slicer anatomy lookup table and found a couple of missed items and other small inconsistencies.

Present in DICOM context file (https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-DICOM-Master.json) but for some reason missing from SlicerGeneralAnatomy context file (https://github.com/QIICR/dcmqi/blob/master/doc/segContexts/SegmentationCategoryTypeModifier-SlicerGeneralAnatomy.json):

Other issues:

fedorov commented 4 years ago

The history of those files is complicated. I believe the source of the DICOM terminology was initially XML prepared for a plugin to ClearCanvas. Later @dclunie updated the content of that file to some version of the DICOM standard. The scripts and the process he used for that purpose, to the best of my recollection, was never shared or documented. Slicer terminology I believe was developed in this spreadsheet. The resources folder contains what I believe are the source files to create JSON representation. I see Liver is present in the CSV file. I don't know what happened and why it is not in the JSON.

This makes me realize I think there are at least 2 issues that need to be resolved longer term:

To address this specific issue you bring up about Slicer terminology, I think it is probably most expedient to manually patch the Slicer JSON terminology file for the first group of items you listed, and also for the remaining 3:

I can fix this tomorrow, or feel free to send a PR.

lassoan commented 4 years ago

I can fix this tomorrow

Sounds great, thank you very much!

dclunie commented 4 years ago

I wouldn't depend on Innolitics, since they don't keep their extract updated.

DICOM CID 7192 and its included context groups should provide most terms:

http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7192.html

Each DICOM context group is provided by the standard in FHIR JSON, FHIR XML, IHE SVS XML standard forms nowadays, which are updated automatically with each DICOM standard release (five times a year) ... vide infra.

The FHIR JSON representation already has a transitive closure performed and uses SNOMED numeric IDs, so you could use that directly, since it is a standard format:

ftp://medical.nema.org/medical/dicom/resources/valuesets/fhir/json/CID_7192.json

David

PS. I checked, and the current standard CID_7192.json does include "Occipital bone", "Diencephalon" and "Vomer bone", and the others that you mentioned (except that the parts are singular, so there is "Rib" not "Ribs").

PPS. for a description of the FHIR resource format see:

http://www.hl7.org/fhir/valueset.html

PPPS. to use the FHIR resource format to create DICOM code sequences you need to be able to map the "system" value they use to a DICOM coding scheme designator. See:

http://www.hl7.org/fhir/terminologies-systems.html http://www.hl7.org/fhir/terminologies.html

(and also the list in my ContextGroupExtraction.java program).

PPPPS. In case it is of interest, attached are the three files I use to extract the FHIR JSON format etc., with each release:

ContextGroupExtraction_asof_2019e.zip

fedorov commented 4 years ago

@lassoan the PR passed the tests, please take a look, and I will merge it.

fedorov commented 4 years ago

@dclunie thank you, this is very helpful. A sticky issue is that the JSON files in question contain information that is not included in the CIDs. Specifically, whether the term is paired, and what modifiers are applicable (as defined by this schema, which may be interesting to you in the context of Sup 219 as well, perhaps). Without that logic, I do not know how to script the generation of the dcmqi JSON files.

As a less ambitious goal, I could reuse the existing JSON files, and just replace SRT with SCT codes, but the FHIR files you mentioned contain only SRT. Is there something that can be used easily to map between the two?

fedorov commented 4 years ago

I wouldn't depend on Innolitics, since they don't keep their extract updated.

@dclunie their current version corresponds to the latest 2019e version of the standard.

I would love not to depend on Innolitics or any scripts of that kind. Perhaps I will not have to, once similar representations of CIODs, attribute modules etc are officially included in the standard, and maintained in sync and alongside with the "machine-readable" DocBook format. If this can be done for CIDs by means of FHIR JSON, I will assume the "glass half full" attitude - perhaps there's light in the end of the tunnel.

fedorov commented 4 years ago

@lassoan I updated the PR, please take a look at #389 and let me know if it is ok now.

lassoan commented 4 years ago

Looks good to me, thank you very much.

fedorov commented 4 years ago

Need to update Slicer - reopening.

fedorov commented 4 years ago

Slicer PR submitted