Such That

One of the challenges with the C-CDA specifications is in understanding a particular kind of constraint.  The general form of this constraint is described in the title of this post.

Here's an example from the specification:

3. SHALL contain exactly one [1..1] templateId (CONF:5252) such that it
    a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.1" (CONF:10036).

There are 344 occurrences of the phrase "such that it".

Think of the "such that it part" part as a where clause:

SELECT templateId from ClinicalDocument 
WHERE (@root='2.16.840.1.113883.10.20.22.1.1')

The cardinality constraint applies to the templateId values after matching the WHERE clause.

This constraint above (and many more) could have been simplified into:
3. SHALL contain exactly one [1..1] templateId where @root = "2.16.840.1.113883.10.20.22.1.1"
Or
3. SHALL contain exactly one [1..1] templateId/@root = "2.16.840.1.113883.10.20.22.1.1"
Or even
3. SHALL contain exactly one [1..1] templateId[@root = "2.16.840.1.113883.10.20.22.1.1"]

In fact, I prefer the last one because [] effectively gives you a WHERE predicate in XPath.

But this doesn't work when there are multiple constraints, and you want to separately indicate which identify each constraint.  See for example the general participant which I slightly simplified below (there's another constraint at 5.c.i. which I omitted):

5. MAY contain zero or more [0..*] participant (CONF:8504) such that it
    a. SHALL contain exactly one [1..1] @typeCode="IND" Individual (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8505).
    b. SHALL contain exactly one [1..1] functionCode/@code="PCP" Primary Care Physician (CodeSystem: participationFunction 2.16.840.1.113883.5.88) (CONF:8506).
    c. SHALL contain exactly one [1..1] associatedEntity/@classCode="PROV" Provider (CodeSystem: HL7ParticipationType 2.16.840.1.113883.5.90) (CONF:8507).

Which would be restated in one line as:
5. MAY contain zero or more [0..*] participant (CONF:8504) WHERE @typeCode="IND" AND functionCode/@code="PCP" AND associatedEntity/@classCode="PROV"
(or in preferred form)
MAY contain zero or more [0..*] participant[@typeCode="IND" and functionCode/@code="PCP" and associatedEntity/@classCode="PROV"]

See the problem?  We have all these constraints around how to express the value of the different coded pieces.  Each one of these is wanting a separate constraint to hang the coding system on, and the value set, et cetera, at least at the modeling level, and more likely at the validation level as well.  A validator that can tell you that you have failed to meet CONF:8506 in the former is much more informative about what you need to do than one that simply tells you that you failed to meeting at least one of the AND criteria in the clauses attached to CONF:8504 in the latter.

There's probably a better way to state these, and it also seems likely that they are overused.  That's the problem when you develop methodology at the same time as you try to use it.  However, in my own experience, there's really no better way to develop methods than to use them at the same time.

So, hopefully you now understand what that construct means, and why it is used, and also understand, if we can fix it, we likely will in the next round of work on Consolidated CDA.  It will certainly be one of my ballot comments if we don't.

   Keith

P.S.  England was fantastic, even if I almost had heart failure more than a dozen times sitting in the passenger seat while watching my wife drive.  I know I would have blown my top if I'd have had to listen to me (or anyone else) while I drove under those conditions.  She's a sweetheart, and so she did all the driving.