PS3.18 Metadata is Dataset only and does not include Group 0002 File Meta Information Status Letter Ballot Date of Last Update 2021/09/05 Person Assigned David Clunie Submitter Name David Clunie Submission Date 2021/03/24 Correction Number CP-2137 Log Summary: PS3.18 Metadata is Dataset only and does not include Group 0002 File Meta Information Name of Standard PS3.18 Rationale for Correction: PS3.18 defines "Metadata", such as retrievable by the Retrieve Metadata transactions, as being the "A DICOM Dataset ..." PS3.10 defines the File Meta Information (Group 0002 Data Elements) as ".. includes identifying information on the encapsulated Data Set". PS3.5 defines the "Data Set" as "Exchanged information consisting of a structured set of Attribute values directly or indirectly related to Information Objects". Ergo, the response payload of a Retrieve Metadata transaction should not include the File Meta Information Group 0002 Data Elements, but this is not obvious from the text of PS3.18 alone. Add clarification. Also clarify that some Attributes in the Metadata may be dependent on the Representation (Transfer Syntax, Media Type) and consequently not match a retrieval of the object. Further clarify that the File Meta Information is also not included in a Store Transaction. Correction Wording:

Amend DICOM PS3.18 as follows:

Metadata A DICOM Dataset where zero or more elements (typically containing large data, such as Pixel Data) have been replaced with Bulkdata URIs. Metadata does not include the Group 0002 File Meta Information Data Elements, which describe but are not part of a Dataset, per . This Part of the Standard makes use of the following terms defined in : DICOM File . DICOM File Format . DICOM File Service . File .

specifies the media types that may be used to encode representations of Metadata for the URI and RESTful services. Only the RESTful Services support Metadata representations.

Media Types for Metadata

Media Type	Descriptions	URI	RESTful
application/dicom+xml	Encodes Instances as XML Infosets defined in the Native DICOM Model defined in .	not applicable	required
application/dicom+json	Encodes Instances in the JSON format defined in .	not applicable	required

...

defines the resources used to retrieve the metadata contained in Instances.

Retrieve Transaction Metadata Resources

Resource	URI Template
Study Metadata	/studies/{study}/metadata
Series Metadata	/studies/{study}/series/{series}/metadata
Instance Metadata	/studies/{study}/series/{series}/instances/{instance}/metadata

The Metadata Resources are used to retrieve the DICOM instances without retrieving Bulkdata. The Metadata returned for a study, series, or instance resource includes all Attributes in the resource. For Data Elements having a Value Representation (VR) of DS, FL, FD, IS, LT, OB, OD, OF, OL, OV, OW, SL, SS, ST, SV, UC, UL, UN, US, UT and UV, the origin server is permitted to replace the Value Field of the Data Element with a Bulkdata URI. The user agent can use the Bulkdata URI to retrieve the Bulkdata. The Metadata describes the corresponding Resource, not any Representation of it that might be separately retrieved, hence includes only the DICOM Dataset (without Bulkdata), and in particular does not include any Group 0002 File Meta Information Data Elements. Some Attributes of the DICOM Dataset may depend on the Representation, not the Resource, especially those that describe the Pixel Data, so may differ from those encoded in a particular retrieved Representation. E.g., Photometric Interpretation (0028,0004) may differ depending on the Transfer Syntax. Information related to Transfer Syntax UID (0002,0010) in the File Meta Information, which might be expected to be of interest for retrieval of the Representation of the Resource in a particular Media Type, may be available using the Available Transfer Syntax UID (0008,3002) in a Search Transaction.

... The Store transaction supports only DICOM resources. The resource can be supplied as a single Instance, or as separate Metadata and Bulkdata.

defines the resources used to store Instances.

Store Transaction DICOM Resources

Resource	URI Template	Description
Studies	/studies	Stores a set of representations that may have different Study Instance UIDs.
Study	/studies/{study}	Stores a set of representations that belong to the same Study, i.e., each representation shall have the same Study Instance UID.

The request payload shall be present and shall contain one or more representations specified by the Content-Type header field. The payload may contain Instances from more than one Study if the Study Instance UID is not specified in the Target URI. The request payload shall consist of either: SOP Instances, or Metadata accompanied by Bulkdata. The Metadata includes only the DICOM Dataset (without Bulkdata), and in particular does not include any Group 0002 File Meta Information Data Elements. The origin server will create appropriate File Meta Information depending on the media type of the supplied compressed pixel data, if it happens to internally store the Dataset in a PS3.10 File. binary instances shall be encoded with one message part per DICOM Instance. Metadata and Bulkdata requests will be encoded in the following manner (see ): All XML request messages shall be encoded as described in the Native DICOM Model defined in with one message part per XML object; the Attributes of the Image Pixel Description Macro may be omitted for the media types specified in . All JSON request messages shall be encoded as an array of DICOM JSON Model Objects defined in in a single message part; the Attributes of the Image Pixel Description Macro may be omitted for the media types specified in . Bulkdata (with the exception of Encapsulated Document (0042,0011) element) and uncompressed pixel data shall be encoded in a Little-Endian format using the application/octet-stream media type with one message part per Bulkdata item. Compressed pixel data shall be encoded in one of two ways: single-frame pixel data encoded using a single-frame media type (one message part); multi-frame or video pixel data encoded using a multi-frame media type (multiple frames in one message part). Uncompressed Bulkdata shall be encoded as application/octet-stream. An Encapsulated Document (0042,0011) Bulkdata element shall be encoded using the media-type from the MIME Type of the Encapsulated Document (0042,0012) Attribute with one message part per document.

The origin server stores Instances from the representations contained in the request payload. The stored Instance(s) shall fully conform to the IOD and encoding requirements of and , respectively. This Transaction stores one or more new Instances, and adds them to new or existing Series and Studies. While creating resources from the representations, the origin server may coerce or replace the values of data elements. For example, Patient Name, Patient ID, and Accession Number might be coerced when importing media from an external institution, reconciling the Instances against a master patient index, or reconciling them against an imaging procedure order. The origin server may also fix incorrect values, such as Patient Name or Patient ID; for example, because an incorrect work list item was chosen, or an operator input error has occurred. If any Attribute is coerced or corrected, the Original Attribute Sequence (0400,0561) shall be included in the DICOM Object that is stored and may be included in the Store Instances Response Module (see ) in the response. For more information on populating the Original Attribute Sequence see . The origin server shall encapsulate or convert any compressed pixel data received as Bulkdata into an appropriate DICOM Transfer Syntax, as defined in . If the request message contains compressed Bulkdata with a Content Type that is one of the media types specified in , the request may omit the Image Pixel Description Macro Attributes and the origin server will derive them from the compressed octet stream. Some media types do not directly correspond to a DICOM Transfer Syntax and the origin server will transform the received bit stream into an uncompressed or lossless (reversibly) compressed Transfer Syntax. This allows a user agent to use consumer media types to encode the pixel data even though it may not have: the pixel data in a form that directly corresponds to a lossless (reversible) DICOM Transfer Syntax, or an API to access the information required to populate the Image Pixel Description Macro. If the supplied compressed bit stream is in a lossless (reversible) format, the intent is to allow full fidelity retrieval of the decompressed pixels, not the format in which it happened to be submitted. The origin server shall encapsulate or convert any compressed pixel data received as bulk data into an appropriate DICOM Transfer Syntax, as defined in . If the supplied compressed octet stream is in a lossy (irreversible) format, there will be a corresponding DICOM Transfer Syntax, and the origin server is not expected to recompress it causing further loss. contains a list of media types containing compressed pixel data from which an origin server shall be able to derive the Image Pixel Data Description Macro Attribute values. Requirements are specified in as follows: Transform No DICOM Transfer Syntax exists; shall be transformed by the origin server into an uncompressed or lossless compressed Transfer Syntax (the choice of which is at the discretion of the origin server). Unchanged Shall be encapsulated in the corresponding DICOM Transfer Syntax without further lossy compression.

Media Type Transformation to Transfer Syntaxes

Media Type	Requirement
image/gif	Transform
Image/jp2	Unchanged
image/jpeg	Unchanged
image/jpx	Unchanged
image/png	Transform
video/mp4	Unchanged
video/mpeg2	Unchanged

In the case of pixel data supplied as image/gif or image/png, the origin server may transform the color representation from indexed color to true color (RGB) as necessary to conform to any Photometric Interpretation constraints specified by the IOD (i.e., if PALETTE COLOR is not permitted) ; such a transformation is considered lossless. If the number of bits per channel of an image/png file is not supported by the IOD, a lossless transformation cannot be performed. An animated image/gif will be converted into a multi-frame image by transforming the frame deltas into fully decoded frames; image/png does not support animation, and Multiple-image Network Graphics (MNG) is not included in . Any transparency information present in an image/gif or image/png file will be discarded, since DICOM does not support the concept of transparency. The actual pixel value used to replace transparent pixels (e.g., black or white) is at the discretion of the implementation, but if the value used does not appear elsewhere in the image, it may be useful to record it in Pixel Padding Value (0028,0120). If an alpha channel is supplied in an image/png file, the alpha channel will be discarded (i.e., considered to consist of all opaque values, consistent with the policy of discarding any transparency information). In the case of pixel data that contains a single channel in the absence of metadata describing the interpretation of the pixel values, the Photometric Interpretation may be assumed by the origin server to be MONOCHROME2 (zero is interpreted as black).