Implementation Notes

This page contains miscellaneous information on modeling and FHIR implementation. The content is primarily directed at informaticists and implementers of mCODE. The following topics are addressed:

• Conformance Requirements
• Terminology Preferences
• Patient
• Body Locations
• Vital Sign Profiles
• Laboratory Profiles
• Representing Provenance of mCODE Information

Conformance Requirements

Relationship to US Core

With one exception (see below), the profiles presented in this guide conform to US Core Implementation Guide (v3.1.0). Each mCODE Profile uses a corresponding US Core profiles as its base profile, and thus, cannot break the rules established by that profile in US Core. For example, if US Core has a required element, by virtue of profile inheritance, mCODE cannot make that element optional. However, it is not true that any instance that conforms to an mCODE profile will automatically conform to US Core. In particular, the use of extensible value sets requires caution. Extensibility is only allowed when an appropriate concept is not available in the US Core value set. Please note:

• In mCODE Comorbid Conditions, SNOMED-CT is recommended for conformance to the 2015 Certification Rule, however as of US Core v3.1.0, it is possible to also use ICD-10-CM as a primary condition code.
• In mCODE Procedures, if an ICD-10-PCS code is used, and a semantically equivalent SNOMED CT or CPT code is available, the resulting instance will not confirm to US Core.
• In GenomicsReport, a LOINC code must be used, if available. If there is no suitable code in LOINC, then a code from an alternative code system (such as a code from the Genetic Testing Registry or other knowledgebase of genomics tests can be used.
• GenomicsReport.category is bound to US Core DiagnosticReport Category (extensible)to align with US Core. The value set however does not include an appropriate term for genomics report. Subsequently, mCODE implementations will fix the LOINC code GE to align with the value constraint specified in the Clinical Genomics Reporting IG GenomicsReport profile.

International Version of mCODE

Although the current version of mCODE is US-specific, there is a potential for an international version of mCODE. If interested, please contact one of the authors.

mCODE Roles

At present, two roles are defined:

• mCODE Data Sender - a participant in exchange of mCODE data who provides mCODE data in response to a data query or autonomously pushes mCODE data to an mCODE receiver. The data sender does not have to be the originator of the data it possesses.
• mCODE Data Receiver - a participant in exchange of mCODE data who accepts mCODE data from an mCODE Data Sender.

In the future, additional roles may be defined.

“Must Support” Interpretation

In FHIR, the MustSupport flag indicates that implementation shall provide “meaningful support” for the element, as defined by its implementation guide. In mCODE, there are two sources of MustSupport elements: those inherited from US Core, and those defined in mCODE. To conform to US Core, the MustSupport elements inherited from US Core must follow the interpretation of MustSupport defined in US Core.

Elements defined as MustSupport in mCODE do not follow the US Core rules. MustSupport elements defined in mCODE shall be interpreted as follows:

• mCODE Data Sender - MustSupport is interpreted as "required to be sent if known" (subject to applicable privacy and security rules). That is, every MustSupport element in a profiled mCODE resource SHALL to be provided to an mCODE Data Receiver, if Data Sender has that data.
• An mCODE Data Receiver SHALL be capable of receiving and storing each required and MustSupport element in mCODE, if the profile has been declared as a "supportedProfile" in the receiver's capability statement.

Unfortunately, FHIR does not have the ability to track the source of MustSupport flags, and the only way to know where a MustSupport flag is defined is by direct comparison of US Core and mCODE profiles.

Required Elements

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.
• The element is not a top-level element, its minimum cardinality is > 0, and its immediate higher-level containing element exists in an instance of the profile.

In other words, a data element may be 1..1, but if it is contained by an optional element, then it is not required unless its containing element is actually present in a given instance of the profile.

mCODE’s rules regarding required data elements are the same as US Core’s rules. To paraphrase those rules, a Data Sender must provide each required element or an explicit data absent reason for each missing data item.

Minimum Requirement for “mCODE Conformance”

The mCODE IG outlines conformance requirements and expectations for individual mCODE instances in terms of structural constraints and terminology bindings. Any FHIR resources claiming to conform to mCODE must validate against the declared mCODE profile.

At present, there are no additional conformance rules on what mCODE data is to be collected, by whom, and when, or when that data is to be exchanged. mCODE Data Senders and Data Receivers may choose the subset of mCODE resources they support, according to their business needs. For example, a Genomics Laboratory may support GenomicsReport, but not vital signs or staging.

FHIR capability statements describe the capabilities of actual implementation or requirements of a desired solution. This IG does not include sample capability statements. The expectation is to use implementation experience collected during the STU period to model the different types of actors (such as medical oncologist, radiologist, genomics laboratory, etc.), and define appropriate capability statements for each, including search parameters and operations.

Terminology Preferences

This implementation guide supplies terminology bindings drawn primarily from LOINC for “observables”, and SNOMED-CT for values, results and findings. When appropriate codes are not available in the preferred vocabulary, alternative vocabularies are used, in the following order of preference: SNOMED-CT (if the element is an observable), NCI Thesaurus and Metathesaurus, and local codes.

The specification of SNOMED US Edition is handled within the FHIR CodeableConcept.version attribute:

{version: "http://snomed.info/sct/731000124108"}

where 731000124108 is the SNOMED namespace assigned to the National Library of Medicine (NLM), who manages the SNOMED US Edition.

Value sets from the FHIR specification and US Core were reused to the extent possible. New value sets where created only when no known existing value sets were deemed to be fit for purpose, or when existing value sets were needed to be extended.

mCODE genomics-related elements in the GenomicsReport and GeneticVariant profiles will support the acceptable code systems stated in the HL7 Clinical Genomics Reporting FHIR IG, STU1 Release.

Patient

FHIR (and mCODE) allows multiple addresses for a patient. The zip code reported in mCODE should be the one specified by Address.use of “home” and Address.type of “physical”.

Body Locations

A single code is often insufficient to precisely determine a body site for the purpose of describing where a tumor is located, where a surgery is targeted, or where a radiation treatment is focused. For example, in breast cancer, the location of a tumor can be described in terms of the radial position (clock face direction) and distance relative to the left or right nipple.

In FHIR, Condition, Procedure, and other resources represent body sites using a single code. In addition, FHIR provides a standard extension, BodyStructure Reference that can be used when a single code is insufficient. However, this approach has not been adopted, for the following reasons:

• The bodySite attribute is a terminology concept, but BodyStructure is a resource, representing a body site on a specific patient. Concepts and instances are not analogous and cannot be arbitrarily swapped.
• Even if the difference between a terminology concept and an patient-specific resource is overlooked, the BodyStructure resource is insufficient for mCODE's purposes.

Instead, mCODE uses an approach that defines body sites conceptually, and has the required specificity, by introducing a laterality extension:

• Laterality - the side of the body the body location, if needed to distinguish from a similar location on the other side of the body

Vital Sign Profiles

The vital signs height, weight, and blood pressure are part of the mCODE data set. However, vital sign profiles are not defined in mCODE. Instead, mCODE uses the FHIR vital sign profiles, which are incorporated by reference into US Core v3.

If and when detailed vital signs profiles are standardized in a widely-accepted FHIR IG, mCODE may switch over to those profiles.

Laboratory Profiles

Complete Blood Count (CBC) and Comprehensive Metabolic Panel (CMP) are part of the mCODE data set. Reporting these results must conform to the US Core Laboratory Result Profile. Several examples of laboratory result reporting are given in the US Core IG. For example, see this erythrocytes laboratory reporting example.

In practice, there are different variations on these panels, as exemplified by this list of various CBCs. The individual LOINC codes of interest to mCODE are any that are reported as part of the CBC and CMP panels, which include, but are not limited to:

• CBC: 20570-8, 26453-1, 718-7, 26515-7, 28539-5, 28540-3, 28542-9, 30384-2, 30385-9, 30428-7, 26464-8, 30180-4, 26444-0, 34911-8, 34910-0, 26446-5, 30376-8, 26450-7, 26449-9, 34913-4, 34912-6, 30395-8, 30394-1, 35058-7, 30397-4, 26463-0, 26462-2, 26471-3, 30406-3, 34922-5, 35050-4, 26478-8, 26474-7, 30413-9, 30412-1, 13046-8, 26477-0, 30420-4, 35082-7, 34921-7, 35039-7, 30423-8, 30422-0, 34915-9, 34914-2, 28541-1, 30433-7, 34923-3, 35029-8, 26485-3, 26484-6, 30441-0, 30440-2, 34925-8, 34924-1, 30445-1, 30444-4, 26498-6, 30446-9, 26511-6, 26499-4, 26508-2, 26507-4, 30450-1, 30449-3, 30451-9,6505-8, 34917-5, 34916-7, 13047-6, 30458-4, 34999-3, 35003-3, 30465-9, 30464-2, 30466-7, 34926-6, 26524-9, 26523-1, 34919-1, 34918-3, 34992-8, 34993-6, 33255-1
• CMP: 2345-7, 3094-0, 2160-0, 3097-3, 33914-3, 50044-7, 48642-3, 48643-1, 17861-6, 2885-2, 1751-7, 10834-0, 1759-0, 1975-2, 6768-6, 1742-6, 1920-8, 2951-2, 2823-3, 2075-0, 1963-8, 2028-9, 33037-3

</p>

Representing Provenance of mCODE Information

Provenance information includes the “who, what, when, where, why” associated with collection, transfer, and updating of clinical information. As a FHIR application, mCODE relies FHIR’s native mechanisms for recording and tracking provenance. As such, mCODE shares all the capabilities and limitations of FHIR provenance tracking. The user should refer to the FHIR specification for more information. Only a brief summary is presented here.

FHIR provenance tracking has three parts:

• All FHIR resources contain a metadata element that specifies a serially-updated version of the resource, a timestamp of the most recent update to the resource, a URI representing the source system of the resource, URLs of the profiles the resource claims to conform to, and security labels and tags.
• In addition, each resource contains elements that represent information about how the resource was obtained, and who or what the information applies to. These attributes vary from resource to resource, and may include information such as the subject of care, the author of the information, performer of an action, the date/time of the action, etc.
• Finally, FHIR provides a Provenance Resource that can be used where additional information is required, or explicit record or provenance is desired.

In summary, mCODE defers to these FHIR mechanisms for recording and tracking provenance.<p> </div>