3.32 Distribute Document Set on Media [ITI-32]

This section corresponds to transaction [ITI-32] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-32] is used by the Portable Media Creator to create the media content and by Portable Media Importer to read the media content.

3.32.1 Scope

In the Distribute Document Set on Media transaction the Portable Media Creator sends information to media reading actors by means of Interchange Media where it stores the information.

3.32.2 Use Case Roles

Actor: Portable Media Creator

Role: Assemble the media content and store it on the media to be distributed.

Actor: Portable Media Importer

Role: Read the Document Submission Set content of distributed media in order to access the document(s) and the relevant metadata and perform import of the documents on the media.

3.32.3 Referenced Standard

ITI TF-3: 4 Metadata used in Document Sharing profiles

DICOM PS3.10 Media Storage and File Format for Data Interchange (DICOM file format). http://dicom.nema.org/

DICOM PS3.12 Media Formats and Physical Media for Data Interchange, Annex F–- 120mm CD-R media, Annex R–- USB Connected Removable Devices, Annex V–- ZIP File Over Media, and Annex W–- Email Media. http://dicom.nema.org/

DICOM PS3.15 Security and System Management Profiles, Annex B–- Secure Transport Connection Profiles. http://dicom.nema.org/

XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A Reformulation of HTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002. http://www.w3.org/TR/xhtml1 .

XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtm-basic .

MDN: RFC3798 Message Disposition Notification. http://www.rfc-editor.org/rfc/rfc3798.txt

3.32.4 Messages

3.32.4.1 Distribute Document Set on Media

This transaction defines the interchange of XDS document submission sets on media. It specifies the requirements for a directory structure, and the physical media where stored.

The file directory structure restrictions and file organization are specified below. These are based on industry standard file systems with restrictions chosen based on experience with demonstrated interoperability in the field of reliable exchange. These are defined in Part 10 of the DICOM standard and summarized below.

The media that are supported are:

• CD-R media. The physical media specification used for the storage on CD-R is a restricted subset of the widely used CD-R media. The restrictions were chosen to ensure interoperability and media reliability. The standard directory and file structure can be recorded to the CD-R media by widely available software, but this software must be set to comply with the interoperability restrictions on recording format. This media specification relies on the healthcare experience gained by CD-R media widely used in radiology and cardiology. It is defined by Annex F in Part 12 of the DICOM standard and is also used in the IHE Radiology PDI Profile for the interchange of images,
• USB Removable Devices. This media specification encompasses a wide range of USB connected flash media, removable storage devices, etc. The standard directory and file structure can be recorded onto any of these media by any system that supports the USB Removable Device type defined by the USB Implementers Forum. This specification is defined in Annex R in Part 12 of the DICOM standard.
• Email transport of ZIP files. This media specification defines the encoding of the directory and file structure as an ordinary ZIP file (maintaining the directory structure) and attaches that ZIP file to an email message. Some additional constraints are added to the email message header to facilitate recognizing the message. This specification is defined in the annexes to part 12 of the DICOM standard called: ZIP File Media and Email media. The ZIP over Email Response Option enables the Portable Media Importer to send an acknowledgment message to the Portable Media Importer.

3.32.4.1.1 Trigger Events

The user at the Portable Media Creator wishes to transport information by the creation and transport of interchange media. The Portable Media Creator assembles the Interchange Media content and stores it on the media.

If the ZIP over Email Response Option is supported, the Portable Media Importer shall detect whether the Import was successful or not.

3.32.4.1.2 Message Semantics

The message semantics of this transaction are described in terms of content specifications for the media.

The Portable Media Creator shall be able to include one or multiple Submission Set(s), including document(s) and associated metadata. Additionally, it shall include a README.TXT file and an INDEX.HTM and associated files for use to display the media content using a simple browser. It may include other files and directories that the Portable Media Importer will ignore.

3.32.4.1.2.1 Media File system and File Naming Restrictions

The following restrictions are needed to ensure broad interoperability:

• Strict ISO 9660 Level 1 compliance for filenames and directories, even on non-CDR media.
• Strict ISO 9660 Level 1 compliance for recording methods on CDR media. This means no packet writing.
• Filenames should not be in lower case, nor have lower case equivalent file names encoded as Joliet or Rock Ridge extensions to the ISO 9660 file system.
• Only file and folder names referenced by the DICOMDIR file are restricted to 8 characters with no extension. Specifically, it is not permitted to name DICOM files based on their SOP Instance UID, since that would exceed the 8 character limit and use the illegal period character, and it is not permitted to add a “.dcm” extension or similar.

Note:   Refer to RAD TF-2: Appendix E of the IHE Radiology Technical Framework for a reference to common implementation misinterpretations and/or errors that are detrimental to interoperability.

3.32.4.1.2.2 Content Organization Overview

The media shall contain at the “root” directory level, as shown in the figure above:

• An IHE_XDM directory.
• Two files for helping to access the content of the media: README.TXT and INDEX.HTM
• An Autorun file or equivalent shall not be present in the root directory. Executable files may be present, but shall not be configured to start automatically.

As shown in the figure above, the IHE_XDM directory shall contain one sub-directory per submission set included on the media.

There may be other files present on the media for other purposes, (e.g., use in compliance with the IHE Radiology Portable Data for Imaging (PDI) Profile). The presence or absence of these files shall not affect performance of this transaction. The grouping with PDI actors is described in RAD TF-2: 4.47.4.1.2.3.3 for the Portable Media Creator and in RAD TF-2: 4.47.4.1.3.4.1 for the Portable Media Importer.

As shown on the figure above, each submission set directory shall contain:

• A METADATA.XML file containing the Document Sharing metadata, as described in ITI TF-3: 4.2.1.5. This shall include the metadata as specified for the XDM Portable Media Creator (XDM MC) in ITI TF-3: Table 4.3.1-3 Sending Actor Metadata Attribute Optionality and may include XDSFolder objects, associations, and other metadata contents. There is no relationship between an XDSFolder and a media directory, although media directories may be referred to as “folders”. The metadata for the submission set shall include unique and different submissionTime.
• One file for each “simple part” document referenced in the metadata as an XDSDocumentEntry
• One sub-directory for each “multipart” document referenced in the metadata as an XDSDocumentEntry (see ITI TF-3: Table 4.2.3.2-1, attribute mimeType set to “multipart/related”)
• Potentially other files and directories that are ignored by the Portable Media Importer

The “multipart” document shall be structured as one sub-directory containing all the parts as file, including the “start” part corresponding to the main file to be open by the “multipart” document viewer. An example of “multipart” document is shown in Figure 3.32.4.1-3.

The URI element of the metadata describing a file that is present on this media shall point to the file containing the document, through a relative URI where the base URI is the directory holding the METADATA.XML file that contains the DocumentEntry.URI attribute. In cases where the files are not located within this media directory for the Submission Set, the relative URI may begin with “../”.

In Figure 3.32.4.1-2, the METADATA.XML file of the Submission Set stored in the SUBSET01 directory will contain many XDSDocumentEntry objects having their elements set as follows (see ITI TF-3: Table 4.1-5, URI attribute for details):

<ExtrinsicObject id="Document1" mimeType="text/xml"... (with URI set to “DOC00001.XML”)

<ExtrinsicObject id="Document2" mimeType="text/xml"... (with URI set to “DOC00002/DOC00002.XML”)

The file named INDEX.HTM in the root directory shall be encoded in compliance with the XHTML Basic recommendation from W3C. It may contain a description of the submission sets, including especially:

• Patient ID and demographics
• Source Facility information

Note:   XDM Distribute Document Set on Media transaction does not require that all the submission sets included in the media are relative to the same patient.

It may also describe other content which is on the media, including the means to launch any executable that may be present on the media.

There shall also be a README.TXT file located in the root directory that shall contain:

• Contact information regarding the Institution that created the media.
• Information regarding the Application that created the media.

• Name of the product application and software version
• Contact information of the vendor of the application that created the media

• General information about the overall organization of the interchange media. This is not intended to be specific to the content stored on this instance of interchange media which, if necessary, should be placed in the INDEX.HTM file.
• Information regarding the Media Viewer application (if a Media Viewer is contained)

• Operating system(s) supported
• Name of the product application and software version
• Contact information of vendor that provided the Media Viewer application
• Disclaimer statement about the intended usage of the application
• List of minimum requirements
• Additional information regarding the usage of the application

Note that generally the README.TXT file is independent of the clinical content of the media, i.e., the same README.TXT may be included on all media created by that application at that institution. Experience has shown that this kind of README.TXT file is very valuable for resolving problems.

In addition, if the Portable Media Creator implements support for the Web Content Option of the PDI Profile then the INDEX.HTM file must meet the requirements of the PDI Profile Web Content Option.

The INDEX.HTMfile located in the root directory shall contain:

• An informative header containing:
• Identification of the institution that created the interchange media
• Optionally, a disclaimer statement about privacy/security from the institution that created the interchange media
• a link to an entry point for accessing the web content of the IHE_PDI directory
• a link to the README.TXT file
• a link to additional non-constrained data (if it exists)
• a manifest which lists the data that can be imported by a Portable Media Importer (i.e., all DICOM content on the media)
• a manifest which lists any patient-related data contained on the CD that cannot be imported (i.e., additional non-constrained content that doesn’t have an importable DICOM equivalent on the media).
• a link to a launch point for a DICOM viewer, if present on the interchange media

3.32.4.1.2.3 Response message

If the ZIP over Email Response Option is supported and a response was requested, the Portable Media Importer shall send a response, based on the [MDN] mechanism, depending of the success of the Import operation:

• Success: the MDN “disposition-type” field is set to “displayed”
• Error: the MDN “disposition-type” field is set to “deleted” and the MDN “disposition-modifier” is set to “Error: xxxx” where “xxxx” is the text detailing the error.

Note 1:   Older implementations of MDN might use “processed” instead of “display”. The current RFC has removed this option but Portable Media Creator should be prepared to receive it. If they receive it, they have to look in the error field to see whether there is an error.

Note 2:   The general mechanism for use of Email is described in ITI TF-2: Appendix T (Informative)

3.32.4.1.3 Media Identification

The Portable Media Creator may add a human-readable identification on the outside of the physical medium, reflecting the originating institution, the time of the creation and content of the media. The method of media marking is outside the scope of this transaction.

If the ZIP over Email Response Option is supported, Portable Media Creator shall be configurable to include in its message header the request for a response:

• “Disposition-Notification-To:”, followed by the email address to which Portable Media Importer shall send the response

Then, the Portable Media Importer shall acknowledge this operation by sending a MDN response to the email address included in the message.

And finally, the Portable Media Creator shall consider that the import is successful unless:

• the disposition-modifier contains the word “error” or “failure”, case insensitive.

Note: This transaction does not specify how errors should be processed because the variety of appropriate responses is too great.

If the ZIP over Email Option is supported, the subject line of the email shall contain the phrase:

• XDM/1.0/DDM

Note:   In case the same Email complies also with the DICOM Email, it is recommended that the subject contains the phrase: XDM/1.0/DDM+DICOM-ZIP

3.32.4.1.4 Expected Actions

The Portable Media Importer shall verify the integrity of the media by comparing their size and hash with the value of the corresponding entries in the METADATA.XML file of the relevant submission set directory. Mismatching documents shall be indicated to the user. Media faults shall be indicated to the user.

If the XDM Portable Media Importer is grouped with a Content Consumer of one or more IHE Content Profiles, that actor is able to perform its processing on the documents it is designed to support.

Note:   This awkward phrasing means that ability to process data on portable media is described by saying that the processing actor is grouped with a Portable Media Importer.

3.32.4.1.4.1 Basic Patient Privacy Enforcement Option

If the Basic Patient Privacy Enforcement Option is implemented:

• The Portable Media Creator shall populate the confidentialityCode in the document metadata with the list of values that identify the sensitivity classifications that apply to the associated document. All documents submitted shall have confidentiality codes. The confidentiality codes for different documents in the same submission may be different.
• The Portable Media Creator shall be able to be configured with the Patient Privacy Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary to understand and enforce the policies. The details of this are product specific and not specified by IHE.
• The Portable Media Creator may have user interface or business rule capabilities to determine the appropriate confidentiality codes for each document. The details of this are product specific and not specified by IHE.
• The Portable Media Importer shall be able to be configured with the Patient Privacy Policies, Patient Privacy Policy Identifiers (OIDs) and associated information necessary to understand and enforce the policies. The meanings of the codes on the media must be provided out of band, e.g., by telephone, fax, or email. The detail of how this is done is product specific and not specified by IHE. If the documents are transferred internally within the organization or to other members of the recipient's affinity domain, appropriate internal confidentiality codes shall be applied.
• The Portable Media Creator shall be able to publish the consent documents and any applicable digital signatures that apply to the collection of content that it has created on portable media.
• The Portable Media Importer shall have the ability to coerce the confidentiality code in the metadata associated with the document from the codes used by the Exporter to the codes used by the Importer.

The Portable Media Importer shall abide by the XDS Affinity Domain Policies represented by the confidentialityCode in the metadata associated with the document. The Portable Media Creator likely will have user access controls or business rule capabilities to determine the details of how confidentiality codes apply to query results. The details of this are product specific and not specified by IHE. These rules shall reduce the query results to only those that are appropriate to the current situation for that actor and user.

3.32.4.1.4.2 Zip over Email

A Portable Media Importer supporting the Zip over Email Option shall support S/MIME (see ITI TF-2: 3.19.3 ) to both decrypt and verify the signature of the message. The Portable Media Importer shall furthermore comply with the security process as defined in the DICOM PS3.15 Annex B.8 (Secure Use of Email Transport).

3.32.5 Security considerations

In the case of physical media, encryption of the CD-R or USB shall not be used.

If the ZIP over Email Option is supported, the transaction shall be secured by S/MIME (see the ATNA Profile) and comply with the security process as defined in the DICOM PS3.15 Annex B.8 (Secure Use of Email Transport). The security process requires the use of S/MIME to both encrypt and sign the message. The encryption is used to maintain confidentiality during the transport. The signature is used to maintain integrity during transport and indicates that the sender is authorized to send the message.

The Portable Media Importer shall check the hash value and size as found in the Document Sharing metadata to detect corruption within the metadata or media. The Portable Media Importer shall notify the user if any errors are detected.

3.32.5.1 Audit Record Considerations

The Distribute Document Set on Media Transaction is a PHI-Export for the Portable Media Creator and a PHI-Import for the Portable Media Importer as defined in ITI TF-2: Table 3.20.4.1.1.1-1.

3.32.5.1.1 Portable Media Creator Audit Message

The audit message for a Portable Media Creator shall comply with the specifications in Section 3.41.5.1, with the following exceptions.

• Event / EventTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document Set on Media").

• Source / UserID is not specialized.
• Destination / UserID is not specialized.
• Destination / MediaIdentifier is required.
• Destination / MediaIdentifier / MediaType is required. The value shall be taken from CID 405, in DICOM PS3.16.
• SubmissionSet / ParticipantObjectIDTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document Set on Media").

3.32.5.1.2 Portable Media Importer Audit Message

The audit message for a Portable Media Importer shall comply with the specifications in Section 3.41.5.2, with the following exceptions.

• Event / EventTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document Set on Media").

• Source / UserID is not specialized.
• Source / MediaIdentifier is required.
• Source / MediaIdentifier / MediaType is required. The value shall be taken from CID 405, in DICOM PS3.16.
• Destination / UserID is not specialized.
• SubmissionSet / ParticipantObjectIDTypeCode shall be ("ITI-32", "IHE Transactions", "Distribute Document Set on Media").