One of the subtleties of constraint in a guide has to do with how different constraints interact. Consider the following two scenarios:
Scenario 1 (Cardinality AND Value Constraint):
- There shall be exactly one [1..1] typeId element beneath the ClinicalDocument element.
- The typeId/@root shall be "2.16.840.1.113883.1.3"
- The typeId/@extension shall be "POCD_HD00004"
In XPath these three assertions could be individually represented as:
- count(/ClinicalDocument/typeId) = 1
NOT: These could be combined into a single expression using and, but there is little value of that to end users because the test would no longer be able to tell them WHICH of the three requirements was not met.Scenario 2 (Cardinality WITH Value Constraint):
- There shall be exactly one [1..1] templateId element where @root = "2.16.840.1.1138220.127.116.11.1.1"
- count(/ClinicalDocument/templateId[@root="2.16.840.1.113818.104.22.168.1.1"]) = 1
The first set of constraints indicate that there shall be only typeId element, and that it must have a particular value (using the II datatype). It prohibits the appearance of a typeId element containing any other value.
The second constraint indicates that there is only one templateId element that has a particular value. It does not prohibit the appearance of other templateId elements containing other values.
In other words, there is a difference between "there shall be only 1, and it shall have this value" and "there shall be only 1 with this value".
This is the root cause of one of the confusions with respect to using other medication vocabulary in the HITSP C32 to record the coded brand names. The intent in that case was to following scenario 2, not scenario 1, as I explained here.
I think the rogue's gallery will help.