There are two actors: the registrar and cancer registry (CR) software.
The process starts when the batch file is loaded into the CR database.
The CR software determines if the event report is a registry event report or a non-registry event report.
For a non-registry event report, the CR software determines if the event report is a relevant cancer report. If it is not a relevant cancer event report, the report is deleted from the CR database. If it is a relevant cancer event report, the registrar reviews the non-registry event report to determine if it is a reportable cancer. If it is not a reportable cancer, the relevant non-registry event report is discarded from the CR database. If the registrar cannot determine if it is a reportable cancer, the registrar requests more information from the data source, receives a response, and again reviews the event report again to check for a reportable cancer.
Regardless of relevance, the CR software determines if the event report is a duplicate of an existing event report. If it is a duplicate event report, it is deleted. If it is not a duplicate, it is assigned a record identification (ID) number. The CR software checks if the event report is an update for an existing report. If it is an update, the CR software finds the matching record in the PendingCorrections table, overwrites the existing record, and deletes the record from the PendingCorrections table.
The CR software standardizes the data values for the updated or new relevant event report. It verifies that the event report passes the data validation checks that have been provided to the hospital registry as part of the submission requirements. If the event report fails one or more edit checks, the CR software stores the erroneous event report, returns it to the data source, and the process stops.
The CR software may perform additional data validation on the event report specific to the CR. If the event report fails, the registrar resolves the discrepancy, requesting more information as needed.
If it is a corrected event report, it is inserted into the PendingCorrections table and the process stops. If it is not a corrected event report, the registrar receives a response from the data source. The CR software updates the abstract with correct data, inserts information into the ErrorMonitoring table, and notifies the data source about the incorrect data.
The CR software determines whether the event report meets the criteria for visual editing. If the event report meets the criteria, the registrar performs visual editing. If discrepancies are found, the registrar requests more information from the data source. If the event report does not have discrepancies, the CR software inserts the event report into the CR database and checks if the event report is eligible for special study. If it is eligible, the CR software notifies the special study group. If it not eligible, the CR software notifies the data source of the results of batch processing and validating the event report, and sends the new event report to the ToBePatientLinked database table.
Business Rules (BR)
For details of the business rules and software requirement, please refer to the Validate Event Report Use Case (PDF-503KB).
- BR01, BR02, and BR03 apply to checking if the event report is a duplicate and if it is a reportable cancer in the CR database.
- BR04 applies to standardization of data values in the abstract.
- BR05 and BR06 apply to checking if the event report passes the edit checks for hospital registries.
- BR07, BR08, and BR09 apply to determining if the event report meets the criteria for visual editing.
- BR11, BR12, BR13, and BR14 apply to determining if the event report passes the CR edit checks.
- BR10 applies to determining if the event report is eligible for special studies.
Please note: Some of these publications are available for download only as *.pdf files. These files require Adobe Acrobat Reader in order to be viewed. Please review the information on downloading and using Acrobat Reader software.