HL7 FHIR® Implementation Guide: Breast Cancer Data, Release 1 - US Realm (Draft for Comment)

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

This is a 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 been approved by by CIMI, and deviations from CIMI are summarized in the section Relationship to CIMI.

Table of Contents

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. Is the content dealing with breast cancer staging complete and correct from a clinical point of view?
  2. Are there other initiatives or projects that also deal with cross-cutting data standards for breast cancer that should be taken into account?
  3. Is the way the ballot material is presented suitable and useful? If not, what type of format(s) would be more informative?
  4. To the best of our knowledge, this is the first time that a single ballot contains CIMI-style models, FHIR logical models, and FHIR Profiles, all related to each other. As such, we are interest in whether the 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 first and foremost on data driving clinical decision-making for medical and surgical oncologists. The first iteration of this guide is focused on breast cancer staging. 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-8) is typically used for staging breast cancer in the US Realm. Their methodology involves not only the well-known T, N, and M elements, but also other elements influence the prognosis of breast cancer patients, including tumor grade, hormone receptor status (progesterone and estrogen), as well as 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.

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.

Modeling Approach

Major sources of information

Specifications consulted for the development of this IG include:

  • American Joint Committee on Cancer (AJCC) Staging Manual (8th Edition)
  • College of American Pathologists (CAP) Cancer Protocols
  • North American Association of Central Cancer Registries (NAACCR) 2018 Site-Specific Data Items Manual (DRAFT)
  • HL7 CDA R2 IG: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers
  • HL7 CDA R2 IG: Clinical Oncology Treatment Plan and Summary

In addition to sources specifically providing clinical content related to cancer and breast cancer, from a modeling perspective, CIMI models were also used as a source.

Harmonization and Prioritization

Data elements were initially prioritized based on the identified scope. Consideration was given to existing representations of the elements across the source material, which varied in complexity from a simple data element dictionary to more well-formed logical models which included relationships between concepts. Value sets for coded elements were also compared across the sources.

Differences across sources drove the development of harmonized detailed clinical models. Final decisions on the inclusion of data elements and attributes were driven by 1) their impact in driving clinical decision making for breast cancer treatment, and 2) their presence in multiple sources, indicative of the importance of the data element across practice areas.

Terminology and Value Sets

The terminology bindings in this implementation guide are preliminary. The primary goal was to identify and vet appropriate values for each coded data element and its attributes.

For those elements for which terminology bindings exist, SNOMED-CT and LOINC were the preferred vocabularies. However, given known gaps in these vocabularies on the domain areas covered in this IG, codes from vocabularies such as ICD-O-3 and the NCI metathesaurus were used.

In addition, 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 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, if and when copyright issues have been resolved.

Open Source Tooling

The tools used to define the models and produce the logical models and the FHIR profiles are open source, developed as part of the Standard Health Record (SHR) Initiative. The SHR tooling consists of several elements:

  • Clinical Information Modeling and Profiling Language (CIMPL). CIMPL (pronounced "simple") is a domain-specific language designed for the task of capturing requirements in a recognizable, human-readable form and defining detailed clinical information models. It has a formal grammar defined in ANTLR4. It has three types of definitional files: data elements, value sets, and profile mappings.
  • Command Line Interface (CLI). CLI is the computer program that parses CIMPL files and produces outputs including CIMCORE, FHIR logical models, FHIR Profiles, and other artifacts.
  • Clinical Information Modeling COmputable REpresentation (CIMCORE). CIMCORE is a computable health care modeling representation in JSON, expressing the class hierarchy, modeling constraints, value sets, and mappings. CIMCORE can be thought of as the "compiled form" of CIMPL, but it is explicitly designed for simplicity and cross-language interoperability. It is used as the central representation from which the various outputs (profiles, logical models, reference model browser) are produced.

The final form of the Implementation Guide (the html pages you see here) was produced using the standard FHIR Implementation Guide Publisher (IGPub).

Relationship to CIMI

The breast cancer model presented here has NOT been approved by the CIMI Work Group. While a serious attempt has been made to align to the CIMI Reference Model (CIMI-RM), the breast cancer model departs from the CIMI-RM in ways explained below. Moreover, CIMI is still actively evolving, and the definition of "CIMI Conformance" is still being discusssed. It is hoped that the breast cancer model will inform future CIMI development.

To the extent possible, the breast cancer staging model has been based on the CIMI Reference Model (CIMI-RM). The last "official" release of the CIMI-RM was Version 0.0.4, for the January 2018 ballot. The CIMI-RM is currently undergoing revisions as part of ongoing development and ballot reconciliation. The breast cancer models incorporate those changes, to the extent those changes are known and have been approved in the CIMI Work Group.

Deviations from CIMI-RM V0.0.4 are called out in the documentation of specific classes. These should be further investigated to understand if closer alignment between, or changes to, FHIR and CIMI could be useful. Here is a summary of those deviations, and our understanding of the reasons (other thoughts would be most welcome):

  1. Areas where FHIR conflicts with CIMI-RM in ways that makes it impossible to express the full intention of the CIMI model in FHIR profiles; for example, where CIMI-RM specifies an attribute to be optional but FHIR requires that attribute, the breast cancer model requires that attribute.
  2. Addition of terminology bindings that do not exist in CIMI-RM.
  3. Areas in CIMI-RM that are significantly structurally different than FHIR that mappings were difficult to define, such as attribution and specimen processing.
  4. Data types have been aligned to FHIR rather than CIMI, to simplify mapping and profile generation.

In addition, most of the oncology classes are derived in a way that may not be considered "textbook CIMI". For example, BreastCancerStage inherits from EvaluationResultRecorded, which is a child of ClinicalStatement. CIMI topic-context pattern would require up to three classes: (1) a BreastCancerStageTopic class inheriting from EvaluationResultTopic, (2) a BreastCancerStageContext inheriting from RecordedContext (if required), and (3) a class or archetype that combines this topic and context into a clinical statement that represents the BreastCancerStage. There are several reasons the breast cancer model departed from this CIMI pattern:

  • Defining separate topic classes (and potentially new context classes) would roughly double the number of classes in the oncology logical model.
  • This pattern interferes with inheritance of mappings. With the tool set used to produce this IG, mappings defined for a parent class are automatically applied to child classes. As a result, most classes do not require separate mappings. This is very efficient. In the example above, BreastCancerStage would not have inherited the mapping between EvaluationResultRecorded and FHIR Observation, since it would be a child of ClinicalStatement. It still could be mapped, but that would have created much more work.
  • Following this part of the CIMI pattern ultimately has little or no effect on the FHIR profiles.

Finally, the breast cancer models have not yet been serialized in the "gold standard" CIMI manner, as Basic Metamodel (BMM) and Archetype Description Language (ADL) files. There is ongoing work to try and accomplish that. For now, the models are presented as FHIR logical models, using FHIR StructureDefinitions.

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
ICD-O-3 World Health Organization