MIRC Templates

From MircWiki
Jump to navigation Jump to search

This article provides examples of MIRC templates for MIRC users and administrators to use as guides in constructing their own.

The RSNA MIRC implementation uses XML files as templates for the automatic construction of MIRCdocuments by several of the services provided by a Storage Service:

  • the Author Service
  • the New Document Service
  • the DICOM Service
  • the TCE Service
  • the Zip Service

Templates are MIRCdocument files; that is, they conform to the MIRCdocument XML schema, extended to include elements that instruct the MIRC automatic document construction mechanism how to insert data from a file into the MIRCdocument. For detailed information on the template elements, see the Template Elements section of The MIRCdocument Schema.

Because templates are XML files, it is critical that they be well-formed, or the system will reject them. For a brief introduction to XML, see the XML Primer.

1 Author Service Templates

The Author Service provides several templates to give users starting points when they create new MIRCdocuments. Author Service templates are generally simple skeletons of MIRCdocuments. Users add components (text, images, etc.) to a skeleton using the Author Service editor and then save the result as a new MIRCdocument.

The example below shows a simple Author Service template for an mstf MIRCdocument. 

<?xml version="1.0" encoding="UTF-8"?>
<MIRCdocument display="mstf">
    <title>Enter a title here</title>
    <section heading="History">
    	<p/>
    </section>
    <section heading="Findings">
    	<p/>
    </section>
    <section heading="Diagnosis">
    	<p/>
    </section>
    <section heading="DDx">
    	<p/>
    </section>
    <section heading="Discussion">
    	<p/>
    </section>
    <image-section heading="Images" image-pane-width="600"/>
    <document-type>Radiologic Teaching File</document-type>
    <publication-date/>
</MIRCdocument>

Note that no title, author, abstract, or keywords elements are included. The Author Service generates these elements automatically if they are missing in the template. The elements are not forbidden, however, so if you are constructing a template for a special purpose, you can preload these elements by placing them in the template.

Note also the HTML paragraph elements in the various section elements. These are not necessary because the user can insert them with buttons in the editor, but they are a convenience.

Text may be preloaded in any element in the template. For example, if you have a standard copyright that you want to appear on all documents, you can insert a rights element containing the standard text.

Author Service templates do not normally contain any of the special template elements which automatically insert data from files since they are not used by the automatic document generator.

2 New Document Service Templates

The New Document Service provides a single template for the creation of a new MIRCdocument from the contents of a form and any files which the user has attached. It is stored in the Storage Service's newdoc directory under the name template.xml.

The default template is shown below. 

<?xml version="1.0" encoding="iso-8859-1"?>

<MIRCdocument display="mstf" first-tab="2">

    <title>Untitled</title>

    <author>
        <name>Anonymous</name>
        <affiliation/>
        <contact/>
    </author>

    <abstract><p>None.</p></abstract>

    <keywords/>

    <section heading="History">
    </section>

    <image-section heading="Images">
    <insert-megasave width="512"/>
    </image-section>

    <section heading="Findings">
    </section>

    <section heading="Notes">
    </section>

    <section heading="Files">
        <p>
            <metadata-refs/>
        </p>
    </section>

    <document-type>radiologic teaching file</document-type>
    <findings/>
    <discussion/>
    <differential-diagnosis/>
    <diagnosis/>
    <anatomy/>
    <pathology/>
    <organ-system/>
    <modality/>
    <category/>
    <level/>

    <authorization>
        <owner/>
        <read/>
        <update/>
        <export/>
    </authorization>

</MIRCdocument>

Notes:

  • Values from the submission form are automatically inserted into the title, author, abstract, and authorization elements.
  • The section elements generate places in the form for the creation of content by the user.
  • The order of the section and image-section elements determines their order in the created MIRCdocument.
  • You can add section elements with different heading attributes to include additional sections in the created MIRCdocument.
  • The Notes section is used to receive the contents of any text files that are submitted along with the form.
  • The insert-megasave element provides the insertion point for images.
  • The metadata-refs element provides the insertion point for non-image files.
  • Although you can remove the Notes and Files sections, doing so reduces the capability of the service to handle non-image files.
  • All the other elements are not filled in by the New Document Service, but are present in the created MIRCCdocument so that they may be edited by the Author Service if necessary.

3 Zip Service Templates

The Zip Service uses templates to construct MIRCdocuments and insert files into them. See the Zip Service User's Manual for an overview of its operation. The Zip Service has a default template which is stored in the Storage Service's submit directory under the name template.xml.

The default template is shown below. 

<?xml version="1.0" encoding="iso-8859-1"?>
<MIRCdocument display="tab" first-tab="1">

    <title>Untitled</title>

    <author>
        <name>Anonymous</name>
        <affiliation/>
        <contact/>
    </author>

    <abstract><p>None.</p></abstract>

    <keywords/>

    <section heading="Notes">
    </section>

    <image-section heading="Images">
        <insert-megasave width="512"/>
    </image-section>

    <section heading="Files">
        <p>
            <metadata-refs/>
        </p>
    </section>

    <document-type>radiologic teaching file</document-type>
    <findings/>
    <discussion/>
    <differential-diagnosis/>
    <diagnosis/>
    <anatomy/>
    <pathology/>
    <organ-system/>
    <modality/>
    <category/>
    <level/>

    <authorization>
         <owner/>
         <read/>
         <update/>
         <export/>
    </authorization>

</MIRCdocument>

Notes:

  • All the elements that are to be included in the document must be present in the template.
  • Values from the submission form are automatically inserted into the author and authorization elements.
  • The abstract and keywords elements are filled in automatically from the path information in the zip file.
  • The Notes section is used to receive the contents of any text files that are encountered in the document's directory in the zip file.
  • The insert-megasave element provides the insertion point for images.
  • The metadata-refs element provides the insertion point for non-image files.

Note also that the elements: 

    <findings/>
    <discussion/>
    <differential-diagnosis/>
    <diagnosis/>
    <anatomy/>
    <pathology/>
    <organ-system/>
    <modality/>
    <category/>
    <level/>

are not actually modified by the Zip Service. They are shown in the template only as an indication of where you might include static text when creating special purpose templates. For example, if you were creating a template for a large number of MR cases, you could preload the modality element in a template.xml file that could be included in the root directory of the zip file, thus overriding the default template and causing all the created MIRCdocuments to be indexed as containing MR data.

Zip Service templates can also contain DICOM template elements. This is not typically done for documents being created for teaching files, so they are not shown in the template above. For some special purposes, however, you can use the block and GxxxxEyyyy elements to capture data from DICOM objects inserted into the MIRCdocument.

4 DICOM Service Templates

The DICOM Service is used for clinical trials and research dataset acquisition. It creates or updates MIRCdocuments whenever it receives a DICOM object. It creates one MIRCdocument for each study (e.g., one SOP Instance UID) and adds all the objects that it receives for the study into that MIRCdocument. The DICOM service uses a template that is stored in the Storage Service's trial directory under the name template.xml.

The standard template is shown below. 

<?xml version="1.0" encoding="UTF-8"?>
<MIRCdocument display="tab" first-tab="4">

    <title>
        <g0010e0010 desc="Patient's Name"/> 
        <g0008e0060 desc="Modality"/> Study - <g0008e0020 desc="Study Date"/>
    </title>

    <author>
        <name><g0008e0080 desc="Institution Name"/></name>
        <contact><g0018e1030 desc="Protocol Name"/></contact>
    </author>

    <abstract>
        <p>
            Patient's Name: <g0010e0010 desc="Patient's Name"/><br/>
            Patient ID: <g0010e0020 desc="Patient ID"/><br/>
            Study Date: <g0008e0020 desc="Study Date"/><br/>
            <g0032e4000 desc="Study Comments"/>
        </p>
    </abstract>

    <section heading="Demographic Data">
        <p>
            <table border="1">
                <g0010e0010 desc="Patient's Name"/>
                <g0010e0020 desc="Patient ID"/>
                <g0010e1090 desc="Medical Record Locator"/>
                <g0010e0030 desc="Patient's Birth Date"/>
                <g0010e1010 desc="Patient's Age"/>
                <g0010e0040 desc="Patient's Sex"/>
                <g0008e0060 desc="Modality"/>
                <g0018e0015 desc="Body Part Examined"/>
                <g0008e0050 desc="Accession Number"/>
                <g0008e0020 desc="Study Date"/>
                <g0008e0030 desc="Study Time"/>
                <g0008e002A desc="Acquisition Datetime"/>
                <g0008e0022 desc="Acquisition Date"/>
                <g0008e0032 desc="Acquisition Time"/>
                <g0020e000D desc="Study Instance UID"/>
                <g0008e0018 desc="SOP Instance UID"/>
            </table>
        </p>
    </section>

    <section heading="Metadata References">
        <metadata-refs/>
    </section>

    <image-section heading="Images">
        <insert-megasave width="512"/>
    </image-section>

    <section heading="not visible" visible="no">
        <patient>
            <pt-name><g0010e0010 desc="Patient's Name"/></pt-name>
            <pt-id><g0010e0020 desc="Patient ID"/></pt-id>
            <pt-mrn><g0010e1090 desc="Medical Record Locator"/></pt-mrn>
            <pt-sex><g0010e0040 desc="Patient's Sex"/></pt-sex>
        </patient>
        <modality><g0008e0060 desc="Modality"/></modality>
        <anatomy><g0018e0015 desc="Body Part Examined"/></anatomy>
    </section>

    <document-type>research dataset</document-type>

    <authorization>
        <owner>admin</owner>
        <read/>
        <update/>
        <export/>
    </authorization>

</MIRCdocument>

Notes:

  • The title element is generated in the form: Perry^John MR Study - 20060101.
  • The author element is taken from the institution name and protocol in the first DICOM object received for the study.
  • The Demographic Data section uses a special feature of the DICOM element, described below, to generate table rows with row labels.
  • The insert-megasave element provides the insertion point for images.
  • The metadata-refs element provides the insertion point for non-image files.
  • The not visible section shows how data can be acquired into a MIRCdocument for indexing purposes without being displayed when the document is viewed.
  • Since the DICOM Service has no way to obtain the owner of document, the owner's username is preloaded in the template.
  • If predefined privileges for reading, updating, an exporting are known for the trial, they can be preloaded in the template.

Normally, a DICOM element simply extracts data from the element in the object and inserts it in the MIRCdocument as is seen in the title element in the template.

When DICOM elements are first-generation children of a table element, however, they automatically generate one row with two data elements, one containing the name of the DICOM element and one containing that element's data from the object. The name of the element is obtained from a table in the DICOM software library. If the element is not known to the software (for example, because it is a private element), the name is taken from the DICOM element's desc attribute.

When a DICOM element is encountered by the document generator, it is replaced by its value in the object. This means that the values come from the first object received for the study. If it is desired to capture data from all DICOM objects received, then the block template element must be used. The following fragment shows a section element that will contain a series of tables, one for each object received. 

<section heading="Elements">
    <p>
        Institution Name: <g0008e0080/>
    </p>
    <block>
        <p>
            <table border="1">
                <g0010e0010 desc="Patient's Name"/>
                <g0010e0020 desc="Patient ID"/>
                <g0010e1090 desc="Medical Record Locator"/>
                <g0010e0030 desc="Patient's Birth Date"/>
                <g0010e1010 desc="Patient's Age"/>
                <g0010e0040 desc="Patient's Sex"/>
                <g0008e0060 desc="Modality"/>
                <g0018e0015 desc="Body Part Examined"/>
                <g0008e0050 desc="Accession Number"/>
                <g0008e0020 desc="Study Date"/>
                <g0008e0030 desc="Study Time"/>
                <g0008e002A desc="Acquisition Datetime"/>
                <g0008e0022 desc="Acquisition Date"/>
                <g0008e0032 desc="Acquisition Time"/>
                <g0020e000D desc="Study Instance UID"/>
                <g0008e0018 desc="SOP Instance UID"/>
            </table>
        </p>
    </block>
</section>

The block element can be used anywhere to preserve its contents for application to subsequent objects that are inserted into the MIRCdocument. The following fragment shows an HTML table element that will contain one row from each DICOM object, with each row showing the Instance Number and the corresponding SOP Instance UID. 

<section heading="Instance Table">
    <p>
        <table border="1">
            <tr>
                <th>Instance Number</th>
                <th>SOP Instance UID</th>
            </tr>
            <block>
                <tr>
                    <td><g0020e0013 desc="Instance Number"/></td>
                    <td><g0008e0018 desc="SOP Instance UID"/></td>
                </tr>
            </block>
        </table>
    </p>
</section>

Note that the reason that the individual DICOM elements do not generate complete rows themselves in this case is that they are not first-generation children of the table element.

5 TCE Service Templates

The TCE Service processes DICOM transmissions received from an IHE TCE Export Manager. These files consist of a manifest, a set of instances, and possibly an Additional Teaching File Information (ATFI) object. All are DICOM objects. The manifest and the ATFI object are examples of DICOM Key Object Selection documents in the forms defined by IHE.

The TCE Service uses a template to create a MIRCdocument for each manifest received. The template is stored in the Storage Service's tce directory under the name template.xml.

The standard TCE template, although it is a separate file stored in a separate place, is identical in contents to the default Zip Service template.

Notes:

  • The Notes section is used to capture the Key Object Description text from the manifest. The full text is inserted in the section, but it is also parsed according to rules defined by MIRC. If the contents match the MIRC-defined rules, they used to update the text values of other elements as described in the TCE Service User's Manual.
  • The ATFI object is also parsed, and its contents are used to update the text contents of other elements.

6 Advanced Topics

The a and iframe elements from the MIRCdocument schema can be used to integrate a MIRCdocument into an environment outside the MIRC site itself. This section provides a few examples of their application in a use case in which an automatically generated MIRCdocument is to be integrated with the contents of a report broker.

In these examples, the systems are assumed to be in a secure environment which allows PHI to be preserved in DICOM objects and MIRCdocuments.

The report broker is assumed to provide access to a report through a URL containing a query string identifying the patient ID and the accession number of the study in the form: 

http://broker?ptid=1234&an=5678

6.1 Linking to a Report

Using the a element and its href child element, one could insert a link into a paragraph like this: 

<section heading="Report">
    <p>
        <a>
            <href>
                 http://broker?ptid=<g0010e0020/>+an=<g0008e0050/>
            </href>
            View the report
        </a>
    </p>
</section>

When the document is generated in response to the receipt of a DICOM object, the href attribute is automatically constructed from the PatientID and AccessionNumber elements of the DICOM object.

In this example, the report is displayed in a separate window when the link is clicked. All the HTML attributes of the a element are supported, so other target values (or no target value) can be set as desired.

Note the use of the plus sign (+) as the separator for the query parameters. Plus signs are converted to XML ampersand entities when the document is rendered.

6.2 Linking to a Report through a URL in a DICOM Element

The previous example could also be coded using the special attribute syntax if the complete URL is available in a DICOM element. Assume that the element (0021,0040) contains the complete URL, perhaps constructed by the anonymizer in a TCE Export Manager. The following syntax could then be used: 

<section heading="Report">
    <p>
        <a href="@g0021e0040">View the report</a>
    </p>
</section>

6.3 Embedding a Report

Using the iframe element and its src child element, one could embed the whole page from the report broker into a paragraph like this: 

<section heading="Report">
    <p>
        <iframe frameborder="0" 
                height="100%" width="100%" 
                scrolling="no" >
            <src>
                http://broker?ptid=<g0010e0020/>+an=<g0008e0050/>
            </src>
            <a target="_blank">
                <href>
                    http://broker?ptid=<g0010e0020/>+an=<g0008e0050/>
                </href>
                View the report.
            </a>
        </iframe>
    </p>
</section>

In this example, the report is displayed within the MIRCdocument in a section entitled "Report". If the document is displayed by a browser that does not support frames, the user will see a link to the report on the broker.

This approach may not be useful in mstf documents because of the relatively small area allocated in the display for the contents of normal sections. In page and tab documents, where adequate space is always available, it can be expected to work well.

It is important to embed the iframe element in a paragraph to preserve it in case the document is edited in the Author Service.

Note again the use of the plus sign (+) as the separator for the query parameters.

Retrieved from "http://mircwiki.rsna.org/index.php?title=MIRC_Templates&oldid=2638"