Difference between revisions of "Cross-enterprise Document Reliable Interchange"

Latest revision as of 14:51, 8 March 2022

provides document interchange (push) 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.

Formal Specification

XDR (html) specification

Final Text

@@ Line 1: / Line 1: @@
-Cross-enterprise Document Reliable Interchange (XDR)
+provides document interchange (push) 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.
+__TOC__
-Status: Trial Implementation
+==Formal Specification==
-Current: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDR_TI_rev2.pdf
+===[https://profiles.ihe.net/ITI/TF/Volume1/ch-15.html XDR (html) specification]===
+* [https://profiles.ihe.net/ITI/TF/Volume1/ch-15.html Final Text]
-Previous: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDR_TI_2006_08_15.pdf
+==See Also==
-= XDR Implementation Guide =
+[[Document Sharing]]
-This page contains supplemental documentation to developers of the XDR profile in IHE. It includes analysis beyond that included in the XDR profile.
+'''Related Profiles'''
-A note on terminology: Document formally refers to the contents (byte stream) of a document being managed by XDS/XDR/XCA while DocumentEntry referes to the metadata describing the document. It then follows that document (not capitalized) is less formal and typically refers to the combination of DocumentEntry and Document. When it is critical, this is spelled out more specifically.
-== Background on XDR ==
-Last updated [[User:BillM|bill]] 15:59, 22 July 2009 (UTC)
-XDR (Cross-Enterprise Document Reliable Interchange) is intended to be a light-weight, point-to-point introduction to XDS. It uses the Provide and Register Document Set transaction, originally defined in XDS, to move documents and associated metadata between two systems. It does not use the Document Repository and Document Registry actors from XDS.  In short, it does not define an environment for sharing (that would be XDS) but instead a way of transporting documents and metadata about documents from one system to another.
-XDR defines two actors:
-;Document Source
-:which generates the Provide and Register Document Set transaction. The requirements on this actor are identical to the ones imposed by the XDS profile except that some operations are not sensible in the XDR environment.  More on this below.
-;Document Recipient
-:which receives the Provide and Register Document Set transaction. The IHE specified requirements on this actor are very minimal.  It must accept the PnR transaction and return the proper acknowledgments. All '''interesting''' handling of the documents and metadata is outside the IHE scope.
-The use of the Provide and Register Document Set transaction in XDR is different than its use in XDS in two ways:
-*In XDR, the optional XDSSubmissionSet.indentdedRecipient attribute can be used to trigger workflow beyond the Document Recipient actor.
-*Not all metadata patterns are usable in XDR.
-DocumentEntry metadata relationships, such as Replace, Append, Transform, are performed by first submitting a document and later submitting a Replace, Append or Transform.  This implies the that the receiving actor is maintaining state of previous submissions. In XDS that would be the Document Registry actor.  In XDR, there is no assumption that state is maintained between submissions. An implementation of the Document Recipient actor is free to handle each request in isolation. The proper reaction of the Document Recipient actor to a Document Replace operation is unspecified. The pre-Connectathon tests for XDR consider this submission an error.
-A second type of metadata relationship that requires different handling in XDR is Folders. A submission of a Folder along with one or more DocumentEntries can be interpreted by the Document Recipient.  But, in XDS one can submit a Folder and later add DocumentEntries to it.  This operation requires state be maintainted in the receiver and therefore the behaviour is unspecified in XDR.
-Additional discussion on these more complex metadata patterns can be found [[XDS_Implementation_Notes#Complex_metadata_operations|here]].
-The above description of XDR is consistent with the profile except that the detail regarding DocumentEntry relationships and Folders is more detail that is contained in the profile at this time.
-== Bridging to XDS ==
-Last updated [[User:BillM|bill]] 15:59, 22 July 2009 (UTC)
-The base use case for XDR is for use in non-XDS environments. Using XDR in an XDS environment could just be thought of as the normal Document Source actor using the Provide and Register Document Set transaction in XDS. But there are some interesting use cases to discuss. The basic issue is how does XDR fit into an XDS environment.
-First, remember the two types of Document Source actor, [[XDS_Implementation_Notes#Document_Source_bound_to_Document_Consumer|with]] and [[XDS_Implementation_Notes#Document_Source_not_bound_to_Document_Consumer|without]] the ability to perform queries. Obviously, XDR is related to the second type since it cannot perform queries.
-This similarity brings us to a use case that has been discussed only recently. The environment of interest is an Affinity Domain (XDS environment) with the Document Registry and all Document Repositories behind a firewall. The actor of interest is a Document Source outside the firewall. Its access through the firewall only allows Provide and Register Document Set transactions, no queries or retrieves. Viewed from outside the firewall this looks like XDR.  Viewed from inside the firewall this looks like XDS.
-The view from outside the firewall could, on the other hand, look like XDS if the Document Source [[XDS_Implementation_Notes#Document_Source_assigning_IDs|assigns metadata ids]] in which case it would be described as a [[XDS_Implementation_Notes#Document_Source_not_bound_to_Document_Consumer|Document Source not bound to a Document Consumer]].
-The bottom line is that XDS and XDR and XCA are just building blocks that can fit into many architectures.
+This page is based on the [[Profile Template]]
 [[Category:Profiles]]
 [[Category:ITI Profile]]
+[[Category:DocShare]]
+Current: [[Frameworks#IHE IT Infrastructure Technical Framework| IT Infrastructure Technical Framework]].

Difference between revisions of "Cross-enterprise Document Reliable Interchange"

Latest revision as of 14:51, 8 March 2022

Contents

Formal Specification

XDR (html) specification

See Also

Navigation menu

Search