Item Inventory DateTime Attribute
| Tag | (0008,0404) |
|---|---|
| Type | Required (1) |
| Keyword | ItemInventoryDateTime |
| Value Multiplicity | 1 |
| Value Representation | Date Time (DT) |
DateTime of creation of the Inventory information for this Item. All Study Attributes in this Sequence Item are correct as of this DateTime. The value shall be at or after the Content Date (0008,0023) and Content Time (0008,0033) of this Inventory SOP Instance.
Note
This Attribute may be used for Study record reconciliation. See Section YYYY.7.10 in PS3.17.
Section YYYY.7.10 in PS3.17
YYYY.7.10 Study Record Reconciliation
Within the tree of linked Inventory SOP Instances, a given Study may be referenced multiple times among the Inventoried Studies Sequence Items. The Items may have different content, but each Item is a complete record of the contents of the Study as known by the creator of that Item.
Differences in content may occur due to changes to the metadata or content (SOP Instances) of the Study during the production of the Inventory, or due to different Series of a Study being stored on different media or storage subsystems, or for other reasons. The application using an Inventory may need to reconcile such multiple occurrences.
DICOM is not prescriptive regarding methods of reconciliation, but the Inventory IOD does provide Attributes that can assist in the process, in particular the various timestamps associated with the Study content and the process of Inventory creation, as shown in Table YYYY.7-3. These timestamp Attributes might be used to establish a timeline of changes to Study content and metadata, and of record extraction for inclusion in the Inventory. For example, a Study record may differ from a record with an earlier Item Inventory DateTime (0008,0404) only with the presence of an additional Series whose Series Date (0008,0021) is after the prior Item Inventory DateTime (0008,0404). The later record might reasonably be considered to be a more current replacement. However, two Study records might have entirely different sets of Series, and in that case simply choosing one record based on timestamp is probably not correct; the Study records would have to be further evaluated for the underlying reason for the difference, and the records potentially merged in some way.
Table YYYY.7-3. Timestamp Attributes Assisting in Reconciliation
|
Attribute |
Tag |
|---|---|
|
Content Date |
(0008,0023) |
|
Content Time |
(0008,0033) |
|
Inventoried Studies Sequence |
(0008,0423) |
|
>Item Inventory DateTime |
(0008,0404) |
|
>Study Update DateTime |
(0008,041F) |
|
>Original Attributes Sequence |
(0400,0561) |
|
>>Attribute Modification DateTime |
(0400,0562) |
|
>Inventoried Series Sequence |
(0008,0424) |
|
>>Series Date |
(0008,0021) |
|
>>Series Time |
(0008,0031) |
|
>>Original Attributes Sequence |
(0400,0561) |
|
>>>Attribute Modification DateTime |
(0400,0562) |
In general, a major factor in reconciling diverse records is a full understanding of how the repository system manages the storage of Studies, and which timestamps and change auditing data it actually records. The reconciliation process will typically need to account for such system design features, which are not conveyed in Inventory SOP Instance Attributes or in DICOM Conformance Statements.
Note that a task for Study record merge is reconciliation of access paths to stored SOP Instances of the Study. This may present challenges if the Study records link to different access methods, target folders, or container files. In the case of conflicting information, it may be necessary to disregard Study or Series level access specifications, and use only the access links to each SOP Instance of the Study as recorded in the Instance level record.
YYYY.7.10.1 Example - Deleted Study
An example will show the dependency on system design for Study record reconciliation. Consider two Inventories, a baseline made at time A and an increment made at a later time B, and during the intervening time a Study is deleted (perhaps because it was assigned to the wrong patient). The migration source storage system might have taken one of several approaches, with the associated result in the time B inventory (this is not an exhaustive list) :
-
It marks the Study as deprecated, but otherwise retains the data - the time B incremental inventory includes the entire set of Study, Series, and Instance records, each with the Removed from Operational Use (0008,0405) Attribute value Y.
-
It marks the Study as deprecated, and deletes all the Series and Instance data - the time B incremental inventory includes only the Study record with the Removed from Operational Use (0008,0405) Attribute value Y.
-
It deletes the references to the Series and SOP Instances of the Study in the database, retains the Study level database record, but does not support a deprecation flag - the time B incremental inventory includes a Study item, but no Series items.
-
It deletes all Study information, with only a record in an audit trail - the time B incremental inventory simply does not record the Study.
In cases 1) and 2), the consumer application knows exactly what has happened, and can make a determination whether to move the deprecated Study data to the migration target repository. That determination would be based, among other factors, on the data retention policies of the organization, and on the technical approach the target system takes to identifying and managing deleted Studies.
In case 3), it might not be clear just from the content of the Inventories what is the appropriate status of the Study. This is further complicated if the SOP Instance files listed in the time A baseline inventory are still accessible from storage, perhaps indicating that the Study was not supposed to be empty. If the consumer application knows that this is the expected behavior of the source system for Study deletion, it might proceed with migration in accordance with organizational policy. However, the application may need to consult external information, such as audit trails or human authorization, before proceeding.
In case 4), without an explicit Study record indicating deletion, the incremental Inventory record for a deleted Study is identical to a record for an unchanged Study (i.e., no record in the Inventory). The migration application would have no reason to suspect that the Study was deleted until it tries to migrate the SOP Instances, and cannot find them. Studies that have gone missing are a patient safety issue, as opposed to Studies that are known to have been deleted for a valid reason, and this situation may trigger an audit investigation.