Cross-enterprise Document Reliable Interchange Implementation
From IHE Wiki
This page contains supplemental documentation to developers of the XDR profile in IHE. It includes analysis beyond that included in the XDR profile.
<<Are there elements from the Profile Implementation Template that might be useful to add here?>>
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 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 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 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.
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 assigns metadata ids in which case it would be described as a 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.