These questions were submitted to ESAC and responses were received from Michael Holck. This ticket documents the Q&A interchange. The reported problem is only a cosmetic concern but should be tracked to ensure these apparent bugs are resolved in the future generation of Schematron files. The extraneous special characters – asterisks around words (e.g., SHALL, DYNAMIC) and multiple brackets (e.g., ‘contain exactly one [[]1..1[]] entry template’) – apparently are artifacts of the current process of using Trifolia to generate Schematron files from QRDA implementation guides (IG). The appearance of these unexplained characters may be a source of confusion to system developers and testers and presumably to end users not knowing if there is any significance of these characters being included in error and warning messages that will be written to QRDA submission feedback reports generated by the CMS receiving systems.

The response from ESAC is that the artifacts like #1 and #2 noted here are things that can be removed with a new generation methodology. #3 is a reasonable convention that is good to continue.

#1 - Issue 1. Why are asterisks used in some assertions? Is it just for emphasis when the message is displayed? If that is the case, then why would the rules that are “not testable” even include the asterisks? Looks like the asterisks are not limited to just the keywords, but can appear around any part of the message. True?

<sch:assert id="a-1098-7890-c" test="not(testable)">MethodCode SHALL NOT conflict with the method inherent in Procedure / code (CONF:1098-7890).</sch:assert>
<sch:assert id="a-1098-8249-c" test="not(testable)">MethodCode SHALL NOT conflict with the method inherent in Observation / code (CONF:1098-8249).</sch:assert>
<sch:assert id="a-1098-31484-c" test="not(tested)">If Observation/value is a physical quantity (xsi:type="PQ"), the unit of measure SHALL be selected from ValueSet UnitsOfMeasureCaseSensitive 2.16.840.1.113883.1.11.12839 DYNAMIC (CONF:1098-31484).</sch:assert>
<sch:assert id="a-1098-10007-c" test="count(cda:participant[@typeCode='IND']) = count(cda:participant/cda:associatedEntity[@classCode=document('voc.xml')/voc:systems/voc:system[@valueSetOid='2.16.840.1.113883.11.20.9.33']/voc:code/@value])">When participant/@typeCode is IND, associatedEntity/@classCode SHOULD be selected from ValueSet 2.16.840.1.113883.11.20.9.33 INDRoleclassCodes STATIC 2011-09-30 (CONF:1098-10007).</sch:assert>

A1. The asterisks just seem to be a bug in the Trifolia generation. I have not found any rhyme or reason behind them looking at the source system and the conformance statements that do this.

#2 - Issue 2. Is it intended to show triple brackets in some messages or is it a typo, for example:

<sch:assert id="a-1098-28499-c" test="not(tested-here)">SHALL contain exactly one [[]1..1[]]@xsi:type="PIVL_TS" or "EIVL_TS" (CONF:1098-28499).</sch:assert>
<sch:assert id="a-1182-28459-branch-28458-c" test="count(parent::node()/cda:entry/child::node()/cda:templateId[@root!='2.16.840.1.113883.10.20.24.3.55']) > 0">SHALL contain exactly one [[]1..1[]] entry template that is other than the Patient Characteristic Payer (identifier: urn:oid:2.16.840.1.113883.10.20.24.3.55) (CONF:CMS_0039).</sch:assert>
<sch:assert id="a-1098-31347-c" test="not(cda:recordTarget/cda:patientRole/cda:patient/sdtc:raceCode) or cda:recordTarget/cda:patientRole/cda:patient/cda:raceCode">If sdtc:raceCode is present, then the patient SHALL contain [[]1..1[]] raceCode (CONF:1098-31347).</sch:assert>

A2. The triple brackets are another artifact of the Trifolia generation that I would guess is a bug.

#3 - Comment 3 (not an issue). What is the meaning of the Edit ID suffixes of “…xx-c” and “…xx-v”? It is curious that many (but not all) of the rules that use asterisks (“*”) within the message also have the “-c” suffix. Any connection?

A3. The -v and -c convention are when a conformance statement has a check for code or vocabulary typically. Where there is a conformance statement that includes a check for a code and a check for the particular value set used you will see this. The conformance numbers will be the same in both checks in the text but the id’s are different using that convention.

The attached file contains more examples from the Schematron file further illustrating the submitted questions and comments.