HL7 FHIR Implementation Guide: Breast Cancer Data, Release 1 - US Realm (Draft for Comment 2)
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 
Specifications consulted for the development of this IG include:
In addition to sources specifically providing clinical content related to cancer and breast cancer, from a modeling perspective, CIMI and FHIR models were also used as a source.
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.
The intention of a logical model is to represent the structure of the model without implementation-specific considerations. The logical model can then be transformed into one or more implementable forms, for example, V2 messages, FHIR profies, C-CDA templates, etc. In theory, this allows logical model retain its value, while implementation fashions come and go.
Of course, the logical model itself must be implemented in some concrete form. In this case, the logical model has been implemented in two formats: FHIR StructureDefinition and Archetype Description Language/Basic Meta Model (ADL/BMM). The latter is the current preferred format for CIMI conformance purposes. Only the FHIR StructureDefinitions are included in the ballot package.
The logical model itself can be described as an object-oriented class hierarchy, with domain-specific classes defined by progressive specialization of more generic parents. For example, a BreastSpecimen is defined by the following class hierarchy:
A typical observation, such as BreastCancerHistologicGrade, is defined in the following hierarchy:
(note: While CIMI uses the term "EvaluationResultRecorded", we have adopted the more concise term, "Observation".)
This class hierarchy is a central feature of CIMI. To fully describe the CIMI modeling approach is beyond the scope of this IG, and the reader is referred to CIMI Modeling Architecture, Methodology & Style Guide. However, it is important to understand a central CIMI tenet, the Topic-Context pattern.
CIMI develops several class hierarchies. The first is the ClinicalStatement hierarchy, exemplified by the BreastCancerHistologicGrade hierarchy, above. A clinical statement represents a fact, opinion, or observation that relates to a patient, for example, "the patient has a diagnosis of congestive heart failure" or "patient has an order for physical therapy" [CIMI Modeling and Quality Guide].
However, ClinicalStatement is not the only class needed to construct a clinical statement. The clinical statement itself has no clinical content; to gain content, the ClinicalStatement class must reference a topic and a context. The topic is the clinical entity being described by the Clinical Statement, for example, a laboratory test. The context describes the circumstance applied to the topic. For example, we can speak of "blood pressure of 120/80" as an observation or a goal; similarly, we can speak of a procedure as recommended, ordered, planned, performed, or not performed. Both the topic and context are defined in class hierarchies of their own. For example, for the BreastCancerHistologicGrade, the topic hierarchy is as follows:
It is important to understand the both the benefits and costs of this design choice. Separating topic and context increases consistency and reuse. For example, the same procedure topic can be used whether the context is recommending the procedure, planning the procedure, or performing the procedure. In addition, by reusing the contexts, each recommendation will have the same set of recommendation-related attributes, courtesy of the shared context. The same is true for each plan or performance, regardless of topic.
Under the topic-context pattern, creating one new domain class can require creating multiple classes. For example, the BreastCancerStage observation requires two new classes: a BreastCancerStageTopic class, where the StageTiming attribute is added, and the BreastCancerStage class itself, which extends and constrains Observation. In the ADL/BMM serialization, the BreastCancerStageTopic properties would form a new class in the BMM, extending the reference model, and the terminology and other constraints would be applied in an archetype. Modelers must weave three threads together form new classes. It is possible that the right user-friendly tooling could mitigate the resulting "what-goes-where?" and "what-comes-from-where?" problems, but tooling cannot decide which of the three hierarchies should be extended. Even in CIMI circles, this is frequently a gray area.
Exploration of alternatives is beyond the scope of this IG, but we briefly method that there is a potential simplification that could retain the key benefits of the topic-context pattern, while greatly simplifying the class hierarchy by eliminating the separate topic and context hierarchies. This involves extending the clinical statement hierarchy with classes that represent different contexts, creating, for example, OrderedStatement, ActionPerformedStatement, ActionNotPerformedStatement, ObservationStatement, etc. This approach creates a fixed set of classes from which all other classes derive.
The Clinical Information Modeling Initiative (CIMI) is an HL7 Work Group that is producing detailed clinical information models to enable interoperability of health care information systems. The goal of CIMI is to create a shared repository of detailed clinical information models, all based on the same core reference model and data types, with formal bindings to standard coded terminologies. CIMI models are logical abstractions, independent of any specific programming language, implementation technology, or type of database.
The current breast cancer model is proffered as an example of a CIMI model. However, it has not yet been approved by the CIMI Work Group. While a serious attempt has been made to align to the CIMI Reference Model (CIMI-RM), the CIMI-RM itself is actively evolving. The last "official" release of the CIMI-RM was Version 0.0.4, for the January 2018 ballot. There are still outstanding issues remaining from that ballot, and ongoing discussions and proof-of-concept demonstrations, that will undoubtably lead to future changes in the CIMI-RM. The breast cancer models incorporate some changes found in a July 2018 unofficial CIMI release.
Some known CIMI differences are called out in the documentation of specific classes. One notable difference is that FHIR data types are used, to simplify mapping and profile generation.
The goal is to achieve CIMI conformance once the definition of such conformance is finalized. How this goal is achieved is in active discussion. One certain aspect of CIMI Conformance is the requirement to serialize domain logical models into Basic Metamodel (BMM) and Archetype Description Language (ADL) files. While that "gold standard" model format of the breast cancer logical models was generated and will be submitted to the CIMI Work Group, that serialization has not included in the ballot because it is not relevant to FHIR. The models here are presented as FHIR logical models and FHIR profiles, both using FHIR StructureDefinition resources.