minimal Common Oncology Data Elements (mCODE) Implementation Guide, published by HL7 International / Clinical Interoperability Council. This guide is not an authorized publication; it is the continuous build for version 4.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-mCODE-ig/ and changes regularly. See the Directory of published versions
This section outlines requirements and recommendations for mCODE participants. The conformance verbs - SHALL, SHOULD, and MAY - are defined in FHIR Conformance Rules. MUST, MUST NOT, SHALL NOT, and REQUIRED are to be interpreted as described in RFC 2119.
Two roles for mCODE Participants are defined:
This IG currently only provides CapabilityStatements and documentation for "pull" (query-response) architectures, however, regardless how exchanges occur, all participants SHALL follow the conformance requirements in this IG, except those specifically identified as applying only to pull architectures.
mCODE participants SHALL meet the following requirements for conformance:
To facilitate conformance testing, testing software must be able to determine which patients are "in-scope" (meaning cancer patients whose data is presented or exchanged with the intention of conforming to mCODE). In general, all patients with confirmed cancer diagnoses SHOULD be covered by mCODE, but mCODE provides several ways to identify this group of in-scope patients. See the Identifying In-Scope Patients page for details.
The information produced and consumed by mCODE participants is defined by a set of profiles. Both Senders and Receivers must conform to the expectations set by these profiles. See the Profile Conformance page for details.
mCODE Senders MUST be able to populate data elements Must-Support (MS) obligations, for all profiles they support (as declared in their CapabilityStatement). Receivers MUST be able to meaningfully process elements with MS obligations for each of the profiles they support (as declared in their CapabilityStatement). "Able to Populate" and "Meaningfully Process" have particular meanings, as discussed on the Profile Conformance page.
mCODE defines operations that Senders and Receivers use to exchange mCODE information. In a "pull" (query-response) architecture, Senders SHALL support the requests below for retrieving all resources conforming to a given mCODE Profile, UNLESS they do not support the profile at all (see "Support All mCODE Profiles" below). For more details on the conformance requirements for Senders and Receivers, see Profile Conformance.
Note that the requests below may return resources associated with patients who are not in-scope patients. These resources MAY not conform to mCODE profiles.
GET [base]/Specimen?type=http://terminology.hl7.org/CodeSystem/v2-0487|TUMOR
(note that TUMOR
must be capitalized)GET [base]/Condition?category=http://snomed.info/sct|372087000
(preferred form)GET [base]/Condition?code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-primary-or-uncertain-behavior-cancer-disorder-vs
(alternate form)GET [base]/Condition?category=http://snomed.info/sct|128462008
(preferred form)GET [base]/Condition?code:in=http://hl7.org/fhir/us/mcode/ValueSet/CancerStageTypeVS
(alternate form)GET [base]/Observation?category= http://snomed.info/sct|385356007
(preferred form)GET [base]/Observation?code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-cancer-stage-type-vs
(alternate form)GET [base]/Observation?category=http://snomed.info/sct|250724005
(preferred form)GET [base]/Observation?code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-tumor-marker-test-vs
(alternate form)GET [base]/Observation?code=http://snomed.info/sct|398192003
GET [base]/Observation?code=http://loinc.org|89247-1
GET [base]/Observation?code=http://loinc.org|89243-0
GET [base]/Observation?category=vital-signs
GET [base]/DiagnosticReport?category=LAB
(note that LAB
must be capitalized)GET [base]/Observation?category=laboratory
GET [base]/Observation?code=http://loinc.org|69548-6
specimen
element in resources conforming to GenomicVariant or GenomicsReportGET [base]/DiagnosticReport?code=http://loinc.org|81247-9
GET [base]/Observation?code=http://loinc.org|53041-0
reasonCode
element, and/or (2) a reference to a resource conforming to PrimaryCancerCondition or SecondaryCancerCondition in the reasonReference
element. Because these elements are not required, these criteria may not identify all conforming resources.GET [base]/Procedure?code=http://snomed.info/sct|387713003
will identify all surgical procedures. Procedure.code
is extensibly bound to CancerRelatedSurgicalProcedureVS, so further filtering to include only Procedures with code
in this value set will identify some but not necessarily all cancer-related surgical procedures.GET [base]/Procedure?code=mcode-radiotherapy-course-summary
GET [base]/Observation?code=http://loinc.org|88040-1
BodyStructure.morphology
is fixed to http://snomed.info/sct|367651003
, but this is not a required element. This may therefore be used to identify some but not all BodyStructure resources conforming to this profile.GET [base]/Observation?code=http://loinc.org|21889-1
Each mCODE participant SHALL publish a FHIR CapabilityStatement listing their supported profiles, by declaring the profile in CapabilityStatement.rest.resource.supportedProfile
. The CapabilityStatement SHALL be returned in response to a GET [base]/metadata
request.
ALL mCODE participants SHALL at minimum support the CancerPatient and PrimaryCancerCondition profiles.
Additional conformance requirements from US Core apply to RESTful interactions, searches, and resource formats in mCODE. mCODE "inherits" all US Core conformance requirements. US Core provides base profiles for many (but not all) mCODE profiles, outlines expectations for handling of missing or unknown data elements, and outlines how to associate provenance information associated with collection, transfer, and updating clinical information.
International users of mCODE may find US Core an impediment to implementation. Application of mCODE to other countries is open to further discussion.
mCODE participants SHOULD meet the following requirements for conformance:
In addition to supporting the core profiles as described above, mCODE participants SHOULD support all profiles defined in mCODE UNLESS the participant does not anticipate supplying or consuming a certain type of data, usually by virtue of playing a limited or specialized role in clinical or information workflows. For example, a genomics laboratory may support GenomicsReport, but not vital signs or staging.
Participants SHOULD also support the non-mCODE-specific profiles that are considered part of an mCODE Patient Bundle, such as blood pressure.
The mCODE Patient Bundle provides a mechanism to retrieve cancer-related resources for an in-scope Patient. Participants SHOULD support this CapabilityStatement (sender/receiver) for the mcode-patient-everything operation, which retrieves an mCODE Patient Bundle for a given Patient ID.
GET [base]/Patient/[id]/$mcode-everything
This endpoint SHALL support start
and end
parameters and MAY support the _since
, _type
, and _count
parameters, which operate the same as in the Patient/[id]/$everything
operation. The _since parameter is provided to support periodic queries to obtain additional information that has changed about the patient since the last query.
For some types of resources, such as vital signs, a large number of resources may exist. Senders may use their discretion to select the resources that are most relevant, e.g., a subset of the vital signs that were recorded. Alternatively, servers may refuse to serve the request and indicate that the client asked for too much data (see OperationOutcome). To limit the number of included resources, callers MAY specify a _count
parameter that pages through the results.
mCODE Patient Bundles SHALL be identified by an id
value that matches the id
in the contained CancerPatient-conforming resource.
meta.profile
to Signal ConformanceParticipants SHOULD populate meta.profile
elements for all resources to indicate which profiles the resources claim to conform to. Servers SHOULD also implement profile search, which allows participants to query using the _profile
parameter to return resources conforming to the profiles declared in meta.profile
.
Profile search and population of meta.profile
originate as "SHALL" requirements in the base FHIR specification; they are not additional requirements imposed by mCODE. However, in practice, few implementations have followed these requirements. Refer to the FHIR Documentation on supported profiles for details.