|Home | About | Journals | Submit | Contact Us | Français|
The Integrating the Healthcare Enterprise (IHE) Teaching File and Clinical Trial Export (TCE) integration profile describes a standard workflow for exporting key images from an image manager/archive to a teaching file, clinical trial, or electronic publication application. Two specific digital imaging and communication in medicine (DICOM) structured reports (SR) reference the key images and contain associated case information. This paper presents step-by-step instructions for translating the TCE document templates into functional and complete DICOM SR objects. Others will benefit from these instructions in developing TCE compliant applications.
Integrating the Healthcare Enterprise (IHE) is an initiative founded and supported by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS). IHE defines profiles for using existing standards to solve incompatibilities between health information systems.1 The Teaching File and Clinical Trial Export (TCE) profile describes actors and transactions for exporting key images from an image manager/archive (i.e., picture archiving and communication system or PACS) to a teaching file, clinical trial, or electronic publication application.2
The TCE actors include export selector, export manager and receiver (Fig. 1). The export selector is a system that provides an interface for selection of key images and input of case information; and it generates the necessary structured reports for export. Ideally, it is grouped with the image manager/archive. The export manager is a system that pseudonymizes the case attributes in the digital imaging and communication in medicine (DICOM) images and the structured reports, then exports to a receiver. The receiver is a system that accepts key images and structured reports, and it is the target destination of the case.
The TCE transactions include store export selection and store additional teaching file information. The transactions store instances [RAD-50] and export instances [RAD-53] do not require the creation of DICOM structured report (SR) objects and are out of the scope of this paper. The store export selection [RAD-51] transaction is a mandatory component of the profile and requires the creation of an export selection manifest, which is a specialized DICOM key object selection (KOS) SR object that references the exported key images and their intended destination. The store additional teaching file information [RAD-52] transaction is an optional component of the profile and requires the creation of an additional teaching file information (ATFI) object—a specialized DICOM-enhanced SR object that stores information about the case, including the author, diagnosis, pathology, and anatomic location.3,4
Figure 1 presents the workflow for the TCE profile. Key images are selected via the export selector, and the manifest is generated. In addition, the ATFI object is also generated. Then, the key images (i.e., instances), manifest and ATFI object are sent from the export selector to the export manager via the RAD-50, RAD-51, and RAD-52 transactions. After appropriate pseudonymization, the key images, manifest and ATFI object are sent from the export manager to the receiver via the RAD-53 transaction. The profile does not require that all the case objects are sent together; however, given that the manifest references the key images and ATFI, it is able to group them appropriately upon receipt.
All DICOM SR objects are composed of modules with attributes. Some modules are common to all DICOM SR objects, whereas others are specific to the type of SR.5 The specific content of an SR object is contained within the SR document content module.5 The TCE documentation includes templates outlining the required and optional attributes of the content unique to the manifest and ATFI objects. However, they do not include the attributes of the common modules required in all DICOM SR objects. To fill in the gaps, one must refer to more than 50 pages within 1,500 pages of DICOM documentation.5,6 This paper presents straightforward, step-by-step instructions for translating these complex templates into functional and complete DICOM SR objects.
Although it is possible to generate DICOM SR objects directly, the easiest method is to construct an extensible markup language (XML) file and then convert the XML file into a DICOM SR object using a DICOM toolkit.7,8 It is important to note that the XML schema is not standardized and varies across toolkits. The examples in this manuscript represent the XML schema defined by the Oldenburg Research and Development Institute for Information Technology Tools and Systems (OFFIS) DICOM toolkit (DCMTK).9 However, the instructions in this manuscript still pertain to any toolkit used. If a different toolkit is used, one must become familiar with the XML schema of that toolkit and should use this paper as a guide to understanding the manifest and ATFI objects.
DICOM SR objects, like all DICOM objects, require three globally unique identifiers (UIDs): study instance UID, series instance UID, and service–object pair (SOP) instance UID. The study instance UID and series instance UID identify the study and series, respectively, within which the object is a member.10 The SOP instance UID is unique to each object. Example methods for generating DICOM-compliant UIDs are documented (DICOM News Group http://groups.google.com/group/comp.protocols.dicom/search?q=UID+root).
The key images will have already been assigned these UIDs. The manifest and ATFI objects adopt the same study instance UID of the key images; however, an SR document does not reside in a series of images.5 Therefore, a single unique series instance UID is generated and applied to both documents. Finally, each object must have its own unique SOP instance UID. After generating the manifest and ATFI objects, the final study will contain multiple series; each series will contain its associated key images plus an additional series containing the manifest and ATFI; and the manifest and ATFI objects will be identified by their own SOP Instance UID.
The TCE profile defines the manifest as an instance of the KOS SOP Class and describes the manifest template, which is a specialization of the DICOM KOS template.6 However, generating a functional manifest actually starts with the KOS information object definition (IOD).5 The IOD outlines all modules that makeup a KOS object. Each module is either mandatory (“M”), conditional (“C”), or user optional (“U”). Herein, all TCE specific attributes of the manifest are addressed, as well as the mandatory common modules with their mandatory attributes.
It is easiest to follow the modules in the order they are listed in Table 1. Table 2 lists all mandatory attributes of the modules that are common between the Manifest and ATFI objects. Included are the name of the attribute, its requirement status (“Type”), and its description. If an attribute type is “1” it is mandatory and must contain a valid value. If it is “1C” it is mandatory if the stated condition is met and must contain a valid value. If it is “2” it is mandatory, but it may contain a null value. In addition, the attribute description section may contain enumerated value definitions and a note regarding the use of the specific attribute.
The process begins with the SOP common module, which identifies the manifest as a key object selection document SOP class and contains the generated SOP instance UID (see “Generating DICOM SR Objects” above). The patient module identifies the patient’s name, ID, date of birth, and gender. The general study module identifies the study instance UID, study date and time, referring physician’s name, study ID, and accession number. Finally, the general equipment module identifies the manufacturer of the equipment that produced the associated key images. Information for the patient module, the general study module, and the general equipment module can be obtained directly from the associated key images and should be the same between all key images, the manifest, and ATFI objects in the same study. Figure 2 is example XML code for these common structured report attributes.
Table 3 lists all mandatory attributes of the modules that are specific to the manifest. The key object document series module identifies the modality, series instance UID, and series number. The modality for a manifest is “KO,” the series instance UID is the newly generated UID that will contain the manifest and ATFI, and the series number can be an arbitrary number that has not already been assigned to one of the selected key images. It is recommended that the DICOM header of the selected key images be read to identify the highest series number already in use and assign the number just above that as the manifest series number. The referenced performed procedure step sequence attribute uniquely identifies the performed procedure step SOP instance for which the series was created and is a mandatory attribute but will be sent as null for the purposes of the manifest. By leaving it out of the XML file, the OFFIS DCMTK will generate the element with null value in the final DICOM SR object. The key object document module identifies the instance number (embedded in the <instance> element in Fig. 2) and the date and time that the manifest was created (embedded in the <content> element in Fig. 4). In addition to being referenced in the SR document content module (described below), all key images must also be referenced in the current requested procedure evidence sequence. Here, the study instance UID is listed again. The SOP Class UID and SOP Instance UID of each key image are referenced (embedded in the <value> element in Fig. 3), and they are grouped in their respective series, referencing the series instance UID. In the tables and templates, the “>” symbol (not to be confused with the same symbol used as the last character in an XML tag) represents the embedment depth of the element. For example, the referenced SOP Class UID and referenced SOP Instance UID of each image are embedded within the referenced SOP sequence, which in turn, is embedded within the referenced series sequence (Table 3).
The SR document content module represents the meat of the manifest. This module defines the information required in the manifest and is used in combination with the export selection manifest template, as outlined in the TCE documentation (Table 4).2 The module begins by identifying the date and time the content was generated. Then, according to the manifest template, comes the container, a specialized value type that contains all the content information. The container is flagged as “separate,” meaning that the contents of the container are not logically linked in a continuous textual flow but rather are separate items.
Each content item in the container may contain up to four types of information: value type, relationship, concept, and value. Value type describes what type of information is represented. In addition to container, the value types used in the manifest are code, PNAME, text, image, and composite, and each will be discussed below. Refer to Table 4 and Figure 4 for the manifest content and XML code associated with each example.
Relationship describes how the item relates to its parent, the container. Three relationships are used in the manifest: has concept MOD, has OBS context, and contains.5 Has concept MOD (“has concept modifier”) is used with the CODE value type and qualifies or further describes the concept of its parent, the container. Has OBS context (“has observation context”) is used with the code and PNAME value Types and describes the individual that assembled the collection of key images as opposed to the patient. Contains is used with the text, image, and composite value types to show they are contained by their parent, the container.
The container, code, PNAME, and text value types all contain a concept, which is a code describing the concept represented by the content item. Each concept has three attributes (code value, coding scheme designator, and code meaning) called the code sequence macro that defines the method for coding the information (Table 5). At this time, IHE has defined three possible concepts for the container of the manifest (Table 4—footnote). Assuming the manifest is being generated for teaching file export, the concept of the manifest container would have a code value, coding scheme designator, and code meaning defined as “TCE001,” “IHERADTF,” and “for teaching file export,” respectively. The code sequence macro is embedded within the concept, which is embedded within the container (Fig. 4).
The value is where the actual information of a content item is stored. The different methods of storing information in the value are dependent on the value type of the content item. Each value type used in the manifest and its associated Relationship, concept, and value are described below.
CODE. All coded information, such as a coded diagnosis or observer type, is stored as a CODE value type. Both the concept and value of a CODE value type require the three attributes of the code sequence macro (Table 5). The relationship is embedded directly within the CODE. The code value, coding scheme designator, and code meaning of the concept are embedded within the concept, which is embedded within the CODE. The code value, coding scheme designator, and code meaning of the value are embedded directly within the CODE. The CODE is embedded within the container. The observer type is a CODE value type and has a relationship (“has OBS context”), a Concept (“121005,” “DCM,” “observer type”), and a value (“121006,” “DCM,” “person”). It is recommended that an observer type along with the PNAME value type person observer (see below) be identified in the manifest to aid routing to the individual that assembled the collection of key images. Both language of content item and descendants and document title modifier are CODE value types and are formatted in the same manner as the observer type.
PNAME. The person observer is stored as a PNAME value type. A person observer must be referenced with a relationship (“has OBS context”), a concept (“121008,” “DCM,” “person observer”), and a value (the first and last name of the person). The relationship and concept are embedded in the same manner as in the CODE value type. The individual’s first and last names are embedded within the value, which is embedded directly within the PNAME. The PNAME is embedded within the container.
TEXT. Any noncoded text information, such as a keyword for the case, is stored as a TEXT value type. The key object description is the disposition or the target purpose of the case. If the case is intended for the personal teaching file of John Doe, the disposition could be “John Doe’s Teaching File.” The key object description is a TEXT value type with a relationship (“contains”), a concept (“113012,” “DCM,” “key object description”), and a value (the disposition). The relationship and concept are embedded in the same manner as in the CODE and PNAME value types. The disposition is embedded as the value within the TEXT, which is embedded within the container.
IMAGE. The SOP Class UID and SOP Instance UID of each key image are stored as an IMAGE value type. The core information of the manifest is the reference to the selected key images. Key images have a relationship (“contains”) but do not have a concept. The IMAGE value is the SOP Class UID and SOP Instance UID of the referenced key image. The relationship and value are embedded directly within the IMAGE, which is embedded within the container.
COMPOSITE. The SOP Class UID and SOP Ins-tance UID of any SR object (including the ATFI) are stored as a composite value type. When an associated ATFI object accompanies the manifest, it is referenced by the manifest in a similar manner as a key image instance. The ATFI has a relationship (“contains”) and a value (the SOP Class UID and SOP Instance UID). The relationship and value are embedded directly within the COMPOSITE, which is embedded within the container.
The TCE profile defines the ATFI object as an instance of Enhanced SR SOP Class. It provides a template of both mandatory and optional information to be included in an ATFI document.2 Generating a functional ATFI object is very similar to that of generating the manifest. A DICOM key object selection object is, in fact, a specialized type of DICOM SR object. The ATFI and manifest objects both contain the same SOP common module, the patient module, the general study module, and the general equipment module (Table 6). For the ATFI, these are created in the same fashion as described in the “Export Selection Manifest” of this manuscript. The SR document series module, the SR document general module, and the SR document content module are different and warrant further discussion.
Table 7 lists all mandatory attributes of the ATFI specific modules. Figure 5 is an example XML code for the mandatory ATFI attributes. The SR document series module identifies the modality, series instance UID, and series number. The modality is “SR,” the series instance UID and series number are the same as the associated manifest. The referenced performed procedure step sequence is tagged as mandatory but will be sent as null for the purposes of the ATFI object and is omitted from the XML file when using the OFFIS DCMTK for XML to DICOM conversion. The SR document general module identifies the instance number (embedded in the <instance> element in Fig. 6) and the date and time that the ATFI object was created (embedded in the <content> element in Fig. 7).
The SR document content module represents the meat of the ATFI object. This module defines the information required for ATFI and is used in combination with the additional teaching file information template, as outlined in the TCE documentation (Table 8).2 The module begins by again identifying the date and time. Next is the container that is flagged as “separate” and contains all the ATFI information. Like the manifest, the ATFI container has a concept section defined as “TCE006,” “IHERADTF,” and “additional teaching file information” for the code value, coding scheme designator, and code meaning, respectively. However, unlike the manifest, the ATFI content items in the container fall into one of only two value types (code or text), and almost all attributes maintain a contains relationship with the container. Figure 6 demonstrates example XML code for the required ATFI content items.
According to the DICOM standard, when radiologists select key images from multiple patients, even if selected for the same educational or research focus, they must be referenced in different manifests.2 This means that if the case author selects two key images from one study of Patient A (A1 and A2) and two key images from one study of Patient B (B1 and B2), images A1 and A2 will be referenced by Manifest A and images B1 and B2 will be referenced by Manifest B. Each manifest will have its own SOP Instance UID. In addition, Manifest A will have the same series instance UID as ATFI A, and both will have the same study instance UID as images A1 and A2, likewise for Manifest B.
In addition, the DICOM standard explains that when radiologists select key images from multiple studies of the same patient separate Manifest and ATFI with their own, DICOM UIDs are required for each study.5 Thus, if images B1 and B2 are from different studies of the same patient, one copy of Manifest B (Manifest B1) will be assigned the study instance UID of image B1, and a second copy of Manifest B (Manifest B2) will be assigned the study instance UID of image B2. Each manifest will have its own SOP Instance UID and reference the SOP Instance UID of the other copy using the identical document sequence attributes outlined in Table 9, with example XML code in Figure 7 (embedded between the open <document> tag and the open <content> tag in Fig. 4). Manifest B1 and B2 are called identical documents, meaning that they both have identical information except they each have their own SOP Instance UID, they have different study instance UIDs based on the study within, which they are associated, they have different series instance UIDs, and they reference their “twin” manifest in the identical document sequence.
ATFI objects follow the same guidelines. Similar to the above example of for Manifest B1 and B2, there would also be ATFI B1 and ATFI B2 as identical documents with their own SOP Instance UIDs, and they would reference each other.
After the XML documents for the manifest and ATFI are created, they must be translated into DICOM SR objects. A DICOM toolkit reads the XML document and generates a functional DICOM SR object with the correct information associated with the appropriate DICOM elements. This is essential to the TCE profile because the export manager and receiver actors must be able to receive and interpret the manifest and ATFI as DICOM objects.
The OFFIS DCMTK toolkit was used to generate test manifest and ATFI objects for this manuscript.9 The Medical Imaging Resource Center (MIRC) export manager was installed on a standard personal computer running Windows XP Pro operating system.11 The test objects were sent to the export manager via the standard DICOM send.
The methods described have been followed to effectively generate functional, TCE-compliant manifest and ATFI objects for selection of images across multiple patients and studies. The test objects were correctly received, pseudoidentified, and queued for export by the MIRC Export Manager.2,11,12
The TCE profile presents an excellent solution for the use of standard transactions for exporting key images for education, research and publication. This paper compliments the TCE profile documentation in providing the necessary instructions for future development of TCE compliant Export Selector applications.
During this project it became apparent that the complexity seemed disproportionate to the desired objective (as described). One of the reasons is the conflict between traditional DICOM and more recent web application technology utilizing XML. Whereas there are available packages (described in paper) for converting between DICOM header information and XML and the reverse and putting DICOM wrappers around report information, maybe it is time to consider another approach.7–9,13 This new approach (DICOM 4?) would integrate XML and web application technology with the spirit of DICOM. Preliminary informal discussions with imaging modality vendors have been negative because of the large installed base. In spite of that, it is time to begin exploring a better way to do this.
The IHE TCE profile provides a standard workflow for harvesting key images for education, clinical research, and publication. This manuscript describes the TCE profile and focuses on step-by-step instructions for generating the two TCE DICOM SR objects: the manifest and ATFI report. Creating these DICOM SR objects is not a trivial task; therefore, we strive to present these instructions in a straightforward understandable manner. In addition, all the information necessary for generating this objects is contained herein. We call for widespread acceptance of this standard and implementation by PACS vendors. Although, harvesting of key images can be accomplish external to PACS, the most ideal clinical workflow calls for tight PACS integration.