minimal Common Oncology Data Elements (mCODE) Implementation Guide
3.0.0-ballot - 2023May
minimal Common Oncology Data Elements (mCODE) Implementation Guide
3.0.0-ballot - 2023May
This page is part of the HL7 FHIR Implementation Guide: minimal Common Oncology Data Elements (mCODE) Release 1 - US Realm | STU1 (v3.0.0-ballot: STU 3 Ballot 1) based on FHIR R4. The current version which supercedes this version is 2.1.0. For a full list of available versions, see the Directory of published versions 
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 MUST be AJCC codes. This has been implemented through addition of maximum value sets to the bindings. The maximum value sets are:
Previously, the CancerStageGroup profile contained optional elements specific to TNM staging. This was misleading because CancerStageGroup could be used for non-TNM staging. To avoid this ambiguity, CancerStageGroup 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 of CancerStageGroup will comply with STU 3 CancerStageGroup, and every resource complying to TNMStageGroup automatically complies to CancerStageGroup.
To support the separation of TNMStageGroup from more generic CancerStageGroup profile, several value sets were renamed. In FHIR, renaming value sets has little or no impact on implementations, since value set names are not directly used in information exchanges. The following TNM value sets were renamed for clarity:
In addition, the following value sets are now associated with the non-TNM CancerStageGroup profile:
Observation.method.Observation.code element in the CancerStageGroup profile.Observation.valueCodeableConcept element in the CancerStageGroup profile.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.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 unambigously 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.
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.
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).
IG © 2019+ HL7 International Clinical Interoperability Council. Package hl7.fhir.us.mcode#3.0.0-ballot based on FHIR 4.0.1. Generated 2023-03-28
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change