XDS Implementation Notes

This page documents implementation notes for general XDS, the issues that are shared by many or all XD* profiles.

Metadata Coding

There are many nuances to coding XD* metadata and unfortunately the standard does not explain them in detail. Much of the detail in the Old XDS FAQ deals with such coding issues. Newer help is documented in this section. Make sure to check the XDS.a and XDS.b specific Implementation Notes pages for metadata version specific discussions.

Classifying RegistryPackage objects as Submission Set vs. Folder

Both Submission Set and Folder objects are based on the ebRIM RegistryPackage element. There are two ways of identifying a RegistryPackage as being a Submission Set vs. a Folder:

1. Check for a Classification labeling the RegistryPackage object
2. Identify an attribute within the RegistryPackage that is unique to either Submission Set or Folder. Patient ID or Unique ID are easy choices. They exist within both Submission Set and Folder objects but have different identificationScheme attributes which can be used to differentiate them.

While differentiating based on Classification is the technically correct approach, it is slightly harder than it should be since ebRIM 2.1/3.0 Schema allows the Classification object to be coded inside the RegistryPackage object or outside. Both of the following metadata snippets represent valid metadata coding:

Classification within RegistryPackage

<…>
    <RegistryPackage id=”SS”>
        <!-- Classify registry package SS as being an XDSSubmissionSet -->
        <Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd” classifiedObject=”SS”/>
    </RegistryPackage>
    <RegistryPackage id=”Fol”>
        <!-- Classify registry package Fol as being an XDSFolder -->
        <Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2” classifiedObject=”Fol”/>
    </RegistryPackage>
<…>

Classification outside RegistryPackage

<…>
    <RegistryPackage id=”SS”/>
    <RegistryPackage id=”Fol”/>
    <!-- Classify registry packages as XDSSubmissionSet/XDSFolder respectively -->
    <Classification classificationNode=”urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd” classifiedObject=”SS”/>
    <Classification classificationNode=”urn:uuid:d9d542f3-6cc4-48b6-8870-ea235fbc94c2” classifiedObject=”Fol”/>
<…>

All Transactions

Duplicate Metadata

Document Source(s) can submit a document multiple times. This results in a XDSDocumentEntry.uniqueId being present on multiple XDSDocumentEntry objects in the Registry. As long as the size and hash attributes are the same, this is considered a normal condition that a Document Consumer must be prepared. This condition can occur for two other reasons. First a Provide and Register transaction can fail because the response message from the Repository back to the Document Source is not delivered. This can happen on a synchronous connection as well as with asynchronous web services as described in the new Async XDS Supplement. A natural response for the Document Source is to resubmit, again causing duplication.

A document replace (RPLC from LifeCycle Management option to XDS) has the known issue that a Document Source replacing a document is not required to find all copies of the document in the Registry. A replacement will be applied to only one copy of the document. Likewise the new topic of Metadata Versioning (currently a white paper) does not carry the requirement to find all copies of the document metadata.

Old XDS FAQ

While new material is to be added to this page, there is older material available from the original XDS FAQ