Page tree
Skip to end of metadata
Go to start of metadata

1       Introduction

1.1      Purpose and Scope

This manual was designed to provide additional guidance and best practices for the implementation of mCODE in the information technology systems of a healthcare provider. This manual includes clinical workflow information and how these workflows support the collection of mCODE data elements.

This manual is designed to be applicable to a wide variety of electronic medical record (EMR) systems. As such, this manual can be used to supplement discussions with particular EMR system vendors on the best practices for implementing mCODE at a particular site.

No EMR specific information is present in this document.

1.2      Target Audience and Assumptions

The intended audience are technical staff at a health system that have access and permission to build within the production environment.  This document assumes that the reader has experience studying, developing, implementing, and optimizing clinical workflows. This document also assumes that the reader is familiar with FHIR. The FHIR Starter guide, currently available from HL7 at https://wiki.hl7.org/FHIR_Starter, is a good place to start if the reader is unfamiliar with FHIR.

2       mCODE Data Elements

2.1      Introduction

mCODE, the minimal Common Oncology Data Elements, defines a set of data elements that are essential for analyzing patient characteristics, treatments, and outcomes across all cancer patients. The FHIR profiles defined in mCODE comply to the requirements defined by US Core.  It is currently available at https://mcodeinitiative.org/access-mcode/.  The Data Dictionary found on the page above should be downloaded and referred to along with this document. The data dictionary contains the data elements and value sets added in mCODE but is not a complete list of elements.

These are presented so that the reader can validate that these collection processes are valid at a given healthcare delivery system of interest. If these workflows are not present in a given healthcare delivery system, the following framework presents a generic approach to resolution:

  • Are the data elements required for any current or future use case planned at your health system?
  • Are the data elements collected by any other workflow at your health system?
  • Who is the ideal role at your health system to collect the information?
  • Where is the best place in their workflow to collect the information?

2.2      Data Elements that Should Not Impact Clinical Workflow

Several of the data elements in mCODE should not require clinicians to capture them. These are presented here along with the anticipated point in the routine provision of healthcare where these elements should be captured. For additional information on these data elements, please refer to the mCODE Implementation Guide and/or Data Dictionary.

2.2.1     Registrar or Front Desk Staff

GroupProfile NameData Element Name
PatientPatientDate of Birth
PatientPatientAdministrative Gender
PatientPatientAddress Zip Code
PatientPatientRace Code
PatientPatientEthnicity

2.2.2     Laboratory Interface

For these data elements, conversations with your laboratory services vendors and/or laboratory information systems vendors may be useful in determining whether you can receive these via an automated interface if you do not currently. 

GroupProfile NameData Element Name

Genomics

Genomics Report

Test Name (and optional code)

Genomics

Genomics Report

Performing Organization Name

Genomics

Genomics Report

Specimen Type

Genomics

Genomics Report

Genetic Variant Tested

Genomics

Genomics Report

Genetic Variant Found

Genomics

Genetic Variant Tested

Gene Studied

Genomics

Genetic Variant Tested

Method

Genomics

Genetic Variant Tested

Data Value

Genomics

Genetic Variant Found

Method

Genomics

Genetic Variant Found

Variant Found Identifier

Genomics

Genetic Variant Found

Variant Found HGVS Name

Genomics

Genetic Variant Found

Variant Found Description

Genomics

Genetic Variant Found

Genomic Source Class

Labs/Vitals

CBC

Panel Member

Labs/Vitals

CMP

Panel Member

Labs/Vitals

Tumor Marker Test

Code

Labs/Vitals

Tumor Marker Test

Data Value

Genomics

Genetic Variant Tested

Variant Tested Identifier

Genomics

Genetic Variant Tested

Variant Tested HGVS Name

Genomics

Genetic Variant Tested

Variant Tested Description

2.2.3     Nurse or Medical Assistant

Group

Profile Name

Data Element Name

Labs/Vitals

Body Height

Data Value

Labs/Vitals

Body Weight

Data Value

Labs/Vitals

Blood Pressure

Diastolic Pressure

Labs/Vitals

Blood Pressure

Systolic Pressure

Treatment

Medication Statement

Date/Time

2.2.4     Clinical Orders

While clinicians are required to capture this information, it should be available from the process of ordering and thus not impact clinical workflow.

Group

Profile Name

Data Element Name

Treatment

Medication Statement

Medication Code

Treatment

Medication Statement

Start Date

Treatment

Medication Statement

End Date

2.2.5     Clinical Diagnoses

If your clinicians do not routinely document clinical diagnoses in discrete fashion, you may need to implement a workflow to do so.

If that diagnosis is not sufficiently detailed, you may need to work with your clinicians. For example, if your clinician chooses to use the ICD-10 code C80.1 for Malignant (primary) neoplasm, unspecified your mCODE implementation will be able to report the code for the Primary Cancer Condition Code, but you will be unable to report the Body Location Code. If that clinician instead chose C50.012 for Malignant neoplasm of nipple and areola, left female breast, you can report the Body Location Code as well. An alternative would be to accept the generic code and separate ask clinicians to record the body location.

Group

Profile Name

Data Element Name

Patient

Comorbid Condition

Clinical Status

Patient

Comorbid Condition

Code

Disease

Primary Cancer Condition

Body Location Code

Disease

Primary Cancer Condition

Condition Code

Disease

Primary Cancer Condition

Date of Diagnosis

Disease

Secondary Cancer Condition

Code

Disease

Secondary Cancer Condition

Date of Diagnosis

2.3      Data Elements that May Impact Clinical Workflow

The data elements in this section are likely to not be captured in current workflows. There is the possibility that they are captured, and the following framework presents a generic approach to evaluation:

  • Does your system currently support the discrete capture of these data elements?
    • If so, what are the current usage statistics of those processes?
  • Who is the ideal role at your health system to collect the information?
  • Where is the best place in their workflow to collect the information?

2.3.1     Clinical Diagnosis Related Information

These data elements relate to the cancer diagnosis or diagnoses on the patient’s chart. Clinical status is expected to be reviewed and updated at significant clinical encounters. For example, clinical status should be updated on an office visit, but not necessarily when a clinician calls the patient. The ability to mark a problem as active or inactive is commonly available in EMRs, and you may wish to begin with validating whether these features (if present) are actively being used at your site.

Histology Morphology Behavior is likely to be documented once on a patient’s chart. After that, histology morphology behavior is likely to be reviewed by the clinician at routine intervals but updated only sparingly.

As a result, in consideration of how to adjust your clinical workflows you may wish to put clinical status in a location that is routinely updated, while histology morphology behavior is in a place that is routinely reviewed.

Group

Profile Name

Data Element Name

Disease

Primary Cancer Condition

Clinical Status

Disease

Primary Cancer Condition

Histology Morphology Behavior

Disease

Secondary Cancer Condition

Clinical Status

Disease

Secondary Cancer Condition

Histology Morphology Behavior

2.3.2     Patient Performance Measures

These measures of patient performance may be captured by nurses, medical assistants, or in some cases the patient themselves. In such instances, the clinician likely reviews this information with the patient at significant clinical encounters. In other cases, this information may need to be entered by the clinician – these preferences should be discussed with your clinical stakeholders as you consider where and how to build out these elements.

Of note, these elements are likely to be capturable in your EMR, specifically if your EMR has oncology specific capabilities. If so, you should begin by evaluating current capture workflows for these elements at your health system and whether they take advantage of these capabilities.

Group

Profile Name

Data Element Name

Patient

ECOG Performance Status

Data Value (Score)

Patient

Karnofsky Performance Status

Data Value (Score)

2.3.3     Cancer Staging Information

Similar to patient performance measures, the capability to discretely capture staging information is likely present in your EMR, especially if your EMR has oncology specific capabilities. You may wish to again begin your evaluation with an assessment of current practices and specifically whether current practices take advantage of these capabilities if they exist.

Group

Profile Name

Data Element Name

Disease

TNM Clinical Stage Group

Data Value (Stage Group)

Disease

TNM Clinical Stage Group

Staging System

Disease

TNM Clinical Primary Tumor Category

Data Value (T Category)

Disease

TNM Clinical Primary Tumor Category

Staging System

Disease

TNM Clinical Regional Nodes Category

Data Value (N Category)

Disease

TNM Clinical Regional Nodes Category

Staging System

Disease

TNM Clinical Distant Metastases Category

Data Value (M Category)

Disease

TNM Clinical Distant Metastases Category

Staging System

Disease

TNM Pathologic Stage Group

Data Value (Stage Group)

Disease

TNM Pathologic Stage Group

Staging System

Disease

TNM Pathologic Primary Tumor Category

Data Value (T Category)

Disease

TNM Pathologic Primary Tumor Category

Staging System

Disease

TNM Pathologic Regional Nodes Category

Data Value (N Category)

Disease

TNM Pathologic Regional Nodes Category

Staging System

Disease

TNM Pathologic Distant Metastases Category

Data Value (M Category)

Disease

TNM Pathologic Distant Metastases Category

Staging System

2.3.4     Cancer Related Procedures

While the ability to capture procedures in discrete fashion is likely present in your system, the ability to connotate that they are cancer related, the treatment intent, and perhaps the target body site may not be discretely captured or may not be captured using the value sets required in mCODE. You should also consider whether your clinical stakeholders currently capture this information in discrete fashion or not.

Group

Profile Name

Data Element Name

Treatment

Cancer Related Radiation Procedure

Code

Treatment

Cancer Related Radiation Procedure

Occurrence Time or Period

Treatment

Cancer Related Radiation Procedure

Target Body Site

Treatment

Cancer Related Radiation Procedure

Treatment Intent

Treatment

Cancer Related Surgical Procedure

Code

Treatment

Cancer Related Surgical Procedure

Occurrence Time or Period

Treatment

Cancer Related Surgical Procedure

Treatment Intent

2.3.5     Medication Order Related Information

While every Certified Electronic Health Record Technology (CEHRT) has the capability to capture medication orders discretely, it is likely that treatment intent and termination reason are not captured. These also have codified value sets in mCODE that should be checked against any existing practices. It’s likely that the best place in your clinical workflow to capture these elements would be the placement and cancellation of the medication order or order set – if that is feasible, consider recommending this to your clinical stakeholders as you discuss the implementation of these elements.

Group

Profile Name

Data Element Name

Treatment

Medication Statement

Termination Reason

Treatment

Medication Statement

Treatment Intent

2.3.6     Patient Outcomes

Cancer disease status has a specific value set and is distinct from the clinical status fields of the primary and secondary cancer conditions. Cancer disease status is a clinician’s overall assessment of the patient’s disease and has a different value set than the primary and secondary cancer disease status. Cancer disease status is expected to be updated at significant clinical encounters and should be placed in the workflow at a point that is routinely updated by clinicians.

It is possible that date of death may be brought into your systems from an external data source, especially if the demise does not occur at your health system.

Group

Profile Name

Data Element Name

Outcome

Cancer Disease Status

Data Value

Outcome

Patient

Date of Death


** Please do not change below this line **

Approved for Public Release: #19-03297-13





  • No labels