The following information is provided to assist the Tester in interpreting the results generated by the CRV.
  • Display names indicated as a WARNING or ERROR during context-free validation, or indicated as a MISMATCH during context-specific validation, need to be evaluated for equivalent text because display names are non-normative.
    • More details: During context-free validation, the CRV checks display name attributes when explicitly defined by the Cancer Reporting IG. Any discrepancies are indicates as an error or warning. During context-specific validation, display names are checked against the test data, and any discrepancies are indicated as a mismatch. Because display names are non-normative, an error or warning may be indicated when in fact the display name in the submitted report has an equivalent meaning. The tester must evaluate the display names in a submitted report whenever a discrepancy is indicated with a display name.
    • If there is an error on the IG Conformance Events Tab or a mismatch on the Test Data Conformance Events tab for the Payer Type display name, the display name should be checked for similar meaning to the one specified in the test data. Since all value sets for Payer Type are not specified, specific codes are not required.
  • Multiple-choice values indicated as a WARNING might actually be valid.
    • More details: The Cancer Reporting IG defines several codes as multiple-choice. Meaning that a single value in a cancer report can come from multiple (usually 3) different code systems or value sets. Many times, two of the code systems/value sets will be bound to SHOULD and the third will be bound to MAY. The test data supplies a code from each code system and/or value set. For example, see "value (Histologic Type)" in the test data and conformance rule 1098-19207 in the IG and Schematron. Any of the provided values are valid. During context-free validation, only the code system/value set choices bound as SHOULD are checked. This means that if a value comes from one of the SHOULD code systems/value sets, then the conformance statement will pass. However, if the value does not come from a code system/value set bound to SHOULD, and even if it does come from a code system/value set bound to MAY, then a warning will be thrown. This warning must checked by the tester.
  • Local values indicated as a WARNING might actually be valid.
    • More details: Some values are defined as: SHOULD be from LOINC, otherwise they SHALL be from a code system local to the sending EHR. For example, see conformance rule 1098-7133 in the IG and Schematron. Similarly to the above, if the value is not from LOINC then a warning is thrown and the tester must check it that the value does indeed come from a local code system.
  • Tester needs to check the relationship between Test Case 3 and Test Case 4.
    • More details: Test Case 4 is an update and replacement to the data in Test Case 3. In Test Case 4, data highlighted in green indicates where data is to be updated from Test Case 3. See the description at Test Data Documentation. Some of the data needs to be the same between the two reports, but because the reports generated by Test Cases 3 and 4 are validated as independent events, the CRV cannot track the data that needs to be shared. The tester must verify that the cancer report for Test Case 4 contains certain values that are equal to corresponding values in Test Case 3's report. These values are highlighted in yellow in the test data for Test Case 4. Additionally, the version number must be greater than the version number in Test Case 3, and the relatedDocument/@typeCode must be "RPLC." See the column "Note To Vendors and Testers" in Test Case 4 for more details.
  • Test Case 5 is a negative test case. The test data must be entered into the EHR system in the same manner as the rest of the test cases. The tester must verify that a cancer report is not generated or would not be submitted for this test case. This is because the cancer diagnosis is not from one of the reportability lists specified as BR 02 on page 21 of Volume 1 of the Cancer Reporting IG.
  • Postal codes are only checked against a list of 5-digit postal codes. Postal codes that are in the format 5-digits, hyphen, 4-digits will throw a warning. This warning must be checked by the tester.
  • If there is a warning for doseQuantity (CONF:1098-7516), then manual inspection is required to verify that units are provided in consumable element itself or in doseQuantity/@unit attribute.
    • From the IG regarding this conformance rule:
      1. Pre-coordinated consumable: If the consumable code is a pre-coordinated unit dose (e.g., "metoprolol 25mg tablet") then doseQuantity is a unitless number that indicates the number of products given per administration (e.g., "2", meaning 2 x "metoprolol 25mg tablet" per administration) (CONF:1098-16878).
      2. Not pre-coordinated consumable: If the consumable code is not pre-coordinated (e.g., is simply "metoprolol"), then doseQuantity must represent a physical quantity with @unit, e.g., "25" and "mg", specifying the amount of product given per administration (CONF:1098-16879).
  • If there is a mismatch displayed in the Test Data Conformance Events tab related to raceCode or sdtc:raceCode, check to make sure that the values in both the raceCode and sdtc:raceCode elements are not equal.

  • If an EHR does not allow null flavors for Patient’s Address State, Patient’s Address City, and Patient’s Address Zip Code, then valid values are acceptable for these elements instead of null flavors for Test Case 2. This will require manual review for these elements for Test Case 2 if mismatches are seen in the Test Data Conformance Events.
  • No labels