The Native DICOM Model defines a representation of binary-encoded DICOM SOP Instances as XML Infosets that allows a recipient of data to navigate through a binary DICOM data set using XML-based tools instead of relying on tool kits that understand the binary encoding of DICOM.
It is not the intention that this form be utilized as the basis for other uses. This form does not take advantage of the self-validation features that could be possible with a pure XML representation of the data.
With the exception of padding, a data source that is creating a new instance of a Native DICOM Model (e.g., the result from some analysis application) shall follow the DICOM encoding rules (e.g., the handling of character sets) in creating Values for the DicomAttributes within the instance of the Native DICOM Model.
Group Length (gggg,0000) attributes shall not be included in a Native DICOM Model instance.
A data recipient that converts data from an instance of the Native DICOM Model back into a binary encoded DICOM object shall adjust the padding as necessary to meet the encoding rules specified in DICOM PS3.5.
The ObjectDescriptors MIME content type for the Native DICOM Model shall be "application/x-dicom.native".
The ObjectDescriptors class UID for the Native DICOM Model shall be "1.2.840.10008.7.1.1".
Support of the Native DICOM Model as both a data source and a data recipient shall be required of all Hosting Systems implementing the interface.
Support of the Native DICOM Model as either a data source or a data recipient shall be optional for all Hosted Applications implementing the interface.
Table A.1.5-1. Native DICOM Model
Name |
Optionality |
Cardinality |
Description |
---|---|---|---|
NativeDicomModel |
R |
1 |
An Infoset (as defined in W3C Recommendation XML Information Set "http://www.w3.org/TR/xml-infoset/") representing the content of a DICOM Data Set (as defined in PS3.5). The directivexml:space="preserve" shall be included. Examples include:
|
Table A.1.5-2. DICOM Data Set Macro
Name |
Optionality |
Cardinality |
Description |
---|---|---|---|
DicomAttribute |
O |
0-n |
An Infoset element corresponding to each DICOM Attribute. |
>keyword |
C |
A |
The keyword as defined in PS3.6. Required unless the DICOM Data Element is unknown to the host. |
>tag |
R |
A |
The four-digit zero-padded hexadecimal values of the Group and Element Numbers of the Data Element Tag, concatenated as a single string without a delimiter and with lowercase letters disallowed. E.g., Data Element (0010,0020) would have a tag of "00100020". For Private Data Elements, the two most significant hexadecimal characters of the Element Number shall be 00, since the Private Creator is explicitly conveyed and the block used in the DICOM encoding shall not be sent (i.e., a Private Data Element has the form gggg00ee). |
>vr |
O |
A |
The Value Representation of this element, represented as a two character uppercase string, as defined in PS3.5 and specified for this Data Element in PS3.6. NoteImplementations may utilize the Value Representation to validate data values, if desired. |
>privateCreator |
C |
A |
The value of the Private Creator Data Element corresponding to the block in which this Private Data Element is used. Required for Private Data Elements. Shall not be present otherwise (i.e., for Data Elements defined by the DICOM Standard). |
>Value |
C |
1-n |
A Value from the Value Field of the DICOM Data Element. There is one Infoset Value element for each DICOM Value or Sequence Item. Required if the DICOM Data Element represented is not zero length and an Item, PersonName, InlineBinary or BulkData XML element is not present. Shall not be used if the VR of the enclosing Attribute is either SQ or PN. |
>>number |
R |
A |
The order in which the Value occurs within the DICOM Value Field, as a number monotonically increasing starting from 1 by 1. NoteThe Number XML Attribute is used to preserve the original order. |
>> plain character data |
C |
1 |
A single DICOM value encoded as plain character data. E.g., a DICOM Decimal String Value Field that contained two delimiter-separated values, e.g., "0.5\0.4" would be encoded as two Infoset Value elements:<Value number="1">0.5</Value><Value number="2">0.4</Value>A Code String Value Field that containing three delimiter-separated values, the second of which was zero length, "MPG\\XR3", would be encoded as:<Value number="1">MPG</Value><Value number="2"></Value><Value number="3">XR3</Value>Contrast the latter example with a zero length Value Field, in which case there would be no Infoset Value elements at all. For DICOM Data Elements whose VR is AT, each value shall be encoded as the four-digit zero-padded hexadecimal values of the Group and Element Numbers of the Data Element Tag, concatenated as a single string without a delimiter and with lowercase letters disallowed. The character encoding is that declared for the Infoset, regardless of any DICOM Specific Character Set, and any necessary translation from the DICOM Specific Character Set to the Infoset character encoding shall have been performed. NoteThis translation might not be completely lossless, particularly with Asian character sets. |
>Item |
C |
1-n |
A DICOM sequence item, in other words a nested DICOM Data Set. Required if the DICOM Data Element represented is a Sequence (has a VR of "SQ") and is not zero length. Not allowed otherwise. |
>>number |
R |
A |
The order in which the Item occurs within a Sequence of Items, as a number monotonically increasing from 1 by 1. NoteThe Number XML Attribute is used to preserve the original order. |
>>Include Table A.1.5-2 “DICOM Data Set Macro” |
R |
1 |
Recursively includes the Data Set corresponding to a Sequence Item. |
>PersonName |
C |
1-n |
A parsed representation in XML of a DICOM Data Element containing a name (i.e., whose VR is PN). NoteParsing Attributes with a VR of PN into an XML representation of the name groups and components simplifies the creation of XPath statements to pull only portions of names out of the DICOM data. Required if the DICOM Data Element represented has a VR of PN and is not zero length. Not allowed otherwise. The rules defined in DICOM PS3.5 on the usage of the Alphabetic, Ideographic, and Phonetic groups of name components within a DICOM Attribute with a Value Representation of PN apply. |
>>number |
R |
A |
The order in which the PersonName occurs within the DICOM Value Field, as a number monotonically increasing from 1 by 1. NoteThe Number XML Attribute is used to preserve the original order. |
>>Alphabetic |
O |
0-1 |
A group of name components that are represented in alphabetical characters (see the definition for the Value Representation of PN in PS3.5). |
>>>Include Table 10.2-1 “Person Name Components Macro” |
|||
>>Ideographic |
O |
0-1 |
A group of name components that are represented in ideographic characters (see the definition for the Value Representation of PN in PS3.5). |
>>>Include Table 10.2-1 “Person Name Components Macro” |
|||
>>Phonetic |
O |
0-1 |
A group of name components that are represented in phonetic characters (see the definition for the Value Representation of PN in PS3.5). |
>>>Include Table 10.2-1 “Person Name Components Macro” |
|||
>BulkData |
C |
1 |
A reference to a blob of data that the recipient may retrieve through use of the GetData() method, a WADO-RS call or a STOW-RS call. Required if the DICOM Data Element represented is not zero length and an XML Infoset Value, Item, InlineBinary or PersonName element is not present. The provider of the data may use a BulkData reference at its discretion to avoid encoding a large DICOM Value Field as text by value in the Infoset. For example, pixel data or look up tables. There is a single BulkData Infoset element representing the entire Value Field, and not one per Value in the case where the Value Multiplicity is greater than one. E.g., a LUT with 4096 16 bit entries that may be encoded in DICOM with a Value Representation of OW, with a VL of 8192 and a VM of 1, or a US VR with a VL of 8192 and a VM of 4096 would both be represented as a single BulkData element. All rules (e.g., byte ordering and swapping) in PS3.5 apply. NoteImplementers should in particular pay attention the PS3.5 rules regarding the value representations of OW and OF. If the BulkData has a string or text Value Representation, the value(s) of the DICOM Specific Character Set Data Element, if present, might be necessary to determine its encoding. |
>>uuid |
C |
A |
An identifier of this bulk data reference formatted as a UUID using the hexadecimal representation defined in ITU-T Recommendation X.667. Required if BulkData URI is not present. Shall not be present otherwise. |
>>uri |
C |
A |
The HTTP(S) URI for this bulk data reference. Required if the NativeDicomModel was:
Shall not be present otherwise. |
>InlineBinary |
C |
1 |
The Value Field of the enclosing Attribute encoded as base64. Required if the DICOM Data Element represented is:
Shall not be present otherwise. There is a single InlineBinary Infoset element representing the entire Value Field, and not one per Value in the case where the Value Multiplicity is greater than one. E.g., a LUT with 4096 16 bit entries that may be encoded in DICOM with a Value Representation of OW, with a VL of 8192 and a VM of 1, or a US VR with a VL of 8192 and a VM of 4096 would both be represented as a single InlineBinary element. All rules (e.g., byte ordering and swapping) in PS3.5 apply. NoteImplementers should in particular pay attention to the PS3.5 rules regarding the value representations of OD, OF and OW. |
The Normative version of the XML Schema for the Native DICOM Model follows:
default namespace="http://dicom.nema.org/PS3.19/models/NativeDICOM" # This schema was created as an intermediary, a means of describing # native binary encoded DICOM objects as XML Infosets, thus allowing # one to manipulate binary DICOM objects using familiar XML tools. # As such, the schema is designed to facilitate a simple, mechanical, # bi-directional translation between binary encoded DICOM and XML-like # constructs without constraints, and to simplify identifying portions # of a DICOM object using XPath statements. # # Since this schema has minimal type checking, it is neither intended # to be used for any operation that involves hand coding, nor to # describe a definitive, fully validating encoding of DICOM concepts # into XML, as what one might use, for example, in a robust XML # database system or in XML-based forms, though it may be used # as a means for translating binary DICOM Objects into such a form # (e.g., through an XSLT script). start = element NativeDicomModel { DicomDataSet } # A DICOM Data Set is as defined in PS3.5. It does not appear # as an XML Element, since it does not appear in the binary encoded # DICOM objects. It exists here merely as a documentation aid. DicomDataSet = DicomAttribute* DicomAttribute = element DicomAttribute { Tag, VR, Keyword?, PrivateCreator?, (BulkData | Value+ | Item+ | PersonName+ | InlineBinary)? } BulkData = element BulkData{ UUID | URI } Value = element Value { Number, xsd:string } InlineBinary = element InlineBinary { xsd:base64Binary } Item = element Item { Number, DicomDataSet } PersonName = element PersonName { Number, element Alphabetic { NameComponents }?, element Ideographic { NameComponents }?, element Phonetic { NameComponents }? } NameComponents = element FamilyName {xsd:string}?, element GivenName {xsd:string}?, element MiddleName {xsd:string}?, element NamePrefix {xsd:string}?, element NameSuffix {xsd:string}? # keyword is the attribute tag from PS3.6 # (derived from the DICOM Attribute's name) Keyword = attribute keyword { xsd:token } # canonical XML definition of Hex, with lowercase letters disallowed Tag = attribute tag { xsd:string{ minLength="8" maxLength="8" pattern="[0-9A-F]{8}" } } VR = attribute vr { "AE" | "AS" | "AT"| "CS" | "DA" | "DS" | "DT" | "FL" | "FD" | "IS" | "LO" | "LT" | "OB" | "OD" | "OF" | "OW" | "PN" | "SH" | "SL" | "SQ" | "SS" | "ST" | "TM" | "UI" | "UL" | "UN" | "US" | "UT" } PrivateCreator = attribute privateCreator{ xsd:string } UUID = attribute uuid { xsd:string } URI = attribute uri { xsd:anyURI } Number = attribute number { xsd:positiveInteger }