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

Profile Conformance

Profile Base

Most mCODE profiles are based on US Core profiles defined in the US Core Implementation Guide (v4.0.1). For example, CancerPatient is based on the US Core Patient profile. Because of the way profiles work in FHIR, any resource that validates against an mCODE profile that is based a US Core profile will automatically be in compliance with the US Core profile.

Where US Core does not provide an appropriate base profile, mCODE profiles FHIR resources. An example is CancerDiseaseStatus, based on Observation because US Core does not provide a profile for non-laboratory observations.

Profile	Based on US Core?	Immediate Parent Profile
Body Structure Identifier	no	Identifier
Cancer Disease Status	no	Observation
Cancer Patient	yes	US Core Patient
Cancer-Related Medication Administration	no	Medication Administration
Cancer-Related Medication Request	yes	US Core Medication Request
Cancer-Related Surgical Procedure	yes	US Core Procedure
Cancer Stage	no	Observation
Comorbidities	no	Observation
ECOG Performance Status	yes	US Core Observation Clinical Test Result
Genomic Region Studied	no	Genomics Reporting IG RegionStudied
Genomics Report	no	Genomics Reporting IG GenomicsReport
Genomic Variant	no	Genomics Reporting IG Variant
Karnofsky Performance Status	yes	US Core Observation Clinical Test Result
mCODE Patient Bundle	no	Bundle
mCODE Patient Group	no	Group
Human Specimen	no	Specimen
Primary Cancer Condition	yes	US Core Condition Problems Health Concerns
Radiotherapy Course Summary	yes	US Core Procedure
Radiotherapy Volume	no	BodyStructure
Secondary Cancer Condition	yes	US Core Condition Problems Health Concerns
TNM Distant Metastases Category	no	Observation
TNM Primary Tumor Category	no	Observation
TNM Regional Nodes Category	no	Observation
TNM Stage Group TNM	no	CancerStage
Tumor	no	BodyStructure
Tumor Marker Test	yes	US Core Laboratory Result Observation
Tumor Size	no	Observation

Profile-Level Conformance Expectations

mCODE expresses requirements and expectations for implementers on the level of entire profiles and individual data elements within those profiles. The conformance rules concerning profiles are as follows:

1. All mCODE profiles that have a top-level Must-Support (MS) flag SHALL be implemented¹.
2. All profiles defined in mCODE SHOULD be implemented 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.
3. The list of implemented profiles SHALL be published in a CapabilityStatement.
4. For each implemented profile, a Data Sender SHALL follow that profile’s conformance statement describing what data SHALL or SHOULD conform to that profile².
5. Support of data elements that reference other profiles MAY require implementers to support additional profiles.
6. A Sender has the responsibility for creating instances that conform to the target profile. All such instances must pass validation against the selected profile.
7. A Receiver SHOULD perform validation on instances it receives. If an instance fails validation, the Receiver MAY reject the instance.

Regarding #7, there are several ways the Receiver can identify the correct profile to use for validation:

• The instance is received in response to a profile search, so the validating profile is known in advance.
• The instance self-identifies an mCODE profile using meta.profile. Every Data Sender SHOULD populate this element.
• The Data Receiver examines the contents of the instance to associate it with a profile. Often, there is an identifying code or category that can be used to associate an instance with a profile.
• The Data Receiver iteratively tries to validate against each of its supported profiles applicable to the instance’s resource type. This is typically a means of last resort.

Element-Level Conformance Expectations

Implementing a Data Element

Implementing an mCODE data element means:

1. A Data Sender SHALL be capable of populating the element, UNLESS the sender does not anticipate supplying or consuming the element, usually by virtue of playing a limited or specialized role in clinical or information workflows.
2. If the element’s minimum cardinality is greater than zero, and the Sender lacks the data necessary to populate the element, then the US Core rules on missing data SHALL be followed.
3. If the element’s minimum cardinality is zero and the Sender lacks the data necessary to populate the element, the element SHOULD be entirely omitted. If there is a specific reason the data is missing, a data absent reason (described in the US Core rules on missing data) MAY be substituted.
4. Senders SHALL NOT substitute nonsense or filler values for missing values.
5. Receivers SHALL be capable of meaningfully processing the element. Depending on context, “meaningful processing” might mean displaying the data element for human use, reacting to it, or storing it for other purposes.

Must-Implement (Versus “Must-Support”)

An implementer SHALL implement certain data elements. These are not necessarily the ones labeled “Must-Support” in the specification. Must-Support elements (marked with the S flag in IG profile pages) do not necessarily need to be implemented, and certain elements that lack MS flags may have to be implemented.

To see which elements have MS flags, consult the “Snapshot Table” or “Snapshot Table (Must-Support)” views of a profile. The “Snapshot Table” view shows all elements, with flags (S) identifying the subset of these elements that are MS. The “Snapshot Table (Must-Support)” view shows only MS elements and therefore does not display MS flags. Note that the “Differential Table” profile view hides MS flags inherited from the parent profile, and is therefore not appropriate for identifying MS elements in a profile.

Outside of data elements that must be implemented, additional data elements MAY be implemented. If a data element is implemented, the profile must be interpreted as if an MS flag were present on that element.

Must-Implement Rules

The following rules determine which data elements must be implemented:

1. Only data elements in implemented profiles (as declared in the Sender or Receiver’s CapabilityStatement) can be Must-Implement (MI). In other words, if a profile is not implemented, then none of the elements of that profile must be implemented, regardless of MS flags³. This rule takes precedence over subsequent rules.
2. A top-level element with an MS flag SHALL be implemented.
3. A nested element (at the second-level or below) with MS flag whose parents all are implemented SHALL be implemented. Note that this includes parent elements that have been implemented electively.
4. An element whose cardinality is 0..0 does NOT need to be implemented, regardless of MS flag⁴.
5. For Data Senders, a required element SHALL be implemented, regardless of whether that element has an MS flag. This is because Data Senders must populate required elements.
6. For Data Receivers, a required element without an MS flag does NOT have to be implemented⁵. This is because Receivers have the option of ignoring an element passed to them if they have elected to not support that element.

More complex cases involving references, sliced arrays, and choice types are outlined in the Must-Implement Summary.

Definition of “Required”

An mCODE data element is required if any of the following criteria are met:

• The element is a top-level element (a first-level property of the resource) and its minimum cardinality is > 0 in the profile.
• The element not a top-level element (a second-level property or below), its minimum cardinality is > 0, and all elements directly containing that element have minimum cardinality > 0 in the profile.

In terms of instances, if profile P has an optional element A whose child element B has minimum cardinality > 0, then any instance where element A is present will only conform to P if element B is present.

Must-Implement Summary

The following table summarizes how Must-Implement (MI) requirements derive from Must-Support (MS) flags. For the sake of completeness, this table covers certain cases not seen in mCODE.

#	MS-Flagged Element	Data Sender (Server) Must Implement?	Data Receiver (Client) Must Implement?	Example
1	Top level element, or nested element whose parents are all MS	Yes	Yes	CancerDiseaseStatus.focus or CancerRelatedMedicationRequest.dosageInstruction.text
2	Element is a nested (child) element and there is no MS flag on its parent element	MI only if the Sender elects to implement the parent element	MI only if the Receiver elects to implement the parent element	US Core Patient version 3.2 Patient.telecom.system
3	Element is a complex data type (such as CodeableConcept) with no MS flag on any immediate sub-element	MI at least one sub-element, and SHOULD implement every sub-element for which the server might possess data	MI every sub-element (since the Receiver cannot anticipate which sub-elements might be populated)	PrimaryCancerCondition.code
4	Element is a complex data type with an MS flag on one or more immediate sub-elements	MI only the sub-elements that are explicitly flagged	same	CancerPatient.name
5	Element is a choice [x] type with no MS flag on any choice	MI at least one datatype choice, and SHOULD implement every datatype for which the server might possess data	MI all datatype choices (since the Receiver cannot anticipate which sub-elements might be populated)	CancerPatient.deceased[x]
6	Element is a choice [x] type with an MS flag on one or more choice	MI only on the datatype choice(s) that are explicitly flagged	same	US Core Laboratory Result Observation Profile version 3.2 Observation.value[x]
7	Element is a Reference() data type with no MS flag on any referenced resource or profile	MI all resources or profiles in the reference that are in Sender’s capability statement	MI all resources or profiles in the reference unless they are outside the scope of the Receiver’s capability statement	Tumor.extension[mcode-related-condition].value[x]
8	Element is a Reference() data type with an MS flag on one or more of the referenced types	MI only on the resources or profiles in the reference that are explicitly MS-flagged, and only if they are in the Sender’s capability statement	MI only on the resources or profiles in the reference that are explicitly MS-flagged, and only if they are in the Receiver’s capability statement	US Core DocumentReference Profile version 3.2 DocumentReference.author
9	Element is a backbone data type	No implementation requirement on sub-elements unless they are explicitly MS-flagged	same	SDC QuestionnaireResponse.item (subelement QuestionResponse.item.definition is not MS)
10	Element is an array that is sliced, with no MS flag on any slice	SHALL be able to populate the array, but no implementation requirement any particular slice	MI array and its contents, including any or all defined slices.
11	Element is an array that is sliced, with MS flags on one or more slices	MI only on the slices that have MS flags	same	TNMStageGroup.hasMember
12	Element that has MS flag is a slice and the containing array does not have an MS flag	No implementation requirement on the slice	same	US Core Patient Profile version 3.1.1 Patient.extension:us-core-race (because Patient.extension is not MS)

Footnotes: