Difference between revisions of "The MIRC ZipObject"
Line 14: | Line 14: | ||
*<b>version</b> provides a version reference for the manifest format. This could be used by software as an aid in interpreting its contents. | *<b>version</b> provides a version reference for the manifest format. This could be used by software as an aid in interpreting its contents. | ||
− | The manifest root element has no required child elements. The intention is that each manifest contain whatever child elements are appropriate to describe the contents of the ZipObject and their relationships with each other as well as external objects, but there is no required standard format. | + | The manifest root element has no required child elements. The intention is that each manifest contain whatever child elements are appropriate to describe the contents of the ZipObject and their relationships with each other as well as external objects, but there is no required standard format. It is expected that each application (e.g., each clinical trial or research project) will invent its own manifest within the constraints of the MIRC requirements. |
An example of a simple manifest is: | An example of a simple manifest is: | ||
Line 31: | Line 31: | ||
version="1"> | version="1"> | ||
<patient-id>123</patient-id> | <patient-id>123</patient-id> | ||
− | <series-uid>1.2.3.4.5.2</series-uid> | + | <series> |
− | <series-uid>1.2.3.4.5.3</series-uid> | + | <series-uid>1.2.3.4.5.2</series-uid> |
+ | <instance-uid>1.2.3.4.5.4</instance-uid> | ||
+ | <instance-uid>1.2.3.4.5.5</instance-uid> | ||
+ | <instance-uid>1.2.3.4.5.6</instance-uid> | ||
+ | <instance-uid>1.2.3.4.5.7</instance-uid> | ||
+ | </series> | ||
+ | <series> | ||
+ | <series-uid>1.2.3.4.5.3</series-uid> | ||
+ | <instance-uid>1.2.3.4.5.9</instance-uid> | ||
+ | <instance-uid>1.2.3.4.5.9</instance-uid> | ||
+ | </series> | ||
</manifest> | </manifest> | ||
</pre> | </pre> |
Revision as of 14:14, 7 November 2006
The MIRC ZipObject is a class that provides access to collections of files wrapped in a zip file. It is intended to encapsulate groups of related files, for instance, the output of analysis of clinical trial data. To carry information that allows applications to know how to relate a ZipObject to other data, each ZipObject must contain a manifest. A manifest is an XML text file named manifest.xml, located in the root of zip file's directory tree (e.g. with no path information).
The root element of a manifest can have any name. By convention, it is called manifest, but in some situations, it can be useful to use different names when a clinical trial has multiple types of ZipObjects and it is desired to make the root element name indicate the type.
The root element has two required attributes:
- uid defines a unique identifier for the ZipObject. The DICOM UID format is strongly suggested, but there is no technical requirement imposed by the RSNA MIRC implementation on the format.
- study-uid provides a reference to the study. It is necessary to link the ZipObject to the MIRCdocument containing the other objects associated with the same study. If the ZipObject contains results obtained from the analysis of DICOM images from a specific study, the DICOM StudyInstanceUID should be used.
The root element has one additional attribute which has special support in the MIRC ZipObject class:
- description is optional. It provides a free text description of the ZipObject. The RSNA MIRC implementation presents this text in the table of object references in a MIRCdocument.
Additional attributes may be included as well; however, they have no special support in the MIRC ZipObject class, for example:
- date provides a date for the ZipObject. The date must be in the format specified by ISO 8601 (YYYY-MM-DD).
- version provides a version reference for the manifest format. This could be used by software as an aid in interpreting its contents.
The manifest root element has no required child elements. The intention is that each manifest contain whatever child elements are appropriate to describe the contents of the ZipObject and their relationships with each other as well as external objects, but there is no required standard format. It is expected that each application (e.g., each clinical trial or research project) will invent its own manifest within the constraints of the MIRC requirements.
An example of a simple manifest is:
<manifest uid="1.2.3.4.5" study-uid="1.2.3.4.5.1" description="Analytical results" />
A more complex manifest might be:
<manifest uid="1.2.3.4.5" study-uid="1.2.3.4.5.1" description="Analytical results" date="2006-11-06" version="1"> <patient-id>123</patient-id> <series> <series-uid>1.2.3.4.5.2</series-uid> <instance-uid>1.2.3.4.5.4</instance-uid> <instance-uid>1.2.3.4.5.5</instance-uid> <instance-uid>1.2.3.4.5.6</instance-uid> <instance-uid>1.2.3.4.5.7</instance-uid> </series> <series> <series-uid>1.2.3.4.5.3</series-uid> <instance-uid>1.2.3.4.5.9</instance-uid> <instance-uid>1.2.3.4.5.9</instance-uid> </series> </manifest>
Important note: The RSNA MIRC implementation does not provide anonymization for ZipObjects.
The RSNA MIRC software provides a ZipObject class, org.rsna.mircsite.util.ZipObject, which provides access to the manifest, certain manifest attributes, and all the files within the zip file. See The RSNA MIRC Source Code for instructions on obtaining the source code.