XDS Implementation Notes

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

Folder Association - RPLC Interaction

The following two rules interact:

1. When a Document Source requests that a Document be replaced and that Document is present in one or more Folders, the replacement Document is automatically added to the Folders as a side-effect by the Document Registry.
2. The Association between Folder and Document is annotated with a secondary Association that links it to the Submission Set thus documenting which submission act linked the Folder and Document.

These two rules interact within the Registry implementation as described in the following flow:

• Registry detects Document Replacement (RPLC Association) in submission, submission must contain replacement document
• Original Document is member of one or more Folders
• Registry generates new HasMember Association between Folder and replacement Document based on rule #1 above
• Registry also generates new HasMember Association between Submission Set (must be present in submission) and the above new Association based on rule #2 above

A naive observer, using the GetSubmissionSetAndContents Stored Query might conclude that the Document Source constructed the entire Submission Set as present in the registry.

Just a reminder...
A Document is added to a Folder by creating a HasMember Association between the Folder and the Document. This can happen at several potential times:

• When the Folder is created
• When the Document is created
• When the Folder and Document are both created together
• After the Document and Folder are created

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

Use of base64 encoding

The use of base64 encoding in XDS.a has been poorly understood for a long time. After a review of relevant standards we have found that the relevant standards clearly specify what is acceptable.

1. Base 64 encoding IS appropriate (may be generated by the Document Source, must be accepted by the Document Repository) for the Provide and Register transaction (XDS.a and XDS.b).
2. Base 64 encoding IS NOT allowed in the Retrieve Document (HTTP GET) transaction.

See Also

The IT Infrastructure Domain manages this profile.

The ITI Technical Framework is the official master document for this Profile.