This page is part of the Breast Cancer Data Logical Models and FHIR Profiles (v0.2.0: STU 1 Draft) based on FHIR R3. . For a full list of available versions, see the Directory of published versions

This is the second For-Comment Ballot for the Breast Cancer Data FHIR Implementation Guide (IG) sponsored by Clinical Information Council (CIC) Work Group, and co-sponsored by the Clinical Information Modeling Initiative (CIMI). The Breast Cancer Data IG was created by the Cancer Interoperability Group, a voluntary group representing a wide variety of organizations and perspectives, including providers, medical professional societies, vendors, and governmental organizations. The models herein have NOT yet been approved by by CIMI, and deviations from CIMI are summarized in the section Relationship to CIMI.

Table of Contents

• Guidance for HL7 Voters
• Purpose
• Background
• Scope
• Implementation Guide Contents
• Modeling Approach
• Terminology Approach
• Open Source Tooling
• Relationship to CIMI
• Diagrams
• Disclaimers

Guidance for HL7 Voters

This section provides orientation to the ballot materials.

Where to Focus

There are several representations of the same content in the ballot materials. Different representations will be useful to different audiences:

• Clinicians and cancer domain experts should primarily focus on the logical models. These models are the simplest representation of the content included in the ballot. Value sets will also be of interest.
• The FHIR community and FHIR implementers should primarily focus on FHIR Profiles and related matter (extensions, value sets, etc.).
• The CIMI community should focus primarily on the reference model that shows how the oncology model derives from the CIMI Reference Model, the FHIR mappings, and the resultant logical models and FHIR Profiles. See Relationship to CIMI for more information.The CIMI community should also inspect the mappings between the breast cancer model and the FHIR profiles. The mappings are found on selected profile pages, on the Text Summary tab. Mappings are not part of all profiles because mappings can be inherited. For example, the mapping of breast cancer diagnosis is entirely based on the mapping found in the ConditionPresenceStatement profile.

Questions for Commenters

The sponsoring work groups and the Cancer Interoperability Group are seeking both general and specific comments regarding this material.

1. The authors have concerns about the complexity of the CIMI model, which forms the basis of the breast cancer logical models. These concerns are discussed further in the Modeling Approach section. We are seeking comment on whether to continue with CIMI, push the CIMI group to a simpler approach, or take another approach entirely.
2. Is the content dealing with breast cancer staging complete and correct from a clinical point of view?
3. This second for-comment ballot IG continues the inclusion of CIMI-style models, FHIR logical models, and FHIR Profiles, all related to each other. We are interested in whether the greater HL7 community of voters find such an approach useful.

Purpose

The Breast Cancer Interoperability FHIR Implementation Guide (IG) contains a subset of logical models for breast cancer focused on data elements used for breast cancer staging. FHIR profiles are provided as an example physical representation of the logical models. This IG also serves as an experimental pilot for the Clinical Information Modeling Initiative (CIMI), presenting a combination of CIMI-derived models, FHIR logical models, and FHIR Profiles.

Background

Several oncology data models exist today. They were created by specialized communities and for specific purposes like generating synoptic reports for pathology, developing oncology treatment plans, reporting to cancer registries, and supporting clinical documentation in an oncology EHR. There is no clear agreement among these models, further complicating the seamless exchange of structured and coded data among these disparate systems. And yet, there is general consensus on the need to have a common set of data elements that allows for the seamless exchange of oncology data as one proceeds through the cancer patient journey of care.

The Cancer Interoperability Project aims to address this concern with the goal of modeling cancer data in a way that can be used for the diagnosis, treatment, and research of cancer. The project is a collaboration of a diverse multidisciplinary group involved in the diagnosis, treatment, research, and surveillance of cancer.

Scope

The IG covers oncology-specific data necessary support breast cancer treatment and research, focusing on data driving clinical decision-making for both clinical providers and the patient. The second iteration of this guide remains focused on breast cancer staging carcinomas. Not included are breast sarcomas and Phyllodes Tumors. The data required for staging involves several clinical domains and specialties, including medical oncology, surgical oncology, and anatomic pathology. The American Joint Commission on Cancer 8th Edition Staging Manual (AJCC-8th Edition) is typically used for staging breast cancer in the US Realm. Their methodology involves not only the well-known T, N, and M classifications, but also other factors which influence the prognosis of breast cancer patients, including tumor grade, hormone receptor status (progesterone and estrogen), human epidermal growth factor 2 (HER 2) status, among others.

Over time, we expect the IG will incrementally evolve to cover a wider range of clinical domains (e.g. radiology, clinical genomics, interventional radiology), and expand its scope to include other key areas for breast cancer diagnosis and treatment (e.g. radiation therapy, chemotherapy), while supporting secondary data use in for clinical research and cancer registry reporting.

Changes to the Second Ballot

The second release of the Breast Cancer IG address comments to the May 2018 ballot release as well as a further refinement to the representation of breast cancer staging elements. These include:

• Replacement of local codes with either LOINC, SNOMED, or NCI Metathesaurus codes, if equivalent concepts exist. Reference the Terminology Approach section for additional details.
• Expanding the T, N, and M classifications from fields accepting a single category code to separate and extensible observations which are used in determining each category. For example, BreastCancerPrimaryTumorClassification is now a FHIR profile which includes TumorDimensions, an element which provides further tumor sizing datails supporting either a clinical or pathological T category.
• Additional data elements that enrich the modeling for staging, including lymph node involvement and tumor size.
• Changes to the CIMI model based on the July 2018 release. Reference the Relationship to CIMI section for additional details.
• A diagram illustrating the most relevant data elements in the IG.

Implementation Guide Contents

The IG contains several different elements, accessed using the top level navigation tabs:

1. Logical Models. The objective of logical models is to help gather and interpret requirements from stakeholders, particularly clinicians, but also registries, researchers, and others. The logical models document the requirements without the added complication of alignment with FHIR. The breast cancer logical models use reproducible patterns established by CIMI. Things to note:
   • The only thing that makes the logical models "FHIR Logical Models" is the use of the StructureDefinition resource as a formal representation. They could just as easily be captured in other formalisms, such as Unified Modeling Language (UML) or Archetype Description Language (ADL).
   • The logical models are separated into "Primary logical models" and "Supporting logical models". The primary models deal directly with breast cancer domain, while the supporting models deal with sub-elements and higher level (parent) models.
   • Each logical model appears on a separate page, which looks something like the documentation of a FHIR resource, including attributes, cardinality, datatype, and terminology bindings.
2. FHIR Profiles. With logical models in place, they can be mapped to FHIR resources. This step requires more knowledge of FHIR than the logical model step. The result is a set of FHIR profiles, which are FHIR Resources that have been shaped (constrained and extended) to match the intent of the logical models. Similar to the Logical Models, the profiles have been separated into "Primary profiles" and "Supporting profiles".
3. Extensions. Extensions are new properties/attributes that do not appear in the base FHIR resources, which are needed to create a FHIR profile. An attempt has been made to minimize the number of extensions appearing in this IG by using Observation.component to represent dependent parts of observations, such as MitoticCountScore and TubuleFormationScore in HistologicGrade.
4. Value Sets. Value sets are the enumeration of values for coded attribues. Due to copyright restrictions on AJCC-derived content, certain critical value sets have been redacted, diminishing the usefulness of this specification.
5. Code Systems. All value sets require a code system. Value sets that are not drawn from standard terminology, such as locally-defined value sets, do not have a natural code system. FHIR overcomes this by generating a custom code system for each locally-defined value set.
6. Downloads. Formal class definitions, in StructureDefinition form, can be downloaded here.
7. Reference Model. FHIR does not have a class hierarchy, but CIMI does. Since the breast cancer models are based on CIMI, they derive from CIMI's class hierarchy. To help view the class hierarchy, we have provided a class browser. The browser allows navigation of the class hierarchy, shows details of each class, and includes attributes and constraints that show where each constraint was introduced in the hierarchy.

Disclaimers

This specification may contain and/or reference intellectual property owned by third parties ("Third Party IP"). Acceptance of the FHIR Licensing Terms does not grant any rights with respect to Third Party IP. The licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the specification or otherwise.

Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability. Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology	Owner/Contact
SNOMED CT	SNOMED International
LOINC	Regenstrief Institute

American Joint Committee on Cancer (AJCC) Staging Content

While the AJCC staging system is recognized as one of the most widely-used standards for breast cancer staging, this guide does not include any AJCC terminology due to unresolved copyright issues. As such, elements related to staging do not currently include required terminology bindings, and refer back to the staging system used for the appropriate codes. The value sets are known, and their inclusion would considerably strengthen the specification. Active discussions continue with AJCC to address licensing and fair use with some resolution anticipated in future ballots. In the meantime, supplementary documentation on how the model uses AJCC staging with one example breast cancer patient will be provided outside of the release of this ballot.