16 Cross-Enterprise Document Media Interchange (XDM)

Cross-Enterprise Document Media Interchange (XDM) provides document interchange using a common file and directory structure over several standard media types. This permits the patient to use physical media to carry medical documents. This also permits the use of person-to-person email to convey medical documents. XDM supports the transfer of data about multiple patients within one data exchange.

Physician to patient to physician - Bob has an MRI and cancer is diagnosed. He is given a CD-R with his MRI results and referral information on it to give to the specialist of his choice.

Patient visiting ED - In addition, Bob, the informed patient, maintains a copy of his EHR record at home and can bring the CD-R with him when he visits the ED for an unrelated emergency.

Physician to physician - Dr. Primary refers his aging patient Mr. Robinson to his first appointment with a gastroenterology specialist. He transfers relevant documents in a zip file attached to an email to the specialist.

The common thread of these use cases is that they are person-to-person communications. The XDM solution is intended to be easy to implement with pre-existing email clients, CD burners and USB ports. XDM does not include any additional reliability enhancements. XDM requires that the recipient be able to support human intervention in order to manually control the importing of the data (patient ID reconciliation, selection of patient of interest from possibly multiple patients’ documents on the media).

XDM is document format agnostic, supporting the same document content as XDS and XDR. Document content is described in Document Content Profiles. Examples are XDS-MS, XPHR, XDS-SD, and XD-LAB.

XDM defines no new metadata. It leverages XDS metadata with emphasis on patient identification, document identification, description, and relationships.

A directory and file structure is documented for populating the media. This structure maintains separate areas for each patient listed and is supported on all referenced media types. Media and the structure were selected based on experience with media interoperability in Radiology, i.e., PDI Profile. The media selected are the widespread CD-R, USB removable media, and email with ZIP attachment.

This Profile has been updated by the Document Encryption (DEN) Supplement.

16.1 XDM Actors/Transactions

Figure 16.1-1 shows the actors directly involved in the XDM Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in XDS, PIX or PDI are not shown.

Table 16.1-1 lists the transactions for each actor directly involved in the XDM Profile. In order to claim support of this Integration Profile with one or more actors, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Section 16.2.

Table 16.1-1: XDM Integration Profile - Actors and Transactions

Actors	Transactions	Optionality	Section
Portable Media Creator	Distribute Document Set on Media [ITI-32]	R	ITI TF-2: 3.32
Portable Media Importer	Distribute Document Set on Media [ITI-32]	R	ITI TF-2: 3.32

16.1.1 XDM Required Actor Groupings

An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).

Table 16.1-2: XDM - Required Actor Groupings

XDM Actor	Actor(s) to be grouped with	Reference
Portable Media Creator	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1
Portable Media Importer	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1

To enable some form of processing of medical data, a Portable Media Creator and Portable Media Consumer is grouped with a Content Creator/Consumer in one or more IHE Content Profile.

Section 16.6 describes some optional groupings in other related profiles.

16.2 XDM Actor Options

Options that may be selected for this Integration Profile are listed in Table 16.2-1 along with the Actors to which they apply. Dependencies between options when applicable are specified in notes.

Table 16.2-1: XDM - Actors and Options

Actor	Options	Vol. & Section
Portable Media Creator	USB (Note 1)	ITI TF-1: 16.2.1
	CD-R (Note 1)	ITI TF-1: 16.2.2
	ZIP over Email (Note 1)	ITI TF-1: 16.2.3
	Basic Patient Privacy Enforcement	ITI TF-2: 3.32.4.1.4.1
	Zip over Email Response (Note 2)	ITI TF-1: 16.2.4
Portable Media Importer	USB (Note 1)	ITI TF-1: 16.2.1
	CD-R (Note 1)	ITI TF-1: 16.2.2
	ZIP over Email (Note 1)	ITI TF-1: 16.2.3
	Basic Patient Privacy Enforcement	ITI TF-2: 3.32.4.1.4.1
	Zip over Email Response (Note 2)	ITI TF-1: 16.2.4

16.2.1 USB Option

In this option the Portable Media Creator writes a set of documents on USB media. The media is physically transported to the Portable Media Importer which then imports the document set.

16.2.2 CD-R Option

In this option the Portable Media Creator writes a set of documents on CD-R media. The media is physically transported to the Portable Media Importer which then imports the document set.

16.2.3 ZIP over Email Option

In this option the Portable Media Creator creates an ordinary ZIP file of the virtual media containing document set(s). The ZIP file is attached to an Email sent to the Portable Media Importer which then retrieves the Email and imports the ZIP file containing the document set.

See ITI TF-2: Appendix T : Use of eMail for a discussion on the use of eMail store and forward architecture.

For secure email, see the ATNA STX: S/MIME Option, ITI TF-1: 9.2.6.5 .

16.2.4 ZIP over Email Response Option

In this option the Portable Media Importer sends a response (MDN Based) to the Portable Media Creator to acknowledge that the Import operation of the Document Set(s) received was successful.

If this option is supported, the ZIP over Email Option shall be supported.

See ITI TF-2: Appendix T : Use of eMail for a discussion on the use of eMail store and forward architecture.

For secure email, see ATNA STX: S/MIME Option, ITI TF-1: 9.2.6.5.

16.3 XDM Process Flow

XDM describes the exchange of a set of a patient’s documents between healthcare providers, such as: physicians, hospitals, special care networks, or other healthcare professionals.

Where XDS is not desirable or available for one of the participants in the exchange of information, XDM is a viable option.

XDM should be used in a situation where the information receiver is an individual who will manually interpret or examine the data and associated documents as though they were using physical media. XDM also allows for the exchange of documents relating to multiple patients, since the data will be interpreted manually by human intervention.

The XDM Integration Profile is intended only for exchange of personal medical documents and not intended to address all cross-enterprise EHR communication needs. Some use cases may require the use of other IHE integration profiles such as XDS, DSG, PIX, and ATNA. Other use cases may only be partially supported, while still others may require future IHE integration profiles.

Use Cases:

1. Dr. Primary refers his aging patient Mr. Robinson to his first appointment with a gastroenterology specialist.

   In a case where either Dr. Primary’s office or Dr. Gastro’s clinic was not able to handle secure email, or other sustained online point-to-point communications (e.g., http over VPN), the XDM Profile would provide further solutions for the simpler environment, such as the use of physical media, or email where the interchanged document set will be manually interpreted by a human intervention.

2. In a hospital that does not have an XDS infrastructure; the XDS-MS Content Profile discharge use case can also be handled by XDM. For example:

   In a hospital, or in the case of a family physician not using robust EHR, the patient could be handed a CD or USB media with their discharge information on it to bring with them to their follow-up visit with their family physician.

3. Mabel is transferred from a hospital setting to her retirement home for long-term care.

   If the hospital does not have an EHR application that automatically interprets her medical data and shares it with the necessary members of her health team, the information can be transferred manually directly to the file clerk, intake coordinator, records manager, or primary physician depending on the organization’s resource model.

4. Stanley’s recent MRI has generated unusual results that Stanley’s primary physician would like to consult with another specialist in a specialized cancer facility located across the state. Since there is not likely to be an affinity domain between the remote health environments, XDM can be used instead.

5. Bob, the informed patient, maintains a copy of his Personal Health Record (PHR) at home. In this situation, Bob can be given a copy of his medical information on physical media such as a CD-ROM to take home with him. Bob now has an advantage that he can continue to have his complete medical record available with him on sudden emergency department visits, even when he is on an out-of-state trip where the new ED would have no access to the repository of his home affinity domain.

This profile is only defining the digital transport mechanism used for such use cases. Content transported will be detailed by Content Profiles such as the ones defined by the IHE PCC (Patient Care Coordination) domain.

16.4 Digital communication

16.4.1 Actual Media Type

The media can be either CD-R or a USB media device because these are the most common media types in other industries for the portable transport of electronic information. This supplement requires using one of these media types, depending on the use case. The benefit and risks of the reusability of the media deployed should be taken into account, especially when the media is under the control of the patient.

16.4.2 Virtual Media over a Network

The media can be a ZIP file containing the document set and sent via a secure email message.

16.4.3 Media Content

The requirements for media content are intended to promote the simple transfer of medical documents, including patient summaries, lab results, discharge letters and reports, and to allow for the viewing of such documents on general purpose computers by care providers or patients.

Created media are required to contain documents and the relevant associated metadata.

The media contains one or more Submission Sets including the documents and the associated metadata, organized in a well-defined directory structure starting at the root level.

The media content can be made web viewable by a web browser by providing optional files containing HTML content. This content must be based on the original documents in order to ensure consistency. Any ordinary web browser can be used to read these files. The Portable Media Importer ignores these files. They are just intended for the human recipient.

Additional content may be present (files, directories), but can be ignored by the Portable Media Importer.

To summarize, the Portable Media Importer has two complementary ways to access the media and its content through a basic web browser:

• By inspecting in the directory dedicated to XDM all the subdirectories that contain a specifically named metadata file compatible with XDM
• By presenting to the user the HTML index file that lists the submission sets and documents contained in the media.

Access to the content of an individual document is outside the scope of this Integration Profile and shall be addressed in specific IHE document content Integration Profiles.

16.5 Security Considerations

The Profile assumes that the Healthcare delivery organizations that are using Portable Media Creator and Importer have an agreement defining when they can interchange PHI. This may require an explicit patient consent (depending on existing regulations) and an agreement on how to manage the potential inconsistency between the security policies. The main aspects that should be covered by this agreement are similar to XDS – see ITI TF-1: Appendix L . In addition, the following aspects should be covered:

• Management of Patient identification in order to perform patient reconciliation correctly upon importation of the documents.
• Measures taken to avoid or limit loss of media or email, and detect that which occurs.

In the case of physical media, security responsibilities for confidentiality and integrity are transferred to the patient by providing the media to the patient. In this case it is the patient’s responsibility to protect the media, and the patient has the authority to disclose the contents of the media as they choose. They disclose the contents by providing the media.

The Portable Media Creator in most cases does not know who the ultimate Importer will be, thus rendering encryption impractical.

In the case of transfer over email using a ZIP attachment, the transaction is secured by the use of S/MIME.

16.6 Cross-Profile Considerations

16.6.1 RAD Portable Data for Imaging (PDI)

A Portable Media Creator in XDM might be grouped with a Portable Media Creator in the RAD PDI Profile to enable it to include DICOM instances on the same media. A grouped PDI / XDM Media Creator application will handle the data for the media as defined for each actor by its profile. This grouping is described in RAD TF-2: 4.47.4.1.2.2.3.

A Portable Media Importer in XDM might be grouped with a Portable Media Importer in the PDI Profile to process the combined PDI / XDM media, for example, for the use in an XDS-I infrastructure. A grouped PDI / XDM Media Importer application will handle the media data as defined for each actor by its profile. This grouping is described in RAD TF-2: 4.47.4.1.3.4.