National Program of Cancer Registries -- Modeling Electronic Reporting
Project

Central Cancer Registry Strategic Assessment and Modeling Session

Requirements Findings

Atlanta, GA

October 25-27, 2006

CDC/DCPC/NPCR

Table of Contents

[PARTICIPANTS 1](#__RefHeading___Toc153172506)

[OBSERVERS 2](#__RefHeading___Toc153172507)

[SUPPORT TEAM 2](#__RefHeading___Toc153172508)

[1 BACKGROUND 3](#background)

[2 SAMS OBJECTIVES 3](#sams-objectives)

[2.1 Objectives 4](#objectives)

[3 SAMS AGENDA 4](#sams-agenda)

[3.1 Day One 4](#day-one)

[3.2 Day Two 4](#day-two)

[3.3 Day Three 4](#day-three)

[4 PROJECT DEFINITION 4](#project-definition)

[5 BARRIERS/CHALLENGES AND ENABLEMENTS
5](#barrierschallenges-and-enablements)

[5.1 Barriers/Challenges 5](#barrierschallenges)

[5.2 Enablements 6](#enablements)

[6 CORE CCR FUNCTIONS 7](#core-ccr-functions)

[7 RECEIVING EVENT REPORTS 8](#receiving-event-reports)

[7.1 Receiving Event Reports Process
8](#receiving-event-reports-process)

[7.2 Receiving Event Reports Decision Tables
9](#receiving-event-reports-decision-tables)

[7.3 Receiving Event Reports Business Rules
10](#receiving-event-reports-business-rules)

[7.4 Receiving Event Reports UML Diagram
12](#receiving-event-reports-uml-diagram)

[8 OPPORTUNITIES FOR IMPROVEMENT 13](#opportunities-for-improvement)

[9 SIDE ITEMS 14](#side-items)

[10 APPENDIX A: CCR AS-IS vs. TO-BE OPERATIONS USE CASE DIAGRAM
15](#appendix-a-ccr-as-is-vs.-to-be-operations-use-case-diagram)

[11 APPENDIX B: PRIORITIZED CORE CCR FUNCTIONS
16](#appendix-b-prioritized-core-ccr-functions)

[]{#__RefHeading___Toc153172506 .anchor}PARTICIPANTS

Patricia Alafaireet, MHA

Project Manager

Health Management and Informatics

Anne Brinton, BA, CTR

QA Manager

Tennessee Cancer Registry

Michael Castera, CTR

QA-IT Liason

Arkansas Central Cancer Registry

Larry Derrick, MEA

Director

Rocky Mountain Cancer Data Systems

Holly Engelhardt, MS

Epidemiologist

Ohio Department of Health

Heidi Gianella, MSIS, RHIA, CTR

Product Manager

IMPAC Medical Systems

Kenneth Hill, MS

Project Manager

The Health Registry Network

John Hoey, BS

Supervisor of Data Processing

New York State Cancer Registry

Ahmed Jamal, MBBS, MPH

Data Manager/Epidemiologist

DHR-Georgia

Amy Kahn, MS

Research Scientist

New York State Cancer Registry

Mary Kennedy, MPH

Manager, Oncology Services

SNOMED

Marlys Knell, CTR

Program Coordinator

North Dakota Cancer Registry

Gary Levin, BA, CTR

Director of Administration/MIS

Florida Cancer System

Qiong Li, PhD

Statistical Analyst

Tennessee Cancer Registry

Sarah Manson, BS, CTR

Quality Control Field Coordinator

Florida Cancer Data System

Paula Marshall, BS, CTR

Oklahoma Central Cancer Registry

Jim Martin, PhD

Director

Virginia Cancer Registry

Suhi Paul, BE

Management Consultant

PHI

Steven Peace, BS, CTR

Westat

Bruce Riddle

Registry Manager

New Hampshire State Cancer Registry

William Ruisinger, CTR

Cancer Registrar

Ohio Cancer Registry

Wendy Scharber, RHIT, CTR

CDC Consultant

Registry Widgets

Andrew Sutliff, BS

Programmer/Analyst III

California Cancer Registry

Sue Vest, CTR

Project Manager

Missouri Cancer Registry

[]{#__RefHeading___Toc153172507 .anchor}OBSERVERS

Faruque Ahmed, MD

Acting Branch Chief

CDC, Cancer Surveillance Branch

Minal Agrawal, MS

Business Analyst

CDC, Northrop Grumman

Timothy Carney, MPH, MBA

Informatics Specialist

CDC

Gayle Clutter, CTR

Program Consultant

CDC, Cancer Surveillance Branch

David Lyalin

Consultant

Northrop Grumman -- CITS

Joseph Rogers

DAST Team Lead

CDC, Cancer Surveillance Branch

Sandy Thames

Public Health Advisor

CDC, Cancer Surveillance Branch

Missy Jamison

CDC

[]{#__RefHeading___Toc153172508 .anchor}SUPPORT TEAM

Gail DeCosta

Facilitator

Advanced Strategies, Inc.

Kahil Branton

Coach

Advanced Strategies, Inc.

Lisa Maturo

Recording Analyst

Advanced Strategies, Inc.

Lori Havener, CTR

Recording Analyst

CDC Consultant

Richard Branton

Advanced Strategies Sponsor

Advanced Strategies, Inc.

Sharon Notari

Advanced Strategies General Manager

Advanced Strategies, Inc.

# BACKGROUND

The Centers for Disease Control and Prevention's (CDC) National Program
of Cancer Registries -- Modeling Electronic Reporting Project
(NPCR-MERP) is a collaborative effort to position the cancer
surveillance community to take advantage of the electronic medical
record (EMR) for cancer surveillance through automated capture of
electronically available data. This will be accomplished by developing
consensus-based recommendations and guidelines, reflected in models to
represent the flow of data through all levels of the cancer surveillance
system. The model will include flow processes from the hospital's EMR
(which includes multiple database systems) and other cancer registry
data sources (such as private pathology labs) to the hospital cancer
registry; from the hospital cancer registry to the state central cancer
registry; and from the state central cancer registry to the national
programs \[CDC National Program of Cancer Registries (NPCR), National
Cancer Institute (NCI) Surveillance, Epidemiology, and End results
(SEER), American College of Surgeons (ACoS) Commission on Cancer (CoC)
and North American Association of Central Cancer Registries, Inc.
(NAACCR)\].

The purpose of NPCR-MERP is to construct a comprehensive model that can
enable NPCR to demonstrate the potential of electronic cancer registry
reporting to their grantees and partners to:

-   Reduce cancer burden in the U.S. population;

-   Identify new capabilities offered by electronic capture of patient
    information;

-   Incorporate national standards;

-   Identify ways to improve completeness, timeliness and quality of
    data;

-   Identify opportunities to automate manual processes for data
    capture;

-   Present models in multiple levels of granularity and specificity;

-   Reduce costs for registries and data providers significantly over
    time;

-   Reflect current industry best practices.

Phase I of the project was a collaboration effort with the Virginia
Commonwealth University Hospital System (VCUHS), the Virginia Cancer
Registry (VCR), the NCI SEER program, the CDC NPCR, Northrop Grumman IT,
and Scientific Technologies Corporation to develop a proposed "straw
man" model that would be used to begin discussions with the broader
cancer surveillance community. Phase II is commencing with a series of
focused Strategic Assessment and Modeling Sessions (SAMS) aimed at
gaining national input on the modeling activity of the NPCR-MERP Team.
The idea is to develop the electronic reporting component of a
comprehensive national consensus model that outlines best practices,
guidelines, and recommendations for the introduction of electronic data
exchange within cancer surveillance.

The first Central Cancer Registry (CCR) Strategic Assessment and
Modeling Session (SAMS) included program managers from several NPCR
funded states and focused on gathering a broad understanding of the CCR
business and barriers to electronic reporting. Objectives for the first
CCR SAMS: define CCR core functions with the focus on electronic
reporting; identify best and worse case scenarios; identify barriers to
electronic reporting; identify opportunities for immediate impact; and,
review diagrams.

# SAMS OBJECTIVES

This is the second CCR SAMS session designed to build on the work
completed in the first SAMS and includes a wider variety of CCR experts
such as cancer registrars, epidemiologist/

statisticians, data managers/IT, program managers, central registry
software vendors, standard setters, and others to provide expertise on
cancer registration and electronic reporting. During the SAMS
participants provided detailed feedback on ideal practices related to
specific CCR functions in an ideal electronic reporting infrastructure.

## Objectives

### To define a comprehensive list of functions that would benefit from electronic manipulation of registry data. For each core function determine how data is retrieved, transmitted, stored, analyzed, utilized, etc. 

> Note: Special emphasis will be on the transmission of data from
> hospital cancer registry and other external data sources into the
> central cancer registry.

### To define and/or refine CCR-related diagrams that expressed CCR entities, processes, data flows, transmission protocols, and standards.

### To establish a representative audience that can be added to the existing CCR workgroup, to provide continued feedback and guidance on the CCR component of the NPCR-MERP Guidelines, Recommendations, and Best Practices in cancer registry electronic reporting.

# SAMS AGENDA

## Day One

Opening comments and introductions

Project briefing

SAMS orientation

Project definition

Brainstorm barriers/challenges and enablements

Closing comments

## Day Two

Review prior work

CCR core functions

Process mapping orientation

High-level map of CCR core functions

Prioritize CCR core functions

Detailed map of as-is model for "Receive event reports"

Improvement opportunities

Debriefing

## Day Three

Review detailed as-is model and discussed boundaries of case finding

Review high-level as-is model (see Appendix A for the UML diagram)

Identify additional opportunities

Develop to-be model for "Receive event reports"

Develop decision tables for "Receive event reports and accept event
reports"

Develop business use case

Debriefing and closing

# PROJECT DEFINITION

This SAMS contributes to developing a blueprint for electronic reporting
of cancer data that will:

-   Identify priorities to make better use of cancer surveillance
    resources;

-   Provide guidance, best practices and a series of resources for
    development of standards-based systems for cancer registration;

-   Enable the reduction of the number of manual processes;

-   Enable better use of the Certified Tumor Registrars' (CTRs) time.

Participants revised the project definition from, "Develop a blueprint
for electronic reporting of cancer data" to "Develop a blueprint for
electronic reporting and automated transmission and automated processing
of cancer data."

***Action item:*** wordsmith the electronic reporting definition. There
was extensive discussion on the meaning of 'electronic reporting'. Does
it include exchanging data on the web? What is human interface?
Definitions discussed:

-   A machine readable format can be exchanged by one system and
    consumed by another system. (definition in glossary)

-   Automated transmission of data between 2 or more parties.

-   Communication between 2 systems.

-   Machine to machine communication of data.

-   Transfer of information from one computer-based system to one or
    more other computer-based systems where the primary operator is not
    human.

-   Automated, unattended (by human) transmission of data between 2 or
    more parties.

# BARRIERS/CHALLENGES AND ENABLEMENTS

The group discussed barriers/challenges and enablements for achieving
the project intentions based on the following questions posed by the
facilitator: 1) What would hinder achieving the project intentions? 2)
What would help achieve the project intentions?

## Barriers/Challenges

The participants were asked, "What would hinder achieving the project
intentions?" Some of the general concerns included the ability to
maintain consistent business rules; reluctance to change; quality of the
data; usability of the EHR; and, that science is moving faster than the
cancer community and we may not be needed in 5 years.

Barriers that impact the hospital registry:

-   Enforcement of national standards and the implementation issues at
    the hospital and non-hospital reporting sources.

-   Impact on hospital registry personnel -- personnel changes,
    education, training, and computer skills.

-   Hard to prioritize this project with all the other standards that a
    hospital has to integrate.

Hardware/software/IT barriers

-   There are competing health information systems with development
    differences.

-   Getting multiple software systems and/or networks to be able to
    communicate in a common language.

-   Identifying variability of CCR in terms of their IT structure and
    find common denominator.

-   Hardware availability.

-   Currently, there are no standards for HL7 transmission and
    interpretations of the HL7 standards are different by institutions.

Cost barriers:

-   Many small players with their own proprietary software have
    financial barriers to become standardized.

-   Different standards and business rules for automated processes
    increase IT costs and sometimes these costs are hidden.

-   There will be an implementation cost. How do you implement the EHR
    concept to make everybody (Hospital, pathology laboratory, other
    reporting sources) report the same/produce the same type of output?

-   The total ownership cost.

Other barriers:

-   Operations resulting from MERP will change required skills. People
    must have greater technical and analytical skills, which will impact
    recruitment.

-   Definition, scope and objective are extremely general and broad;
    therefore, there is not sufficient time to complete this project.

-   There is no overall authoritative body - lack of a strong center or
    coordinating group that has the ability to reach executive
    decisions.

-   Data ownership. Who takes the responsibility if there is a change or
    addendum and who ensures that any change in data are transmitted?

-   There is no national agreement on unit of analysis of patient record
    or event record to be sent to registrars.

-   There are multiple standard setters. What do we do if we pick the
    wrong standards?

-   Impact on volunteer time to set standards and educate staff. How do
    we find time, make time, and fund time to do all of this?

## Enablements

The participants were asked, "What would help achieve the project
intentions?"

The fact that the cancer community has a strong track record for
developing standards, collaborating, and utilizing shared resources will
make it easier to educate stakeholders of this project and enable
standardization across the board. There is a political will to move
national health initiatives forward as well as a strong interest in
support of this project to help achieve the project goals.

Technological enablements presented:

-   As technology becomes more and more standard, we won't have to
    invent things from scratch.

-   Explore possible infrastructure resources that are within the
    department e.g., CCR may not have SQL server, but could borrow space
    from a server or system.

-   Adopt open source standards to help achieve project intentions (do
    not have proprietary license restricting use of standards) e.g.,
    type of machine readable record that has proprietary format that
    cannot be used by other systems.

-   Limit software solutions for each process to reduce complexity.

-   Utilize long-term partnerships with software vendors.

Enablements for data use:

-   Easy accessibility and availability of data that can be linked from
    different data sources e.g., hospital discharge data.

-   Look at upcoming ways to collect/analyze data e.g., web services and
    URLs.

-   The amount of cancer data available from clinical research is
    expanding. If we can provide a national resource that catalogs data
    this will be more useful to public health and science.

Other enablements:

-   Change regulations at the state, federal and international levels to
    change standards or mandate reporting.

-   EHR and the diverse capability of handling multiple diseases are key
    in making this project happen.

-   Availability of funds to do this project would help achieve project
    intentions.

-   Opportunity/need for education from the lowest level up.

-   Finite set of fields that are not fuzzy/separate distinct fields
    will make design easier.

-   Clear means for collecting, collating and disseminating the
    information on advancement of products, to drive our efforts now and
    going forward.

-   Ability to clearly define data collection rules.

-   Develop standard business rules for all production processes.

# CORE CCR FUNCTIONS

A list of core CCR functions developed prior to the meeting was
presented to the participants. The participants reviewed and discussed
the list and made modifications. The following is a list of the core CCR
functions identified by participants:

-   Receiving Event Reports

-   Case Finding (passive and active)

-   Consolidation

-   Follow Back

-   Patient Linkage

-   Abstracting and Coding

-   Audits/QC/QA

-   Rapid Case Ascertainment

-   Source Record and Cancer Level Editing

-   Tumor Linkage

-   Death Clearance

-   Data Enhancement

-   Calls for Data

-   Data Use

-   Follow-up

-   Research Linkage

-   Training

-   Security, Privacy and Authentication Policy Requirements

***Action item:*** determine which term to use Case Finding vs. Case
Ascertainment*.* There was discussion on whether Case Finding should be
changed to Case Ascertainment. It was suggested that Case Finding is
more of a hospital registry term.

The participants agreed that Decision Making is part of each core
function process and not a separate function. Decision Making will not
be included in the list of core functions.

There is not a separate core function for Management Reports. It was
agreed that Management Reports is part of the Audits/QC/QA core
function.

The participants were asked to prioritize these core CCR functions to
determine which core function would be modeled first (see Appendix B).
Each participant selected their top 3 functions. The following 3 core
functions received the most votes: Receiving Event Reports, Case
Finding, and Consolidation. A second vote on the top 3 core functions
determined that Receiving Event Reports would be the first function to
be modeled.

# RECEIVING EVENT REPORTS

The group discussed their As-Is processes for Receiving Event Reports.
Then, the group discussed the To-Be process for Receiving Event Reports
electronically and developed the process table (section 7.1), decision
tables (section 7.2) and the business rules (section 7.3).

## Receiving Event Reports Process 

+---+-----------+-------------+------------------------------+--------+
| * | **Name**  | **Trigger** | **D                          | *      |
| * |           |             | escription/Policies/Business | *Proce |
| I |           |             | Rules**                      | ssor** |
| D |           |             |                              |        |
| * |           |             |                              |        |
| * |           |             |                              |        |
+===+===========+=============+==============================+========+
| 1 | Define    |             | 1.  Look at existing         |        |
| . | Standards |             |     standards for potential  |        |
| 0 | for Data  |             |     use                      |        |
|   | Sources   |             |                              |        |
|   |           |             | 2.  It would be beneficial   |        |
|   |           |             |     to have a national       |        |
|   |           |             |     unique identifier to     |        |
|   |           |             |     link patients            |        |
|   |           |             |                              |        |
|   |           |             | 3.  Not a trivial task to    |        |
|   |           |             |     come up w/standards even |        |
|   |           |             |     amongst ourselves        |        |
|   |           |             |                              |        |
|   |           |             | 4.  Communicate w/EHR        |        |
|   |           |             |     initiatives -- need to   |        |
|   |           |             |     participate on HITSP     |        |
+---+-----------+-------------+------------------------------+--------+
| 2 | Enter     |             | 1.  Some data sources enter  | Data   |
| . | Event     |             |     event reports into a     | Source |
| 0 | Report    |             |     web-based application.   | via    |
|   |           |             |                              | web    |
|   |           |             | 2.  Data sources w/out       |        |
|   |           |             |     registry-type operations |        |
+---+-----------+-------------+------------------------------+--------+
| 3 | Generate  |             | 1.  Other Data sources       | Data   |
| . | Event     |             |     generate reports using   | Source |
| 0 | Report    |             |     HL7 CDA templates        | via    |
|   |           |             |     according to defined     | elec   |
|   |           |             |     standards for data       | tronic |
|   |           |             |     sources.                 | subm   |
|   |           |             |                              | ission |
+---+-----------+-------------+------------------------------+--------+
| 4 | Log Event | Event       | 1.  All event reports        |        |
| . | Report    | Report      |     received are logged in   |        |
| 0 |           | received    |     and the status marked as |        |
|   |           | ele         |     received.                |        |
|   |           | ctronically |                              |        |
+---+-----------+-------------+------------------------------+--------+
| 5 | Determine | Event       | 1.  Determine what format    | Aut    |
| . | Record    | Report      |     the file/record is in.   | omated |
| 0 | Format    | logged      |                              |        |
|   |           |             | 2.  Candidate formats        |        |
|   |           |             |     include:                 |        |
|   |           |             |                              |        |
|   |           |             | -   NAACCR current version   |        |
|   |           |             |                              |        |
|   |           |             | -   NAACCR prior version     |        |
|   |           |             |                              |        |
|   |           |             | -   EHR known format         |        |
|   |           |             |                              |        |
|   |           |             | -   Other known format       |        |
|   |           |             |                              |        |
|   |           |             | -   Unknown format           |        |
|   |           |             |                              |        |
|   |           |             | **See 1.0 Decision Table**   |        |
+---+-----------+-------------+------------------------------+--------+
| 6 | Convert   | Data Record | 1.  Convert the data values  | Aut    |
| . | Data      | in EHR or   |     to NAACCR values for     | omated |
| 0 | Values    | other known |     records which are        |        |
|   |           | format      |     received in a known      |        |
|   |           |             |     format that is not the   |        |
|   |           |             |     current NAACCR format.   |        |
+---+-----------+-------------+------------------------------+--------+
| 7 | Determine | Data Record | 1.  Determine if a record    | Aut    |
| . | If Record | in          |     can be accepted.         | omated |
| 0 | Accepted  | acceptable  |                              |        |
|   |           | format      | **See 2.0 Decision Table**   |        |
+---+-----------+-------------+------------------------------+--------+
| 8 | Reject    | Data Record | 1.  Reject the record and    | Aut    |
| . | Event     | in previous |     notify the data source.  | omated |
| 0 | Report    | NAACCR      |                              |        |
|   |           | format or   |                              |        |
|   |           | Unknown     |                              |        |
|   |           | format      |                              |        |
+---+-----------+-------------+------------------------------+--------+
| 9 | Provide   | Patient is  | 1.  Patient's state of       |        |
| . | Source    | resident of |     residence is based on    |        |
| 0 | Record to | a state     |     his primary address.     |        |
|   | State of  | with data   |                              |        |
|   | Residence | exchange    | 2.  If the patient is        |        |
|   |           | agreement   |     resident of another      |        |
|   |           |             |     state with which there   |        |
|   |           |             |     is a data exchange       |        |
|   |           |             |     agreement, send the      |        |
|   |           |             |     source record to that    |        |
|   |           |             |     state.                   |        |
+---+-----------+-------------+------------------------------+--------+
| 1 | Record    | Data        | 1.  If a record is a         |        |
| 0 | Error     | received is |     complete duplicate or if |        |
| . |           | duplicate   |     minimum defined data was |        |
| 0 |           | record, or  |     not included, store the  |        |
|   |           | minimum     |     record with the          |        |
|   |           | data not    |     non-accepted records,    |        |
|   |           | supplied.   |     record the reason and    |        |
|   |           |             |     notify the Data source.  |        |
+---+-----------+-------------+------------------------------+--------+
| 1 | Capture   |             | 1.  Processes 11.0 & 12.0    |        |
| 1 | event     |             |     were a proposal from one |        |
| . |           |             |     SME. Due to the lack of  |        |
| 0 |           |             |     time, the proposal was   |        |
|   |           |             |     not presented to the     |        |
|   |           |             |     group for discussion.    |        |
+---+-----------+-------------+------------------------------+--------+
| 1 | Extract   |             |                              |        |
| 2 | a         |             |                              |        |
| . | nalytical |             |                              |        |
| 0 | in        |             |                              |        |
|   | formation |             |                              |        |
+---+-----------+-------------+------------------------------+--------+

## Receiving Event Reports Decision Tables

Decision Tables: review the decision tables (1.0 and 2.0) by going down
the column, in the Condition section each condition with a Y means 'Yes,
this condition is true' and N means 'No, this condition is not true', in
the Actions section each action with a Ö means 'for the condition(s)
represented as the Y/N in the column above, this action is performed'.

+----------------------------------------------------------+---+---+---+---+
| **1.0 Decision Table: Determine Record Format, Convert   |   |   |   |   |
| Data Values, and Reject Report**                         |   |   |   |   |
+==========================================================+===+===+===+===+
| **CONDITION**                                            | * | * | * | * |
|                                                          | * | * | * | * |
|                                                          | A | B | C | D |
|                                                          | * | * | * | * |
|                                                          | * | * | * | * |
+----------------------------------------------------------+---+---+---+---+
| In current NAACCR format: Y/N                            | Y | N | N | N |
+----------------------------------------------------------+---+---+---+---+
| In previous NAACCR format: Y/N                           | \ | Y | N | N |
|                                                          | - |   |   |   |
+----------------------------------------------------------+---+---+---+---+
| In other known format: Y/N                               | \ | \ | Y | N |
|                                                          | - | - |   |   |
| (E.g. EHR, AIMS/Epath, Pathology, Death tapes, hospital  |   |   |   |   |
| correction record)                                       |   |   |   |   |
+----------------------------------------------------------+---+---+---+---+
| **ACTIONS**                                              |   |   |   |   |
+----------------------------------------------------------+---+---+---+---+
| 1\. Go to Validate                                       | Ö |   |   |   |
+----------------------------------------------------------+---+---+---+---+
| 2\. Reject report                                        |   | Ö |   | Ö |
+----------------------------------------------------------+---+---+---+---+
| 3\. Convert data values to NAACCR values                 |   |   | Ö |   |
+----------------------------------------------------------+---+---+---+---+
| 4\. Store orig. data values                              |   |   | Ö |   |
+----------------------------------------------------------+---+---+---+---+

  ----------------------------------------------------------------------------------------------------
  **2.0 Decision Table: Determine if Record                                                    
  Accepted**                                                                                   
  -------------------------------------------- ------- ------- ------- ------- ------- ------- -------
  **CONDITION**                                **A**   **B**   **C**   **D**   **E**   **F**   **G**

  Duplicate Record: Y/N                        Y       N       N       N       N       N       N

  Reportable Condition: Y/N                    \-      N       N       Y       Y       Y       Y

  Cancer terminology in record: Y/N            \-      Y       N       \-      \-      \-      \-

  Minimum Data Supplied: Y/N                   \-      \-      \-      N       Y       Y       Y

  Patient Info Included: Y/N                   \-      \-      \-      \-      N       Y       Y

  Resident of Registry's Population area: Y/N  \-      \-      \-      \-      \-      Y       N

  **ACTIONS**                                                                                  

  1\. Mark as non-reportable                           Ö                                       

  2\. Delete record (HIPAA compliance)                         Ö                               

  3\. Request Patient Info                                                     Ö               

  4\. Log as received & Mark as duplicate      Ö                                               

  5\. Notify source of error & reason          Ö                       Ö                       

  6 Accept Source Record & notify Data Source                                          Ö       Ö

  7\. Send to State(s) w/ exchange agreements                                                  Ö
  ----------------------------------------------------------------------------------------------------

## Receiving Event Reports Business Rules

+-----------------------------------------------------------------------+
| Use Case ID:                                                          |
+-----------------------------------------------------------------------+
| Use Case Name: Receive Event Reports Electronically                   |
+-----------------------------------------------------------------------+
| Goal: To accept event report records with reportable cancer           |
| conditions.                                                           |
+-----------------------------------------------------------------------+
| Pre-Conditions:                                                       |
|                                                                       |
| 1.  Report is from a trusted source                                   |
+-----------------------------------------------------------------------+
| End Conditions:                                                       |
|                                                                       |
| 1.  Event report record has been accepted to go forward.              |
+-----------------------------------------------------------------------+
| Actors:                                                               |
|                                                                       |
| 1\. CCR software                                                      |
|                                                                       |
| 2\. Data Source software                                              |
+-----------------------------------------------------------------------+
| Triggers:                                                             |
|                                                                       |
| 1\. Event report has arrived electronically from a Data Source.       |
+-----------------------------------------------------------------------+
| Priority:                                                             |
+-----------------------------------------------------------------------+
| Frequency of Use:                                                     |
+-----------------------------------------------------------------------+
| Background:                                                           |
+-----------------------------------------------------------------------+
| Includes:                                                             |
+-----------------------------------------------------------------------+
| Exceptions:                                                           |
|                                                                       |
| -                                                                     |
+-----------------------------------------------------------------------+
| Special requirements:                                                 |
|                                                                       |
| -                                                                     |
+-----------------------------------------------------------------------+
| Assumptions:                                                          |
|                                                                       |
| -                                                                     |
+-----------------------------------------------------------------------+

+---+------------------------+--------------------------------+--------+
| \ | Main Scenario          | Alternate Scenarios            | Bu     |
| # |                        |                                | siness |
|   |                        |                                | Rules/ |
|   |                        |                                |        |
|   |                        |                                | R      |
|   |                        |                                | emarks |
+===+========================+================================+========+
| 1 | CCR receives an event  | 1a.1 CCR pulls an event report |        |
| \ | report from a Data     | from a Data Source.            |        |
| . | Source electronically. |                                |        |
+---+------------------------+--------------------------------+--------+
| 2 | CCR logs record as     |                                |        |
| \ | received.              |                                |        |
| . |                        |                                |        |
+---+------------------------+--------------------------------+--------+
| 3 | CCR determines the     | 3a.1 Not a known format or     |        |
| \ | event report is in the | previous NAACCR format         |        |
| . | current NAACCR format. |                                |        |
|   |                        | > 3a.1.1 Reject the report     |        |
|   |                        | >                              |        |
|   |                        | > 3a.1.2 Notify Data Source of |        |
|   |                        | > rejection                    |        |
|   |                        | >                              |        |
|   |                        | > 3a.1.3 End of use case       |        |
|   |                        |                                |        |
|   |                        | 3a.2 Electronic Health record  |        |
|   |                        | or other known format          |        |
|   |                        |                                |        |
|   |                        | > 3a.2.1 Store original data   |        |
|   |                        | > values                       |        |
|   |                        | >                              |        |
|   |                        | > 3a.2.2 Convert data values   |        |
|   |                        | > to NAACCR data values (if    |        |
|   |                        | > necessary)                   |        |
+---+------------------------+--------------------------------+--------+
| 4 | CCR determines that    | 4a.1 Minimum data not supplied | BR02,  |
| \ | minimum data has been  |                                | BR05   |
| . | supplied.              | > 4a.1.1 Record error          |        |
|   |                        | >                              |        |
|   |                        | > 4a.1.2 Notify Data Source of |        |
|   |                        | > error and reason             |        |
|   |                        | >                              |        |
|   |                        | > 4a.1.3 End of use case       |        |
+---+------------------------+--------------------------------+--------+
| 5 | CCR determines that    | 5a.1 Duplicate record          | BR03   |
| \ | the record is not a    |                                |        |
| . | duplicate.             | > 5a.1.1 Mark as duplicate     |        |
|   |                        | >                              |        |
|   |                        | > 5a.1.2 Notify Data Source of |        |
|   |                        | > error and reason             |        |
|   |                        | >                              |        |
|   |                        | > 5a.1.3 End of use case       |        |
+---+------------------------+--------------------------------+--------+
| 6 | CCR determines that    | 6a.1 Not a reportable          | BR01   |
| \ | the record is for a    | condition                      |        |
| . | reportable condition.  |                                |        |
|   |                        | > 6a.1.1 CCR determines that   |        |
|   |                        | > record is a relevant cancer  |        |
|   |                        | > data report.                 |        |
|   |                        | >                              |        |
|   |                        | > 6a.1.1.1 Mark relevant       |        |
|   |                        | > cancer data report as        |        |
|   |                        | > non-reportable.              |        |
|   |                        | >                              |        |
|   |                        | > 6a.1.2 CCR determines that   |        |
|   |                        | > the record is a non-cancer   |        |
|   |                        | > related data report          |        |
|   |                        | >                              |        |
|   |                        | > 6a.1.2.1 Delete Non-cancer   |        |
|   |                        | > related data report record   |        |
|   |                        | >                              |        |
|   |                        | > 6a.1.3 End of use case       |        |
+---+------------------------+--------------------------------+--------+
| 7 | CCR determines that    | 7a.1 Not a resident            | BR04   |
| \ | patient is a resident  |                                |        |
| . | of the registry's      | > 7a.1.1 CCR determines that   |        |
|   | population area.       | > data exchange agreement      |        |
|   |                        | > exists with the patient's    |        |
|   |                        | > state of residence.          |        |
|   |                        | >                              |        |
|   |                        | > 7a.1.2 Send record to state  |        |
|   |                        | > of residence.                |        |
+---+------------------------+--------------------------------+--------+
| 7 | CCR accepts source     |                                |        |
| \ | record.                |                                |        |
| . |                        |                                |        |
+---+------------------------+--------------------------------+--------+
| 8 | CCR notifies Data      |                                |        |
| \ | Source of accepted     |                                |        |
| . | record.                |                                |        |
+---+------------------------+--------------------------------+--------+

  ------ ------------------------------------------- ---------------------
         Business Rule Statement                     Remarks/Links

  BR01   To determine if reportable follow           
         requirements from the appropriate reporting 
         manual provided by the state                

  BR02   Minimum data requirements vary by cancer    ***Action:*** Need to
         registry, data source and type of event     define specifics in
                                                     subsequent workgroups

  BR03   To determine duplicate, every field must    
         match (i.e. field by field deterministic)   

  BR04   State residency is based upon principal     
         residency at diagnosis                      

  BR05   When minimum data is not supplied, some     
         registries will hold the data and correct   
         it later.                                   
  ------ ------------------------------------------- ---------------------

##   {#section .unnumbered}

##  {#section-1 .unnumbered}

## Receiving Event Reports UML Diagram

[The Receiving Event Reports UML diagram will be placed here upon
completion.]{.mark}

# OPPORTUNITIES FOR IMPROVEMENT

Opportunities for improvement were captured throughout the session. Some
were captured on the side as the high-level as-is process was being
modeled others were documented during the 'opportunity for improvement'
brainstorming session.

There were several opportunities for improvement discussed for physician
reporting. The main concept was to reduce the quantity of paper coming
in manually by providing a web based entry or gateway for physicians to
report cases. Another physician reporting issue is physicians (or their
staff) do not want to take the time to input data into systems or their
practice is so small/rural they do not have web based capabilities in
their office. Recommendations to address this issue:

-   Train/certify high school students on confidentiality and data
    entry. Most high schools have computers with Internet access and
    trained students could complete the data entry/data submission
    tasks.

-   Computerized Physician Order Entry (CPOE) is becoming popular.
    Support for pay for performance initiative is growing. We can
    support/push these initiatives to encourage physicians to become
    more supportive of providing good electronic data.

-   Provide a nationwide standard bubble form (e.g., SAT test) which can
    be scanned in electronically. It would become part of the medical
    record to ease the entry of information for physicians, making this
    more accessible to reporting sources without Internet access.

Manual case submission processes could be improved. Some CCRs hold paper
records for a time period before entering them and other CCRs enter all
paper records with reportable conditions and let the computer match
them. Automation of abstracting/coding for the reporting source would
reduce the time necessary to enter information.

There is a need to standardize received/processed data. As healthcare
sources move towards the EHR there will be more opportunities to build
partial records from multiple sources that will eventually be combined
into full records. Therefore, reporting sources would not be required to
transmit an entire record format and standardized formats would be
tailored for reporting sources. Currently some systems require
conversion of records to a different format while other systems support
different types of records. As standards are developed, we should
consider adopting existing ones or providing tools to convert between
standards (e.g., using billing data standards and extending UB91). One
recommendation was to focus on open standards and move away from
proprietary standards.

Government initiatives will recommend the use of EHR and all government
agencies will have to use the Health Information Technology Standards
Panel (HITSP) recommendations. The cancer community needs to identify
the most effective entry point and actively participate in EHR
initiatives to ensure the EHR standards address our needs.

The Health Level 7 (HL7) Clinical Document Architecture (CDA) was
recommended by HITSP as a standardized EHR messaging transmission
format. Currently the NAACCR Cancer Abstract Transmission work group is
working on a pilot project to test the use of CDA to transmit data from
the hospital registry to the CCR and to develop an implementation guide.
Members of MERP participate on this work group.

Other opportunities for improvement include:

-   There is not a standard transmission record for getting death
    records from vital statistics. This leads to a cumbersome process to
    match the death records.

-   Storage is cheap. All submitted source records should be stored and
    available to use in the future. These source records could be used
    when checking duplicates.

-   CCRs could receive data from central services, mini-locators or
    regional health information organizations (RHIOs).

-   Real-time reporting - sources can push information to CCRs without
    creating an abstract; pre-populate fields in the abstract to ease
    entry (these could be used for things such as including people on
    clinical trials); automate editing processes; and, query reporting
    sources for updates.

-   Software must be rewritten to make it easy to get useable input
    data.

-   Pull full NAACCR 11 format from EHR. Start with partials and move
    towards full in 6 months down the road.

-   Have different record for different types of cancer.

-   Versioning -- some states will auto-convert a format up to the
    current version and some states reject older versions.

-   Minimal source validation for those sources we trust.

-   The Certification Commission for Healthcare Information Technology
    (CCHIT) is providing certification criteria for ambulatory EHR
    systems.

-   Capture and store 'events' that are produced as patient receive
    treatment and produce analytical records on the fly to satisfy our
    clients.

-   Perform visual editing of 10% of all records which pass editing

-   Develop a method to determine where path-only cases have received
    treatment.

-   Develop a method to back out of matching when a wrong decision has
    been made.

# SIDE ITEMS

During the course of the SAMS the team identified items that could not
be addressed during this event. These were noted on a side sheet for
action later:

-   Need to identify places where business rules don't exist.

-   NCRA workload workgroup will be doing surveys of all CCRs. They will
    ask questions like "how much time is spent doing Case Finding?" If
    we do not have common understanding of terms, then data will not be
    accurate.

-   Make a list of standard-setting groups and determine how to
    participate.

-   NPCR has a standard that requires CCRs to keep all submitted cases.
    This goes into effect on 2007.

-   There is a parallel set of efforts to report on radiology reports,
    cost records, genetics, and infusion records. Opportunity to
    integrate. (Borders on the scope of integration). States
    (Medicaid/Medicare) are trying to link their claims to the cancer
    registry to see the average cost of treatment. Sometimes the first
    trigger is receiving a record from an Infusion center or Radiation
    center before we find out about a new cancer case.

-   During subsequent meetings of MERP, would like to define specific
    minimum data requirements for each data source. This was flagged
    during Use Case discussions.

-   There is disagreement between CCRs regarding the boundary of case
    finding.

# APPENDIX A: CCR AS-IS vs. TO-BE OPERATIONS USE CASE DIAGRAM

![](media/image1.wmf){width="7.126388888888889in"
height="9.20486111111111in"}

# APPENDIX B: PRIORITIZED CORE CCR FUNCTIONS

The group prioritized the core CCR functions by making two voting
passes. For the first pass, the group was asked to choose their top
three priorities. Then a second voting pass was made to prioritize the
top three functions. This priority was then used to determine which
function should be modeled first.

+--------------------------------------------------+--------+---------+
| **Core CCR Functions**                           | **Prio | **Pri   |
|                                                  | rity** | ority** |
|                                                  |        |         |
|                                                  | *      | **(pass |
|                                                  | *(pass | 2)**    |
|                                                  | 1)**   |         |
+==================================================+========+=========+
| Receiving Event Reports                          | 14     | 15      |
+--------------------------------------------------+--------+---------+
| Case Finding                                     | 15     | 6       |
+--------------------------------------------------+--------+---------+
| Consolidation                                    | 10     | 5       |
+--------------------------------------------------+--------+---------+
| Follow Back                                      | 8      |         |
+--------------------------------------------------+--------+---------+
| Patient Linkage                                  | 6      |         |
+--------------------------------------------------+--------+---------+
| Abstracting & Coding                             | 4      |         |
+--------------------------------------------------+--------+---------+
| Audits/QC/QA                                     | 3      |         |
+--------------------------------------------------+--------+---------+
| Rapid Case Ascertainment                         | 2      |         |
+--------------------------------------------------+--------+---------+
| Source Record & Cancer Level Editing             | 2      |         |
+--------------------------------------------------+--------+---------+
| Tumor Linkage                                    | 2      |         |
+--------------------------------------------------+--------+---------+
| Death Clearance                                  | 2      |         |
+--------------------------------------------------+--------+---------+
| Data Enhancement                                 | 2      |         |
+--------------------------------------------------+--------+---------+
| Calls for Data                                   | 1      |         |
+--------------------------------------------------+--------+---------+
| Data Use                                         | 1      |         |
+--------------------------------------------------+--------+---------+
| Follow Up                                        | 0      |         |
+--------------------------------------------------+--------+---------+
| Research Linkage                                 | 0      |         |
+--------------------------------------------------+--------+---------+
| Training                                         | 0      |         |
+--------------------------------------------------+--------+---------+
| Security, Privacy & Authentication Policy        | 0      |         |
| Requirements                                     |        |         |
+--------------------------------------------------+--------+---------+

#  {#section-2 .unnumbered}