15 Cross-Enterprise Document Reliable Interchange (XDR)

Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS Registry and Repositories.

XDR provides a reliable and automatic transfer of documents and metadata for one patient between EHR systems even in the absence of an XDS infrastructure. XDR supports the reuse of the Provide and Register Set transaction-b with Web-Services as transport. Transfer is direct from source to consumer; no repository or registry actors are involved.

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

XDR defines no new metadata or message formats. It leverages XDS metadata with emphasis on patient identification, document identification, description, and relationships.

This Profile has been updated by the XDS Metadata Update, and Asynchronous AS4 Option Supplement.

15.1 XDR Actors/Transactions

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

Table 15.1-1 lists the transactions for each actor directly involved in the XDR 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 15.2.

Table 15.1-1: XDR Integration Profile - Actors and Transactions

Actors	Transactions	Optionality	Section in Volume 2
Document Source	Provide and Register Document Set-b [ITI-41]	R	ITI TF-2:3.41
Metadata-Limited Document Source	Provide and Register Document Set-b [ITI-41]	R	ITI TF-2:3.41
Document Recipient	Provide and Register Document Set –b [ITI-41]	R	ITI TF-2:3.41

15.1.1 Actor Profile Requirements

An implementation of the Document Source or Metadata-Limited Document Source shall be able to submit documents. Whether a submission contains a single document or multiple documents depends on workflows, policies, and other external factors which are outside of the scope of this transaction.

15.1.2 XDR 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 15.1.2-1: XDR - Required Actor Groupings

XDR Actor	Actor(s) to be grouped with	Reference
Document Source	CT / Time Client	ITI TF-1: 7.1
	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1
Metadata-Limited Document Source	CT / Time Client	ITI TF-1: 7.1
	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1
Document Recipient	CT / Time Client	ITI TF-1: 7.1
	ATNA / Secure Node or Secure Application	ITI TF-1: 9.1

15.2 XDR Actor Options

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

Table 15.2-1: XDR - Actors and Options

Actor	Options	Volume & Section
Document Source	Basic Patient Privacy Enforcement	ITI TF-1: 15.2.2
Metadata-Limited Document Source	Basic Patient Privacy Enforcement	ITI TF-1: 15.2.2
Document Recipient	Basic Patient Privacy Enforcement	ITI TF-1: 15.2.2
	Accepts Limited Metadata	ITI TF-1: 15.2.3

15.2.1 Intentionally Left Blank

15.2.2 Basic Patient Privacy Enforcement Option

For this option, see ITI TF-1: 10.2.9

15.2.3 Accepts Limited Metadata Option

When the Document Recipient declares this option, it will accept metadata entries from a Metadata-Limited Document Source which use the less rigorous metadata attribute requirements in [ITI-41] as shown in ITI TF- 3 : 4.3.1 and Table 4.3.1-3.

15.3 XDR Process Flow

XDR 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 Registry/Repositories are not yet implemented or available for the exchange of information, XDR is the viable approach.

In a situation where the information is going to an automated application or robust system capable of automated storage or processing of documents relative to one patient, XDR is the appropriate profile.

The XDR Integration Profile is intended only for exchange of patient related medical documents and not intended to address all cross-enterprise EHR communication needs.

Since there is no XDS Document Repository available at the gastro clinic, Dr. Primary cannot use XDS to communicate the XDS-MS referral to Dr. Gastro. Also, since there is no affinity domain linking Dr. Primary and Dr. Gastro, XDR is preferable to XDS for the exchange of Mr. Robinson’s referral information. XDR is also appropriate for Dr. Gastro’s documents communication to Dr. Primary.

Use Cases:

1. Dr. Primary refers his aging patient Mr. Robinson to his first appointment with a gastroenterology specialist.
   
   Since there is no XDS Document Repository available at the gastro clinic, Dr. Primary cannot use XDS to communicate the XDS-MS referral to Dr. Gastro. Also, 4120 since there is no affinity domain linking Dr. Primary and Dr. Gastro, XDR is preferable to XDS for the exchange of Mr. Robinson’s referral information. XDR is also appropriate for Dr. Gastro’s documents communication to Dr. Primary.
2. Mabel is transferred from a hospital setting to her retirement home for long-term care.
   
   XDR: Mabel’s information can be transferred from the hospital to the long-term care facility’s EHR application for future review by her attending physicians and nurses, through XDR.
3. 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, XDR can be used instead.
4. Mrs. Sweettooth has been diagnosed with adult diabetes and her specialized circle of care has not yet gotten organized to provide shared access to a common repository. Until they do, they will need to exchange her information peer-to-peer using XDR.

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.

15.4 Digital communication

It is a webservice-based HTTP message.

15.5 Security Considerations

The profile assumes that the health organizations that are using Document Source and Document Recipient have an agreement defining when they can interchange PHI. This may require an explicit patient consent (depending on the regulation) 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 Appendix L. In the case of XDR, the EHR-to-EHR (or PHR) communication is a transient XDS Affinity Domain. In addition, the following aspects should be covered:

• Management of Patient identification in order to perform patient reconciliation correctly upon importation of the documents.

Both actors for this profile require a grouping with Secure Node.