Reminder: Do not include any PHI or PII in Confluence. If you require 508 accessibility assistance, please send an email to email@example.com
Five test cases are run as part of the test procedure. Note that only one version of Test Case 1 is used. Note also that Test Case 4 is designed as an update to Test Case 3 so the test data may not need to be entered separately into the EHR system. For more information see the section below "Information About the Test Cases."
Links to the spreadsheet versions of the test cases are below:
Information About the Test Cases
- Use Test Cases for Version 1.1.1 for new testing. The Test Cases for Version 1.0.5 are also provided above for reference.
- Where multiple value sets and/or code systems are allowed for a single data element or attribute, use of any one is acceptable for testing. The correct values for every choice have been provided in the test data. For example, see the Data Element "value (histologic type)" in the test data.
- For several templates, all required elements must be populated. Details are not provided in the spreadsheet when they are fixed values because they are clearly defined in the Cancer Reporting IG. Examples include “No Known TNM Clinical Stage Observation” (see Test Case 3) and “No Known TNM Pathologic Stage Observation.”
- Test data values for display names and narrative text are non-normative. Meaning that these values in a cancer report are not required to be exactly as defined in the test data. These values in the cancer report do, however, need to contain equivalent text, and this determination can be made by the tester when evaluating context-specific test cases for any mismatches.
- The column "Note to Vendors and Testers" in the test data provides information about any special circumstances for a particular data point. It highlights, among other things, the relationship between values as described in the Cancer Report Validator Testing Process Document, section "Context-specific (Test Data Conformance) Validation."
Test Case 1a and 1b – Choose One
Test Case 1 has a version "a" and a version "b", only one of which must be tested. Version "a" has data pertaining to radiation treatment contained in the Radiation Oncology Section template. Version "b" has the information in that template nulled. This accommodation was made because EHR vendors may not have the ability to record radiation treatment information. However, the Radiation Oncology Section template is always a required template, and so the information provided in version "b" indicates the manner in which that information can be nulled. If a vendor can utilize the information in the Radiation Oncology Section template, then version "a" of Test Case 1 must be used. Test Case 1b can be used as an example for Test Cases 2, 3, 4, and 5 on how to provide Radiation Oncology Section with null flavors.
Test Case 2 – Minimal Information
Test Case 2 is designed to contain the minimal set of information that a valid cancer report requires. All required data is nulled if allowed and optional data is not included.
Test Cases 3 and 4 – Replacement Report
There is a close relationship between Test_Case_3_Two_Cancer_Diagnoses and Test_Case_4_Two_Cancer_Diagnoses_Update. The latter is designed to produce a report that is a replacement of the former because some of the data have been updated. The data in Test Case 4 that are highlighted in green are the data that change. This relationship was built between the two test cases because the Cancer Reporting IG specifies that a cancer report can be updated and replaced with a newer version. When a report is updated, the new version of the document must contain the same setId as the document that it is replacing and the relatedDocument/@typeCode must be “RPLC”. In addition, the relatedDocument/parentDocument/id and relatedDocument/parentDocument/setId of the new version of the document must match the ClinicalDocument/id and ClinicalDocument/setId of the document it is replacing (or parent document), respectively. These elements are highlighted in yellow in the test data. The data element “Version Number” must also be set to a number greater than 1 (the first replacement would be “2”, and so on).
It is, of course, up to the EHR vendor to determine how the updated document is produced for Test Case 4. Since the majority of the data is shared between Test Case 3 and Test Case 4 -- including the patient name, date of birth, and Social Security number -- the complete set of data for Test Case 4 would not need to be re-entered as a precondition for testing. The data entered for Test Case 3 can likely be updated to reflect the changes represented in Test Case 4 and in fact this is the spirit of the test case.
In the past the test team has asked that vendors change a random piece of data determined on the fly to ensure that the reports are generated in real-time. If this test will carry over to this year, then it might be useful to include that process with Test Case 4 since the purpose of that test case is to change data and update a previous report. The tester could include random change to the data in addition to the changes indicated in Test Case 4.
Test Case 5 – Negative Test
Test_Case_5_Non-reportable is designed to ensure that only reportable cancer diagnoses are reported to the registry. Therefore, to run this test case, the tester should ensure that a cancer report is NOT submitted to the CRV. However, the test data must still be entered into the EHR system. The decision on whether or not to report the cancer diagnosis to the registry is based on the inclusion of a diagnosis from one of three reportability lists. Those lists are defined as BR 02 on page 21 of Volume 1 of the Cancer Reporting IG. In order for a report be sent to a registry, in the Problem Section template of a report(<templateId root="2.16.840.1.1138126.96.36.199" extension="2014-08-08"/>), one of the observation values must be from one of the reportability lists. On a more technical level, one of the results of the following XPath statement must be from one of the reportability lists.