1. The comment that started "We have noticed mismatches within the 2021 CMS QRDA I IG and HL7 QRDA I STU R5.2 with respect to template ID’s and extensions" -- The 2021 QRDA I sample file is not yet fully developed and was not yet available during this review. Any use of extension="2020-02-01" is from the 2021 CMS IG and would not be present in the HL7 QRDA I STU 5.2 IG, Schematron, or sample file.
2. The comments regarding presence <id> or @moodCode, when the conformance statement is not in the template -- These templates have conformance statements stating they must conform to another template. This is how other elements or attributes are required.
3. The comment regarding Medication Administered -- Author has MAY cardinality, which the Schematron does not enforce. Author Participation is SHALL NOT.
4. The comment regarding Procedure Performed -- The Schematron assertion is correct because it is enforced as a warning and the conformance statement is a SHOULD. The conformance text in the Schematron needs to be updated to align with the IG.
5. Is it allowable to have duplicate entries for the same element with same code and timings but with different id root? – This gets into how receiving systems identify duplicate data. If the intent is to send the same data then the id root should be the same as well. Look in page 51 of Vol 1 below the table.
6. There were many instances of having “at least one [1..*] id” for some templates. Can we get an example of multiple id’s? – There is no use case to constrain that field, but also no use case for multiple. For QRDA templates, one id is expected, but we didn't constrain in case an implementation needs multiple.
7. Will there be a problem if we write both the author dateTime and relevant Period/relevant dateTime [for negated templates] in the QRDA file? – In the receiving system effectiveTime will be ignored, so it shouldn't be a technical problem. When negated, the measure specification is looking for author dateTime.

Thank you everyone for your comments. All comments have been addressed by the QRDA development team. See the attached spreadsheet for details. Below are responses to some of the comments that offer clarification to submitters.

There appears to be an issue with the schematron assertion for this conformance statement.

Data types of TS SHALL have either @value or @nullFlavor but SHALL NOT have @value and @nullFlavor. (CONF: CMS_0113)

This does not allow the following effectiveTime (used in Medication, Administered template 2.16.840.1.113883.10.20.24.3.42) for frequency

< effectiveTime xsi:type = "PIVL_TS" operator = "A" >
< period value = "24" unit = "h" />
</effectiveTime>

This assertion doesn't seem to work. Any QRDA files with multiple data entries will fail this check (e.g., 2 encounters).

<sch:assert id="a-CMS_0051-error" test="count(cda:entry[*[cda:templateId[@root != '2.16.840.1.113883.10.20.24.3.55']]]) = 1">SHALL contain at exactly one [1..1] entry (CONF:CMS_0051) such that it 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>

Presumably, this should allow any number of entries that have exactly 1 templateId that isn't 2.16.840.1.113883.10.20.24.3.55?

These are the conformance statements in the CMS IG

3. SHALL contain at least one [1..*] entry (CONF:CMS_0051) such that it
a. 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).*
4. SHALL contain at least one [1..*] entry (CONF:4444-14430_C01) such that it
a. SHALL contain exactly one [1..1] Patient Characteristic Payer
(identifier: urn:oid:2.16.840.1.113883.10.20.24.3.55)
(CONF:4444-14431).

Thank you for the opportunity to comment on these Draft 2021 CMS QRDA I Implementation Guide and Schematron. Please find below our comments for your perusal.

1) We have noticed mismatches within the 2021 CMS QRDA I IG and HL7 QRDA I STU R5.2 with respect to template ID’s and extensions. Please find below some examples from the template:

• Sample file has no mention of template ID’s with extenstion of ‘2020-02-01’ in the template.
• Following template ID’s and extension are present in schematron and 2021 CMS QRDA I IG but missing from Sample QRDA file and HL7 QRDA I STU R5.2. Same is the case with template ID’s having extension of ‘2020-02-01’.
• "count(cda:templateId[@root='2.16.840.1.113883.10.20.17.2.1.1'][@extension='2016-03-01']) = 1">SHALL contain exactly one [1..1] templateId (CONF:CMS_0040) such that it SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.17.2.1.1" (CONF:CMS_0041). SHALL contain exactly one [1..1] @extension="2016-03-01" (CONF:CMS_0042).
• <sch:assert id="a-CMS_0023-error" test="count(cda:entry[count(cda:act[cda:templateId[@root='2.16.840.1.113883.10.20.17.3.8.1'][@extension='2016-03-01']])=1]) = 1">SHALL contain exactly one [1..1] entry (CONF:CMS_0023) such that it SHALL contain exactly one [1..1] Reporting Parameters Act - CMS (identifier: urn:hl7ii:2.16.840.1.113883.10.20.17.3.8.1:2016-03-01) (CONF:CMS_0024).</sch:assert>
• Also note that 2021 CMS QRDA I IG Figure 5 is not in sync with sample QRDA file CDAR2_IG_QRDA_I_R1_STU5_2_Sample.xml.

2) We have noticed mismatches with requirement of Author Participation template in the HL7 IG for some elements. Please find few examples below:

Allergy Intolerance (V2)

Table 255 Author Participation (required) ‘2.16.840.1.113883.10.20.22.4.119’

Schematron:

<sch:assert id="a-4444-30034-error" test="count(cda:author[cda:templateId[@root='2.16.840.1.113883.10.20.22.4.119']])=0">SHALL NOT contain [0..0] Author Participation (identifier: urn:oid:2.16.840.1.113883.10.20.22.4.119) (CONF:4444-30034).</sch:assert>

Table 256- Snippet

Similar instances found in multiple templates like Intervention Performed, Diagnostic Study Performed, Procedure Performed Datatype.

3) Comment on Diagnosis Datatype: ** 

• Diagnosis Concern Act (V4)

In HL7 QRDA I STU R5.2 there is no mention of having id tag in Table 196 whereas it is present in Sample file as well as Figure 109.

• Diagnosis (V3)

Sample File has QDM Attribute: Reason V3 ‘2.16.840.1.113883.10.20.24.3.88’ even though negationInd is not present. No reference of Diagnosis having Reason attribute is mentioned in HL7 IG.

4) Comment on Diagnostic Study Performed Datatype:

• Diagnostic Study Performed (V5)

Schematron:

<!-- Removed 4444-29633 for STU 5.2 -->

<!-- <sch:assert id="a-4444-29633-error" test="count(cda:id)=1">SHALL contain exactly one [1..1] id 4444-29633. </sch:assert> -->

In HL7 QRDA I STU R5.2, Table 214 does not mention about id in XPath but Figure 117 has id tag. 

• Diagnostic Study Performed has incorrect extension for Facility location.

5) Comment on eMeasure Reference on QDM:

eMeasure-Reference-QDM-externalDocument-errors is not checking on @moodCode=’EVN’ nor it is mentioned in the in HL7 QRDA I STU R5.2 table 102 but it is present in Sample file and Figure 61.

6) Comment on Intervention Performed Datatype:

2.16.840.1.113883.10.20.24.3.32 has incorrect extension in HL7 QRDA I STU R5.2 table 210.

7) Comment on Medication Administered Datatype:

Medication, Administered (NOT DONE) has used author ‘2.16.840.1.113883.10.20.24.3.155’ in Sample file but the schematron and HL7 QRDA I STU R5.2 point to Author Participation ‘2.16.840.1.113883.10.20.22.4.119’ with [0..*] cardinality . Could you please let us know which of these are correct?

8) Comment on Procedure Performed Datatype:

<sch:rule id="Procedure-Activity-Procedure-warnings" schematron has assertion

<sch:assert id="a-1098-32479-warning" test="count(cda:author[cda:templateId[@root='2.16.840.1.113883.10.20.22.4.119']])>=1">SHOULD contain at least one [1..*] Author Participation (identifier: urn:oid:2.16.840.1.113883.10.20.22.4.119) ([CONF:1098-32479).</sch:assert|conf:1098-32479).%3c/sch:assert]> 

But in the HL7 QRDA I STU R5.2 Table 218 has [0..*] which is conflicting. In the schematron, count is checked to be >=1, shouldn’t it be >=0?

9) Comment on Encounter Performed:

Encounter Performed (V5)

Encounter Performed diagnosis attribute is written using Encounter Diagnosis QDM 2.16.840.1.113883.10.20.24.3.168 as per sample file. Is there any usage of the old template for Encounter Diagnosis (V3) 2.16.840.1.113883.10.20.22.4.80? This is not used in the sample file. As per Page 154 in HL7 QRDA I STU R5.2, Encounter Diagnosis is used to represent all diagnosis.

10) General Questions:

• Is it allowable to have duplicate entries for the same element with same code and timings but with different id root?
• There were many instances of having “at least one [1..*] id” for some templates. Can we get an example of multiple id’s?
• It is mentioned that for Negated datatypes, use the author dateTime attribute to reference timing and must not use Relevant Period/relevant dateTime. Will there be a problem if we write both the author dateTime and relevant Period/relevant dateTime in the QRDA file?

We have reviewed the document and have the following comments (see attached for screen shots included - QRDA-HQR-2021-Review-Results.docx):

Here is a summary:

1. Section 5.1.5 of the IG is worded in a way that is a little difficult to understand: "In the CHPL, this would be the number that is generated when select get EHR Certfication ID for a suite of products that make up the hospital's EHR solution."
2. Table 9, Column 4.  The Patient Data Section Version and extension are not correct.  It still lists the old version (V6) and extension (2019-02-01)
3. In Section 5.2.3, the CONF# for Observation changed to 4444-14431_C01.  The text for #4 does not include the _C01 for CONF# 4444-14431_C01.  
4. In Table 14 for CMS_0074, 3rd column, 2nd paragraph, there is an instance of 2020. Should this be 2021?  In the 2020 guide, this also was 2020, so we assumed it should be 2021.
5. In the new Chapter 6, the paragraph that begins with "For example, when reporting the first resulted sodium value and ...." was difficult to understand.  It may be fine but wanted to point out that it was hard to read.  It was a very long sentence.
6. In the new Chapter 6, should the following have the first occurrence of “element” plural - "For each of the core clinical data element specified  in the CMS529v1, the measure specification returns the specific encounter id that a core clinical data element result is associated with."
7. Table 26 - Row 4444-14430_C01, column 4 still has 4388 when it should have 4444_14431.
8. Table 9 row "StructuredBody" still has 4388 for column 5.  The CDAR2 guide has 4444.  Should it be 4444.
9. In table 5.3.2 - Table 14 (other HQR validations), CMS_0070 gets split onto two pages
10. In table 5.3.2 - Table 14 (other HQR validations), CMS_0077 gets split onto two pages
11. In Section 5.3.3, BirthTime, should example get updated for newborn with more recent year.  The example is 201809102223
12. In  Section 5.3.3 - Encounter and EffectiveTime - US Realm both list -1300 through +1400 as valid UTC time shifts.  The last row of this table for NA, lists -1200 through +1400 as valid UTC time shifts. Should these be consistent and should they all be -1200 -> +1400?  If so, should the example for the NA row change from -1262 to -1162?
13. CMS_0074 is listed twice in Table 27.  We believe the 2nd occurrent should be CMS_0082 or CMS_0083 for CEHRT

Section 5.2.3.2 Reporting "unit" for Result Value - add additional language to clarify reporting when result criteria does not specify unit in measure logic:

"If eCQM definition does not use the “unit” in the measure logic for the “result” criteria, for example, ["Laboratory Test, Performed": "INR"] INRLabTest where INRLabTest.result > 3.0, then the laboratory test performed result must be reported as data type REAL or Interval REAL (xsi:datype="REAL" or xsi:datype="IVL_REAL") for results such as INR=2.4 or INR>=4.5."

The error message in the schematron needs to be updated to match the assertion.

<sch:assert id="a-CMS_0001-extension-error" test="@extension='2020-02-01'">SHALL contain exactly one [1..1] templateId (CONF:CMS_0001) such that it SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.24.1.3" (CONF:CMS_0002). SHALL contain exactly one [1..1] @extension="2108-02-01" (CONF:CMS_0003).</sch:assert>