minimal Common Oncology Data Elements (mCODE) Implementation Guide
3.0.0 - STU3 Release
minimal Common Oncology Data Elements (mCODE) Implementation Guide
3.0.0 - STU3 Release
This page is part of the HL7 FHIR Implementation Guide: minimal Common Oncology Data Elements (mCODE) Release 1 - US Realm | STU1 (v3.0.0: STU 3) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
The following changes occurred between the [STU 3 ballot (March 2023)] and publication of STU 3, in response to ballot comments.
SNOMED CT can declare concepts inactive if they are duplicate, ambiguous, erroneous, or outdated. Several SNOMED CT codes used in mCODE STU 2 became inactive and had to be replaced for STU 3:
mCODE 2.1 and 3.0.0-ballot did not include any profiles for non-TNM staging, so there was no indication on how to use mCODE to represent staging for lymphoma and leukemia, for example. To address this issue, several non-TNM staging profiles were added. Given the numerous non-TNM staging systems, a set of profiles were added for illustrative purposes:
Recurrences and unrelated cancers sometimes occur years after previous metastatic disease, for example, in the case of an adult with history of childhood leukemia. The details of the previous disease may be unavailable, but the fact that the patient had cancer previously may be clinically significant. The profile HistoryOfMetastaticCancer provides a method of recording this fact in the absence of other details. This addition brings mCODE and CMS’s Enhancing Oncology Model into full alignment.
Additional stage type identifiers and staging methods were added to CancerStageTypeVS and CancerStagingMethodVS. These are values that could potentially be used in the future and inclusions or exclusions do not affect the immediately functionality of mCODE. Codes associated with pediatric cancers were moved out of mCODE in anticipation of an IG focused on pediatric cancer. Certain codes requested from SNOMED were added. Again, since the bindings of these values sets are extensible, inclusion or exclusion of particular values does not affect functionality.
An explanation of how Observation.code differs from (and sometimes subsumes) Observation.method in CancerStage and its descendants was added.
In CancerPatient, birth sex (an extension inherited from US Core), is now designated as must-support.
mCODE is moving incrementally toward SNOMED CT as the preferred, standard vocabulary (except for identification of laboratory tests and a few other cases). While still accepting LOINC codes in Observations related to TNM staging, SNOMED CT codes are now preferred. Users should transition towards SNOMED CT in these profiles.
A code representing the detection of metastases has been added, for when disease status changes from local disease to metastatic disease. The two disorder codes for partial and full remission, formerly from the SNOMED CT disorder hierarchy, have been replaced with analogous codes from the qualifier value hierarchy. This change was based on SNOMED guidance that the value of FHIR Observations should be a code from the qualifier hierarchy or finding hierarchy (see https://confluence.ihtsdotools.org/display/FHIR/Observation+binding). To assure backward compatibility with this change, the two deprecated disorder codes have been moved into a maximum value set, while the binding of the revised value set is now preferred. This gives implementers time to transition to the new codes for partial and full remission, since the old disorder codes are still accepted (but not preferred).
In the ballot version, approximately 20 new examples involving genomics and next generation sequencing (NGS) we added. To increase the visibility of these examples, a new page listing all these examples in one place was added.
An mCODE user pointed out that the TreatmentTerminationReason extension was unnecessary, because FHIR natively includes a statusReason element that is meant to explain the current status of procedures and medication actions (requests and administrations). When status = “stopped” the statusReason provides the termination reason. Extensions should be avoided when n+ative FHIR elements provide the same functionality. Therefore, the TreatmentTerminationReason extension has been deprecated, and henceforth users should populate the statusReason field with the values from TreatmentTerminationReasonVS. Two additional values were added to the termination reason value set, representing termination due to pregnancy and termination due to conclusion of the clinical trial.
The binding strength of Condition.stage.type in the PrimaryCancerCondition profile has been relaxed to extensible, since it is unreasonable to expect that the CancerStagingMethodVS valueset will encompass all possible staging methods.
HL7 specifications use RFC 2119 keywords to indicate conformance requirement levels. In RFC 2119, the words MUST, REQUIRED, and SHALL are synonymous. The mCODE specification has always used MUST and SHALL interchangeably. Even though this is 100% acceptable within RFC 2119, FHIR specifications generally prefer the word SHALL, so the specification was changed to follow this precedent.
—-
The following changes occurred between STU 2 publication (January 2022) and the STU 3 ballot (March 2023). For a history of previous changes, please see the prior change logs in the appropriate versions.
mCODE STU 3 accepts SNOMED equivalents of AJCC codes, in addition to AJCC codes as in STU 2. This provides maximum interoperability across AJCC licensed and unlicensed systems, but does not break existing applications.
Based on a new licensing agreement between SNOMED International and the American College of Surgeons, SNOMED CT now contains equivalents of AJCC staging codes. For example, SNOMED CT concept 1229967007 represents AJCC’s cN0 category. To be clear, a clinician would never see the SNOMED codes. The user interface would work with the familiar AJCC staging codes, whil the SNOMED equivalents would exist only in the back-end system.
Due to copyright restrictions still in effect, specific AJCC codes cannot be enumerated in HL7 standards. Because of this restriction, staging value sets were only vaguely defined in mCODE STU 2. In STU 3, however, mCODE has taken advantage of the new licensing agreement by redefining the staging value sets in terms of SNOMED CT’s AJCC-equivalent codes, allowing specific enumeration of codes in staging-related profiles. The following value sets are now defined in terms of SNOMED CT:
This change addresses the issue https://jira.hl7.org/browse/FHIR-37593.
The binding strength for these value sets remains “preferred”, meaning that the SNOMED codes are not required. However, any alternative codes SHALL be AJCC codes. This has been implemented through addition of maximum value sets to the bindings. The maximum value sets are:
Previously, the CancerStage profile contained optional elements specific to TNM staging. This was confusing because CancerStage was intended also for non-TNM staging. To avoid this ambiguity, CancerStage no longer contains the optional TNM-specific content. A separate child profile, TNMStageGroup, has been added as a template for TNM-specific staging. This change is backward compatible, since any resource complying with the STU 2 version (named CancerStageGroup) will comply with STU 3 CancerStage, and every resource complying to TNMStageGroup automatically complies to CancerStage.
To support the separation of TNMStageGroup from more generic CancerStage profile, several value sets were renamed. In FHIR, renaming value sets has little or no impact on implementations, since value set names and ids are not used in information exchanges (although they are involved in validation algorithms). The following value sets were renamed for clarity:
Observation.method.In addition, the following new value sets are now associated with the parent profile, CancerStage:
Observation.code element in the CancerStage profile. The value set contains LOINC, SNOMED, and NCI Thesaurus terms that represent staging observables, such as “clinical M stage” or “FIGO ovarian tumor stage”. These values identify what is being reported in Observation’s value element.Observation.valueCodeableConcept element in the CancerStage profile. Because there are numerous possible staging values across all staging systems, this value set is only a brief sampling, presented as an example.Based on user feedback on the complexity of the STU 2 design, comorbidities have been redesigned into a more compact, practical form. As a full redesign, this change is not backward compatible.
is-a operator was replaced with the descendant-of operator, removing the top-level code when it was not a valid choice.Based on user feedback that the required bindings on certain fields were a barrier to broader implementation the following changes were made:
This value set has been expanded to include a code indicating that the patient’s cancer has metastasized. The disorder codes for full and partial remission have also been replaced with qualifier codes.
mCODE has been updated to the current version of US Core, STU 5. Because there are new profiles in STU 5 that should be used as parent profiles, some mCODE profiles were affected. In particular, the parent profiles of KarnofskyPerformanceStatus and ECOGPerformanceStatus were switched from Observation to the newly-introduced US Core Observation Clinical Test Result Profile. Secondly, the parent profiles of PrimaryCancerCondition and SecondaryCancerCondition were switched to [US Core Condition Problems and Health Concerns Profile]. This change is not backward compatible.
As a result, there are new required values for Condition.category or Observation.category:
In KarnofskyPerformanceStatus and ECOGPerformanceStatus , the category “clinical-test” is required.
As an example of how to assign a category, the JSON for a primary cancer condition must now include:
"category" : [
{
"coding" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/condition-category",
"code" : "problem-list-item"
}
]
}
]
mCODE is now is explicitly dependent on the Genomics Reporting IG STU2 (v2.0.0) (GRIG). This eliminates the duplication of profiles that existed in STU 1 and STU 2, and assures that the two IGs remain in synchronization. The following changes were made:
The mCODE bundle definition now slices on resource type, rather than profile. Slicing logic was changed because, in some cases, instances could not be assigned unambiguously to a slice, causing the FHIR validator to output errors. With this change, the assignment to a slice will always be unambiguous. This change has no effect on the contents or use of the mCODE bundle.
To enable more complete reporting of patient history, a new Observation profile for recording a patient’s cancer history was added. This profile has an optional Boolean value. If the value is false, it indicates an assertion of absence of a history of metastatic cancer. If the value is true or absent it indicates a history of metastatic cancer. HistoryOfMetastaticCancer. If there is no instance of an Observation of this type, and there is no instance of a SecondaryCancerCondition, then there is no evidence for or against a past or present metastatic cancer.
Maturity indicators, based on the FHIR Maturity Model (FMM) have been added to profiles and value sets. These indicators show up in the IG but have no functional affect on implementations.
Radiotherapy subject matter experts requested a way to link CancerDiseaseStatus to a RadiotherapyVolume through the Observation.focus element. This broadens the choices of STU2, which were Reference(PrimaryCancerCondition or SecondaryCancerCondition or Tumor) and are now Reference(PrimaryCancerCondition or SecondaryCancerCondition or Tumor or RadiotherapyVolume). This allows a change in disease status to point to a specific area of the body, not just a specific Tumor or condition.
Users requested a link between TumorMarkerTest and the condition the test is related to. Optional RelatedCondition extension was added to TumorMarkerTest. See https://chat.fhir.org/#narrow/stream/229074-CodeX/topic/Reference.20between.20tumor.20characteristics.20and.20cancer.20diagnosis
A specimen is a specimen. There was no real reason to distinguish specimens obtained for genomic analysis from those obtained for other uses. A single profile, HumanSpecimen, was created to represent any specimen from a human subject. Since this profile is no longer associated with a single domain (Disease or Genomics), specimens were added to the Patient domain. The values for specimen type are a subset of codes representing human-sourced specimens (fluids, tissues, etc.) from http://terminology.hl7.org/CodeSystem/v2-0487.
stage.type value set binding was corrected. It should have indicated the staging method that gave rise to the value appearing in stage.summary (such as AJCC Version 8).
____________
The change log for changes prior to mCODE version 2.1 continues here
IG © 2019+ HL7 International / Clinical Interoperability Council. Package hl7.fhir.us.mcode#3.0.0 based on FHIR 4.0.1. Generated 2023-10-25
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change