Metadata Update

This page contains examples supporting the Metadata Update profile. These examples show only enough metadata to explain the operation of the update. Many of these metadata objects are incomplete.

Update DocumentEntry Metadata

Trigger object shown with SubmissionSet HasMember Association. This DocumentEntry, the trigger object, is submitted with an lid attribute and the lid and id attributes do not match. Therefore this is an attempt to update a DocumentEntry. Note the PreviousVersion slot in the Association. The lid and uniqueId attributes are shown since they are key to evaluating the preconditions.

   <ExtrinsicObject id="Document01" lid="urn:uuid:06b5ba28-4b6e-47ec-b3f0-d42e2ebd637a"
           objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">

        <!-- UniqueId attribute -->
        <ExternalIdentifier 
            identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
            value="1.2009.0827.08.33.5016"
            objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
            id="urn:uuid:a89a35db-cb9c-4e9e-9f9a-e55fda5c9475" 
            registryObject="Document01">
            <Name>
                <LocalizedString value="XDSDocumentEntry.uniqueId"/>
            </Name>
        </ExternalIdentifier>
    </ExtrinsicObject>

    <Association id="urn:uuid:883e0490-ff31-4753-8133-945b73d99d94"
        objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association"
        associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
        sourceObject="SubmissionSet01" 
        targetObject="Document01">
        <Slot name="SubmissionSetStatus">
            <ValueList>
                <Value>Original</Value>
            </ValueList>
        </Slot>
        <Slot name="PreviousVersion">
            <ValueList>
                <Value>1</Value>
            </ValueList>
        </Slot>
    </Association>

Precondition object. Note the version matches the PreviousVersion above, the status is Approved, and the uniqueId attribute matches. Thus satisfying the precondition.

    <ExtrinsicObject 
        id="urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd"
        lid="urn:uuid:06b5ba28-4b6e-47ec-b3f0-d42e2ebd637a"
        objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
        status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">
        
        <VersionInfo versionName="1"/>
        
        <!-- UniqueId attribute -->
        <ExternalIdentifier
            identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
            value="1.2009.0827.08.33.5016"
            objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
            id="urn:uuid:7ae00a8d-0152-46d9-bc66-aae8ab4e2edd"               
            registryObject="urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd">
            <Name>
                <LocalizedString value="XDSDocumentEntry.uniqueId"/>
            </Name>
        </ExternalIdentifier>
    </ExtrinsicObject>

Trigger object and SubmissionSet HasMember Association as saved to registry. Note:

• Version has been filled in
• id attributes have had UUIDs generated
• Status attribute has been filled in

<!-- Trigger object -->
    <ExtrinsicObject id="urn:uuid:f139f6ea-ba10-4887-86d1-f95bf698ee3d"
        lid="urn:uuid:06b5ba28-4b6e-47ec-b3f0-d42e2ebd637a"
        objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
        status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">

        <VersionInfo versionName="2"/>

        <!-- UniqueId attribute -->
        <ExternalIdentifier identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
            value="1.2009.0827.08.33.5016"
            objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
            id="urn:uuid:a89a35db-cb9c-4e9e-9f9a-e55fda5c9475"
            registryObject="urn:uuid:f139f6ea-ba10-4887-86d1-f95bf698ee3d">
            <Name>
                <LocalizedString value="XDSDocumentEntry.uniqueId"/>
            </Name>
        </ExternalIdentifier>
    </ExtrinsicObject>

    <Association id="urn:uuid:883e0490-ff31-4753-8133-945b73d99d94"
        objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association"
        associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
        sourceObject="urn:uuid:93f9e4f8-cd53-4118-b197-ed9e0453ece0"
        targetObject="urn:uuid:f139f6ea-ba10-4887-86d1-f95bf698ee3d">
        <Slot name="SubmissionSetStatus">
            <ValueList>
                <Value>Original</Value>
            </ValueList>
        </Slot>
        <Slot name="PreviousVersion">
            <ValueList>
                <Value>1</Value>
            </ValueList>
        </Slot>
    </Association>

This is the updated metadata of the original object. Note the status has changed to Deprecated

    <ExtrinsicObject 
        id="urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd"
        lid="urn:uuid:06b5ba28-4b6e-47ec-b3f0-d42e2ebd637a"
        objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
        status="urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated">
        
        <VersionInfo versionName="1"/>
        
        <!-- UniqueId attribute -->
        <ExternalIdentifier
            identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
            value="1.2009.0827.08.33.5016"
            objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
            id="urn:uuid:7ae00a8d-0152-46d9-bc66-aae8ab4e2edd"               
            registryObject="urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd">
            <Name>
                <LocalizedString value="XDSDocumentEntry.uniqueId"/>
            </Name>
        </ExternalIdentifier>
    </ExtrinsicObject>

Deprecate DocumentEntry

The trigger object is a Deprecate Association as shown. The soruceObject points to the SubmissionSet (not shown). If the targetObject is a DocumentEntry and its status is Approved then its status is changed to Deprecated (urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated).

    <Association id="id_01"
        objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association"
        associationType="urn:ihe:iti:2010:AssociationType:Deprecate"
        sourceObject="SubmissionSet01" 
        targetObject="urn:uuid:e0985823-dc50-45a5-a6c8-a11a829893bd">
        <Slot name="OriginalStatus">
            <ValueList>
                <Value>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</Value>
            </ValueList>
        </Slot>
    </Association>

Closed Issues

MV001: Should UpdateReason values be prefixed by a namespace? See MV013 for discussion. UpdateReason has been removed.

MV002: Should UpdateReason, as specified in the SubmissionSet Association be a classification instead of a slot? See MV013 for discussion.

MV004: Should a Deprecate request use a (new) Deprecates Association Type instead of HasMember? The text has been updated to use a new Deprecate Association type.

MV005: Should a move to off-line request use a (new) Offline Association Type instead of HasMember? A new Association type of Offline has been created.

MV006: Should a deletion use a (new) Deletes Association Type instead of HasMember? Deletion is no longer done through SubmissionSet Associatoins. The Delete Document Set transaction has been added.

MV007: Could Metadata Versioning support Dynamic Document Entries? No. We have shown that these are two independent concepts. A Dynamic Document Entry is just another metadata object so it may be updated via Metadata Versioning just like any other registry object but has no special relationship with Metadata Versioning.

MV008: The use of a code to label the type of update has been questioned. Do we need to restrict the use of this mechanism to approved types of updates? If the coded labeling of update types is discarded then the UpdateReason Slot on the Association should be removed and instead we should require a free text comment in the //ExtrinsicObject/VersionInfo/@comment field. This approach is available to developers but not required or suggested by this supplement. The current version of the paper removes the UpdateReason slot entirely and instead lists specific DocumentEntry attributes that must be maintained across versions.

MV009: In existing XDS, a document can be submitted multiple times with same uniqueID as long as hash is identical. How should this be handled if the multiply submitted document is version 3 of a document? Since the actual document is not being updated, the hash is not useful. Is it legal, according to ebRIM and ebRS for there to be two ExtrinsicObjects in the Registry with the same version? If id is same, if different? It seems that the second should be ignored if the metadata is exactly the same and rejected if it is not. The second case probably coming from two different stations trying to do different updates at the same time. Registry Adaptor could assign the version number. Seems that there could be pitfalls to this approach. A closer reading of the standard (ebRIM) shows that the registry assigns the version numbers so this is an implementation issue for the Document Registry actor and not relevant to this specification. Furthermore, the PreviousVersion Slot on SubmissionSet HasMember Associations enables the detection of multiple simultaneous updates.

MV010: Metadata versioning would seem to make obsolete the existing discussion on precedence of RPLC/XFRM/APND relationships and which ones deprecate previous content. Metadata versioning gives the opportunity to surgically deprecate documents, no need for fancy rules. This is no longer an issue.

MV011: Offline (as in removed from available storage) needs to be coded separately from UpdateReason and status. Later if returned to available storage, need to restore its prior status. This is managed through the documentAvailability Slot on DocumentEntry and requires a new version of the DocumentEntry be submitted to change its value. The Document Administrator actor is responsible for sifting through the past versions of the DocumentEntry to find the “original value” when a document is brought back online.

MV013: The UpdateReason attribute may be too restrictive and of very little value since the differences between to versions of an ExtrinsicObject can be determined by comparison. The UpdateReason attribute of the Submission Set Association has been removed. First it restricts the use of this mechanism. To be useful from an interoperability perspective it would have to be a coded term. In its place is a list of ExtrinsicObject attributes that may not be updated.

MV014: The functionality described in this paper should become a named option on the XDS.b profile. A named option has been introduced.

MV014: (oops on duplicate number) The marking of a document as Offline or Online can be done by submitting an update to the DocumentEntry. It is currently specified as being controlled by the submission of an Offline Association. We need to determine which approach to stick with. I cannot see a strong reason to pick either one. This is now managed through the documentAvailability slot on DocumentEntry.

MV019: A Stored Query initiated by the Doc Con does not return DocumentEntry objects marked as deleted. If the request comes from the XDS Admin Client actor they are returned. There is currently no way to distinguish between these requests. Stored Query operation does not depend on the actor initiating. DocumentEntry objects marked as Deleted are never returned. The Deleted availabilityStatus is no longer used.

MV021: For now sending metadata updates through the Repository actor is acceptable. This enables early testing and research. Should this capability be kept or abandoned long term thus requiring a direct connection between Document Source and Document Registry? The introduction of the XDS Admin Client and XDS Admin actors would imply the direct connection. Update transaction always goes from XDS Admin actor directly to the Document Registry actor.

MV024: The specification of the lid attribute is incorrect. An original version of a DocumentEntry can have lid != id. The fact that lid is not otherwise present in the registry is the signal that this is an original version. This form of original version will not be allowed in XDS.

MV003: Are there use cases for updating the metadata of Folder objects? Now that Folders are used in Content Profiles the ability to update their metadata may be necessary. Folders are now included.

MV007: (The wording is weird because I also published this note on the Implementation Guide.) 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.

MV015: The new actor name, XDS Admin actor, is a horrible name. I include it for now but hope to get a better suggestion through public comment. An alternate name “Document Metadata Updater” was suggested. I made no changes so far since the suggestion came in a bit late. New name is Document Administrator.

MV016: It is now acceptable to update the XDSDocumentEntry.patientId attribute. But, there is no facility for updating the XDSSubmissionSet.patientId attribute (or other attributes). Patient ID update has been documented.

MV017: An attempt to retrieve a deleted document should fail but there is no interaction between the Repository and Registry to allow enforcement. This should be coordinated between the Document Repository and the Document Administrator actors. Deletion of a DocumentEntry in the registry and a document in the repository are unconnected operations. No transaction exists to tell a repository to delete a document. So, the only way to coordinate the deletion of a document and its documententry is for the repository to be bound to the document administrator actor so that its implementation has knowledge of both.

MV022: Should a named option be created for the Document Consumer actor? This option would signal that the implementation is compatible with a Document Registry that implements Metadata Versioning. Yes, Done.

MV023: Should we control the result of a delete operation? If an implementer decides to allow real deletes (remove documents and DocumentEntry objects) should the profile require they also delete the SubmissionSet and Associations linked to the document? The Delete Document Set transaction does not require this consistency. It is left to the system developer.

MV025: Currently the Patient ID attribute is labeled as not updatable. This may change depending on committee debate. Patient ID is now updateable.

MV026: In early discussions we established that either SubmitObjectsRequest or UpdateObjectsRequest could be used for Metadata Update. According to ebRS, SubmitObjectRequest can be used to submit new objects or updates to existing objects. UpdateObjectsRequest can only carry updates to existing objects. This specification requires this transaction to carry updates to DocumentEntry and Folder objects as well as new SubmissionSet and Association objects. So, only SubmitObjectsRequest can be used.

MV027: A new use case was received asking for the ability to delete documents in the Document Repository along with their DocumentEntry object in the Document Registry. This should be handled by a Document Administrator actor coordinating out of band with the Document Repository actor. Hope this is good enough for now. In IHE Rad, during a face-to-face meeting early in February, we identified that within Radiology, changes to a study is quite often, including deleting a study. This means with XDS-I.b the manifest will have to be deprecated, with or without a replacement. Occasionally, the manifest should in fact be deleted instead of deprecated. The two features are mentioned in the Metadata Versioning whitepaper. Just wondering what is the status of this whitepaper and whether it will be turned into a profile soon. Otherwise, IHE Rad may have to specify some interim mechanism for handling deletion and deprecate without replacement, and then replace such mechanism when ITI is ready with Metadata Versioning. Technically, this use case can be satisfied using the ebRS request RemoveObjectsRequest. The parameters are a list of ObjectRefs giving the id (entryUUID) of the Documents to be deleted. If received by the Document Repository, the Document would be deleted and the request forwarded to the Document Registry to signal the deletion of the DocumentEntry. Issues: 1) How would the Document Repository translate the entryUUID into the uniqueID? (answer: use a Stored Query to the registry to discover: a bit awkward for a Document Repository – requires binding with a Document Consumer …) Issue 2) How much metadata would be deleted? Only the DocumentEntry? Include the Submission Set and connecting Association? What if Submission Set contains other DocumentEntries? Remove from Folders as well? We have placed this issue as “out of scope” for now. The “how much to delete” question does not need to be decided in this profile. A second issue is causing a problem. If the decision to delete the manifest is coming from the Document Repository then the tools we have provided are sufficient. If the this decision is coming from somewhere else we have not provided a way to tell the Document Repository actor to delete a Document. Additional discussions with Radiology are necessary to move forward.

MV028: Need ability to remove a DocumentEntry from a Folder. This can be done by deprecating the Folder to DocumentEntry HasMember association.

MV029: Metadata Status Updating: the status change is signaled by the addition of particular Association (linked to a Submission Set). The status change can trigger a new version of the DocumentEntry (created internally by the Document Registry) or simply make the change to the existing version. Both approaches can be ‘decoded’ later. Currently the text calls for the change to be applied to the current version.

MV030: Support for Deferred Document Creation requires: 1) changing status from DeferredCreation to Approved and 2) updating size and hash attributes. These two changes need to happen in one request. Do we need to give developers instructions on the ordering of handling these operations? Status change and attribute update can be packaged into one update which is handled as an atomic transaction.

MV032: Can the following be done? Submit document followed by Replace followed by another Replace. Next, use Metadata Update/Delete to remove middle DocumentEntry from chain. Any Registry Object can be deleted by Delete. A new RPLC cannot be submitted alone (without the replacing DocumentEntry). This implies we need to be able to change a sourceObject or targetObject attribute on an Association. But, ebRIM says sourceObject and targetObject are immutable. This leaves us with the need to submit a replace association independent of the “new” DocumentEntry. Now with the ability to submit arbitrary Associations and deprecate Associations in an update, this use case can be managed.

MV036: Currently is permitted to add new Associations and Folders via Update Document Set so that the reshuffling of metadata to accommodate Patient ID updates are possible. This is discussed in section 10.4.14 in the third bullet. Some think adding Folders this way is not necessary. They would rather submit the new folder via the Register Document Set transaction and then build Associations to it via Update Document Set transactions. Ability to add Folders in Updates was made to avoid using two transactions. So, we need to resolve: simplicity of one transaction or purity of only allow the addition of new Associations in Updates. Solution: new Folders will have to be added via the Register Document Set-b transaction.

MV039: Should a parameter be added to FindDocuments Stored Query to all filtering of DocumentEntries based on availabilityStatus so that Offline documents can be ignored? Parameter has been added.

MV040: The availabilityStatus is now used on Associations (it wasn’t used prior to this supplement) but it is not a parameter on any Stored Query. It has been added to all the Stored Queries where it makes sense.