DICOMWeb JSON Mapping Details

Last week I attended the DICOMWeb conference in Philadelphia, PA and had a chance to talk with Rob Horn on a few details of the DICOMWeb JSON mapping:

Encoding of PN attributes

The JSON example mappings in PS 3.18 show PN attribute values encoded as an object with a property 'Alphabetic' rather than a string:

        "00080090": {
            "vr": "PN",
            "Value": [
              {
                "Alphabetic": "^Bob^^Dr."
              }
            ]
        },

I was already familiar with the HL7 like encoding of person names using the ^ character to separate the different components (e.g. family name complex, given name complex, etc).  What I didn't know was that this is the alphabetic "component group" of a name and there are two other component groups - ideographic and phonetic.  These other component groups are used to support some languages where a name does not have an alphabetic version.  In P10 encoding, each of these component groups is separated by an '=' sign.  Here is an example from PH 3.5 Chapter H:

• Yamada^Tarou=山田^太郎=やまだ^たろう

When the XML mapping was defined, it was decided to give each group component a name rather keep it as a single value separated by an = sign.  This is describe in PS 3.19 Table A.1.5-2.  DICOMWeb implementors should take note of this as PN is handled differently in XML and JSON mappings than it is in DICOM P10 encodings.  I know of one DICOMWeb implementation that is encoding PN as a string rather than an object with the different component groups.

Optionality of Value property

One thing the JSON example mappings in PS 3.18 do not show is that the Value property is optional.  The specific rule for this can be found in PS3.19 Table A.1.5-2:

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.

What this means is that the Value property will not always be present and this needs to be taken into account when parsing the JSON response (and when creating a DICOM JSON document!).  I know of one DICOMWeb implementation that omits the Value property for PN attributes and two other implementations that send a zero length value as an empty string rather than omitting the Value property.