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

From IHE Wiki
Jump to navigation Jump to search
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Cross-enterprise Document Reliable Interchange (XDR)
+
__TOC__
  
Status: Trial Implementation
 
  
Current: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDR_TI_rev2.pdf
+
==Summary==
 +
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.
  
Previous: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDR_TI_2006_08_15.pdf
+
==Benefits==
 +
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 Implementation Guide =
+
==Details==
 +
XDR supports the reuse of the Provide and Register Set transaction-b with Web-Services as transport. Transfer is direct from source to recipient, 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 page contains supplemental documentation to developers of the XDR profile in IHE. It includes analysis beyond that included in the XDR profile.
+
==Systems Affected==
 +
Systems involved in this profile are:
 +
* EHR, EMR, HIE, HIO
  
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.
+
'''Actors & Transactions:'''
 +
[[Image:XDR-Actor-Transaction.jpg]]
  
== Background on XDR ==
+
==Specification==
  
Last updated [[User:BillM|bill]] 15:59, 22 July 2009 (UTC)
+
'''Profile Status:''' [[Comments| Final Text]]
  
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.
+
'''Documents:'''
 +
[http://www.ihe.net/Technical_Framework/index.cfm#IT IHE IT Infrastructure Technical Framework Version 5 or later]
 +
* Vol. 1 -
 +
** [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=15_Cross_Enterprise_Document_Re Section 15],
 +
** [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=Appendix_E__Cross_Profile_Consi Appendix E Cross Profile Considerations],
 +
** [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=Appendix_J__Content_and_Format_ Appendix J Content and Format of XDS Documents],  
 +
** [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf#nameddest=Appendix_K__XDS_Concept_Details Appendix K XDS Concepts]
 +
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf#nameddest=3_41_Provide_and_Register_Docum Vol. 2b - Sections 3.41 Provide and Register Document Set]
 +
* [http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf#nameddest=4_0_Metadata_used_in_Document_S Vol. 3 - Section 4.0 Metadata used in Document Sharing]
  
XDR defines two actors:
+
'''CDA mapping to XDS Metadata:'''
;Document Source
+
:* [http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf#nameddest=4_1_1_XDSDocumentEntry_Metadata PCC TF-2:4.1.1]
: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.
+
'''Underlying Standards:'''
 +
:* ebMS OASIS/ebXML Messaging Services Specifications v3.0
 +
:* ebRIM OASIS/ebXML Registry Information Model v3.0
 +
:* ebRS OASIS/ebXML Registry Services Specifications v3.0
  
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.
+
==See Also==
  
Additional discussion on these more complex metadata patterns can be found [[XDS_Implementation_Notes#Complex_metadata_operations|here]].
+
[[Document Sharing]]
  
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.
+
'''Related Profiles'''
 
 
== 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:Profiles]]
 
[[Category:ITI Profile]]
 
[[Category:ITI Profile]]
 +
[[Category:DocShare]]

Revision as of 10:00, 30 October 2017


Summary

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.

Benefits

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.

Details

XDR supports the reuse of the Provide and Register Set transaction-b with Web-Services as transport. Transfer is direct from source to recipient, 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.

Systems Affected

Systems involved in this profile are:

  • EHR, EMR, HIE, HIO

Actors & Transactions: XDR-Actor-Transaction.jpg

Specification

Profile Status: Final Text

Documents: IHE IT Infrastructure Technical Framework Version 5 or later

CDA mapping to XDS Metadata:


Underlying Standards:

  • ebMS OASIS/ebXML Messaging Services Specifications v3.0
  • ebRIM OASIS/ebXML Registry Information Model v3.0
  • ebRS OASIS/ebXML Registry Services Specifications v3.0

See Also

Document Sharing

Related Profiles

This page is based on the Profile Template