...

The Markup group, shown in Figure 8, captures textual information and graphical representation as DICOM SR value type SCOORD and SCOORD3D for two dimensions and three dimensions, respectively. The available graphic types for two dimensions are point, multipoint, polyline, circle, and ellipse. Each drawing type has an x and y coordinate defined in the TwoDimensionSpatialCoordinate class. The TwoDimensionGeometricShapeEntity class has TwoDimensionSpatialCoordinate, the SOPInstance UID of the image that contains the pixel and the frame number within the referenced SOP Instance to which the reference applies. The first frame shall be denoted as frame number 1. In the case of a multi-frame image, we use the frame number from the DICOM header. Available two-dimensional graphic types [6] are as follows.

The available graphic types for three dimensions are point, multipoint, polyline, polygon, ellipse, and ellipsoid. Each drawing type has x, y, and z coordinate defined in the ThreeDimensionSpatialCoordinate class. The ThreeDimensionGeometricShapeEntity class has ThreeDimensionSpatialCoordinate as well as the frame of reference for a Series. Available three-dimensional graphic types [6] are as follows.

The TextAnnotationEntity class has coordinates captured as SCOORD or SCOORD3D graphic type as TwoDimensionMultiPoint or ThreeDimensionMultiPoint, respectively. A TextAnnotationEntity's MultiPoint implementation is expected to have no more than two coordinates that can be represented as an arrow connecting TextAnnotationEntity to a point on an image. Only the ImageAnnotation class can have markups.

Figure 8. Markup Group

The ImageReference group, as shown in Figure 9, represents an image or collection of images being annotated. The two possible types of references are DICOM and URI or web image reference. First, DICOMImageReferenceEntity associates with other classes that mimic the DICOM information model. It has one ImageStudy object that has one ImageSeries object, which in turn has one or more Image objects. The ImageStudy class has study instance UID, start date and start time, and procedure description. ImageStudy may have zero or more references to DICOM objects via the ReferencedDicomObject class. The ImageSeries class has series instance UID. The Image class has SOP class UID and SOP instance UID. The Image class has two associations with GeneralImage and ImagePlane; both classes came from the DICOM module general image and image plane, respectively. They are used to store frequently-used DICOM tags such as patient orientation, pixel spacing, and image position. The second image reference type is WebImageReference that contains a URI to an image.


Figure 9. ImageReference Group

Note that abstract classes in the AIM schema are AnnotationCollection, AnnotationStatement, ImageAnnotationStatement, AnnotationOfAnnotationStatement, AnnotationEntity, CharacteristicQuantification, CalculationResult, Entity, GeometricShapeEntity, ImageReferenceEntity, TwoDimensionGeometricShapeEntity, ThreeDimensionGeometricShapeEntity, MarkupEntity, SegmentationEntity and SpatialCoordinate. [0..1] denotes an optional occurrence of an attribute.

...

AIM annotations can only contain either one or more image annotation or annotation-of-annotation type. An image annotation is represented by the ImageAnnotation class. The class is used to annotate images. Annotation-of-annotation is represented by AnnotationOfAnnotation class. The class is used to annotate other AIM annotations for comparison and reference purposes. Each class inherits all properties of the abstract class, AnnotationEntity.
There are two root classes that can contain either ImageAnnotation or AnnotationOfAnnotation; namely ImageAnnotationCollection and AnnotationOfAnnotationCollection respectively. These are the two kinds of annotation collections that can be instantiated. An instance of ImageAnnotationCollection class contains one or more instances of related ImageAnnotation class. An instance of AnnotationOfAnnotation class may contain a collection of instances of ImageAnnotation and/or AnnotationOfAnnotation class.

Both annotation collections may contain information about the equipment (Equipment class) used to create an AIM instance and the user (User class) who created the AIM instance.

An instance of ImageAnnotation object has annotation and markup information on one or more images in the same series and study. Annotation and markup information describes particular findings of a single thing found on an image or images. For instance, if there are two nodules found on an axial image, two ImageAnnotation instances must be created. Image markups of the same nodule put on different images in the same study can be captured in a single ImageAnnotation instance. ImageAnnotation must have one or more ImageReference objects, which can be either DICOM image objects or URI (Uniform Resource Identifier) image objects. ImageAnnotation may be associated with one instance of a Person class. ImageAnnotation may have zero or more AuditTrail, SegmentationEntity, MarkupEntity (e.g. text, two-dimension geometric shape or three-dimension geometric shape), ImagingPhysicalEntity (e.g. anatomic entity), ImagingObservationEntity, InferenceEntity, CalculationEntity, TaskContextEntity, and AnnotationRoleEntity instances.

An AnnotationOfAnnotation has annotation information about one or more AIM annotations, which can be ImageAnnotation or AnnotationOfAnnotation. It is used for the purpose of comparison, reference, and annotating additional information to existing AIM ImageAnnotation or AnnotationOfAnnotation instances. An example of this type of annotation can be used to compare measurement results of the same tumor from two studies from timepoint one and two of the same patient. AnnotationOfAnnotation may have zero or more AuditTrail, ImagingPhysicalEntity (e.g. anatomic entity), ImagingObservationEntity, InferenceEntity, CalculationEntity, TaskContextEntity, AnnotationRoleEntity and AdjudicationObservation instances.

An AnnotationOfAnnotation has references to instances of ImageAnnotation or AnnotationOfAnnotation via two kinds of AIM statements, namely AnnotationOfAnnotationHasAnnotationOfAnnotationStatement and AnnotationOfAnnotationHasImageAnnotationStatement.

...

How to Extend the AIM Foundation Model

The previous section describes the AIM foundation in detail. This section provides information used to extend the AIM foundation model to store other information that is not currently available in the foundation model. As described in sections 4 and 5, the AIM information model uses UML to depict the type of information it is currently capable of collecting. The model explicitly describes how image annotation semantic contents can be stored. A class name in the model was intentionally created to inform a reader of what information is stored in the class. Each attribute in a class supports the class purpose. A relationship between classes indicates how one class works with other classes to form and capture a larger concept and information.

...

...

Guidelines to the AIM Foundation Model

This section provides a set of guidelines to extend the AIM Foundation Model. The foundation model conceptually orders classes in the AIM UML model into six groups: AIM Statements, General Information, Calculation, Image Semantic Content (Finding), Image References, and Markup. You may extend the foundation model to fit your own needs by following the criteria. If you want your additions to be included in the official NCI AIM model, please enter your request directly at https://tracker.nci.nih.gov/browse/AIM.

1. Naming Convention:
   1. A name of a class must explicitly describe what information the class will collect. It must start with a capital letter. If part of the class name has a capital abbreviation, only the first character of the abbreviation is capitalized, e.g. DICOM should be Dicom see figure 10.

Figure 10. A Class Name

Association name, figure 11, of a source class has the same name as the source class name with the first character being a lower case.

Figure 11. An Association Name of a Source Class

Association name of a target class, figure 12, has the same name as the target class name with the first character being a lower case.

Figure 12. An Association Name of a Target Class

1. 1. A source class may have or contain 1-to-0..* (zero-to-many) or 1-to-1..* (one-to-many) associations to a target class. The target association name must append "Collection", figure 13, at the end of the class name.

Figure 13. An Example of Collection

1. It must be possible to map a new class to DICOM SR data element(s). See "AIM DICOM SR templates" for more information. It is important for a user to have knowledge about DICOM SR and how to modify a DICOM SR template properly because new classes added to the model will need to be stored in DICOM format.
2. Use ISO 21090 data type for every attribute in a class. Using ISO 21090 data type provides a good foundation to convert AIM information to HL7 Clinical Document Architecture (CDA).
3. A name of any class extending from the Entity class must end with the word "Entity". A class derived from the Entity class represents an existence of a thing or concept that is not currently captured in the AIM foundation model. A new entity class can also be included if a user wants to explicitly express what information the new model will be able to store.
4. A class that can be used to construct an AIM statement must extend or inherit from the Entity class.
   1. There must be a subject and object class.
   2. A predicate must be selected from a list of existing predicate from section 4.b.4. You may use your own predicates.
   3. A name of an AIM statement shall be a concatenation between the name of a subject class, predicate and the name of object class.
5. AIM markup is modeled after DICOM 2D and 3D spatial coordinate geometries [2]. New additional markups must be able to be stored in DICOM SR format.

...

...

Extending AIM Foundation Model to AIM 4.0

AIM 4.0 model, Figure 14, is an official extension of the AIM foundation model. This extension explicitly captures lesion results and measurements derived during image-based clinical trials [7,8]. There are nine new classes that cover lesion annotation needs. Three classes were created for lesion observation as follows.

• LesionObservationEntity

The class is an abstract class that stores observations made about lesions in both clinical trial and day-to-day clinical treatments. For detailed information, see DICOM Clinical Trials Results Reporting Supplement (Working group 18).

• GeneralLesionObservationEntity

This class contains general observations made about lesions in clinical trial results and day-to-day clinical treatment that are not specific to timepoint. For detailed information, see DICOM Clinical Trials Results Reporting Supplement (Working group 18).

• TimePointLesionObservationEntity

This class contains observations made about lesions in day-to-day clinical interpretations and clinical trial results at a specific timepoint. It also includes "lesions" that are created for the purpose of calibrating scanned film or other secondary capture images. For detailed information, see DICOM Clinical Trials Results Reporting Supplement (Working group 18).

Figure 14. AIM 4.0 Model

Six classes were created for AIM statements as follows.

• AnnotationOfAnnotationHasGeneralLesionObservationEntityStatement

An instance of annotation-of-annotation may have one or more general lesion observations associated with it. AnnotationOfAnnotationHasGeneralLesionObservationEntityStatement represents a direct relationship between an instance of annotation-of-annotation and general lesion observation. If you have two general lesion observations, you will need to create two statements.
A use case: An adjudicator wants to create a general lesion observation statement from an annotation-of-annotation.
Assumption:

• An annotation-of-annotation, each with general lesion observation, was created earlier from a reader.
• There is a system capable of reading and extracting information from the annotation for further displaying, computing and manipulating purposes.

Working with AIM:

1. Create a general lesion observation instance.
2. Create an AnnotationOfAnnotationHasGeneralLesionObservationEntityStatement statement linking the annotation-of-annotation (subjects) to the general lesion observation (objects).

• AnnotationOfAnnotationHasTimePointLesionObservationEntityStatement

An instance of annotation-of-annotation may have one or more timepoint lesion observations associated with it. AnnotationOfAnnotationHasTimePointLesionObservationEntityStatement represents a direct relationship between an instance of annotation-of-annotation and timepoint lesion observation. If you have two timepoint lesion observations, you will need to create two statements.
A use case: An adjudicator wants to create a timepoint lesion observation statement from an annotation-of-annotation.
Assumption:

...

1. Create a timepoint lesion observation instance.
2. Create an AnnotationOfAnnotationHasTimePointLesionObservationEntityStatement statement linking the annotation-of-annotation (subjects) to the timepoint lesion observation (objects).

...

• GeneralLesionObservationEntityHasImagingPhysicalEntityStatement

The class is used to record a relationship between a general lesion observation entity and imaging physical entity. Each lesion observation can only be directly related to one imaging physical entity.
A use case: An imaging interpreter wants to link a general lesion observation and imaging physical annotation.

Working with AIM:

• Create an imaging physical entity instance.
• Create a general lesion observation entity instance.
• Create a GeneralLesionObservationEntityHasImagingPhysicalEntityStatement statement linking the general lesion observation entity (subjects) to the imaging physical entity (objects).

...

• ImageAnnotationHasGeneralLesionObservationEntityStatement

An instance of image annotation may have one or more general lesion observations associated with it. ImageAnnotationHasGeneralLesionObservationEntityStatement represents a direct relationship between an instance of image annotation and general lesion observation. If you have two general lesion observations, you will need to create two statements.
A use case: An adjudicator wants to create a timepoint lesion observation statement from an image annotation.

Assumption:

1. An image annotation, each with timepoint lesion observation, was created earlier from a reader.
2. There is a system capable of reading and extracting information from the annotation for further displaying, computing and manipulating purposes.

Working with AIM:

• Create a timepoint lesion observation instance.
• Create an ImageAnnotationHasTimePointLesionObservationEntityStatement statement linking the annotation-of-annotation (subjects) to the time-point lesion observation (objects).

...

• ImageAnnotationHasTimePointLesionObservationEntityStatement

An instance of image annotation may have one or more timepoint lesion observations associated with it. ImageAnnotationHasTimePointLesionObservationEntityStatement represents a direct relationship between an instance of image annotation and time-point lesion observation. If you have two general lesion observations, you will need to create two statements.
A use case: An adjudicator wants to create a timepoint lesion observation statement from an image annotation.
Assumption:

1. An image annotation, each with timepoint lesion observation, was created earlier from a reader.
2. There is a system capable of reading and extracting information from the annotation for further displaying, computing and manipulating purposes.

Working with AIM:

• Create a timepoint lesion observation instance.
• Create an ImageAnnotationHasTimePointLesionObservationEntityStatement statement linking the image annotation (subjects) to the timepoint lesion observation (objects).

...

• TimePointLesionObservationEntityHasImagingPhysicalEntityStatement

The class is used to record a relationship between a timepoint lesion observation entity and imaging physical entity. Each lesion observation can only be directly related to one imaging physical entity.
A use case: An imaging interpreter wants to link a timepoint lesion observation and imaging physical annotation.
Working with AIM:

...

You can download the AIM foundation and 4.0 models from https://wiki.nci.nih.gov/x/z4X3Ag.

...

AIM Software Toolkit

Based on the above model, an AIM programming library has been constructed to create, validate, and transform between AIM XML documents and DICOM SR. Implementors should familiarize themselves with the AIM schema and be able to deduce relationships between classes in the schema. The library is a set of APIs. It is independent from the Graphical User Interface (GUI) and workflow of an application. All interactions with the AIM library are done through AIM library APIs. In addition to the AIM library, the application would need to provide for:

...

The AIM software library is a collection of C++ application programming [10] interfaces used to construct the AIM information model based on a UML class diagram. ANIVATR is a referenced implementation of the AIM library. The ANIVATR software application validates AIM annotations and transcodes them into different artifacts, namely native AIM XML and DICOM SR. We have developed AIM annotations in DICOM SR such that they can be created and displayed in a variety of medical imaging workstations, notably the AIM on ClearCanvas workstation and eXtensible Imaging Platform (XIP) as well as in clinical imaging devices. ANIVATR reads and transcodes DICOM SR into an AIM XML representation and vice versa.

...

AIM Library

The AIM library is a C++ [9] module. It consists of two logical parts: implementation of the AIM Schema as an object model and definition of a set of operations, which can be performed on the object model.

The AIM library can be used as a linked dependency of another application. All exported library APIs are thought to conform to ANSI C++ (1998/2003). Various STL containers are used extensively throughout the library and in the public APIs.

The object model implementation creates an ANSI C++ class for each class in the AIM Schema. The Class hierarchy closely follows the AIM Schema. Each object's model class provides mutation methods (Set and Get method) for every attribute in the corresponding AIM Schema class. All changes to the class states are done via those mutation methods. The whole AIM Schema is represented by the object model through containment and inheritance.
The set of object model operations supported by the AIM library includes persisting the model in XML and DICOM SR formats. The reverse set of operations of reading XML and DICOM SR instances into the object model is supported as well.

...

Using AIM Library

To instantiate an AIM model, a software developer should start with creating either an AnnotationOfAnnotationCollection or ImageAnnotationCollection object and populating its related objects' content. All required attributes need to be populated with valid data. Optional attributes are depicted in the AIM schema with [0..1].

...

The AnnotationOfAnnotationCollection object is required to have at least one AnnotationOfAnnotation object. AnnotationOfAnnotation works very much the same way as ImageAnnotation for calculation group and image semantic content group (see section 7.c). The AnnotationOfAnnotation object must have at least one AIM statements that contains a UID of ImageAnnotation or AnnotationOfAnnotation object. AnnotationOfAnnotation may store a conclusions derived by interpreting an imaging study and/or medical history in a collection of Inference object, which stores the information as a code sequence based on a controlled terminology.
AnnotationOfAnnotation may refer to a collection of ImageAnnotation objects that can come from different studies.

The AIM model and DICOM templates do not explicitly address the issue of Study Instance UID, Series Instance UID and SOP Instance UID creation of an AnnotationOfAnnotation object. These three UIDs can be generated by AIM implementers for the purpose of creating an AIM DICOM object. When an AIM DICOM object is transformed to AIM XML or HL7 CDA, these three UIDs are not being used.

...

Operations provided by the AIM library reside in the operations/ folder of the library. All operations are performed on the object model via DCMModel and XMLModel classes.
AIMLib/operations/DCMModel.h contains operations for DICOM SR.

To read an AIM library object from the DICOM SR file, use one of the two available APIs:

...

Two more APIs are available to write AIM library object(s) to a DICOM SR file:

• WriteAnnotationToFile / WriteAnnotationsToFile will serialize AIM library object(s) into a DICOM SR.

AIMLib/operations/XMLModel/.h contains operations for AIM XML.
To read an AIM XML file into an AIM library object use:

...

The AIM development environment on Windows systems requires a few configurations. An example of how an environment may be set up follows.
Environment variables:

JAVA_HOME=c:\jdk6
BOOST_ROOT=C:\Program Files\boost\boost_1_34_1

...