Table of Contents

Description

The purpose of the use case is to transmit cancer case information to state central cancer registries. The intent is to provide access to data not currently available, or available through non-standard and/or manual methods; it will not replace hospital registry reporting methods that are working well. The cancer use case will help assess how to address the gaps in workflow and triggers, and the ability to leverage MedMorph RA IG along with other existing HL7 FHIR® Implementation Guides to address the public health information needs.

Problem Statement

Cancer is a mandatory reportable disease; every state has public health law/regulation requiring information to be reported to a central cancer registry about all cancers diagnosed or treated within that state. Central cancer registries are population-based cancer registries that collect data on all cancer diagnosed in residents in a defined geographic area. The main sources of information include information from treatment facilities (e.g., hospitals, clinics/physician offices), diagnostic services (e.g., pathology laboratories) and vital statistics (e.g., death certificates). Central cancer registries have an emphasis on epidemiology and public health to determine patterns among various populations, monitor cancer trends over time, guide planning and evaluation of cancer control efforts, help prioritize health resource allocations and to advance clinical, epidemiologic and health services research ¹. Even with reporting requirements, cancer surveillance is complex given the heterogeneous nature of the disease, numerous diagnostic and prognostic factors, and multiple medical encounters that produce data from a variety of non-harmonized data sources.

Challenges include:

• Inability to identify which patient diagnoses and encounters require reporting

• A lack of data in discrete fields (e.g., narrative blob text fields, PDF documents)

• Issues with data flow

• Delays in data availability

• Managing proper timing of creating and transmitting reports

• A lack of standardized systems for cancer data collection and reporting (in some cases)

These challenges make it difficult for registries to synthesize information in a timely and actionable way. Automation of cancer case registry reporting will reduce the burden of manual or other non-standardized data collection processes that currently exist.

Goals of the Use Case

The goal of this use case is to automate the capture of cancer cases and cancer treatment information not reported by other sources and provide incidence data faster for research and public health. It will leverage the Making Electronic Data More Available for Research and Public Health (MedMorph) Reference Architecture (RA) IG and other existing FHIR® infrastructure to transmit cancer case information primarily from ambulatory care practices to central cancer registries. This Use case will not replace hospital registry reporting methods which are working well. Additionally, this use case aims to identify data standards that allow for the collection and transmission of these data electronically from EHRs automatically rather than relying on labor-intensive manual processes and duplications of effort.

Scope of the Use Case

In-Scope

• Collect standardized data on all types of reportable cancers diagnosed and/or treated

• Define under what circumstances an EHR system must create and transmit a cancer report to the central cancer registry

• Identify the data elements to be retrieved from the EHR to produce the cancer report

• Use NAACCR Volume II data dictionary for standardized data collection

• Include data collection along the longitudinal spectrum (Diagnosis -> Staging -> Initial Treatment -> Death)

Out-of-Scope

• Validation of the EHR data

• Data captured outside the EHR and communicated directly to registries

• Changes to existing provider workflow or existing data entry

• Policies of the clinical care setting to collect consent for data sharing

• Integrating claims data into the trigger event to send a report to the cancer registries

Use Case Actors

Electronic Health Record (EHR): A system used in care delivery for patients and captures and stores data about patients and makes the information available instantly and securely to authorized users. While an EHR does contain the medical and treatment histories of patients, an EHR system is built to go beyond standard clinical data collected in a provider’s provision of care location and can be inclusive of a broader view of a patient’s care. EHRs are a vital part of health IT and can:

• Contain a patient’s medical history, diagnoses, medications, treatment plans, immunization dates, allergies, radiology images, and laboratory and test results

• Allow access to evidence-based tools that providers can use to make decisions about a patient’s care

• Automate and streamline provider workflow

A FHIR Enabled Data Source exposes FHIR APIs for other systems to interact with the EHR and exchange data. FHIR APIs provide well-defined mechanisms to read and write data. The FHIR APIs are protected by an Authorization Server which authenticates and authorizes users or systems prior to accessing the data. The EHR in this use case is a FHIR Enabled EHR.

Health Data Exchange (HDEA) (MedMorph’s backend services app): A system that resides within the clinical care setting and performs the reporting functions to public health and/or research registries. The system uses the information supplied by the metadata repository to determine when reporting needs to be done, what data needs to be reported, how the data needs to be reported, and to whom the data should be reported. The term “Backend Service” is used to refer to the fact that the system does not require user intervention to perform reporting. The term “App” is used to indicate that it is similar to a SMART on FHIR App which can be distributed to clinical care via EHR vendor specified processes. The EHR vendor specified processes are followed to enable the Backend Services App to use the EHR's FHIR APIs to access data. The healthcare organization is the one who is responsible for choosing and maintaining the Backend Services App within the organization.

Central Cancer Registry: A data repository that receives and stores cancer case information.  Data Repositories are actively managed and are used to receive data, store data, and perform analysis as appropriate. These data repositories could be operated or accessed by PHA (or their designated organizations), research organizations with appropriate authorities and policies.

Central Cancer Registry Reporting Process Abstract Model

Figure 1 below is the Abstract Model that illustrates the actors, activity, and systems involved in the Central Cancer Registry Reporting Use Case workflow.

Open

Figure 1: Central Cancer Registry Reporting Process Abstract Model

Use Case User Stories and Diagrams

Preconditions 

Preconditions describe the state of the system, from a technical perspective, that must be true before an operation, process, activity, or task can be executed. Preconditions are what need to be in place before executing the use case flow.

The preconditions for the cancer registry reporting use case include:

• Use Case Trigger: A cancer diagnosis has been recorded in the EHR

• EHR and central cancer registry systems support HL7 FHIR APIs

• Pertinent data elements are captured discretely in the EHR

• Public Health uses allowed by HIPAA and other statutory authorities have been defined and implemented

• Provisioning workflows have been established. The workflow includes activities that publish the various metadata artifacts required to make EHR data available to public health and/or research. These activities include publishing value sets, trigger codes, reporting timing parameters, survey instruments, structures for reporting, etc. These artifacts are used subsequently in data collection and reporting workflows.

User Stories

User Story Cancer Diagnosis and Treatment - Reporting based on Specific Criteria

A patient visits her primary care provider (PCP) because of a lump in her breast. The provider orders a mammogram and then a biopsy that is sent to the pathology laboratory for testing. The laboratory analyzes the biopsy specimen which indicates the patient has breast cancer. The pathology report is sent to the provider who ordered the biopsy. On January 20, 2022, the provider confirms the diagnosis of breast cancer. This information is integrated into the patient’s EHR. The patient is informed of her test results. The PCP clinic’s electronic reporting system determines that the patient has been diagnosed with a cancer that meets the criteria for reporting to the central cancer registry, as defined by the national standard Cancer Reportability List. These lists and other reportability criteria are contained in the Health Data Exchange App (HDEA), MedMorph’s backend services app. The HDEA handles all the trigger events for exchanging a patient’s EHR information across systems and is notified when the encounter is closed. The HDEA creates a standard report with the required data elements and sends it to the central cancer registry in the state where the patient resides, as required by state law. On February 2, 2022, the PCP orders a further workup and clinically stages the patient’s cancer. This information is also included in the patient’s EHR. The HDEA recognizes that this initial staging information does not meet the criteria for reporting because the information has been added within six months of the initial report transmitted to the central cancer registry (i.e., the initial report was sent January 20, 2022, and the staging information was done February 2, 2022). Thus, the staging information is in the EHR, but does not yet trigger the HDEA to report or exchange this information.

The patient has surgery on February 9, 2022, and the PCP refers her to a medical oncologist in the same clinic for further treatment. The medical oncologist sends the patient to the radiation therapy department to initiate radiation therapy as part of the first course of treatment for her breast cancer. Radiation therapy is given through September 29, 2022 and is documented in the EHR as the reason for the encounter/visit. The HDEA is notified of this update by the patient’s EHR and determines that the patient was seen for treatment of a cancer that meets the criteria for reporting to the central cancer registry and is more than six months after the initial diagnosis was transmitted to the central cancer registry. Thus, the HDEA creates a standard report with the required data elements and securely sends it to the central cancer registry in the state where the patient resides, as required by state law.

After radiation was completed on September 29, 2022, the medical oncologist initiates the chemotherapy regimen on October 10, 2022, as part of the first course of treatment for her breast cancer. The chemotherapy drugs are infused, and the chemotherapy treatment is documented in the EHR as the reason for the encounter/visit. The HDEA determines that the patient was seen for treatment of a cancer that meets the criteria for reporting to the central cancer registry; however, it does not meet the criteria for transmitting to the central registry because it has been added to the EHR between 6 months and 12 months of the initial diagnosis and transmission of a cancer report.

After 12 months from the initial diagnosis and transmission of a cancer report to the central cancer registry, the HDEA generates and sends a standard report with essential data elements to the central cancer registry in the state where the patient resides. At every subsequent 12 months after the initial diagnosis and transmission of a cancer report to the central cancer registry, the HDEA generates and sends a standard report with essential data elements to the central cancer registry in the state where the patient resides, until the patient is recorded as deceased or there have been no updates to the patient’s EHR record. These timed exchanges of a patient’s EHR information are triggered by criteria set up in the HDEA and run seamlessly in the background without human intervention, which eases mandatory reporting requirements.

Cancer Diagnosis and Treatment Main Flow

The table below illustrates each actor, role, activity, input, and output of each step of the Cancer Diagnosis and Treatment user story.

Table 1: Cancer Diagnosis and Treatment Flow

Cancer Diagnosis and Treatment Activity Diagram

Figure 2 below illustrates the flow of events and information between the actors for the Cancer Diagnosis and Treatment workflow.

Open

Figure 2: Cancer Diagnosis and Treatment Activity Diagram

Cancer Diagnosis and Treatment Sequence Diagram

Figure 3 below represents the interactions between actors in the sequential order that they occur in the Cancer Diagnosis Treatment workflow.

Open

Figure 3: Cancer Diagnosis and Treatment Sequence Diagram

Alternate Flow – Reporting Every Encounter

Cancer - Reporting Every Encounter Alternate Flow

The Cancer Diagnosis and Treatment – Reporting Every Encounter user story remains the same as the Cancer Diagnosis and Treatment user story except instead of identifying a category of criteria that triggers a report, the “all reports” criteria are set.

The table below illustrates each actor, role, activity, input, and output of each step of the Alternate Cancer Diagnosis and Treatment Reporting Every Encounter user story

Table 2: Cancer - Reporting Every Encounter Alternate Flow

Cancer - Reporting Every Encounter Activity Diagram

Figure 4 below illustrates the flow of events and information between the actors for the Cancer Diagnosis and Treatment -  Reporting Every Encounter workflow.

Open

Figure 4: Cancer - Reporting Every Encounter Activity Diagram

Cancer - Reporting Every Encounter Sequence Diagram

Figure 5 below represents the interactions between actors in the sequential order that they occur in the Cancer Diagnosis and Treatment – Reporting Every Encounter workflow.

Open

Figure 5: Cancer - Reporting Every Encounter Sequence Diagram

Postconditions

• The submitted cancer report resides in the central cancer registry.

Data Requirements

Cancer Data Elements: Note that these are pulled from NAACCR Version 21 Data Standards and Data Dictionary.

The table below illustrates the data element, definition, sample values or codes, USCDI, and USCDI element name for cancer reporting.

Click here for a detailed MS Excel version of the table below which includes mapping to US Core, USCDI, mCODE, and electronic Case Reporting (eCR).