DICOM JSON Model

[David Clunie]

Hi

Since Dave Harvey mentioned XML, private elements, etc., recently,
it occurred to me to remind everyone to take a look at the proposed
DICOM JSON model.

Take a look at Sup 166, "Query based on ID for DICOM Objects by
REpresentational State Transfer (REST) Services (QIDO-RS)":

http://www.dclunie.com/dicom-status/status.html#Supplement166

It is currently out for letter ballot, and even if you don't
care about QIDO or RESTful services per se, you may still be
interested in the DICOM JSON Model that Sup 166 proposes to add
to PS 3.18.

There is an example of a query response at the very end,
which is a quick way to get up to speed with what is being
proposed; it even has some private data element examples
and ideographic names.

David

[Mathieu Malaterre]

On Thursday, September 12, 2013 2:57:16 PM UTC+2, David Clunie wrote:
> Take a look at Sup 166, "Query based on ID for DICOM Objects by
>
> REpresentational State Transfer (REST) Services (QIDO-RS)":
>
>
>
> http://www.dclunie.com/dicom-status/status.html#Supplement166
>
>
>
> It is currently out for letter ballot, and even if you don't
>
> care about QIDO or RESTful services per se, you may still be
>
> interested in the DICOM JSON Model that Sup 166 proposes to add
>
> to PS 3.18.
>
>
>
> There is an example of a query response at the very end,
>
> which is a quick way to get up to speed with what is being
>
> proposed; it even has some private data element examples
>
> and ideographic names.

Some comments:

Comment #1

X.Y RS REQUEST/RESPONSE
a. SearchForStudies
b. SearchForSeries
c. SearchForInstances

What is the rational for *not* having SearchForPatients ? Does QIDO rely only on Study Root Query/Retrieve model ?


Comment #2

In X.Y.1 Request
...
{dicomTag}.{attributeID}, where {attributeID} is an element of the sequence specified by {dicomTag}
{dicomKeyword}.{attributeID}, where {attributeID} is an element of the sequence specified
by {dicomKeyword}
...

IMHO, it is missing the Item identifier, eg:

{dicomTag}.{Item#}.{attributeID}, where {attributeID} is an element of the sequence specified by {dicomTag}
{dicomKeyword}.{Item#}.{attributeID}, where {attributeID} is an element of the sequence specified by {dicomKeyword}

For ref, see sup118, where an example is given:

/DicomNativeModel/DicomAttribute[@keyword=”ViewCodeSequence”]/Item[@number=1]/
/DicomAttribute[@keyword=”CodeMeaning”]/Value[@number=1]



Comment #3

The restriction ("shall") is a bit restrictive for X.Y.2.1.1 Study Matching and al. It rely on Optional Keys (PS 3.4-2011, Table C.6-5 STUDY LEVEL KEYS FOR THE STUDY ROOT QUERY/RETRIEVE INFORMATION MODEL). Which means implementation of a proxy QIDO to an existing DICOM SCP may not always be possible.

...
Providers of the SearchForStudies service shall support the following query keys:
ModalitiesInStudy / 00080061
ReferringPhysiciansName / 00080090
...

Comment #4

...
TM Time String, restricted to DICOM Time format (HHMMSS.FFFFFF&ZZXX)
...

I do not believe TM contains ZZXX the offset from Coordinated Universal Time (UTC).


Comment #5

I personally find it very cumbersome that Keyword or Tag is used a key, you never know if you are getting:

"RetrieveURL": {
"Tag": "00081190",
"VR": "UT",
"Value": [ "http://example.org/1.2.3" ]
}
or
"00081190": {
"Tag": "00081190",
"VR": "UT",
"Value": [ "http://example.org/1.2.3" ]
}

If I were to implement this Sup, I would not implement the Keyword scenario since it only adds complexity. I do however see the point that is makes the output more human readable, but I would have done it this way:

"00081190": {
"Keyword": "RetrieveURL",
"VR": "UT",
"Value": [ "http://example.org/1.2.3" ]
}


My 2 cents,
-M

[Mathieu Malaterre]

On Friday, September 13, 2013 11:29:15 AM UTC+2, Mathieu Malaterre wrote:
> If I were to implement this Sup, I would not implement the Keyword scenario since it only adds complexity. I do however see the point that is makes the output more human readable, but I would have done it this way:
>
>
>
> "00081190": {
>
> "Keyword": "RetrieveURL",
>
> "VR": "UT",
>
> "Value": [ "http://example.org/1.2.3" ]
>
> }

[Answering to myself]

I cannot see how it could be done otherwise, since it would imply that any QIDO-RS implementation is required to be updated to the very latest DICOM standard. Indeed an implementation may not know the meaning (=Tag number) of a particular Keyword recently added to the standard.

[Mathieu Malaterre]

That's not really a problem, since Tag is always sent as part of the JSON message. So one does not need to even read the top level JSON name, but instead rely on Tag Value...

sorry for the noise,

[José Antonio Pérez]

I would like to add some observations to the comments by Mathieu:

> X.Y RS REQUEST/RESPONSE
> a. SearchForStudies
> b. SearchForSeries
> c. SearchForInstances
>
> What is the rational for *not* having SearchForPatients ? Does QIDO rely only on Study Root Query/Retrieve model ?

I do not think this is a real problem. Since every response includes the PatientID field, the client application calling the web service could easily group the responses by patients, then show a list of studies for every patient in the result set.

> IMHO, it is missing the Item identifier, eg:
>
> {dicomTag}.{Item#}.{attributeID}, where {attributeID} is an element of the sequence specified by {dicomTag}
> {dicomKeyword}.{Item#}.{attributeID}, where {attributeID} is an element of the sequence specified by {dicomKeyword}
>
> For ref, see sup118, where an example is given:
>
> /DicomNativeModel/DicomAttribute[@keyword=”ViewCodeSequence”]/Item[@number=1]/
> /DicomAttribute[@keyword=”CodeMeaning”]/Value[@number=1]

With regard to this comment, I assume that the normal scenario is the caller application willing to obtain matching responses for ANY item number. May be I do not catch the real meaning of your comment, but I am unable to think on a scenario where you want to obtain matching responses ONLY if such responses are placed at a given position but not if they are placed at any other position.

> TM Time String, restricted to DICOM Time format (HHMMSS.FFFFFF&ZZXX)

Agree with this. May be some parts should be included as optional ones? I mean: HHMMSS[.FFFFFF[&ZZXX]]

I have just had a look at the dicom fields of a rather new CT in our hospital. All the 'DA' fields are in the form of YYYYMMDD, and the 'TM' fields are HHMMSS


> I personally find it very cumbersome that Keyword or Tag is used a key...
> I would not implement the Keyword scenario since it only adds complexity. I do however see the point that is makes the output more human readable...

+1. I agree at 100% I would allow to include the keyword or even the tag name as optional fields to allow for human readability, but I would use the tag number as the JSON name of the dicom data element / attribute.

> So one does not need to even read the top level JSON name, but instead rely on Tag Value... sorry for the noise,

Noise? I do not think this is noise at all. Parsing the output results will be more complicated (*1) using keywords than just using tag number. If the output results are returned using just the tag names, the implementation of the QIDO-RS would be easier, and even could be done with no dicom dictionary at all.

(*1): http://stackoverflow.com/questions/14487987/search-json-object-for-fields-1


Regards,

José Antonio
LinkedIn: http://goo.gl/lW17d

[Peter Tate]

I've got a couple of questions regarding the JSON format.

1. Emtpy value handing. Supp 166 proposes using null for empty values:
If an attribute is present in DICOM but empty, it shall be preserved in the DICOM JSON object and passed
914 with the value of “null”. For example:
"Value": [ null ]

null seems to be required for numbers (except for my second comment below) but is there a semantic difference between an empty string "" and a null value in the representation?

2. The Table F.2.3-1 (DICOM VR JSON Mapping) lists a number of VR's should have a representation of "Number". The column heading seems to imply that this maps to the JSON 'Number' format in: http://www.ietf.org/rfc/rfc4627.txt which implies that VR's such as IS (Integer String) should be numbers and therefore appear without quotes.

In the example, however, very value is quoted
From the text:
...
"NumberOfStudyRelatedSeries": {
"Tag": "00201206",
1090 "VR": "IS",
"Value": [ "4" ]
1092 },
...

I would have expected:
...
"NumberOfStudyRelatedSeries": {
"Tag": "00201206",
1090 "VR": "IS",
"Value": [ 4 ]
1092 },
...

Is this an error in the example or does the table F.2.3-1 imply that everything in the JSON representation is a string that contains a number. If it is a string that contains a number, should there be an explicit statement about the valid number representation? Personally I would prefer the former since in javascript implementations and JSON parsers I'm familiar with it is simpler to deal with JSON numbers rather than have to do the conversions manually.

[Peter Tate]

On Thursday, 19 September 2013 11:58:51 UTC-4, Peter Tate wrote:
> On Thursday, 12 September 2013 08:57:16 UTC-4, David Clunie wrote:
>
> > it occurred to me to remind everyone to take a look at the proposed
> > DICOM JSON model.

Once again with respect to empty value handing, Supp 166 proposes using null for empty values:

"Value": [ null ]

The way I read this JSON is "an array with one value, and the value is null".

If the value is empty, why not just use an empty array (an array with no values)?
"Value": []



It seems to me that this is a more unambiguous mapping between the DICOM and JSON models.

Similarly for a sequence with no items supp 166 states:
— Sequence: An array whose elements are one of:
— A DICOM JSON Model object representing an item of a DICOM sequence
— NULL representing an empty sequence item

NULL is not explicitly defined. I assume NULL here refers to F2.5 DICOM JSON Model Null Values and not the JSON null value.

[Mathieu Malaterre]

On Thursday, September 19, 2013 9:35:40 PM UTC+2, Peter Tate wrote:
> On Thursday, 19 September 2013 11:58:51 UTC-4, Peter Tate wrote:
>
> > On Thursday, 12 September 2013 08:57:16 UTC-4, David Clunie wrote:
>
> >
>
> > > it occurred to me to remind everyone to take a look at the proposed
>
> > > DICOM JSON model.
>
>
>
> Once again with respect to empty value handing, Supp 166 proposes using null for empty values:
>
>
>
> "Value": [ null ]
>
>
>
> The way I read this JSON is "an array with one value, and the value is null".
>
>
>
> If the value is empty, why not just use an empty array (an array with no values)?
>
> "Value": []
>

From my understanding:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.wbit.610.help.config.doc/topics/rjsonnullunsempprops.html

I believe your second solution is not possible. I have not been able to produce such output using the json-c lib BTW.

So the definite answer is: "Value": [ null ] IMHO

>
>
> It seems to me that this is a more unambiguous mapping between the DICOM and JSON models.
>
>
>
> Similarly for a sequence with no items supp 166 states:
>
> — Sequence: An array whose elements are one of:
>
> — A DICOM JSON Model object representing an item of a DICOM sequence
>
> — NULL representing an empty sequence item
>
>
>
> NULL is not explicitly defined. I assume NULL here refers to F2.5 DICOM JSON Model Null Values and not the JSON null value.

From my limited experience:
https://sourceforge.net/p/gdcm/gdcm/ci/master/tree/Source/MediaStorageAndFileFormat/gdcmJSON.cxx

I discovered some fun stuff:
- SQ declared as UN (CP-246),
- an SQ with empty items,
- \ISO 2022 IR 13\ISO 2022 IR 87 should encode as [ null, "ISO 2022 IR 13", "ISO 2022 IR 87" ] or is it [ "", "ISO 2022 IR 13", "ISO 2022 IR 87" ] ?
- do we send Group Length ?

Have fun !

[gunter zeilinger]

I strongly vote against having to include a "Value" or "Sequence" - and consequently also a "PersonName" property - with [ null ] for empty to encode empty attributes in the DICOM JSON Model. In accordance with the XML Model, the Value property should be just omitted for empty attributes.

The XML sample in Table F.3.1-1 XML to JSON Mapping:

<DicomAttribute Keyword=Keyword … >
<Value number="1"></Value>
</DicomAttribute>

is invalid. See DICOM Part 19, Annex A:
Table A.1.5-2 DICOM Data Set Macro
:
>>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.!!!!

gunter
P.S. Newest version of dcm4che includes XSL STylesheets to generates the JSON Model from the XML Model:

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-dcm2xml/src/etc/dcm2xml/json_compact.xsl

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-dcm2xml/src/etc/dcm2xml/json_indent.xsl

omitting the Value property for empty attributes and using "InlineBinary": "<base-64-encoded-binary-vale>" for OB, OD, OD and OW attributes, in accordance with the extension of the XML Model in Supp 163, as I suggest.

Installing dcm4che-3.2.1 ( http://sourceforge.net/projects/dcm4che/files/dcm4che3/3.2.1/ ) you may use its dcm2xml utility to directly convert any DICOM binary file to JSON:

$ dcm4che-3.2.1/bin/dcm2xml -x dcm4che-3.2.1/etc/dcm2xml/json_indent.xsl <dicom-file>

PPS: Newest alpha version of dcm4chee archive ( http://sourceforge.net/projects/dcm4che/files/dcm4chee-arc4/4.1.0.Alpha3/ ) already provides WADO/QIDO/STOW-RS services. But its installation is rather "hardcore" ( https://github.com/dcm4che/dcm4chee-arc/blob/master/INSTALL.md ). So be warned.

[Peter Tate]

On Friday, 20 September 2013 03:17:14 UTC-4, Mathieu Malaterre wrote:
> > Once again with respect to empty value handing, Supp 166 proposes using null for empty values:
> > "Value": [ null ]
> >
> > The way I read this JSON is "an array with one value, and the value is null".
> >
> > If the value is empty, why not just use an empty array (an array with no values)?
> >
> > "Value": []
> >
> From my understanding:
>
> http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.wbit.610.help.config.doc/topics/rjsonnullunsempprops.html
>
> I believe your second solution is not possible. I have not been able to produce such output using the json-c lib BTW.
>
> So the definite answer is: "Value": [ null ] IMHO
>

I don't accept the argument that using an empty array is not possible. The C# Netwonsoft.Json library will output emtpy arrays, and the JSON standard allows the syntax - it's right there on the home page of http://www.json.org/. It appears to me that these are implementation details of websphere and the json-c library. I will accept that for pragmatic purposes - maximum compatibility with existing implementations - that this is a compromise. I would also accept that the argument that the value exists, but is always null, thought as a matter of personal preference it would not be my first choice.

So I suppose an implementer should never output and empty array?

>
> From my limited experience:
>
> https://sourceforge.net/p/gdcm/gdcm/ci/master/tree/Source/MediaStorageAndFileFormat/gdcmJSON.cxx
>
>
>
> I discovered some fun stuff:
>
> - SQ declared as UN (CP-246),
>
> - an SQ with empty items,
>

Right, not covered explicitly. Could be (pardon the use of OtherPatientIDsSequence):
- NULL like an empty sequence item:
"OtherPatientIDsSequence": {
"Tag": "00101002",
"VR": "SQ",
"Sequence": [ null ]
},

- an array sequence that contains an empty sequence item:
"OtherPatientIDsSequence": {
"Tag": "00101002",
"VR": "SQ",
"Sequence": [
[null]
]
},

- an empty array:
"OtherPatientIDsSequence": {
"Tag": "00101002",
"VR": "SQ",
"Sequence": [ ]
},


For that matter, if we have a sequence of two items, and the second item is empty, the JSON encoding would seem to be:
"OtherPatientIDsSequence": {
"Tag": "00101002",
"VR": "SQ",
"Sequence": [
{
"PatientID": {
"Tag": "00100020",
"VR": "LO",
"Value": [ "54321" ]
},
"IssuerOfPatientID": {
"Tag": "00100021",
"VR": "LO",
"Value": [ "Hospital B" ]
}
},
[ null ]
]

},



> - \ISO 2022 IR 13\ISO 2022 IR 87 should encode as [ null, "ISO 2022 IR 13", "ISO 2022 IR 87" ] or is it [ "", "ISO 2022 IR 13", "ISO 2022 IR 87" ] ?
>

Yuck. Without clarification I assume both are valid.

> - do we send Group Length ?

I wouldn't :). Seriously though, it doesn't seem to be required for the QUIDO-RS use cases.

[José Antonio Pérez]

Capitalization of JSON key names and XML attribute names is not consistently used through the documentation. They should be precisely defined because both XML and JSON are case sensitive.

I have experienced this problem working on a piece of software that tries to recover information from a Dicom storage server. The idea is to recover the information using the standard models: Native Dicom Model (XML) and Dicom JSON

I will try to show the discrepancies with references to different sections of the documentation:


According to DICOM PS 3.19 2011,
Annex A.1: Native Dicom Model

Some of the XML attribute names appear in uppercase or lowercase inconsistently.

Table A.1.5-2 DICOM Data Set Macro

Some attribute names appear with the first letter in lowercase: 'keyword', 'tag', 'vr', 'privateCreator', ...

A.1.6 Schema, line 1050
DicomAttribute = element DicomAttribute {
Tag, VR, Keyword?, PrivateCreator?,
( BulkData | Value+ | Item+ | PersonName+ )?
}
Attribute names used here use begins by a capital letter: 'Keyword', 'Tag', 'VR', 'PrivateCreator'

A.1.7 Examples

/DicomNativeModel/DicomAttribute[@keyword=”ViewCodeSequence”]/Item[@number=1]/
/DicomAttribute[@keyword=”CodeMeaning”]/Value[@number=1]

Notice the attribute name 'keyword' appearing in lowercase. This example has been written having in mind that attribute name 'keyword' does not use any capital letter at all.


* If we try to extract information using XPath expressions, capitalization should be well defined and it must be used consistently. Otherwise, we will have problems.

XML is case sensitive, including attribute names. So, XPath queries to extract the information are case sensitive, too.


Now, to the second document:

Sup 166 LB, Annex F.2.1.1.1

<?xml version="1.0" encoding="UTF-8"?>
<NativeDicomModel>
<DicomAttribute Tag="0020000D" VR="UI" Keyword="StudyInstanceUID">
<Value
number="1">1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873</value>
</DicomAttribute>
</NativeDicomModel>
...

If we try to apply the XPath query example from the annex A.1.7 in the "PS 3.19" document, the query will fail: The attribute is not named 'keyword', but 'Keyword'.

This same problem translates to the Dicom JSON model.

Sup 166 LB, Annex F.2.1.1.2

[
{
"StudyInstanceUID": {
"Tag": "0020000D" ,
"VR": "UI",
"Value": [ "1.2.392.200036.9116.2.2.2.1762893313.1029997326.945873" ]
}
}
...

Notice the letter case for the JSON key names 'Tag', 'VR', 'Keyword'

JSON is also case-sensitive (including key names)

The document "Sup 166 LB" is consistent itself in the usage of uppercase or lowercase letters. Unfortunately, there are some products developed over the previous (and, may be, missleading) standard (Native Dicom Model), so the user can end up obtaining XML / JSON responses like these (In fact, I have just suffered this, using one well known open source Dicom toolkit).

XML:

<DicomAttribute keyword="StudyDate" tag="00080020" vr="DA">
<Value number="1">20051107</Value>
</DicomAttribute>
...

JSON:

{
"StudyDate" : {
"tag" : "00080020",
"vr" : "DA",
"Value" : [
"20051107"
]
},
...

Currently, I am assuming the right syntax is that of document 'sup 166 LB' (Initial capital letter. At least, this document is itself fully consistent).

Before opening a bug report on the website of third party software product I would like to hear more reputed opinions about this issue.


Regards,

José Antonio Pérez
http://goo.gl/lW17d

[Mathieu Malaterre]

On Friday, September 20, 2013 4:38:26 PM UTC+2, gunter zeilinger wrote:
> $ dcm4che-3.2.1/bin/dcm2xml -x dcm4che-3.2.1/etc/dcm2xml/json_indent.xsl <dicom-file>

Great post !

Quick report, your tool seems to be using "Alphabetic", instead of "SingleByte" for PN.

[Mathieu Malaterre]

Also there is an issue with UL (vers US):


"RegionFlags" : {
"tag" : "00186016",
"vr" : "UL",
"Value" : [
"2"
]
},

It should be a number, not a string.

[Mathieu Malaterre]

And AT does not seems to be supported at:


"FrameIncrementPointer" : {
"tag" : "00280009",
"vr" : "AT",
"Value" : [
"1577059"
]
},

while DICOM states:


(0028,0009) AT (0018,1063) # 4,1-n Frame Increment Pointer

[Mathieu Malaterre]

On Friday, September 20, 2013 4:38:26 PM UTC+2, gunter zeilinger wrote:

> I strongly vote against having to include a "Value" or "Sequence" - and consequently also a "PersonName" property - with [ null ] for empty to encode empty attributes in the DICOM JSON Model. In accordance with the XML Model, the Value property should be just omitted for empty attributes.

"strongly" is ... a bit "strong" ?

I think it really clarify intention. For instance see our previous posts where we can have empty items. Having an explicit null makes it so easy to read and parse.

Furthermore, we currently can have "Value", "Sequence" or "PersonName", right. Well imagine that next year we could also have "YetAnotherKey". So how would an existing parser -say- your dcm4chee implementation would cope with:

"00090010": {
"Tag": "00090010",
"VR": "UN",
"YetAnotherKey": [ { "AreYouEmpty" : "No", "IsThisSerious" : "Yes" } ]
},

My guts tells me that you see it as:

"00090010": {
"Tag": "00090010",
"VR": "UN",
},

which translates as:

"00090010": {
"Tag": "00090010",
"VR": "UN",
"Value": null
},

Having/Not Having the explicit "Value/Sequence/PersonName": null, disambiguates this scenario IMHO.

[gunter zeilinger]

On Thursday, September 26, 2013 1:14:20 PM UTC+2, Mathieu Malaterre wrote:

That's intended: The first component group of a Person Name may be also encoded in a multi-byte character set (i.e. UTF-8) , so calling it Single Byte is a misnomer. Guess who wrotes the first draft reads an outdated version of the standard before CP-964: Correct alphabetic name encoding for Unicode .

[gunter zeilinger]

Fixed: https://github.com/dcm4che/dcm4che/commit/c13a743e95bb4b6e41ea5bcc100ac448090c2cee

Thanks!

[gunter zeilinger]

Right. Fixed: http://www.dcm4che.org/jira/browse/LIB-120

Perhaps, we should also explicit specify the encoding of AT values in the Native DICOM XML Model in a CP...

[gunter zeilinger]

Hi José,

A.1.6 Schema, line 1050
DicomAttribute = element DicomAttribute {
Tag, VR, Keyword?, PrivateCreator?,
( BulkData | Value+ | Item+ | PersonName+ )?
}

does not specify that attribute names begins by a capital letter! "Tag", "VR", "Keyword", "PrivateCreator" are just references to the following definitions:

Keyword = attribute keyword { xsd:token }
Tag = attribute tag { xsd:string{..}}
VR = attribute vr { .. }
PrivateCreator = attribute privateCreator{ xsd:string }

But,

PersonName = element PersonName {
Number,
element SingleByte { NameComponents }?,
element Ideographic { NameComponents }?,
element Phonetic { NameComponents }?
}

should be corrected to

PersonName = element PersonName {
Number,
element Alphabetic { NameComponents }?,
element Ideographic { NameComponents }?,
element Phonetic { NameComponents }?
}

to be consistence with CP-964.
Table A.1.5-2 DICOM Data Set Macro already specifies ">>Alphabetic" and not ">>SingleByte" as element name for the component group with the "alphabetical" representation of person names.

[gunter zeilinger]

On Thursday, September 26, 2013 3:14:49 PM UTC+2, Mathieu Malaterre wrote:
> On Friday, September 20, 2013 4:38:26 PM UTC+2, gunter zeilinger wrote:
>
> > I strongly vote against having to include a "Value" or "Sequence" - and consequently also a "PersonName" property - with [ null ] for empty to encode empty attributes in the DICOM JSON Model. In accordance with the XML Model, the Value property should be just omitted for empty attributes.
>
>
>
> "strongly" is ... a bit "strong" ?
>
>
>
> I think it really clarify intention. For instance see our previous posts where we can have empty items. Having an explicit null makes it so easy to read and parse.
>

Sorry, I don't see. Why is

emptySequence = attr.Sequence.length === 1 && attr.Sequence[0] === null;

"easier"

than

emptySequence = !attr.Sequence;

?

>
>
> Furthermore, we currently can have "Value", "Sequence" or "PersonName", right. Well imagine that next year we could also have "YetAnotherKey". So how would an existing parser -say- your dcm4chee implementation would cope with:
>
>
>
> "00090010": {
>
> "Tag": "00090010",
>
> "VR": "UN",
>
> "YetAnotherKey": [ { "AreYouEmpty" : "No", "IsThisSerious" : "Yes" } ]
>
> },
>
>
>
> My guts tells me that you see it as:
>
>
>
> "00090010": {
>
> "Tag": "00090010",
>
> "VR": "UN",
>
> },
>
>
>
> which translates as:

What do you mean with "translates" ?

>
>
>
> "00090010": {
>
> "Tag": "00090010",
>
> "VR": "UN",
>
> "Value": null
>
> },
>
>
>
> Having/Not Having the explicit "Value/Sequence/PersonName": null, disambiguates this scenario IMHO.

Sorry, I don't see your argument. E.g., assuming my suggestion, to also use "InlineBinary" in the JSON Model to include base64 encoded OB, OD, OF, OW or UN values as introduced in the XML Model by Supp-163 will be accepted. And you want that a QIDO-RS client can handle reponses from QIDO-RS services, which still encodes OB, OD, OF, OW values as "Value", but also from updated QIDO-RS service implementations. If empty attributes will have to include Value: [null] or InlineBinary: null , the detection of empty attributes would have to be bloated to


emptyValue = attr.Value ? (attr.Value.length === 1 && attr.Value[0] === null)
: (attr.InlineBinary === null);

Just omitting the Value/InlineBinary property for empty attributes will shorten this to

emptyValue = !(attr.Value || attr.InlineBinary);

My rational for just omitting Value/PersonName/Sequence/InlineBinary for empty attributes is: KISS (keep it simple, stupid), align with XML Model, simplifies XSLT XML -> JSON

Regards,

gunter

[José Antonio Pérez]

Hi Gunter (and everybody else),

...does not specify that attribute names begins by a capital letter! "Tag", "VR", "Keyword", "PrivateCreator" are just references to the following definitions...

Well. It looks like I was so clumsy to reference the less appropriate example.

I Will try now to be a bit more specific:

I am trying to implement a QIDO-RS gateway in order to interact (cfind) with any (VNA) Dicom server.

I am using your "findscu" tool from the dcm4che 3.2.1 software package. This is an excelent piece of software, very well conceived and engineered. The skills and knowledge related to Dicom to develop such a tool are out of my reach currently, so I prefer to use your solid and reliable tools and minimize the needs for local development.

The first step is to get the responses from the server. These responses can be obtained as a set of XML files (Native Dicom Model) this way:

$ LANG="en_US.UTF-8" /usr/local/dcm4che/dcm4che3/bin/findscu \
-b DCMQR \
-m 00100020='99999' \
-c MYP...@192.168.1.96:104 \
--xml \
--out-dir /tmp/dummy/ > /dev/null

What I obtain with this command is a set of text files with XML contents including Dicom attributes like this one:

...

<DicomAttribute keyword="StudyDate" tag="00080020" vr="DA">

<Value number="1">20060711</Value>
</DicomAttribute>
...

As I said before, the tool is very well engineered, and it is able to apply a xsl transformation to generate the output in JSON format (but you already knew that). We can invoke the command this way:

$ LANG="en_US.UTF-8" /usr/local/dcm4che/dcm4che3/bin/findscu \
-b DCMQR \
-m 00100020='99999' \
-c MYP...@192.168.1.96:104 \
--xml \
--xsl /usr/local/dcm4che/dcm4che3/etc/dcm2xml/json_indent.xsl \
--out-dir /tmp/dummy/ > /dev/null

In this case the output text files do present the information formatted as JSON, somewhat like this:

...

"StudyDate" : {
"tag" : "00080020",
"vr" : "DA",
"Value" : [

"20060711"
]
},
...


THE PROBLEM: Notice in both cases the ***capitalization*** of the XML attribute names and the JSON key names. All the examples in sup166 refer to "Keyword", "Tag" and "VR", but here, we are obtaining "keyword", "tag" and "vr". On the other side, the XPath example in PS 3.19 (example A.1.7) includes lowercase letters for "keyword". The capitalization is not consistent across these two documents.

The problem comes when coding a client application that makes use of these web services. If someone tries to write an XPath expression to extract such information, they will run into troubles. XML, JSON, XPath are case sensitive, even for the attribute names. So, I think that both Dicom standards (XML and JSON) should indicate the proper capitalization of these elements and, consequently, the applications should implement the correct capitalization.

Thanks in advance for your attention,

José Antonio

[gunter zeilinger]

Hi José,

You are right. Supp 66 Letter Draft uses capitialized names for JSON properties and XML attributes, where the XML model specification in Part 17 defines lower case attribute names. Latest final draft of Supp 66 seems to change the XML model specification, to also use capitialized attribute names, but it still contains some inconsistencies. Anyway, I will update the XML representation implementation and XML->JSON stylesheet in dcm4che, as soon there is a final final version of Supp 66.

gunter

[David Clunie]

Hi Gunter, Jose

Thanks for noticing the capitalization inconsistency.

I assume you referring to Sup 166, not Sup 66, and PS 3.19, not
PS 3.17.

The XML conventions that are stated in PS 3.19 describing the
use of XML elements (e.g., "Value") and XML attributes of XML
elements (e.g., "vr") are clearly stated in Section 10 Data
Exchange Model Conventions, and will not change (i.e., there
would be no reason for Sup 166 to mess with the existing
XML representation):

"1. XML Element names (listed in the first column) are in
CamelCase, with the first letter capitalized.
2. XML Attribute names (listed in the first column) are
in camelCase with the first letter in lower case."

Accordingly, the XPath requirements with respect to capitalization
are already clear and unambiguous. Indeed there is an XPath
example in PS 3.19 A.1.7 to highlight this:

"/NativeDicomModel/DicomAttribute[@keyword=”ViewCodeSequence”]/Item[@number=1]/

/DicomAttribute[@keyword=”CodeMeaning”]/Value[@number=1]"

As for JSON, Sup 166 is a work in progress, so any experimental
implementation of it is going to be subject to change; there is
only one "final" version and that will be the "Final Text" version
of it; currently it is out for ballot and there is nothing "final"
about that.

Both the normative text and examples in Annex F of Sup 166 of
the DICOM Native Model in XML are just incorrect, i.e.:

<DicomAttribute Tag="0020000D" VR="UI" Keyword="StudyInstanceUID"/>

should be

<DicomAttribute tag="0020000D" vr="UI" keyword="StudyInstanceUID"/>

and as for the definition mapping, if we want to be consistent about
the case conventions between XML and JSON, for each (XML) attribute
rather than saying:

"The “VR” attribute maps to the “VR” child property"

I think it should say, for each of the (XML) "attributes"

"The “vr” attribute maps to the “vr” child property"

Note that concept of a DICOM "attribute" and an XML "attribute" are
distinct but make for some confusing language.

I don't know of any reason why the JSON capitalization should
be any different from the currently defined XML capitalization,
so presumably this will be fixed in the final text of Sup 166.

David

[gunter zeilinger]

Thanks David,

Right, I meant Part 19 and Supp 166, and read sup166_ft_draft_07.docx in the non public area at the nema ftp server. I 100 % agree with your view of what should be changed/corrected and was not.

gunter

[gunter zeilinger]

Just updated dcm4che's XSL Stylesheets for XML -> JSON transformation

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-dcm2xml/src/etc/dcm2xml/json_compact.xsl

https://github.com/dcm4che/dcm4che/blob/master/dcm4che-tool/dcm4che-tool-dcm2xml/src/etc/dcm2xml/json_indent.xsl

to sup166_ft_draft_07 - but keeping capitalization as defined by the XML Model.

gunter

[Jörg Riesmeier]

Gunter,

> Perhaps, we should also explicit specify the encoding of AT values in the
> Native DICOM XML Model in a CP...

I totally agree. Did you already contact DICOM WG-06 (possibly with a CP)?

Regards,
Jörg

PS: I already noted this issue in the DCMTK bug tracker (#551).

[gunter zeilinger]

Just looked into sup166_ft_draft_08, which fixes the inconsistencies concering capitalization of attribute names, but added others:

So it now specifies for the JSON Model:

"Attributes with a Value Representation of DT or TM shall conform to the W3C Date and Time format recommendations (see www.w3.org/TR/NOTE-datetime). "

which introduces an inconsistency with the encoding of DT and TM values specified by DICOM PS.3.5. (E.g.: 19970716192030.45+0100 vs. 1997-07-16T19:20:30.45+01:00). And why then they stay with the DICOM encoding for DA values?

It also defines a new scheme for encoding Person Names:

{
"Alphabetic": {
"FamilyName": ["<family-name-complex>"],
"GivenName": ["<given-name-complex>", "<middle-name>" ],
"Prefix" : ["<name-prefix>"],
"Suffix" : ["<name-suffix>"],
},
"Ideographic": {
:
},
"Phonetic": {
:
}
}

I would have preferred to simple align it with the Native XML Model and PS.3.5:

{
"Alphabetic": {
"FamilyName": "<family-name-complex>",
"GivenName": "<given-name-complex>",
"MiddleName": "<middle-name>",
"NamePrefix" : "<name-prefix>",
"NameSuffix" : "<name-suffix>",
},
"Ideographic": {
:
},
"Phonetic": {
:
}
}

gunter

[gunter zeilinger]

Ok, it seem's they have reverted the change in the Person Name encoding in now available sup166_ft.docx, but they kept the W3C encoding of DT and TM values.

gunter

[gunter zeilinger]

Jörg,

No, I have not yet sent a corresponding CP to WG6. I hoped Supp 166 FT may already address this issue - but now it seems it did not.

If the JSON Model now use ISO 8601 formatted TM and DT (and DA?) values, we may also think to also explicit specify the encoding of TM and DT (and DA?) values in the XML Model analogous.

gunter

[José Antonio Pérez]

Available?

Is this document (sup166_ft) already available to the general public, or do you mean available for the members of the working group?

I am interested in this document, but I am unable to find it.

José Antonio

[Chris Hafey]

I am just now looking at QIDO-RS and see an inconsistency in Supplement 166. F.2.1.2 has an example of a JSON model which has attributes wrapped in an array while example in F.4 shows the attributes wrapper in an object. I hope the object wrapping is the standard way is the array wrapper is extremely inconvenient for JavaScript developers. A few other comments:

1) Inconsistent casing on the attribute properties - vr vs Value. Javascript is type sensitive and the most common convention is to begin properties with lower case letters
2) By using the group/element as the property name, Javascript developers will be unable to use dot notation to reference the attributes as it is not supported for property names that begin with numbers. It would have been *really* nice to prefix the tag with a letter like 'x' so dot notation could be used.

Chris Hafey

[Chris Hafey]

A correction, I was referring to the example F.2.1.1.2. Another issue is that the JSON in F.2.1.1.2 is invalid since it is missing commas between each array element. I know one vendor has implemented it in a manner that follows the F.2.1.1.2 for the siim hackathon (including the missing commas). This vendor is also returning the JSON objects in multipart which I hope is invalid as it would be problematic for JavaScript developers.

[Chris Hafey]

OK I see now that these are examples of two different things. F.2.1.1.2 is illustrating a collection of results while F.4 is illustrating a single result. The only correction here is to add commas between each result in the F.2.1.1.2 example and perhaps reviewing the wording to see if there is a way to make it clearer for implementors (since one implementor has already misinterpreted it).