DCMTK

Rationale for Correction:​
Unlike all other SR Content Items, the value of the NUM (the Measured Value Sequence) is Type 2, i.e., allowed to be empty.​
This was intentional, to allow for the presence of the Content Item when the value was "unknown", although in practice, this is rarely,​
if ever, encountered.​
It is not clear what the intent of the Mandatory presence of the Content Item in a Template is, however, with respect to the presence​
or absence of the DS value. Taken literally, the Content Item is required to always be present, but the Measured Value Sequence​
may be zero length at any time.​
The purpose of being empty was clarified in CP 260, which added an optional Numeric Value Qualifier Code Sequence to communicate​
the reason for the absence, whihc included both being unknown as well as various arithmetic and measurement device failure​
reasons. One scenario that the CP did not consider was the use of a an SR instance full of "empty" values as a "fill in the blanks"​
form, but that has not proven to be a practical use (and there is no reason why NUM Content Items should be different from other​
Content Items like TEXT and CODE in that respect).​
When the Measured Value Sequence is empty, the units encoded in Measurement Units Code Sequence within Measured Value​
Sequence cannot be sent either. This gives rise to uncertainty about the implications of mandatory UNITS specified in the Value Set​
Constraint column of a Template. Specifically, does a requirement to use a particular unit imply that the units (and hence the numeric​
value itself) must be sent? That was not the intent; rather, the units should be used IFF there is a numeric value sent.​
Despite all the foregoing, it is not clear that permitting the numeric value (and its accompanying units) to be empty if unknown was​
a good idea in the first place, nor that template designers understand that this feature exists and hence their use of M for a Content​
Item may not be as "mandatory" as they think it is. Further, one could argue that whether or not to allow an empty value should be​
explicitly controlled at the template level. I.e., there should be two "flavors" of M for NUM, analagous to the difference between Type​
1 and 2 in P3.3.​
Since the DS VR that encodes the Numeric Value cannot represent some valid failure conditions (e.g., IEEE NAN, +/-infinity, etc),​
one cannot simply make its presence with a non-zero length mandatory at this stage without significant installed base impact. I.e.,​
we cannot change Measured Value Sequence from Type 2 to Type 1.​
No changes are needed related to the Content Item Macro used in worklists and acquisition context protocols, since it uses a Type​
1 Numeric Value that is not nested within a Measured Value Sequence, and hence is never permitted to be empty (nor for those use​
cases, would a value ever be unknown or unavailable due to failure).​
It is proposed to clarify that the presence of a UNITS constraint does not mean that the value and units have to be sent.​
It is proposed to clarify that the existing M means that the value and units are required unless there is a valid arithmetic or failure​
reason for them to be absent, as opposed to merely being nominally unknown. Leave all current uses of NUM in Templates with a​
requirement of M (i.e., a value is now required). Though by narrowing the current definition of M, this is theoretically a breaking​
change, in practice it is extraordinarily unusual to encounter a zero length Measured Value Sequence, so this is thought to have no​
impact on the installed base.​
It is proposed to change the requirement for a Numeric Value Qualifier Code Sequence from Type 3 to Type 1C, to require its​
presence if the Measured Value Sequence is zero length. Though this is theoretically a breaking change, in practice it is extraordinarily​
unusual to encounter a zero length Measured Value Sequence, so this is thought to have no impact on the installed base.​

See: ftp://medical.nema.org/medical/dicom/final/cp2023_ft_ClarifyUnknownNumericMeasurementValueInSR.pdf