Difference between revisions of "Metadata Update"

From IHE Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
This page contains examples supporting the Metadata Update profile.
+
This page contains examples supporting the Metadata Update extensions to XDS. These examples show only enough metadata to explain the operation of the update.  Many of these metadata objects are incomplete.
  
−
== OASIS ebXML Registry 3.0 support for Metadata Versioning ==
+
== New Entry ==
  
−
This work is enabled by new metadata management features introduced into version 3.0 of the ebXML Registry standard (ebRIM and ebRS). The key new concept is the ability to maintain multiple copies or versions of a metadata object, such as an ExtrinsicObject, which represents in metadata a single real document in a repository. In terminology of the standard, all objects stored in the registry are called Registry Objects.  A new concept is the Registry Object Instance, a specific version of a Registry Object. Collectively, all the versions of a Registry Object are called a Logical Registry Object.
+
== Update DocumentEntry Metadata ==
  
−
All Registry Objects are identifiable by their id attribute. All objects in the registry must have a unique value for their id attribute. This sense of identity is maintained when metadata versioning is introduced. To allow a collection of registry objects to be grouped together and be identified as versions of the same object, two new attributes are introduced: the Logical ID and the VersionInfo element. While all objects must have unique value for their id attribute to maintain their identity, all objects that are versions of the same logical object have the same logical id or lid attribute.  
+
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.
  
−
The simplest form of an ExtrinsicObject, as specified in ebRIM 2.1, looks like:
+
<pre>
 +
  <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>
 +
</pre>
 +
 
 +
Precondition object. Note the version matches the PreviousVersion above, the status is Approved, and the uniqueId attribute matches.  Thus satisfying the precondition.
  
 
<pre>
 
<pre>
−
<ExtrinsicObject id=”urn:uuid:123...”>     
+
    <ExtrinsicObject  
−
</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>
 
</pre>
 
</pre>
  
−
containing only an id attribute giving it its identity. Note that we use a shortened format for UUIDs to improve readability. In ebRIM 3.0 this same object could be coded as:
+
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
  
 
<pre>
 
<pre>
−
<ExtrinsicObject id=”urn:uuid:123...” lid=”urn:uuid:123...”>     
+
<!-- Trigger object -->
−
</ExtrinsicObject>
+
    <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>
 
</pre>
 
</pre>
  
−
In this version of the standard, the registry object still maintains its identity by having a unique value for the id attribute. The presence of the lid attribute having the same value as the id attribute indicates that this is the first, the original, version of the object. Current XDS, XDS.a and XDS.b, return this format from a Stored Query since that transaction is coded in ebRIM 3.0.  Future versions of an object, that is version 2..n of an object, will have new values for the id attribute but the original value for the lid attribute. The value of the lid attribute is always equal to the value of the id attribute of the first version of the registry object. To query, in SQL, for all versions of this ExtrinsicObject one would use an SQL clause of
+
This is the updated metadata of the original object.  Note the status has changed to Deprecated
  
 
<pre>
 
<pre>
−
lid='urn:uuid:123...'
+
    <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>
 
</pre>
 
</pre>
  
−
and each ExtrinsicObject returned would have the same value for the lid attribute but a different value for its id attribute.
+
== Deprecate DocumentEntry ==
  
−
Note that while the lid attribute labels the various versions of a registry object and the id attribute allows each version to be addressable by being unique, these two attributes are inadequate for determining which is the first version, the second version, etc. For this the standard introduces the VersionInfo element which looks like:
+
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).
  
 
<pre>
 
<pre>
−
<VersionInfo versionName=”2” comment=””/>
+
    <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>
 
</pre>
 
</pre>
  
−
This element is required in all registry objects.  In XDS, this means it is required in ExtrinsicObject, RegistryPackage (submission set and folder), and Association. It is also required on Classification and ExternalIdentifier objects.
+
== 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.
  
−
The ebRIM 3.0 specification introduces rules on the behavior of versions of registry objects. All versions of an ExtrinsicObject reference the same document in the repository. For XDS.b this implies that all versions of a DocumentEntry/ExtrinsicObject must carry the same value for the XDSDocumentEntry.uniqueId attribute since it is used to reference the actual document in the repository.
+
'''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.
−
An Association always references a specific version of a registry object through its id attribute. Its attributes sourceObject and targetObject hold the id attribute of the object being pointed at.
 
  
−
The lid attribute is not required in the submission of a registry object. The value of the lid attribute defaults to the value of the id attribute thus creating the first version of a registry object by default.  
+
'''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.
  
−
The VersionInfo attribute is never submitted to the registry, it is generated by the registry and always returned from a query. The versionName portion of the VersionInfo attribute is automatically allocated and set by the registry. It defaults, in the standard, to versionName=”1.1” but the registry implementation is not constrained in what numbering scheme it uses. The comment portion of the VersionInfo attribute is set by the comment attribute of the <rim:Request/> element.  In XDS.b this corresponds to the <rim:SubmitObjectsRequest/> element that is coded in the Provide And Register Document Set and Register Document Set transactions. Note that this comment applies to all objects submitted in the request.
+
'''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.
  
−
The ebRS 3.0 standard includes the request/verb, UpdateObjectsRequest, for submitting updates to a Registry Object.  A traditional update in ebRS is to update or add a single attribute, such as a Slot, to an existing Registry Object. Creating a new version of an object is a separate operation. Note that updates can be carried in either UpdateObjectsRequest or SubmitObjectsRequest requests according to ebRS 3.0.  
+
'''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.
  
−
When a registry object (such as an ExtrinsicObject) is updated, the submitter must query the registry for the previous version, update the parts of the object as needed and resubmit the entire registry object. Individual attributes cannot be updated.
+
'''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.
  
−
The ebRIM 3.0 standard allows for the creation of new status attribute values.
+
'''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.

Latest revision as of 11:09, 21 July 2017

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

New Entry

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.

Retrieved from "http://wiki.ihe.net/index.php?title=Metadata_Update&oldid=103050"