Condition, diagnosis, or reason for seeking medical attention.

Data Element
Condition Status
Description

Disease trend, also referred to as disease status, represents the clinician's overall judgment on the current trend of a condition, e.g., whether it is stable, worsening (progressing), or improving (responding). The judgment may be based a single type or multiple kinds of evidence, such as imaging data, physical examination, tumor measurements, laboratory data, etc. The condition trend can be reported multiple times during the course of a condition, each report representing the clinical judgement at that point in time. The element is important in assessing disease progression and determining the efficacy of treatments.
Submitted By: Andre Quina / MITRE
Data Element Information
Data Element Description Disease trend, also referred to as disease status, represents the clinician's overall judgment on the current trend of a condition, e.g., whether it is stable, worsening (progressing), or improving (responding). The judgment may be based a single type or multiple kinds of evidence, such as imaging data, physical examination, tumor measurements, laboratory data, etc. The condition trend can be reported multiple times during the course of a condition, each report representing the clinical judgement at that point in time. The element is important in assessing disease progression and determining the efficacy of treatments.
Use Case Description(s)
Use Case Description Practitioner doing disease assessment and creating a plan of treatment (the A and P in SOAP) may leverage disease staging as a way to link to standards of care.

CMMI is also requiring the collection of certain specific “clinical data elements” (CDEs) from participants in the mandatory Radiation Oncology (RO) model scheduled to begin in January 2021, and has issued an informal RFI soliciting public comment on the draft CDEs. Staging is one of the proposed CDEs required for reporting in the RO model. See: https://innovation.cms.gov/media/document/ro-clin-data-elements-rfi-v2

Event for its collection and use: Staging is determined and recorded after diagnosis. Often staging is determined through a use of a variety of diagnostic tests. The results of those tests inform the disease stage. While disease staging is used to inform the treatment of many diseases such as Alzheimer’s and heart failure, it is most common in cancer treatment. In cancer treatment staging is used to describe the size of the tumor (in the case of solid tumors), location of a cancer, and if or where the cancer has spread. Staging is used to cluster clinically homogenous patients to inform treatment options, to establish cohorts of patients for research, and for cancer control purposes when comparting populations to assess outcomes or natural history (e.g., in a population-based cancer registry).

Frequency of use: While not all diseases or all cancers are staged, staging is a critical element for cancer care. For cancers that are staged, the frequency of use is near universal.

Broader collection and use: For cancers that are staged, staging information is foundational to understanding the extent and characteristics of the cancer. Staging can help to inform viable treatment options and predict the course a cancer will take and how likely treatments are to be successful. Staging information is relevant to nearly all Health IT systems supporting cancer patient care and public health. As a result, staging information is relevant to nearly all cancer related use cases for cancers that are staged and would be exchanged across all involved systems.

Estimate the breadth of applicability of the use case(s) for this data element Staging can be considered a core element associated with the Problem domain as a way to communicate the extent and seriousness of the disease. In this context usage would extend to most practitioners using a certified EHR, which is the majority of physicians in the US.

Specifically for cancer roughly 1.8M people in the US will be newly diagnosed with cancer in 2020. There are approximately 13,000 oncologists practicing in the US. Staging is critical for all of those patients and oncologists for cancers that are staged.
Use Case Description The trend of the disease can indicate the effectiveness of treatments. Disease trend provides an indication of patient outcome that is amenable for collection as part of routine care. Disease trend is being evaluated as part of the ICAREdataTM project focused on cancer. The overall goal of the ICAREdata project is to enable clinical oncology research by prospectively gathering high quality real-world data (RWD). The ICAREdataTM project is a collaboration between The MITRE Corporation and the Alliance for Clinical Trials in Oncology and is being conducted in association with randomized controlled trials (RCTs) and National Cancer Trial Network (NCTN) institutions. As a pilot use case for the mCODE (Minimal Common Oncology Data Elements) standard, the study is evaluating disease trend among other outcome elements of mCODE and to demonstrate a real-world data strategy for clinical trials. As part of the study, an open source infrastructure and automated standards-based interface for data capture and exchange are being developed and piloted.

Disease trend is a clinician’s qualitative judgment on the current trend of the cancer, e.g., whether it is stable, worsening (progressing), or improving (responding). The judgment may be based a single type or multiple kinds of evidence, such as imaging data, assessment of symptoms, tumor markers, laboratory data, etc. Through the ICAREdata study disease trend is being collected in the EHR for patients that are currently enrolled in a clinical trial that incorporates the ICAREdata protocol (currently 3 trials). The goal of the ICAREdata study is to demonstrate a correspondence between disease trend and traditional evaluations of tumor response used in cancer clinical trials (e.g., RECIST criteria). This would provide a validated measure of patient outcome in the EHR that would advance the use of real world data in support of post market surveillance, clinical trial design, observational studies, and clinical trial execution.

Event for its collection and use: Disease trend is collected at every patient encounter.

Frequency of use: Disease trend provides a critical patient outcome in structured form. Availability of structured patient outcome data is extremely limited, particularly for cancer patients. Disease trend represents the oncologist’s evaluation of the current response of the cancer to treatment. As such, disease trend is often the basis for many of the decisions around the current or future course of treatment.

Broader collection and use: With the current limited availability of structured patient outcomes it is extremely difficult to develop analytics to evaluate the safety and efficacy of approved therapies in real world populations. The broad availability and exchange of disease trend would accelerate the applicability of real world data across a broad variety of use cases.
Estimate the breadth of applicability of the use case(s) for this data element While particularly applicable to cancer, disease trend is relevant to all conditions. As a core element associated with the Problem domain, usage of disease trend would extend to most practitioners using a certified EHR, which is the majority of physicians in the US.

See:
http://icaredata.org
https://confluence.hl7.org/display/COD/EHR+Endpoints+for+Cancer+Clinical+Trials
https://www.cdc.gov/cancer/dcpc/data/index.htm
https://www.asco.org/research-guidelines/reports-studies/state-cancer-care
Healthcare Aims
  • Improving the health of populations
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) HL7 FHIR Implementation Guide: minimal Common Oncology Data Elements (mCODE) Release 1 - US Realm | STU1
http://hl7.org/fhir/us/mcode/
Additional Specifications HL7 FHIR Implementation Guide: minimal Common Oncology Data Elements (mCODE) Release 1 - US Realm | STU1

http://hl7.org/fhir/us/mcode/
Current Use Extensively used in production environments
Supporting Artifacts Staging information for cancer is collected in most EHR systems. For cancer the representation of staging is standardized. Staging is widely exchanged using APIs however many of those APIs are not broadly standardized. The standard exchange of staging information using FHIR based implementation guides is still limited but is progressing.

Disease trend is currently often only collected in unstructured notes. Through the ICAREdata study disease trend is being collected at an increasing number of health systems (currently 5 health systems) and has been implemented by Epic.
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts Staging information is frequently exchanged across a variety of use cases and settings.

Through the ICAREdata study disease trebd is being collected at an increasing number of health systems (currently 5 health systems). Disease trend and staging are being exchanged between those health systems and the Alliance for Clinical Trials in Oncology using FHIR APIs for analysis against clinical trial data.

https://confluence.hl7.org/display/COD/EHR+Endpoints+for+Cancer+Clinical+Trials, https://confluence.hl7.org/display/COD/EECT+Supporting+Materials
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) AJCC codes frequently used for cancer staging are proprietary

There are no restrictions on disease trend
Restrictions on Use (e.g. licensing, user fees) None
Privacy and Security Concerns This data falls under general HIPAA regulations
Estimate of Overall Burden How hard is it to access and provide the data?
Since staging and disease trend are routine evaluations for cancer the only additional burden is in the structured collection where that is not already part of standard workflows. The applicability of staging will vary by specialty.

Is it only available in an outside system, such as a lab reporting system?
No.

Does it need to be calculated by the patient or provider, or can it be automatically retrieved or calculated by the system in a production environment?
Both staging and disease trend are assessed by the clinician.

Does it require significant time on the part of patient or provider to access or record or does it require an interruption in normal workflow to capture?
Both staging and disease trend are routine evaluations for cancer. The applicability of staging will vary by specialty.

Does it require significant developer time to implement in EHR systems?
Epic is in the process of implementing mCODE data elements for the problem domain focused on disease trend. Given the minimal complexity for representing disease trend, implementation has been relatively low burden. Disease staging has variable complexity and use across different specialties leading to a higher implementation burden. However, most EHRs are already capable of recording staging for cancer.
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.

Comment

Submitted by csnewman on

Clarify status meaning

In the description of Condition Status, the use of the wording "presents or manifests" is odd for a status. This evokes more of a phenotypic description (rash, etc) than a status. Perhaps alignment with the definition of Immunization Status and/or Procedure Status could be considered.

Submitted by suchen on

This data element has…

This data element has support from the HL7® FHIR® CodeX™ Accelerator community. CodeX supported FHIR data standards for cancer, genomics and cardiovascular health have a rapidly growing footprint of traction and adoption. The CodeX community is rapidly growing its membership, with invested Member leaders driving implementation-focused use case pilots forward.

The Disease Trend data element-related exchange is utilized in the CodeX EHR Endpoints for Cancer Clinical Trials Use Case by leveraging the minimal Common Oncology Data Elements (mCODE) Implementation Guide. Pertinent links for mCODE, and mCODE’s real world adoption and traction include:

This data element is important to the CodeX “ICAREdata” Use Case: EHR Endpoints for Cancer Clinical Trials: https://confluence.hl7.org/display/COD/EHR+Endpoints+for+Cancer+Clinical+Trials

This use case aims to capture high quality clinical treatment data in electronic health records (EHRs) to enable oncology research. There are 5 key partners, including government, research, and industry, involved in the use case. This prospective use case pilot is currently active at 7 health sites as part of 11 clinical trials.

This data element is also referenced to by the CMS’s Enhancing Oncology Model (EOM), which leverages mCODE for data submissions to CMS. The USCDI Disease Trend data element correlates to the “Current Clinical Status Trend” noted in EOM.

Submitted by suchen on

Note that the disease trend…

Note that the disease trend/status is a required part of CPT Evaluation and Management (E/M) guidelines required for clinical documentation for new and established office patients. These guidelines were updated by the American Medical Association (AMA) and Centers for Medicare & Medicaid Services (CMS) and went into effect on January 1, 2021.

Patient disease status/trend is required for determining complexity of medical decision-making (MDM) for a given patient encounter. For example, when assessing the nature and number of clinical problems, some of the ways clinicians are asked to categorize disease processes are:

  • Self-limited or minor
  • Established problem, stable or improved
  • Established problem, worsening
  • New problem, no additional work-up planned
  • New problem, additional work-up planned

............

This submission is made on behalf of CodeX (Common Oncology Data Elements eXtensions), a member-driven HL7 FHIR Accelerator community of professional medical societies, health systems, industry and others seeking to achieve interoperability via the mCODE (minimal Common Oncology Data Elements) standard in order to drive step-change improvements in cancer patient care and research.

https://confluence.hl7.org/display/COD/CodeX+Home

Log in or register to post comments

FormGuide

Help

1. Optional: Background Text / Cover Letter

The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.

If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.

If you are only commenting on a single data class or element, you may leave this field blank.

2. Select the Data Class

To specify which data class your comment addresses:

  1. In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
  2. If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
  3. Note that the Data Class field will automatically populate based on your current location in the platform:
    1. If you are on a data class page, the field will be set to that specific data class
    2. If you are on a data element page, the corresponding data class will be pre-selected
       

3. Select the Data Element

To specify which data element your comment addresses:

  1. In the "Data Element" drop-down menu, select the specific data element you want to comment on.
  2. The drop-down menu will display only the elements available under the data class you selected in the previous step.
  3. You can use the search function within the drop-down to quickly locate a specific data element.
  4. If you are commenting on the data class itself rather than a specific element, you may leave this field blank.

Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.
 

Data Class and Data Element

Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.

4. Optional: Propose New Data Class or Element

If you cannot find the appropriate data class or element for your comment:

  1. Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
  2. This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
  3. In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
  4. Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Propose New Data Class or Element

Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.

5. Complete the Comment Form

Fill out the required fields in the comment form:

Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.

Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.

6. Optional: Add Additional Comments

If you need to comment on multiple data classes or elements:

  1. After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
  2. A new comment section will appear, allowing you to enter details for your additional comment.
  3. For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
  4. Complete the Subject and Comment fields for your additional comment.
  5. Repeat this process for each additional comment you wish to submit.

Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.

7. Optional: Upload Supporting Files

The platform allows you to upload supporting documentation to enhance your comment:

  • Locate the "File Upload" section at the bottom of the comment form.
  • Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.

Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.

Upload Supporting Files

Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.

8. Optional: Save and Exit

If you need to pause your work and return to complete your comment later:

  1. Click the "Save and Exit" button at the bottom of the form.
  2. Your comment will be saved as a draft that you can access and complete later.
  3. When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
  4. Click this button to continue working on your draft.
  5. You will be taken to a review page where you can:
    1. Select "Submit Comment" to officially submit your feedback.
    2. Click "Edit" to return to the comment form and make changes
    3. Select "Discard Draft" to delete the saved draft and start fresh

Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.

9. Review and Submit

Once you have completed your comment:

  1. Click the "Review and Submit" button at the bottom of the form.
  2. This will take you to a review screen displaying your comment(s) in full.
  3. Review all information for accuracy and completeness.
  4. On this review screen, you have three options: 
    1. Click "Submit Comment" to officially submit your feedback
    2. Click "Edit" to return to the comment form and make changes
    3. Click "Discard Draft" to delete the comment and start fresh
  5. The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records. 
  6. If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Review and Submit

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

USCDI Comments

Close

Add a New Comment

Review comment and Submit

Edit
Comment #1