Instance Origin Status Attribute
| Tag | (0400,0600) |
|---|---|
| Type | Optional (3) |
| Keyword | InstanceOriginStatus |
| Value Multiplicity | 1 |
| Value Representation | Code String (CS) |
Categorizes the locality of the entity from whence the Instance originated.
Enumerated Values:
- LOCAL
-
Acquired or created in the local entity.
- IMPORTED
-
Imported from an external entity.
Note
-
The interpretation of the meaning of local and imported are user-specific. The purpose of this Attribute is to provide a means of communicating a user-specific decision, not to attempt to achieve uniformity with respect to any particular organizational or geographical boundary around any particular organizational or geographical entity, be it an entity that is a device, system, facility, office, department, site, enterprise, region, nation, etc.
-
A typical pattern would be for an archive to set a value of LOCAL when receiving Instances on the network from a modality within the hospital but to set a value of IMPORTED when receiving Instances from an interchange media reader or an external network Instance sharing gateway. Displaying the value of this Attribute in a viewer then makes it apparent to a user whether or not an Instance is "one of their own". How a receiver determines whether or not the sender is local is not specified, but could, for example, be determined from the sender's AE Title.
-
When Instances are transported from one entity to another and then imported, it is expected that this Attribute be set to an appropriate value for the new context, overwriting any previous value. E.g., a value of LOCAL used within an archive at the site where the Instances were acquired would be coerced to a value of IMPORTED when those Instances were received by another site to which the patient had been transferred. Whether or not previous values of this Attribute are copied into Original Attributes Sequence (0400,0561) after coercion is not specified.
-
It is not expected (but nor is it prohibited) that this Attribute will be removed by an exporting entity, since it may be useful to a recipient to know whether or not the Instance was local to the previous entity or not. Similarly, a modality may populate this Attribute with a value of LOCAL after creating the images, but is not required to.
-
The round-trip case, e.g., when an image is acquired locally, exported, locally deleted and then re-imported may be challenging unless a local record is maintained. I.e., after acquisition, in the local archive it would be expected to be LOCAL. After re-importation without any local state, it may be hard to determine that it once was LOCAL. Other Attributes such as Institution Name may not be sufficient to reliably detect this.
-
A new SOP Instance UID (0008,0018) is not required when adding or coercing this Attribute, since a derived Instance is not being created. See Section C.12.4.1.1 Derivation Description and Section B.4.1.3 Coercion of Attributes in PS3.4 .
-
A more detailed history of the handling of an Instance may be recorded in Contributing Equipment Sequence (0018,A001).
-
This Attribute may need to be removed during de-identification. See Annex E “Attribute Confidentiality Profiles (Normative)” in PS3.15.
Section C.12.4.1.1 Derivation Description
C.12.4.1.1 Derivation Description
If an Image is identified to be a Derived Image (see Section C.7.6.1.1.2 “Image Type”), Derivation Description (0008,2111) and Derivation Code Sequence (0008,9215) describe the way in which the image was derived. They may be used whether or not the Source Image Sequence (0008,2112) is provided. They may also be used in cases when the Derived Image pixel data is not significantly changed from one of the source images and the SOP Instance UID of the Derived Image is the same as the one used for the source image.
Note
-
Examples of Derived Images that would normally be expected to affect professional interpretation and would thus have a new UID include:
-
images resulting from image processing of another image (e.g., unsharp masking),
-
a multiplanar reformatted CT image,
-
a DSA image derived by subtracting pixel values of one image from another.
-
an image that has been decompressed after having been compressed with a lossy compression algorithm. To ensure that the user has the necessary information about the lossy compression, the approximate compression ratio may be included in Derivation Description (0008,2111).
An example of a Derived Image that would normally not be expected to affect professional interpretation and thus would not require a new UID is an image that has been padded with additional rows and columns for more display purposes.
-
-
An image may be lossy compressed, e.g., for long term archive purposes, and its SOP Instance UID changed. PS3.4 provides a mechanism by which a query for the original Image Instance may return a reference to the UID of the lossy compressed version of the image using the Alternate Representation Sequence (0008,3001). This allows an application processing a SOP Instance that references the original image UID, e.g., a Structured Report, to obtain a reference to an accessible version of the image even if the original SOP Instance is no longer available.
Section B.4.1.3 Coercion of Attributes in PS3.4
B.4.1.3 Coercion of Attributes
At any Level of Storage Support, the SCP of the Storage Service Class may modify the Values of certain Attributes in order to coerce the SOP Instance into the Query Model of the SCP. The Attributes that may be modified are shown in Table B.4-1.
Table B.4-1. Attributes Subject to Coercion
|
Attribute Name |
Tag |
|---|---|
|
Patient ID |
(0010,0020) |
|
Issuer of Patient ID |
(0010,0021) |
|
Other Patient IDs Sequence |
(0010,1002) |
|
Study Instance UID |
(0020,000D) |
|
Series Instance UID |
(0020,000E) |
The SCP of the Storage Service Class may modify the Values of Code Sequence Attributes to convert from one coding scheme into another. This includes changing from deprecated Values of Coding Scheme Designator (0008,0102) or Code Value (0008,0100) to currently valid Values.
If an SCP performs such a modification, it shall return a C-STORE response with a status of Warning.
Note
-
Modification of these Attributes may be necessary if the SCP is also an SCP of a Query/Retrieve SOP Classes. These SOP Classes are described in this Standard. For example, an MR scanner may be implemented to generate Study Instance UIDs for images generated on the MR. When these images are sent to an archive that is HIS/RIS aware, it may choose to change the UID of the study assigned to the study by the PACS. The mechanism by which it performs this coercion is implementation dependent.
-
An SCP may, for instance, convert retired Code Values with a Coding Scheme Designator Value of "99SDM", "SNM3" or "SRT" to the corresponding SCT Code Values and use the "SCT" Coding Scheme Designator, in accordance with the DICOM conventions for SNOMED (see PS3.16).
-
Modification of Attributes that may be used to reference a SOP Instance by another SOP Instance (such as Study Instance UID and Series Instance UID Attributes) will make that reference invalid. Modification of these Attributes is strongly discouraged.
-
Other Attributes may be modified/corrected by an SCP of a Storage SOP Class.
-
Modification of Attributes may affect digital signatures referencing the content of the SOP Instance.