The MIRC TCE Service

This article describes how to configure the TCE Service. It is intended for MIRC administrators and for third-party developers intending to interface their products to the TCE Service.

The TCE Service implements the Export Receiver actor defined in the IHE TCE Integration Profile. The TCE Service is implemented in a CTP pipeline. The function of the pipeline is to receive objects and to group them into teaching file cases as defined by a manifest supplied with the objects by the sending system (typically a PACS workstation). The pipeline can be configured as described in [[1]].

1 Standard TCE Export Receiver Functions

The TCE Service contains and DICOM Storage SCP that receives manifests, Additional Teaching File Information (ATFI) objects, and DICOM instances from an IHE Export Manager. The TCE Service pipeline includes a special TCEStorageService that creates a MIRCdocument from all the objects identified in a manifest. As such, it fully meets the requirements of a TCE Export Receiver.

2 MIRC Extensions to the TCE Profile

The MIRC TCE Service implementation provides several extensions to the IHE TCE profile, including the ability to parse the Key Object Description element in the manifest to obtain information not provided in the profile, and the ability to accept a manifest as an XML MIRCdocument template.

2.1 Key Object Description

The Key Object Description element in the IHE manifest is an Unlimited Text DICOM element. Some PACS vendors provide a user interface on the Export Selector (typically a PACS workstation) allowing the user to populate this element with comments. Since the TCE specification does not provide elements for certain fields of interest to teaching file authors, MIRC implements a syntax for the element and parses it whenever a manifest is received.

The syntax allows character sequences in the form mirc:path=value to be inserted anywhere in the element text, where path defines the path from the root element of the MIRCdocument to the element whose value is to be modified and value is the value to be inserted in the element. Paths do not include the root element name. Whitespace is not allowed in mirc:path=. Values may contain whitespace, including newline characters. Values consist of all the characters after the equal sign and before the next mirc:path=value sequence.

IHE currently does not define elements for two important fields:

• the username of the user on the teaching file system;
• the title of the created document.

The Key Object Description syntax can be used to supply these fields as shown below:

mirc:title=My Document Title
mirc:authorization/owner=myusername
mirc:freetext=

For an element in a MIRCdocument to be populated from the parsed values in the Key Object Description element, there must be an element in the TCE template.xml file which has the same path relative to the root element. Any parsed value which does not correspond to a path in the MIRCdocument is ignored.

In the example above, the last item, mirc:freetext=, is used simply to delimit the previous item and to allow users to insert comments.

The entire contents of the Key Object Description element are inserted in the Notes section of the template, allowing the author to see any unparsable notes passed in the element.

Note to third-party developers wishing to interface to the MIRC TCE Service: it is possible to place all the content of teaching file items in an ATFI object in the Key Object Description element without having to construct the ATFI object. While this is not encouraged, this approach removes the complexity of an ATFI object from the list of excuses not to implement TCE. Just do it.

3 XML Manifest

The TCE Service Pipeline has two ImportService elements, one for reception of DICOM objects via the DICOM protocol, and one for the reception of both DICOM and XML objects via the HTTP protocol.

An XML manifest is a MIRCdocument XML template that contains a special element identifying the SOPInstanceUIDs of the instances (and ATFI object, if any) for inclusion in the teaching file case.

When the TCEStorageService receives a normal TCE manifest (a DICOM KOS object). it uses a standard MIRCdocument template to control the form of the created case. When the manifest is a MIRCdocument XML template, it uses the manifest as the template for the created case. The purpose of the XML template is to allow third-party developers greater control over the format of the case and to avoid the necessity for creating either the DICOM manifest or the ATFI object, since all the information in both objects can be passed in the template itself.