One of the fundamental principles of DICOM is the use of controlled terminologies, or lexicons, or coding schemes (for the purposes of this guide, these can be used interchangeably). While using dcmqi
you will encounter various situations where you will need to select codes to describe the data you are converting into DICOM. In this and the following sections we give you an overview and describe the general principles of deciding on how to choose such codes.
Controlled terminologies define a set of codes, and sometimes their relationships, that are carefully curated to describe entities for a certain application domain. Consistent use of such terminologies helps with uniform data collection and is critical for harmonization of activities conducted by independent groups.
When codes are used in DICOM, they are saved as triplets that consist of
CodeValue: unique identifier for a term
CodingSchemeDesignator: code for the authority that issued this code
CodeMeaning: human-readable code description
DICOM relies on various sources of codes, all of which are listed in PS3.16 Section 8 of the standard.
The first question while choosing the coding scheme is whether you will use an existing code, or define your own. Depending on your choice, follow one of the two recipes below.
If there is no matching code that is already included in DICOM, you can search one of the existing terminologies/ontologies for a suitable code: this option often requires more effort, but it will make your resulting data consistent with the existing controlled terminologies, facilitating reasoning on the resulting data, and aggregation of the results collected from different sources. This “semantic” approach using standard codes allows for greater reuse and harmonization with other data sets, since the need for natural language parsing of plain text during “data mining” is obviated by the commonality of standard codes for standard entities, such as anatomical regions, types of tumor, etc. The choice of the coding scheme and specific codes will depend on the specific data conversion task.
Introduce a new coding scheme: if you follow this option, you can either reuse an existing terminology which is not listed in the DICOM standard here, or define your own terminology and set of codes. You can still produce the data that is harmonized with other sources, but to achieve this you will need to make sure all "data producers" follow your coding scheme! This approach is suitable when you are working on an application where no established terminology exists (e.g., no consensus within your community is reached), or when semantic interoperability is not a priority.
While DICOM allows for reuse of the codes defined in other terminologies, such as SNOMED, as well as those defined in the DICOM standard itself, so called “private” codes can also be defined by the creator of the object, when no standard codes are available. Such private codes are distinguished by a coding scheme designator that must start with the “99” prefix.
As an example, consider Dr. Smith developed a new model for estimate ADC from diffusion MRI. Since the method is new, there is no standard code for it. Dr. Smith then can establish her own coding scheme designator, say, 99DRSMITH
, and define a new code as the following triple:
('SADC123','99SMITH','Smith Diffusion Model')
.
To find a suitable code in an existing terminology, you will need to know what terminology to search, and you will need a tool that would facilitate your search.
DICOM has a preference for using SNOMED-CT codes. If you find a code in SNOMED-CT that would fill an important gap, but is not in the standard, you can propose inclusion of that new code into the standard. While looking for codes in SNOMED-CT, note the following guideline from the standard (PS3.16, Section 8.1.1):
8.1.1 Use of SNOMED Anatomic ConceptsIn general, DICOM uses the anatomic concepts with the term "structure", rather than with the term "entire". This is an important distinction in SNOMED. "Entire" is a child concept to "structure", has a more restricted meaning, and typically is used in conjunction with treatments (e.g., "excision of entire right kidney"). It is used in distinction to other sibling children of the parent concept that may identify parts of the parent anatomic feature. Since imaging typically targets both the anatomic feature and the area around it, or sometimes just part of the anatomic feature, DICOM usually uses "structure" concepts that are more inclusive than the "entire" concepts.
However, keep in mind that:
the process of contributing something into the DICOM standard is lengthy and can take a year before you see your change in the standard text;
you will need to learn the procedures of contributing changes to the standard;
although the SNOMED-CT codes included in the standard are exempt from the licensing constraints of SNOMED-CT, the ontology defined by SNOMED-CT is NOT covered by the exemption. Therefore, you will still need a secondary ontology if you are concerned about the license, and want to do reasoning on your data.
If a certain term is not found in SNOMED, it might be possible to add it. If you would like to request adding a new term in the context of DICOM, you can contact DICOM secretariat at http://www.dicomstandard.org/contact/secretariat/, and they would then pass your request to the person responsible for the interactions with SNOMED. Also, each country has its SNOMED national member contact: http://www.snomed.org/our-customers/members, in case you want to make a non-DICOM related request.
Therefore, it can be more practical to find a suitable term in an ontology other than SNOMED-CT.
In this regard, David Clunie, the long-time Editor of the DICOM standard, gave the following guidance on what terminologies to consider when a gap in the standard is identified:
[...] we (DICOM) use FMA then NeuroNames as a fallback when there are no appropriate SNOMED codes (yet), and have contacts with each of the appropriate groups to extend the schemes as necessary. We have not used RadLex for anatomy, since it is all/mostly(?) in FMA anyway (and if I recall correctly, was derived from it, since the original RadLex protagonists had no interest in reinventing that wheel).
If you need to automate anatomical code mapping, consider using the UMLS as a tool ... frequently both SNOMED and FMA terms map to a common UMLS code which helps a lot.
You can also use the FMAIDs included in the RadLex ontology (http://purl.bioontology.org/ontology/RADLEX) to map from RadLex back to FMA (or the reverse, since I think the FMA OWL file also includes the RadLex RIDs), then to UMLS and on to SNOMED, and indeed then undo the pre-coordinated laterality (if necessary) using the SNOMED hierarchy.
To search existing terminologies, you can consider using the following tools that search across different ontologies:
With both of these search engines you have an option of the advanced search to restrict the terms to a specific ontology.
There are also some search tools that provide searches for the individual ontologies (such as FMA), but in some instances their search capabilities are not flexible enough, and as such we recommend BioPortal and OLS. Unfortunately, neither BioPortal nor OLS include Neuronames, so you will need to use the specialized search tool for that ontology: http://braininfo.rprc.washington.edu/.
Here is an illustrative example of searching for a term "anterior cingulate gyrus", which is not included in DICOM (note that you can use AnatomicRegionModifier
to encode laterality of the structure).
Using BioPortal, go to the Advanced search, put the search term in the search box, and specify FMA in the "Ontologies" selector:
The search is successful, leading to this entry, which includes the FMA ID 61916. Coding scheme designator for FMA is FMA
, so the you can use the following code to describe the item:
(61916, FMA, "Anterior cingulate gyrus")
Using OLS, you can select the specific ontology, and search specifically in FMA for the same term, which will result in the same code:
Note that OLS is (as of writing this) using a "slimmed down version of FMA", but for common purposes perhaps this should still be sufficient.
Definition of post-coordinated codes from UMLS: https://utsreport.nlm.nih.gov/umlsreport/sourceDocs/postcoordinated.html
In DICOM, the process of choosing a code, and a coding scheme, depends on the context. In the following, we will discuss some of the guidelines that can be used to choose suitable codes for the tasks of segmentation, measurements and parametric map conversion supported by dcmqi
.
While converting segmentations, you will need to define the following coded entities in the JSON file:
SegmentedPropertyCategoryCodeSequence
SegmentedPropertyTypeCodeSequence
SegmentedPropertyTypeModifierCodeSequence (when applicable)
AnatomicRegionSequence (when applicable)
AnatomicRegionModifierSequence (when applicable)
This looks overwhelming indeed! That's why we developed to help you interactively choose the codes for each of those items. If you want to know the details, read on!
For each of these attributes, DICOM provides guidance on the selection of the suitable codes.
SegmentedPropertyCategoryCodeSequence codes are listed in context group ID (CID) (extensible, i.e., you are not forced to use only the codes from this selection)
SegmentedPropertyTypeCodeSequence codes are defined in , which points to the application-specific CIDs that you can follow for the lists of codes
SegmentedPropertyTypeModifierCodeSequence is an optional attribute that augments segmented property type code. As an example, if SegmentedPropertyTypeModifier is "Kidney", SegmentedPropertyTypeModifier can be "Left" to specify laterality. More modifier codes are available in , as an example see .
Users and commercial and open source DICOM developers can be reassured that they may continue to use the subset of SNOMED concepts in the DICOM standard in their products and software, globally and without a fee or individual license.
TBD - work in progress
anatomic codes selection.
MeasurementMethodCode (optional): code describing the model used for deriving the quantity.
ModelFittingMethodCode (optional): code describing the model fitting method.
In the future we plan to provide specific recipes that describe the sets of codes suitable for specific use-cases (e.g., estimating Apparent Diffusion Coefficient (ADC) from Diffusion-Weighted MRI, or performing pharmacokinetic modeling of the Dynamic Contrast-Enhanced MRI).
AnatomicRegionSequence and its modifier do not always have to be specified. In some situations, information contained in SegmentedPropertyType is sufficient. E.g., if one is creating an atlas, where the properties are purely anatomical, and there is no more to say about them than the anatomy, then the anatomy goes in the Segmented Property Type Code Sequence. If one has different types of properties (e.g., necrosis, enhancing rim, gross tumor volume), but one wants to say something about the anatomy (e.g., where the tumor is at), then the property goes in Segmented Property Type Code Sequence and the anatomy goes in Anatomic Region Sequence. When you do want to specify AnatomicRegion, you can consult for the list of codes. Modifier for this code is specified as needed, following the same approach as discussed for SegmentedPropertyTypeModifierCodeSequence.
we mentioned earlier provides an interactive interface to somewhat simplify the task of populating the codes discussed above.
Most, if not all codes listed in the contexts referenced earlier are from SNOMED CT, and have DICOM CodingSchemeDesignator SRT
. The reason for this is that coding scheme is the preferred controlled terminology used by DICOM . Most, if not all, of the codes used to define the entities above are from SNOMED CT. SNOMED CT maintains a systematically organized computer processable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting. SNOMED CT maintains the hierarchy of relationships among the codes, which can be used for semantic reasoning on the data. As an example, see .
Note that SNOMED CT codes included in the DICOM standard are exempt from . The details are discussed in . In short:
The following codes can be passed to describe the parametric map you are converting using :
QuantityValueCode: Quantity being measured at each pixel - select code from , or introduce a .
MeasurementUnitsCode: Units of measurement. DICOM uses code system (CodingSchemeDesignator UCUM
) to describe units. Some of the commonly used unit codes are listed in , but as discussed in , any of the UCUM codes can be used in DICOM.
DerivationCode: select code from , or introduce a .
AnatomicRegionSequence and Modifier (optional): follow the same guidelines as discussed for
Relevant development of the codes related to ADC calculation can be found in DICOM Correction Proposal (CP). These codes are expected to become part of the standard in Spring 2017.
For now, the best place to start is (select pm-schema
in the Validation schema selector) that you can use to choose an existing example and modify it to tailor to your use case.