Skip directly to search Skip directly to A to Z list Skip directly to navigation Skip directly to page options Skip directly to site content

Hospital Abstracting Data Flow Diagram

The hospital abstracting data flow diagram shows the detailed procedural flow of control of the function. A text description of the diagram and legend may be found below. For information about reading diagrams, see Diagram Conventions.

HDFD 1.5 - NPCR AERRO: Perform Abstracting Data Flow Diagram
Version 1.0 Revised: 4-8-2010

Data Flow Diagram Legend

Data Flow Diagram Legend

There are two actors: the registrar and cancer registry (CR) software.

The process starts when the registrar selects a new reportable cancer that is ready to be abstracted. The CR software checks whether event reports for these cases are waiting for review of reportability by the registrar. If there are event reports to be reviewed, the registrar reviews them to decide if they are reportable. If it is a reportable cancer, the CR software creates and auto-populates a new cancer abstract from the event reports in the TobeAbstracted table. If the event report is not a reportable cancer, the software updates the follow-up information on the CR record and stores the event report in the MatchedEventReports table. If the registrar cannot decide if it is a reportable cancer, the CR software stores the event report in the PendingInformation table and the registrar sends e-mail to the appropriate personnel to determine reportability; when the registrar receives a response, he or she reviews the report again to decide reportability.

The new cancer abstract created from the event reports in the ToBeAbstracted table is displayed for registrar review. The registrar reviews the event report to determine if more than one new abstract is required. If required, the CR software creates and auto-populates a new abstract. If no new abstract is required, the registrar checks the abstract to see if populated data are correct. If the data are not correct, the registrar revises the incorrect data and notifies the data source about the incorrect data. If the data are correct, the registrar checks data completeness. If the data are not complete, the registrar requests more information from the data source; when the registrar receives a response, he or she reviews the abstract again for reportability and completeness. If the data are complete, the registrar determines the completion level and sets the status flag and timestamp for the abstract. The CR software sets the reporting and end point triggers and stores information in the MatchedEventReports table, and the process stops.

Business Rules (BR)

For details of the business rules and software requirements, please refer to the Hospital Abstracting Use Case [PDF-392KB].

  • BR01 applies to CR software identifying new reportable cancer cases ready to be abstracted.
  • BR02, BR03, and BR04 apply to creation and auto-population of a new cancer abstract with event reports in the ToBeAbstracted table.
  • BR07, BR08, and BR09 apply to determining the reportability and completeness of event report.
  • BR05 and BR06 apply to determining completion level and setting status flags, timestamps, and reporting and end point triggers.

Software Requirements (SR)

  • SR01, SR02, and SR03 apply to creation and auto-population of a new cancer abstract with event reports in the ToBeAbstracted table.
  • SR04, SR05, SR06, and SR07 apply to determining whether more than one new abstract is required.
  • SR08 applies to determining the completeness and setting the status flag and timestamp for event reports.
  • SR09 applies to electronic filing of documents.
  • SR10 applies to determining reportability of the event report.
Top