AIM Templates etc - QIICR/ProjectIssuesAndWiki GitHub Wiki

Relevance

  • AIM is not used in QIICR, in preference to using DICOM SR standard templates as an encoding mechanism
  • QIICR is interested in learning about the use cases of AIM that in your opinion cannot be satisfied by DICOM SR: please contact Andrey Fedorov, fedorov AT bwh.harvard.edu to describe your use case
  • The material on this page is of background interest for assuring coverage of the use cases

AIM Templates: examples

Related discussions

On Wed, Feb 5, 2014 at 7:16 PM, David Clunie wrote:

Hi guys

In the "learning from experience" category, I took a look at some of these templates in more detail.

They all seem to follow a relatively simple question/answer pattern within major heading categories, which is easy to encode naturally as a DICOM SR.

For example, in the TCGA-KIRC kidney template, we could encode the same thing in DICOM (eliding the codes for clarity), literally following the AIM structure as:

CONTAINER: "TCGA-KIRC Tumor Report"

CONTAINER: "Image Acquisition Stuff"

TEXT or CODE: "Acquisition Protocol" = ? CODE: "Modality" = "CT"|"MR" CODE: "Contrast Phase" = "Precontrast" CODE: "Contrast Phase" = "Corticomedullary" ...

CONTAINER: "Anatomy Stuff"

CODE: "Target Region" = "Kidney" CODE: "Multiple Tumors" = "Yes"|"No"|"NA" CODE: "Number of Tumors on Left Side" = "None","1","2","3",">3","NA" CODE: "Number of Tumors on Right Side" = "None","1","2","3",">3","NA"

CONTAINER: "Dominant (largest) Tumor Characteristics"

CODE: "Pathology" = "renal adenocarcinoma" CODE: "Location" = "Right"|"Left"|"NA" CODE: "Margin" = "well-defined"|"ill-defined"|"NA" CODE: "Composition" = "solid"|"cystic"|"NA" CODE: "Necrosis" = "0%"|"1-33%"|"34-66%"|"67-100%"|"NA" CODE: "Calcification" = "Yes"|"No"|"Required images not available"|"NA" CODE: "Growth Pattern" = ">= 50% exophytic"|"<50% exophytic"|"Entirely Endophytic"|"NA"

CONTAINER: "Measurements"

NUM: "Long axis" = 99 mm

SCOORD: POLYLINE

IMAGE

Generally we don't permit "not applicable" in DICOM SR templates (either the answer has to be there, or the question or group of inapplicable questions isn't send at all).

In practice, we would probably re-use some existing templates and headings to describe the acquisitions, and anatomy ("Target Region"), etc., for commonality with templates used in other SR applications (I have hinted at that above with my "stuff" container headings).

I notice that the coding schemes being used include SNOMED and RADLEX (already supported in DICOM), and the NCI Thesaurus, which does not have standard coding scheme designator (even though the AIM templates are using "NCIt" as if it were already defined). I will add a CP to DICOM to add "NCIt".

I also see use of a private coding scheme "99_NCI_CIP", which is fine to handle concepts not obtainable from standard schemes; I hope someone is tracking these codes so they don't get reused for something else. I also noticed a lot of them that are already standardized (e.g., the code (KIRC-02,99_NCI_CIP,"well-defined") (used for tumor margin) is already in SNOMED as (R-40771,SRT,"Well defined") and in NCIt as (C81187,NCIt,"Well-defined").

Something similar is also in RadLex: (RID45665,RADLEX,"moderately well-defined margin"); there is no plain "well defined" there (I guess that's a radiologist not willing to commit :)). There are lots of other good "margin" related codes in RadLex though.

I mention this since we should make every effort in QIICR to use standard codes for questions and answers for maximum re-usability and search-ability.

One of the other things I notice is that though all the values are coded, the questions are not! E.g., for the "Tumor Margin" question, there is just a plain text label. IMHO this is bad, and any SR templates we create will require codes (this is a DICOM requirement, since all SR questions are coded).

Finding good codes for questions requires care; for example, a code from SNOMED that is intended for the concept of pathological involvement of margins in resected tumors might read "tumor margin" but mean something quite different. We created a code in DICOM to handle this for that reason, (111037,DCM,"Margins"), defined as "the characteristic of the boundary, edges or border of a detected lesion", before RadLex existed. Now we would probably use (RID5972, RADLEX,"margin") instead.

One stylistic thing I see in some of these types of templates is a count of things, where above a certain number it is sent with a code for greater than, and there is also a not applicable, and a bunch of unnecessary codes are "made up" for the enumerations (i.e., a code for 1, a code for etc.). One can handle this more elegantly with a more complex template, but if one wants to stick to a single coded answer, one can use UCUM (units of measure), which allows a code for a unit that is a single digit (e.g., "1", "2", etc.), rather than making up codes for "1 tumor", "2 tumors", etc.

E.g., instead of (KIRC-44,99_NCI_CIP,"3") one could use (3,UCUM,"3"), and then one only needs to "make up" new codes for ">3", etc. UCUM also allows what is being counted to be communicated, though it doesn't affect the dimensionless physical unit (e.g., "3{tumors}").

David

PS. The templates use "RadLex" as the coding scheme designator, rather than the correct "RADLEX", by the way; these are case sensitive so this matters.

On Sunday, March 11, 2012 2:02:54 PM UTC-4, David Clunie wrote:

It also isn't necessary, since it addresses

a problem already solved by DICOM SR and HL7 CDA ROIs.

This is interesting, as I was convinced that AIM, stored as DICOM SR

instead of XML, had to be seen as a DICOM SR following a strict template.

Once can certainly transcode an AIM instance into a DICOM SR using

a mechanical process without loss of information, and that was

one of the original goals of the project, but the result is not

something that looks much like a DICOM SR "should", and hence it

becomes more difficult to data mine and render using ordinary SR

approaches (see below).

For any particular use-case, there is a need for a formal (or

informal)

"template" that is applied to constrain the pattern of encoding and

the concepts an values; this is true whether one uses AIM or "native"

SR< but AIM as an unnecessary and unhelpful additional "abstraction",

which is, unfortunately, inconsistent with all the other DICOM PS 3.16

templates that are used for similar purposes.

You should use DICOM SR instead (+/- supporting objects like RT

Structure Sets, Segmentations and Presentation States as appropriate).

My interest would go out to storing separate findings as DICOM SR's

containing the semantic data as it is defined in AIM (observation

(0-n), anatomy (0-n), equipment, user,etc.) for the sake of data

mining, together with references to DICOM objects (1-n) such as

images, wave forms, etc. and numerical data (0-n) as a result of

measurements or analysis.

There are certainly existing DICOM SR templates and content items that

can be assembled to do just that sort of thing.

A commonly used pattern, for example, is TID 300 Measurement, which is

used a lot in ultrasound reports. A flat list of these, perhaps nested

in a section container, may suffice for your purposes.

A general pattern that is used in DICOM SR templates is to make sure

that the numeric content item has a coded concept name that is

meaningful, or that a finding or observation has a meaningful

"question" in the coded concept name paired with a meaningful value

(chosen from a constrained value set specified in the template). This

greatly facilitates data mining and extraction and rendering.

So for example, in a DICOM SR template we might say using TID 300:

NUM: (G-A185,SNM3,"Long_Axis") = 39.579597 (mm,DCM,"mm")

HAS CONCEPT MOD: CODE: (G-C0E3,SRT,"Finding Site") =

(T-28201,SRT,"Right Upper Lobe of Lung")

INFERRED FROM: SCOORD: (121112,DCM,"Source of Measurement") =

POLYLINE {143,300,92,326}

SELECTED FROM: IMAGE: =

(1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.9328.50.1.10717) [Frame 0]

Whereas in AIM, to say the same thing might translate into:

CONTAINS: CONTAINER: (zzz002,99NCIAIM,"Annotation") [SEPARATE]

CONTAINS: CONTAINER: (zzz033,99NCIAIM,"Anatomic Entities")

[SEPARATE]

HAS OBS CONTEXT: CODE: (zzz008,99NCIAIM,"Anatomic Entity") =

(REX0001,RADLEX,"LUNG")

HAS OBS CONTEXT: CODE: (zzz008,99NCIAIM,"Anatomic Entity") =

(REX10003,RADLEX,"RIGHT UPPER LOBE")

CONTAINS: CONTAINER: (zzz011,99NCIAIM,"Calculation") [SEPARATE]

HAS CONCEPT MOD: CODE: (zzz012,99NCIAIM,"Calculation Type") = (G-

A185,SNM3,"Long_Axis")

HAS ACQ CONTEXT: UIDREF: (112040,DCM,"Tracking Unique

Identifier") = "0"

HAS ACQ CONTEXT: TEXT: (112034,DCM,"Calculation Description") =

"Linear Measurement"

CONTAINS: CONTAINER: (zzz015,99NCIAIM,"Calculation Result")

[SEPARATE]

HAS OBS CONTEXT: CODE: (zzz016,99NCIAIM,"Calculation Result

Type") = (crt001,99NCIAIM,"Scalar")

HAS OBS CONTEXT: TEXT: (zzz017,99NCIAIM,"Number of Dimensions")

= "1"

CONTAINS: CONTAINER: (zzz038,99NCIAIM,"Calculation Dimensions")

[SEPARATE]

CONTAINS: CONTAINER: (zzz039,99NCIAIM,"Calculation Dimension")

[SEPARATE]

HAS ACQ CONTEXT: TEXT: (zzz040,99NCIAIM,"Dimension Index") =

"0"

HAS ACQ CONTEXT: TEXT: (zzz041,99NCIAIM,"Dimension Size") =

"1"

HAS ACQ CONTEXT: TEXT: (zzz018,99NCIAIM,"Dimension Label") =

"Length"

CONTAINS: CONTAINER: (zzz019,99NCIAIM,"Calculation Result

Datum") [SEPARATE]

HAS OBS CONTEXT: NUM: (zzz020,99NCIAIM,"Calculation Result

Data") = 39.579597 (mm,DCM,"mm")

HAS ACQ CONTEXT: CONTAINER: (zzz042,99NCIAIM,"Calculation

Result Coordinate") [SEPARATE]

HAS OBS CONTEXT: TEXT: (zzz040,99NCIAIM,"Dimension Index") =

"0"

HAS OBS CONTEXT: TEXT: (zzz043,99NCIAIM,"Coordinate

Position") = "0"

CONTAINS: CONTAINER: (zzz030,99NCIAIM,"Image Annotation")

[SEPARATE]

HAS ACQ CONTEXT: CODE: (zzz048,99NCIAIM,"Image Annotation Type")

= (iat001,99NCIAIM,"RECIST_Baseline_Target_Lesion")

CONTAINS: CONTAINER: (zzz027,99NCIAIM,"Geometric Shapes")

[SEPARATE]

CONTAINS: CODE: (zzz022,99NCIAIM,"Geometric Shape") =

(zzz023,99NCIAIM,"2D Geometric Shape")

HAS PROPERTIES: SCOORD: (zzz044,99NCIAIM,"Annotation Shape") =

POLYLINE {143,300,92,326}

SELECTED FROM: IMAGE: =

(1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.9328.50.1.10717) [Frame 0]

HAS PROPERTIES: CODE: (zzz021,99NCIAIM,"Include Flag") =

(R-00339,SRT,"No")

HAS PROPERTIES: TEXT: (112039,DCM,"Tracking Identifier") = "-1"

(this is from an old example, and may not be representative of the

more recent AIM model or DICOM SR translation of it, and the RadLex

codes may not be valid).

To be fair, and to also include all the extra stuff like the RECIST

lesion type, the tracking identifier and stuff, in DICOM SR I would

problem write it something like this (extending TID 300 modifiers,

and adding the UID and human readable label (which are from DICOM

TID 4108 as used in CAD)):

NUM: (G-A185,SNM3,"Long_Axis") = 39.579597 (mm,DCM,"mm")

HAS CONCEPT MOD: CODE: (RP-100022,99RPH,"Timepoint Baseline") =

(R-0038D,SRT,"Yes")

HAS CONCEPT MOD: CODE: (G-C0E3,SRT,"Finding Site") =

(T-28201,SRT,"Right Upper Lobe of Lung")

HAS OBS CONTEXT: UIDREF: (112040,DCM,"Tracking Unique Identifier")

= "0"

HAS OBS CONTEXT: TEXT: (112039,DCM,"Tracking Identifier") = "-1"

INFERRED FROM: SCOORD: (121112,DCM,"Source of Measurement") =

POLYLINE {143,300,92,326}

SELECTED FROM: IMAGE: =

(1.2.840.10008.5.1.4.1.1.2,1.3.6.1.4.1.9328.50.1.10717) [Frame 0]

Or, depending on what else I had to say about a time point, I might

nest the measurements in an outer container that defined the time

point characteristics (identifier, days from enrollment, date of

imaging studies used, etc.).

Likewise, in DICOM SR one would encode categorical observations as

simple CODE content items, with the concept name representing a

"question" and the concept value representing the answer, e.g.:

HAS OBS CONTEXT: CODE: (REX4001,RADLEX,"Conspicuity") =

(REX4007,RADLEX,"Extremely Obvious")

whereas in AIM this might be:

HAS OBS CONTEXT: CODE: (zzz009,99NCIAIM,"Imaging Observation") =

(REX4001,RADLEX,"Conspicuity")

HAS PROPERTIES: CONTAINER: (zzz032,99NCIAIM,"Imaging Observation

Characteristics") [SEPARATE]

HAS OBS CONTEXT: CODE: (zzz010,99NCIAIM,"Imaging Observation

Characteristic") = (REX4007,RADLEX,"Extremely Obvious")

I.e., there is no artificial encoding of the structure of the AIM

class that is an Imaging Observation, or a Calculation, etc.

My point being though, that layering the generality of the AIM model

on top of SR (which has its own general model that AIM redundantly

replicates gratuitously differently), makes "data mining" a bit

harder.

David

PS. More complex structures may be appropriate when there is a lot

more application level interoperability required and a more extensive

data model (e.g., when doing clinical trials one also needs more

complex models that include multiple findings about each lesion,

categorical and quantitative, multiple samples, multiple methods,

multiple readers, multiple time points, multiple modalities, an

audit trail record of changes and corrections, links to the

worklist, identification and description of multiple readers and

adjudicators, presentation state captured at time of measurement,

etc.).