Amendment History

Review Timetable

© International Health Terminology Standards Development Organisation 2012. All rights reserved.
SNOMED CT® was originally created by the College of American Pathologists.
The International Release of SNOMED CT® is distributed by the International Health Terminology Standards Development Organisation (IHTSDO), and is subject to the IHTSDO's SNOMED CT® Affiliate Licence. Details of the SNOMED CT® Affiliate Licence may be found at http://www.ihtsdo.org/our-standards/licensing/.
No part of this document may be reproduced or transmitted in any form or by any means, or stored in any kind of retrieval system, except by an Affiliate of the IHTSDO in accordance with the SNOMED CT® Affiliate Licence. Any modification of this document (including without limitation the removal or modification of this notice) is prohibited without the express written permission of the IHTSDO.
Any copy of this document that is not obtained directly from the IHTSDO [or a Member of the IHTSDO] is not controlled by the IHTSDO, and may have been modified and may be out of date. Any recipient of this document who has received it by other means is encouraged to obtain a copy directly from the IHTSDO [or a Member of the IHTSDO. Details of the Members of the IHTSDO may be found at http://www.ihtsdo.org/members/].

Glossary

Domain Terms

Introduction

Purpose

The purpose of this project is to suggest improvements to the representation of "presence" in the SNOMED CT Concept Model by analyzing and integrating various exiting materials on the Observables Model, Clinical Life Phases, and Situations with explicit context.
The representation of "presence" (and its corresponding inverse, "absence") in SNOMED CT is currently inconsistent. Furthermore, it has long been recognized that representing "presence" in the Observables Model requires something beyond the model's prototypical approach to representing observations about "qualities," such as length, concentration, mass, and volume.

Audience and stakeholder domain

The representation of "presence" is within the scope of the Observables Model, and the Observables Model itself is of particular interest to users who want to record observations and observation results in clinical data collection forms employed within electronic health record (EHR) systems.
The audience for this document also includes all standards terminology leaders and implementers, as well as the community of SNOMED CT authors who may be requested to implement the recommended specification.

Input from stakeholders

The Observable and Investigation Model Project Group and the Event-Condition-Episode (ECE) Model Project Group have been identified as the primary stakeholders within IHTSDO.
A lengthy slide presentation was prepared in an effort to synthesize key aspects of other slide presentations that have been developed by various IHTSDO experts over several years and to suggest some new potential solutions to the problem of "presence." This presentation contained copies of many slides that most members of the two project groups have previously seen. In the interest of time, an abbreviated version of the presentation was given to the ECE group at its meeting on August 22, 2016. A slightly different abbreviated version of the presentation was given to the Observables Project Group on September 6, 2016 . Both groups kindly provided helpful feedback. Comments from these presentations have been incorporated into this document and into a revised version of the complete presentation. That version of the presentation is linked to this document as an appendix. References to specific slides in this presentation are made frequently in this document, as an alternative to copying specific slides into figures within the document.

Degree of consensus on the statement of problem

There is a high degree of consensus about the nature of the problems that the Observables Model, which has been under development for a number of years, seeks to address. In particular, there is widespread recognition of the difficulties involved in clearly distinguishing among findings, disorders, situations, observable entities, and observation results. For example, numerous concepts in the Clinical finding and Situation with explicit context hierarchies contain the word "present" in their fully specified names.

Statement of the problem or need

Summary of problem or need, as reported

As reported in ITHSDO-836, there is a question about how to represent "colostomy present" and the extent to which this idea differs from a statement that a patient has undergone a surgical procedure, such as "my father was subjected to a colostomy (procedure)."
The interrelated problems described in Section 3.5 make it clear that the issue of modeling "presence" extends well beyond the relatively simple use cases described in IHTSDO-836.

Summary of requested solution

Although there has been no single requested solution, there has been a longstanding recognition that the Observables Model should represent "presence" as an observation result rather than a property type. (See Slide 16 in the Appendix.) The implications of this analysis are described in more detail in Section 3.4.

Statement of problem as understood

There is a need to represent the idea of "presence" in a more consistent and coherent way within the SNOMED CT Concept Model. From an ontological standpoint, the Observables Model's approach of using property types to describe a quality or "feature" of an entity, which works well for laboratory observables, is not adequate for representing "presence."

Detailed analysis of reported problem, including background

Examples of "presence" in SNOMED CT

Slide 14 in the Appendix provides some examples of how the word "present" is currently used in the SNOMED CT Clinical finding and Situation with explicit context hierarchies. A regular expression search for the word "present" followed by a space (to avoid getting the word "presentation") in the July 2016 International Release using the IHTSDO Browser found 435 concepts with a semantic tag of "(finding)," 74 concepts with a semantic tag of "(situation)," and 30 concepts with a semantic tag of "(disorder)." A similar search for the word "absent" followed by a space found 224 concepts with a semantic tag of "(finding)," 66 concepts with a semantic tag of "(situation)," and 61 concepts with a semantic tag of "(disorder)."

The Observables Model and formal ontological principles

The Observables Model is one of the first efforts to introduce formal ontological principles into SNOMED CT. The objectives for doing so include making it easier to inter-operate with other biomedical ontologies based on these principles, helping remove inconsistencies from SNOMED CT, and improving the overall quality of the terminology.
As noted in Section 1.1, the Basic Formal Ontology (BFO) is an upper level ontology developed to support integration of data obtained through scientific research. It is widely used in the biomedical domain and is extensively documented. BioTopLiteis another upper level ontology for the life sciences. It is consistent with BFO, but it arguably aims to be simpler.
Section 1.1 contains definitions for a number of ontological terms from BFO because they can be useful in understanding the problems and potential solutions involved with representing "presence" in SNOMED CT. Slides 21-23 in the Appendix illustrate the basic BFO categories of independent continuant, dependent continuant, and occurrent.
Explicitly introducing formal ontological terms (with their precise philosophical definitions) into a clinical terminology like SNOMED CT would run the risk of making the terminology seem "foreign" to clinical end-users. While terms like "independent continuant" may be perplexing to clinical end-users, other terms like "process" and "material entity" are arguably "friendlier" to typical clinicians. Although it may be neither practical nor desirable for SNOMED CT to attempt to incorporate all the nuances of any particular formal ontology (such as BFO), there appears to be widespread agreement that SNOMED CT content should at least be consistent with the most basic formal ontological principles.

Property types in the Observables Model

The Observables Model has two different sets of attributes. One of these attribute sets describes the target of the observation, i.e., what the observation "is about," and the other attribute set models how the observation is made. Slide 20 in the Appendix explains that IS ABOUT is the first attribute of the Observables Model because it identifies the target of the observation. It is worth noting that the Concept Model attribute 704647008| Is about (attribute) | already exists in SNOMED CT.
In identifying the target of an observation, the Observables Model relies heavily on property types, which are defined in Section 1.1. Four different kinds of observables that can be represented with property types have been identified:

• Quality observables – an observable about a characteristic or feature, a quality, that is inherent in a person or a thing, for example the mass of a human being, the temperature of the internal organs, the concentration of sodium in plasma, the angle of a joint, etc.
• Disposition observables – an observable about a characteristic or feature that is not always realized in full, for example the susceptibility towards antibiotics of bacteria of a certain population, etc.
• Function observables – an observable about the ability of a person, some part of a human, or a thing to perform activities or realize processes, for example the ability to walk,
• Process observables – an observable about a process or the outcome of a process, e.g. secretion rate, heart- or respiration rates, etc.

All four of these types of observables can be regarded as feature of entity observables, because they are "about" some feature or attribute of another entity. Qualities, dispositions, and functions are dependent continuants, which inhere in (or are borne by) some independent continuant. The existence of a dependent continuant depends on the independent continuant in which it inheres.
Attributes or features of a process can be said to "characterize" that process or to represent some measureable aspect of it. For example, heart rate is an attribute of the cardiac cycle.Attributes of processes are referred to as "process profiles" in BFO.
Slides 9 through 12 in the Appendix provide examples of these four types of observables. Slide 26 in the Appendix illustrates how the four kinds of "feature of entity" observables relate to the BFO hierarchy.
Other types of observables that can use property types may be identified in the future. Slide 27 in the Appendix, which illustrates the BFO continuant hierarchy, suggests that property types can be used for observables about any kind of specifically dependent continuant.

Observables without property types

There are some types of observables for which the observation target cannot be adequately represented by property types because the observation targets are not features or attributes of other entities. There is a longstanding recognition that "presence" should not be represented by a property type but should instead be regarded as an observation result.Slide 16 in the Appendix, entitled Dealing with "presence," explains that "presence" and "absence" should be disallowed as values of the Observables Model PROPERTY TYPE attribute. This makes sense, because "presence" and "absence" are not really features of some other entity, in contrast to qualities like mass, temperature, volume, or concentration.
If the observation targets for quality, disposition, function, and process observables can all be represented by using property types, then what kinds of observables cannot be represented by property types? The answer would seem to be (1) observables that are "directly about" independent continuants, and (2) observables that are "directly about" occurrents that cannot be characterized by features or attributes of processes. Slide 29 in the Appendix attempts to illustrate how these "non-property-type" observables relate to the BFO hierarchy.

Observation results as information entities

Observables (i.e., observable entities), observation procedures, and observation results are closely related. Slide 33 in the Appendix illustrates these relationships. Interestingly, this diagram indicates that the observation target for an observable or observation result is a "property or quality," even though we now recognize that some observation targets cannot be represented by property types. Slide 34 in the Appendix shows that observables, observation procedures, and observation results have closely coordinated models. Observation procedures can be modeled using the same attributes as observables, but observation procedures have an additional METHOD attribute. Observation results can be modeled using the same attributes as observables, but observation results have an additional HAS VALUE attribute. A detailed analysis of observation procedures is out of scope for this project, but the main focus of the project can be described as investigating how to use the HAS VALUE attribute to model "presence" as an observation result.
In order to promote the "face validity" of observation result concepts (i.e., the degree to which an FSN or preferred term "looks right" or "makes sense" to a casual reader with a clinical background), it is important that the allowed values of the HAS VALUE attribute for different types of observation results be carefully considered. The different sets of allowed values in the Qualifier value hierarchy should be carefully "tuned" for different types of observation results in order to make such observation result value concepts more consistent and understandable.
Slides 37 and 39 in the Appendix indicate that observation results should be regarded as "information artifacts". More precisely, an observation result is an "information content entity," which is a "generically dependent continuant" (as described in Section 1.1). This simply means that an observation result contains information that "is about" something else (another entity) and that the information can easily be copied from one medium or physical artifact (such as a disk drive or paper chart) to another. An Information Artifact Ontology (available at https://github.com/information-artifact-ontology/IAO ) is under development and aims to be consistent with BFO.

Observation results and clinical life phases

Concepts in the Clinical finding hierarchy are being re-interpreted as clinical life phases as part of the work being done by the ECE project group. Slides 43 through 47 in the Appendix explain what clinical life phases are and how they help correct many subsumption problems within the Clinical finding hierarchy. A clinical life phase is defined as a phase of a patient's life during which a condition is fully present. A condition is a (typically pathological) structure, disposition, or process of clinical relevance. Because Release Format 2 (RF2) does not support nesting, there is currently no "has condition" attribute in SNOMED CT. Rather, role groups are used to represent conditions wherever possible. The most common example of modeling a condition is a role group that contains a FINDING SITE attribute and an ASSOCIATED MORPHOLOGY attribute. "Tetralogy of Fallot" is classic example of how re-interpreting clinical findings as clinical life phases can correct existing subsumption problems. Currently, "Tetralogy of Fallot" is a direct child of "Pulmonic valve stenosis," even though it is not strictly correct to say that "Tetralogy of Fallot" is a kind of pulmonic valve stenosis. It is, however, correct to say that that the set of patients in whom Tetralogy of Fallot is present is necessarily a subset of the set of patients in whom pulmonic valve stenosis is present.
From the standpoint of representing "presence," the most interesting thing about clinical life phases is that the notion of "presence" is already an integral part of the definition of a clinical life phase. Thus, if an observation result is about a clinical life phase, there is a question about what should be the allowed values of the HAS VALUE attribute. Using "present" as the value of the HAS VALUE attribute seems inappropriate because it is clearly redundant and arguably confusing.

Clinical life phases vs. Clinical findings

There are concepts in the current Clinical finding hierarchy that do not appear to meet the definition of clinical life phase. These concepts should presumably be treated as observation results. Typical examples include 302112009|Colostomy present (finding)|, 300563005|Spleen present (finding)|, and 162057007|Nausea present (situation)|.
For the sake of clarity, clinical life phase will be used in the remainder of this document to refer to the concepts in the existing Clinical finding hierarchy that meet the definition of a clinical life phase, even if the Clinical finding hierarchy is not ultimately renamed.

Relationship between clinical life phases and observables

Concepts in the Clinical finding hierarchy (which should be regarded as clinical life phases) can connect to concepts in the Observable entity hierarchy by means of the INTERPRETS attribute. It may be advisable to restrict the range of this attribute to "Feature of entity" observables (i.e., those observables that use property types) because these are the kinds of observables on which clinical life phases may depend. For example, bradycardia, tachycardia, and fever arguably depend on "Feature of entity" observables as follows:

• Bradycardia or tachycardia INTERPRETS Heart rate (observable entity)
• Fever INTERPRETS Body temperature (observable entity)

There was a previous suggestion that all clinical finding concepts having INTERPRETS attributes be moved from the Clinical finding hierarchy to a new Observation result hierarchy, but it seems important to preserve a link to "Feature of entity" observables if a clinical life phase such as "a period of a patient's life in which the condition bradycardia is fully present" is deemed reasonable.

Observation results and Situations with explicit context

Slides 37 and 39 in the Appendix indicate a longstanding recognition that concepts in the Situation with explicit context hierarchy should be treated as information artifacts or entities. There appears to be essentially no difference between the terms "situation" and "clinical life phase." The idea of clinical life phases arose out of work comparing different interpretations of disorder codes in SNOMED CT and ICD as "conditions" vs. "situations."The term "clinical life phase" was apparently chosen over the term "clinical situation" to avoid confusion because the word "situation" was already used in the Situation with explicit context hierarchy. From an ontological perspective, clinical life phases and situations are both occurrents (because they unfold over time), whereas the concepts that currently reside in the Situation with explicit context hierarchy arguably represent information entities. Thus, it would seem that the use of the word "situation" in the name "Situation with explicit context" is something of a misnomer.

Subsidiary and interrelated problems

The following subsidiary and interrelated problems were identified by following links from IHTSDO-836 in Confluence:

• IHTSDO-239 requests adoption of systematic naming conventions for FNSs containing the phrases "on examination," "X present," and "X absent."
  • IHTSDO-655 is described as: " Ensure that Fully Specified Names adhere to the style guide with respect to abbreviations, punctuation, acronyms, word order, or other style guidance as documented in the terming guide." This includes, but obviously is not limited to, use of words such as "present" and "absent."
  • There are also references to IHTSDO-261, IHTSDO-836, and IHTSDO-314.
• IHTSDO-261 requests clarification on modeling descriptions such as "X presence known absent" or "X absence known present."
  • IHTSDO-533 concerns a request to add "HLA-B 5701 Positive status" and "HLA-B 1502 Positive status," including questions about whether the requested concepts should be modeled as findings or observable entities.
  • There are also references to IHTSDO-836, IHTSDO-314, and IHTSDO-239.
• IHTSDO-314 requests clarification on modeling "Presence of X (situation)" versus "Presence of X (finding)."
  • IHTSDO-109 is entitled "Refining meaning in clinical findings, including situation, disorder, observation result." The description of this JIRA item is worth quoting in its entirety because it aptly sums up the existing inconsistencies in SNOMED CT:

There is a need to define the meaning of "finding", "disorder", "situation" in a reproducible way, or come up with alternative categories and alternative definitions. Otherwise there will be duplication, confusion, and impairment of the value of the terminology. Recent revisions suggest categories such as "condition" with "structure, process, disposition" subtypes, and "clinical life phase", and "information entity" which includes "observation result". These need further definition, examples, and a full elaboration.
Here are some typical questions that illustrate the difficulties:
1) Observation results vs clinical life phases: "What is the difference between |bradycardia (finding)| and |bradyarrhythmia (disorder)| ? Is one a subtype of the other? If not, why not?"
2) Situations vs clinical life phases: "What is the difference between |Nausea present (situation)| and |Nausea (finding)|? Why have two codes when only one appears to be needed here?"
3) Clinical phase with an abnormality vs clinical phase with a disposition: "What is the difference between |Headache (finding)| and |Headache disorder (disorder)|? What is the relationship between them?"

• IHTSDO-925 focuses on "Situation hierarchy refinement."
• IHTSDO-332 suggests retirement of the |77386006|Patient currently pregnant (finding)| concept.
• There are also references to IHTSDO-836 and IHTSDO-239.

Risks / Benefits

Risks of not addressing the problem

The risks of not addressing the problem are stated clearly in IHTSDO-109: There is a need to define the meanings of "finding", "disorder", "situation" in a reproducible way, or come up with alternative categories and alternative definitions. Otherwise there will be duplication, confusion, and impairment of the value of the terminology. This statement can be expanded to include the need to define the meanings of "observable entity," "observation procedure," and "observation result" as part of ongoing work on the Observables Model. A satisfactory answer to the question "What is the difference between a finding and an observation?" has remained elusive.
The problem of how to represent "presence" in the SNOMED CT Concept Model is clearly an issue within the scope of the Observables Model. The effects of the Observables Model will extend beyond the Observable entity hierarchy to other SNOMED CT hierarchies, including Clinical finding and Situation with explicit context. Thus, the "presence problem" is closely related to most of the interconnected problems described in Section 3.5. These problems must be addressed in a consistent and integrated manner. The major risk of not doing so is that SNOMED CT could be criticized as inconsistent and difficult to use. This risk affects not only end users of the terminology but also the IHTSDO editors responsible for enhancing and maintaining it.
A major use case involves the need to employ SNOMED CT in populating clinical data collection forms of the kind commonly found in EHR systems. These forms often ask whether a patient has had a particular clinical problem or undergone a particular procedure. Thus, such forms can usefully be regarded as collections of "question-answer pairs" that frequently involve the issue of "presence." Inconsistent representations of "presence" in SNOMED CT are likely to result in inconsistent coding in the clinical records that are populated by completing such data collection forms.
Another risk of not addressing the problem is that SNOMED CT may be perceived as not adhering sufficiently to formal ontological principles. The use of formal ontologies in biomedical applications appears to be growing, and there is a risk that SNOMED CT could seem to be "out of step" with current approaches to knowledge representation.
The following project risk profile is based on the assessment instrument as described in the Guide to Stakeholder Engagement in Content Development.

Thus, representing "presence" and "absence" as observation results should be regarded as a controversial, high-risk project that is part of the even larger project of implementing the Observables Model.

Risks of addressing the problem

The major risks of addressing the problem can be divided into the broad categories of resource requirements and end-user acceptance. The issue of "presence" lies within the purview of the Observables Model, and the Observables Model has implications for multiple SNOMED CT hierarchies. When the issue of "presence" is viewed in the context of interrelated problems involving the Observables Model, it seems clear that addressing all of these problems in a coherent manner will require a heavy commitment of resources. Many person-years of effort will undoubtedly be required to revise or add many thousands of concepts. It is conceivable that the IHTSDO could deem the resource requirements to be larger than what the organization can afford, at least in the near term.
Any major change to SNOMED CT will probably have to confront the issue of end-user acceptance. End-users may be resistant to change, especially if it requires them to modify an existing production system. While some kinds of users (such as those engaged in academic research) may welcome substantial changes to the terminology, others may feel that the changes are unnecessary and offer little value for their particular use cases. The IHTSDO always has to balance the trade-offs between making improvements to the terminology and disrupting existing users who have already deployed it.

Requirements: criteria for success and completion

Criteria for success/completion

Although IHTSDO-836 is focused on representing "presence" in the Concept Model, it seems clear that this objective can only be regarded as successfully completed if it is addressed as part of a more comprehensive effort to develop a clear and consistent approach to modeling observables and observation results that cannot be regarded as "features of entities." Property types are well suited to representing (1) some feature or quality that inheres in an independent continuant (2) some attribute or profile that characterizes a process. However, property types are not well suited to representing cases where an observation targets an entity "directly," as opposed to targeting a feature or attribute of a different entity. Consequently, the success criteria presented below apply to any observables/ observation results that cannot be well represented by property types.

Strategic and/or specific operational use cases

From the perspective of the SNOMED CT Detailed Content Development Plan 2011-2015, the main uses cases for observables and observation results involving "presence" are "1A. Patient summary / Discharge summary" and "1B. Problem list." In particular, SNOMED CT observable and observation result concepts should be straightforward to use in completing the kinds of structured data collection forms that are often required for clinical histories and physical examinations. As mentioned in Section 4.1.1, items on these forms can often be viewed as "question/answer pairs," where the observable corresponds to the question and the observation result corresponds to the answer. These forms commonly ask whether a patient has a particular clinical finding/disorder or has undergone a particular procedure. In addition, there may be questions and answers about physical features that may be observed.
Use case "1E. Order communication and result reporting" is important for the Observables Model overall, but this use case can generally be handled by "feature of entity observables." For laboratory tests in particular, the target of the observation is likely to be a measurable quality such as concentration, mass, or volume.

Solution Development

Outline of initial design

The general approach to solution development began with two basic set of questions:

• If one takes "feature of entity" observables (i.e., quality observables, disposition observables, function observables, and process observables) as the starting point, then what other kinds of observables and observation results need to be represented by the Observables Model? Is the idea of "presence" relevant to all of these "non-feature-of-entity" observation results? Can all of these "non-feature-of-entity" observation results be represented in the same way, or are there different requirements for different subtypes?
• As explained in Section 3.4.5, observables and observations results can be modeled with the same attributes, but an observation result must have an additional HAS VALUE attribute. Consequently, there is a question about how the Qualifier value hierarchy should specify ranges for the HAS VALUE attribute for observation results that do not use property types (i.e., for "non-feature-of-entity" observation results). Can all "non-feature-of-entity" observation results use the same set of allowed values, or should there be different sets of allowed values for different subtypes? Are there any naming conventions or styles that should be applied to the sets of allowed values in an effort to make it clear that they are being used to model observation results? Although reworking parts of the Qualifier value hierarchy that are used as observation result values is beyond the scope of this project, it is important to identify parts of the Qualifier value hierarchy that are candidates for revision if they are re-interpreted as allowed values for "non-feature-of-entity" observation results.

Identifying kinds observation results without property types

Slides 26 and 29 in the Appendix are attempts to show where "feature of entity" observables fit into the BFO hierarchy and to suggest the kinds of observables and observation results that remain to represented even though they are not "features of entities." There seem to be two main categories:

• Independent continuants.
• Occurrents that cannot be represented as attributes of processes (by using process observables)

An observation may be about an independent continuant "directly," as opposed to being about a dependent continuant for which it serves as a bearer. In SNOMED CT, such observations are commonly about the "presence" of material entities, including body structures, organisms, and substances.
Similarly, an observation may be about an occurrent or process "directly," as opposed to being about an attribute or feature that is part of the process. In SNOMED CT, the most important use cases in this category are (1) observables or observation results about clinical life phases and (2) observables or observation results about procedures.
Some types of observation results about clinical life phases (i.e., clinical findings that fit the definition of a clinical life phase) and procedures are currently handled in the Situation with explicit context hierarchy. It may, however, also be desirable to represent "non-contextual" observation results that refer to the subject of record in the present time.
SNOMED CT also contains a separate Event hierarchy. For the purposes of this project, observables and observation results about events are being considered out of scope. The reason is that the word "event" is sometimes used as a synonym for the word "occurrent." Both words seem to denote "entities that unfold over time." Clinical life phases and procedures can both arguably be regarded as types of events, just as they are types of occurrents. The general topic of how occurrents (or events, if they are the same thing) relate to each other is something that the ECE Group should probably consider eventually.
One possible approach to representing observation results about "non-feature-of-entity" observables is to treat them all in the same way. For example, one could argue that "present" or "absent" should be used as values of the HAS VALUE attribute, regardless of whether the target of the observation is a material entity, a clinical life phase, or a procedure. This approach, of course, runs the risk of overlooking any important differences that may exist for these different observation targets.

Observation results about clinical life phases

As noted in Section 3.4.6, the idea of "presence" is an integral part of the definition of clinical life phase, which is "a phase of a patient's life in which a condition is fully present." Thus the question of how to represent "presence observation results about clinical life phases" is arguably a conundrum. One possible solution can be found in a paper by Schulz, et al.This paper makes a clear distinction between clinical entities and information entities, explaining that information entities have clinical entities as their referents (i.e., information entities in health records are "about" clinical entities). In addition, it proposes a simple five-value scale that can be used to describe that what an information entity says about a clinical entity: excluded, unlikely, not excluded, likely, and confirmed. The paper also investigates the complicated subsumption relationships that may exist among the five categories of excluded, unlikely, not excluded, likely, and confirmed. Even if such subsumption relationships are not considered, it would seem that this simple five-value scale could be extremely useful as a set of allowed values for observation results about clinical life phases. In particular, this five-value scale does not contain the words "present" or "absent" and it consequently makes clear that the five values describe results of observations (i.e., information entities) about clinical life phases.
It should be emphasized that these five values have nothing to do with the ontological definition of a clinical life phase. Rather, they would appear in the Qualifier value hierarchy as allowed values for the HAS VALUE attribute of an observation result when the target of the observation is a clinical life phase.
Slide 49 in the Appendix illustrates the proposed position of allowed values excluded, unlikely, not excluded, likely, and confirmed within the Qualifier value hierarchy. Slide 50 in the Appendix provides some additional commentary on the meanings of these five categories.
The attributes available for defining clinical life phases can connect them to body structures, organisms, substances, procedures, events, observable entities, and other clinical life phases. The richness of these connections raises an interesting question concerning whether observables and observation results about clinical life phases might be sufficient to represent any observable or observation result that does not use property types (i.e., that are not "features of entities"). This question, which is mentioned on Slide 53 in the Appendix, suggests that procedures and material entities could be connected to clinical life phases by appropriate attributes instead of serving as observation targets themselves. However, this approach would probably require extensive analyses by the Event-Condition-Episode Project Group and the Observables Project Group before it could seriously be considered for implementation. In the meantime, it seems advisable to treat observables or observation results about clinical life phases, procedures, and material entities separately.

Re-interpreting Situations with explicit context as observation results

For the reasons explained in Section 3.4.9, concepts in the Situation with explicit context hierarchy should arguably be re-interpreted as observation results. The current view is that this hierarchy acts as an "axis modifier" for clinical findings and procedures, meaning that the concepts in this hierarchy refer to "associated findings" or "associated procedures" but are not clinical findings or procedures themselves. This view can be recast as saying that the concepts in this hierarchy are information entities that refer to (or "are about") clinical entities (specifically, clinical life phases and procedures).
Slides 56 through 58 in the Appendix suggest how the Situations with explicit context hierarchy could be restructured within an observation result hierarchy:

• Instead of using an ASSOCIATED FINDING attribute, there can simply be a sub-hierarchy called Clinical life phase observation result.
• Instead of using an ASSOCIATED PROCEDURE attribute, there can simply be a sub-hierarchy called Procedure-related observation result.
• The FINDING CONTEXT attribute could be replaced by the HAS VALUE attribute applied to concepts in Clinical life phase observation result sub-hierarchy. The existing Finding context value sub-hierarchy could be recast as the set of allowed values for the HAS VALUE attribute when it is applied to concepts in the Clinical life phase observation result sub-hierarchy. As suggested by Slide 59 in the Appendix, most concepts in the existing Finding context value sub-hierarchy could probably be replaced by the simple five-value scale of excluded, unlikely, not excluded, likely, and confirmed, as described in Section 6.1.2.
• The PROCEDURE CONTEXT attribute could be replaced by the HAS VALUE attribute applied to concepts in Procedure-related observation result sub-hierarchy. The existing Context values for actions sub-hierarchy could be recast as the set of allowed values for the HAS VALUE attribute when it is applied to concepts in the Procedure-related observation result sub-hierarchy. As shown in Slide 61 in the Appendix, many of these values concern planning or scheduling procedures; hence, it seems unlikely that they could be replaced by the simple five-value scale of excluded, unlikely, not excluded, likely, and confirmed, as described in Section 6.1.2
• As shown in Slide 63 in the Appendix, the SUBJECT RELATIONSHIP CONTEXT and TEMPORAL CONTEXT attributes would remain and would be used in an Observation result with explicit context sub-hierarchy.

It is interesting to note that these proposed changes would narrow the scope of "explicit context" because an observation result would have "explicit context" only if it has a SUBJECT RELATIONSHIP CONTEXT or TEMPORAL CONTEXT attribute. Situation with explicit context concepts that currently have a FINDING CONTEXT or PROCEDURE CONTEXT attribute but no SUBJECT RELATIONSHIP CONTEXT or TEMPORAL CONTEXT attribute (i.e., those that apply to the subject of record and the present time) would become "simple" observation result concepts without any "explicit context."

Observation results about material entities

As shown in Slide 14 in the Appendix, examples of observation results about material entities include 302112009|Colostomy present (finding)|, 301319006|Hand present (finding)|, and 438508001|Virus present (finding)|. Slides 31 and 32 in the Appendix provide examples of how observation results about material entities could be modeled.
Allowed values for Material entity observation results could be based on the existing 260411009|Presence findings (qualifier value)| and 272519000| Absence findings (qualifier value)| sub-hierarchies.

Proposed revisions to a hierarchy of observation results

Slide 76 in the Appendix shows a proposed design for the top levels of an observation result hierarchy. The main categories would be:

• Observation results about features of entities
• Observation results about clinical life phases
• Observation results about procedures
• Observation results about material entities

Observation results about features of entities are considered out of scope for this project because they do not concern representing "presence." Observation results about features of entities would most commonly be represented in an information model rather that in SNOMED CT because they typically consist of a numeric value and an associated unit of measure. Laboratory observation results are prime examples of this pattern. However, some kinds of observation results about features of entities may be qualitative in nature and would consequently require sets of allowed values to be specified in the Qualifier value hierarchy.

Significant design or implementation decisions / compromises

Ontological realism, information entities, and default context

"Ontological realism" (as defined in Section 1.1) takes the position that ontologies describe "universals in reality." From a clinical perspective, this means that ontologies describe classes of things such as inherent qualities, pathological anatomical structures, clinical life phases, and therapeutic procedures. In other words, ontologies seek to describe "clinical entities," which are classes of entities that exist or occur in the real world.
It is widely recognized, however, that what is recorded in clinical records is actually information about clinical entities. In other words, clinical records are populated by information artifacts such as observation results and interpretations. The degree to which information artifacts accurately describe the entities in reality to which they refer is highly variable. For example, observation results can be "false positives" or "false negatives." Observation results also reflect varying degrees of uncertainty.
If one were to begin developing a terminology like SNOMED CT de novo, one might wish to maintain a sharp and consistent distinction between classes of clinical entities that exist in reality and information artifacts that are about (or refer to) those entities. A disadvantage of this approach is that it would probably result in a huge proliferation in the number of concepts in the terminology. Typically, there would be one concept to represent a clinical entity that "exists in reality" (such as a clinical life phase or procedure) and another concept to represent an information artifact that is about (or refers to) the corresponding clinical entity. In this "purist" approach, the code for the information artifact concept is what would be recorded in a medical record.
The rationale behind SNOMED CT default contexts is presumably based on the desire to avoid this proliferation of concepts where there is one concept for a clinical entity that "exists in reality" and another concept for an information artifact (i.e., observation result) that is about (or refers to) the corresponding clinical entity. When an SCTID for a Clinical finding or Procedure is recorded in an electronic health record, the information model used by that electronic health record (or the software that manages the information model) presumably needs to "know" that the recorded SCTID "really means" that a clinical finding (or clinical life phase) has been confirmed by observation or that a procedure has been performed.
On the other hand, there are some observation results that should arguably be represented explicitly in SNOMED CT. We can identify at least three use cases:

• There is an explicit context for the observation result. In other words, there is an explicit SUBJECT RELATIONSHIP CONTEXT because the observation result is about someone other than the patient or there is an explicit TEMPORAL CONTEXT because the timing of the observation result is something other than the present.
• There are existing concepts in the Clinical finding hierarchy that should be treated as observation results instead of clinical life phases. These are often concepts such as "Hand present," which can be regarded as observation results about material entities.
• The observation result needs to represent negation or uncertainty. For observables or observation results about clinical life phases, an observation result value of "excluded" could be used as an indicator of negation (with the caveat that observation results do not always accurately represent reality). Similarly, observation result values such as "likely" or "unlikely" can be used to indicate uncertainty.

It is worth noting that these use cases could be handled by delegating them to an information model instead of representing them in the terminology. Indeed, it is expected that "feature of entity" observation results will usually be represented only in an information model, because they often consist of a numeric value accompanied by a unit of measure. The notions of explicit context, negative observation results, and uncertain observation results could also arguably be represented only in an information model, rather than in SNOMED CT. Accordingly, some users may elect to represent these kinds of observation results in an information model instead of using any corresponding concepts in SNOMED CT. It seems unlikely, however, that most observation results could be removed from SNOMED CT because there are a large number of existing concepts in the Situation with explicit context hierarchy and the Clinical finding hierarchy that should be re-interpreted as observation results. These concepts may already be widespread use and may have been specifically requested by end users.

Importance of clearly specifying allowed values for observation results

The Qualifier value hierarchy, in which all the concepts are primitive, currently specifies
allowed values (i.e., ranges) for many Concept Model attributes. Thus, the Qualifier value hierarchy should specify the allowed values of the HAS VALUE attribute for different kinds of observation results. Appropriate naming of these qualifier value concepts could arguably go a long way toward making observation results more consistent and understandable.
It is important to avoid conflating presence and existence. One could certainly argue that these two words have the same meaning. If something exists, then it must be present. If something is present, then it must exist. However, the words existence and presence are used rather differently in SNOMED CT. Existence, in the sense of existential quantification in description logic, is involved in the formal ontological definitions of clinical entities. On the other hand, presence has typically been used for various kinds of observation results, such as "hand present" or "nausea present." In other words, we could say that the notion of existence is used in formal ontological definitions of clinical entities, whereas the notion of presence is used in information entities that refer to (or "are about") clinical entities.
Needless to say, these rather different uses of the words existence and presence can be extremely confusing (at least in English). For this reason, it may be advisable to avoid the use of terms like "present," "known present," "absent," and "known absent" in the parts of the Qualifier value hierarchy that specify the allowed values for observation results. The FSNs of concepts that are allowed values for observation results should arguably be worded in ways that clearly suggest (or "sound like") observation result values. For example, terms like "observed [to be] present," "found," and "detected" are arguably less confusing that the single word "present" because these terms connote observation result values to a casual reader. Similarly, terms like "observed [to be] absent," "not found," and "not detected" are arguably less confusing than the single word "absent" for the same reason (i.e., that they connote observation result values).
On the other hand, the names of allowed values for observation results must take common clinical usage into account. For example, if a pathologist looking through a microscope is accustomed to using the word "present" to describe the result of observing a particular cellular morphology, then it may be preferable not to ask the pathologist to change that customary way of recording observation results. In that case, it might be desirable to add descriptions (synonyms) such as "observed present" or "found" to the concept having an FSN of "present" in order to convey the impression that the concept is an observation result value.
Another way to address these issues is to use a semantic tag of "(observation result value)" for concepts in the Qualifier value hierarchy that are descendants of an "Observation result value (qualifier value)" concept. Concepts such as "Present (observation result value)" or "Absent (observation result value)" may be sufficiently clear to avoid misinterpretation without actually changing the wording of concept names and descriptions.
Although a thorough analysis of the Qualifier value sub-hierarchies that specify allowed values for observation results is beyond the scope of this project, some simple principles for improving these sub-hierarchies seem obvious. Concepts that appear to have duplicate or very closely related meanings should be avoided. For example, why is it necessary to have both "Done" and "Performed?" Careful consideration should be given to whether the concepts in given sub-hierarchy should be mutually exclusive. If they are not mutually exclusive, should any subsumption relationships among the allowed values be specified?

Modeling Examples

Design decisions can be illustrated by modeling examples, as shown by Slides 66 though 71 in the Appendix. The "higher level" observation result concepts of Clinical life phase observation result, Procedure-related observation result, and Observation result with explicit context are modeled in Slides 66, 67, and 68. The specific examples of Chronic disease absent, Family history of bariatric operative procedure, and Hand present are modeled in Slides 69, 70, and 71. In some cases, an existing SCTID is used but the FSN is changed for purposes of illustration. For example, 52101004|Present (qualifier value)| is shown as 52101004|Present (observation result value)|.
It is worth noting that the interpretation of default context described in Section 6.2.1 means that a number of Situation with explicit context concepts arguably become completely unnecessary. An example is 162057007|Nausea present (situation)|. If "Nausea" is interpreted as a clinical life phase (i.e. "a phase of a patient's life in which nausea is fully present"), then entering 422587007|Nausea (finding)| into an electronic health record would have the default meaning that the clinical life phase in which nausea is fully present has been confirmed by observation.

Evaluation of Design

Exceptions and Problems

Deciding whether or not to use a property type, or deciding which property type to use, is not always straightforward. Some examples are described below:

• A particularly thorny issue concerns the use of "presence" properties in LOINC. The LOINC User's Guide – June 2016 (available from www.loinc.org) contains the following statements:
  • Some tests report the name of an organism (or initially report the presence of any organism, and later identify the particular strain), toxic substance, antibody or antigen, as a test result. Use "Prid" (presence or identity) as the type of property field for results of this sort.
  • ACnc means the number of arbitrary units in a volume (arbitrary concentration). We originally used ACnc as a "temporary" place-holder for observations with ordinal answers. We then transitioned to replacing ACnc with either "Pr" (for results simply based on whether the analyte is present or not without being determined by a cut off value) or "Threshold" (for observations reported as "positive" or "negative" based on an internal threshold or cut off). As we updated existing terms with the new model, in many cases it was difficult to definitively know how results were determined. Therefore, as of release 2.56, we are using a single property of "PrThr" to represent results based on either the presence or absence of an analyte regardless of whether or not it is based on an internal cut off. This change was approved by the Laboratory LOINC Committee in June 2016.The display name will continue to say "Presence". All of the existing terms with a Property of "ACnc", "Pr" or "Threshold" and a Scale of "Ord" were updated to have the Property "PrThr" for the 2.56 release. A single term with Property "ACnt" and Scale "Ord" was also updated to have the Property "PrThr."
  • The use of these LOINC properties obviously contradicts the idea that "presence" should be represented as an observation result and not as a property type, as described in Section 3.4.4. One can argue, however, that any laboratory test is actually measuring or attempting to detect a feature of some entity (typically represented as the LOINC "component"). This point of view suggests that it may be possible to devise Observables Model property types that capture the intended meaning of the LOINC "presence" properties without violating the dictum that "presence" should be represented as an observation result instead of a property type. Of course, the development of such Observable Model property types would require consultation with the maintainers of LOINC to ensure that the proper semantics are being captured. Rather than a having a numeric value, observation result values such as 260373001|Detected (qualifier value)| or 260415000|Not detected (qualifier value)| would be used for with Observables Model property types corresponding to the LOINC "Prid" or "PrThr" properties.
• Functioning observables and observation results provide an interesting use case that highlights the kind of analyses that are sometimes needed to determine whether a feature of entity observation result is sufficient by itself or whether a clinical life phase observation result that INTERPRETS a "feature of entity" observation result is a better representation. Slide 11 in the Appendix provides an example of a functioning observable concerning the ability to walk. From an ontological standpoint, a function has its realization in a functioning (i.e., in a process). There is a question, however, about how to represent allowed values for observation results about functioning. One approach is to create a set of allowed values for "feature of entity" observation results about functioning. Thus, one could imagine an allowed value for a "feature of entity" observation result such as "Does not walk" could be a qualifier value of "Does not." An alternative approach is to take the position that "Does not walk" is best represented as "a phase of a patient's life in which he or she does not walk." In this case, the clinical life phase would have an INTERPRETS attribute with a value that is a "feature of entity" observable such as "Ability to walk" and a HAS INTERPRETATION attribute with a value of "Does not." The second approach is more consistent with the way concepts about functioning are currently represented in the Clinical finding hierarchy, but this does not necessarily mean that it superior to the first approach. An obvious advantage of the first approach is that it would involve only one concept instead of two concepts.
• A similar question can be raised with respect to observation results about material entities. For example, one could argue that "Spleen present" should be regarded as a clinical life phase in which the spleen is present. In this case, the clinical life phase would have a FINDING SITE of "Spleen structure" and the value of the observation result about this clinical life phase would have one of the allowed values described in Section 6.1.2. One could argue, however, that this approach entails "stretching" the definition of a clinical life phase (especially since the spleen in this example is not a pathological structure).

The questions concerning observation results about functioning and material entities both raise the issue of how "flexible" the editorial guidance about the use of clinical life phases should be. In the interest of simplicity, it can be argued that the best choice is to avoid using a clinical life phase whenever a "feature of entity" observation result can adequately represent the intended meaning.

Design Strengths

The greatest strength of the design is arguably that it provides a clear separation of observation results that use property types from those that do not. Observation results that use property types are collectively referred to as "feature the entity" observation results, of which there are four kinds: quality observation results, disposition observation results, function observation results, and process observation results. Observation results that do not use property types are divided into observation results about clinical life phases, observation results about procedures, and observation results about material entities. Different kinds of observation results can be added to the model as the need arises, but the kinds of observation results illustrated on Slide 76 of the Appendix seem to cover most current use cases.
The design takes into account that the idea of "presence" is an integral part of the definition of a clinical life phase. Accordingly, it advocates a simple five-value scale of excluded, unlikely, not excluded, likely, and confirmed as the set of allowed values for observation results about clinical life phases.
The design is an attempt to be consistent with formal ontological principles, at least a basic level. In particular, it attempts to maintain a clear distinction between clinical entities that exist in reality and information entities that refer to (or "are about") those clinical entities.
The design recognizes the importance of carefully analyzing and revising the Qualifier value sub-hierarchies that specify the allowed values for different types of observation results. In particular, it recognizes the need to make the concept names in these sub-hierarchies suggest that they are observation result values, either by changing concept names and descriptions or adding a new semantic tag such as "(observation result value)." At a minimum, there is need to eliminate duplicate meanings in the sub-hierarchies that enumerate observation result values and to make the concepts in these sub-hierarchies mutually exclusive where possible.
The design addresses a long-standing need to re-interpret the Situations with explicit context hierarchy as observation results. It retains the notion of explicit context for observation results where the time is something other than the present and the subject is someone other than the patient of record. On the other hand, it allows observation results where the subject is the patient of record in the present time to be handled more simply (i.e., by not regarding them as having "explicit content").
The design accommodates the existing idea of default context as a means of avoiding the proliferation of concepts that would occur if every clinical entity concept had a corresponding information entity concept that referred to it.

Design Weakness

The major weaknesses of the design involve a high level of resources that would be required to implement it, as well as possible resistance by end users to the magnitude of the changes involved. In particular, restructuring the Situation with explicit context hierarchy as a part of a hierarchy of observation results might be perceived as an unwelcome change in some quarters.
Another potential weakness of the design is that it is motivated by formal ontological principles, which may be regarded as alien to clinical users.

Design Risks

Recommendation:

The recommendations in this section are based on the analyses in Section 3 and proposed solutions in Section 6.

Detailed design final specification

The following actions are proposed:

• Prefer using property types wherever possible. Since the Observables Model arguably works best when property types can be used, the sub-hierarchy of allowed property type values in the Qualifier value hierarchy should be enhanced in an effort to maximize the number of observables that can be modeled successfully using property types.
• Identify the kinds of observables and observation results that cannot use property types. It has been established that property types can be used for quality, disposition, function, and process observables. These can collectively be referred to as "feature of entity" observables, because the target of the observation is an attribute of another entity. Given this background, there is a need to identify the other types of observables and observation results that need to be modeled. Two main types have been identified:
  • Independent continuants, typically material entities such as body structures, organisms, and substances.
  • Processes that cannot be modeled as process observables by using property types to represent attributes of processes. The two most important of these types are observables and observation results about clinical life phases and procedures.
• Construct a new SNOMED CT top-level information entity hierarchy and an observation result sub-hierarchy. Explicitly introducing observation results into SNOMED CT means that there should also be an explicit distinction between information entities (of which observation results are a type) and clinical entities that exist in reality. Information entities refer to (or "are about") clinical entities. Strictly speaking, the statements recorded in medical records are information entities, which may or may not accurately characterize the clinical entities to which they refer. The notion of default context, however, is used to avoid proliferation of information entity concepts. The proposed structure of an observation result hierarchy is shown in Slide 76 of the Appendix.
• Remove concepts that do not meet the definition of clinical life phase from the Clinical finding hierarchy and move them to an Observation result subhierarchy. Examples include 302112009|Colostomy present (finding)|, 301319006|Hand present (finding)|, and 438508001|Virus present (finding)|.
• Re-structure the Situation with explicit context hierarchy into a new sub-hierarchy of observation results. There is a longstanding recognition that the concepts in the Situation with explicit context hierarchy are information entities. It is proposed that the Situation with explicit context hierarchy be restructured as illustrated in Slides 57 and 63 of the Appendix.
• Review and refine sub-hierarchies of allowed observation result values. A very important aspect of representing observation results in SNOMED CT is that the concepts used as allowed values of HAS VALUE attribute should seem to be intuitive and sensible. It is proposed that the following sub-hierarchies in the Qualifier value hierarchy be reviewed and revised to establish clear sets of allowed values for observation results that do not involve property types:
  • 410514004|Finding context value (qualifier value)| This subhierarchy contains candidate allowed values for the HAS VALUE attribute for observation results about clinical life phases. As suggested by Slide 59 in the Appendix, most or all of the concepts currently in this sub-hierarchy could probably be replaced by the simple five-value scale of excluded, unlikely, not excluded, likely, and confirmed. These five values are arguably preferable to any concepts whose names contain the words "present" or "absent" because the idea of "presence" is an integral part of the definition of clinical life phase, as explained in Section 6.1.2.
  • 288532009|Context values for actions (qualifier value)| This subhierarchy contains candidate allowed values for the HAS VALUE attribute for observation results about procedures. As an example of the kinds of revisions that may be appropriate, one could ask why there is any need for both 385658003|Done (qualifier value)| and 398166005|Performed (qualifier value)| in this subhierarchy.
  • |Presence findings (qualifier value)| and |272519000|Absence findings (qualifier value)| These subhierarchies contain candidate allowed values for the HAS VALUE attribute for observation results about material entities. Examples of problems that need to be corrected include 264866005|Neoplasm present (qualifier value)| and 264872005|Nodules present (qualifier value)|. Such concepts belong in an observation results hierarchy rather than in the Qualifier value hierarchy.
• Develop an implementation plan as part of an overall approach to implementing the Observables Model. It seems clear that addressing "presence" in the Concept Model should be part of an overall plan for addressing observation results in general, which in turn must be part of an overall plan for implementing the Observations Model.

Quality program criteria

Quality metrics

Quality metric 1

Quality metric 2

Quality metric 3

Quality metric 4

Project Resource Estimates

Resource estimates for implementing the Observables Model as whole were originally prepared in Refining Meaning in Clinical Findings, including Situation, Disorder, and Observation Result. Since addressing the problem of representing indicators of "presence" as observation results should be regarded as part of the overall implementation plan for the Observables Model, these estimates are still quite relevant.

Scope of construction phase

The construction phase should take a staged approach that permits evaluation from multiple perspectives before proceeding to full construction and the transition phase. For construction of the parts of the Observables Model described in this document, the following steps should be considered:

• Creation of a prototype with the proposed high-level categories of Information entity, Observation result, Observation result with explicit context, Clinical life phase observation result, Procedure-related observation result, and Material entity observation result, as illustrated in Slides 63 and 76 in the Appendix.
• An attempted full revision of the allowed values for the kinds of observation results described in this document and listed in Section 7.1.
• Creation of a test set of up to 200 concepts containing the words "present" or "absent" in their FSNs, drawn from the existing Clinical finding and Situation with explicit context hierarchies. An attempt should be made to model this test set of concepts with full description logic definitions.
• Technical evaluation of the correctness and comprehensiveness of the proposed models.
• Evaluation of the understandability, reproducibility, and usefulness of the proposed observation result content.
• Stakeholder engagement and feedback from potential end-users.

Projection of remaining overall project resource requirements

The overall resource requirements can only be estimated in detail after the preliminary construction phase proposed above has been completed.

Expected project resource requirement category

The scope of this project is large and is likely to require many person-months of effort. As mentioned previously, addressing the problem of "presence" should be part of an overall plan to implement the Observation Model in its entirety over multiple release cycles. It should be expected that priorities within the overall implementation effort will change over time, as end user needs and IHTSDO resources are periodically re-assessed. For example, addressing the problem of "presence" might be given a lower priority than representing functioning observables.

Expected project impact and benefit

The benefits of this project are expected to be large, especially in terms of making the terminology more consistent and easier to understand. Consistency with formal ontological principles, especially with respect to the distinction between information entities and clinical entities, should be significant improvement in the overall quality of the terminology. Additionally, editorial guidance for representing observation results should become easier to write.

Indicative resource estimates for construction, transition and maintenance:

• Construction phase: The preliminary test set of concepts described in Section 9.1 could be drawn from concepts containing the words "present" or "absent." Searching in the ITHSDO browser reveals 465 concepts in the Clinical finding hierarchy and 74 concepts in the Situation with explicit context hierarchy that contain the word "present." Similar searches revealed 285 concepts in the Clinical finding hierarchy and 66 concepts in the Situation with explicit context hierarchy that contain the word "absent."
• Transition phase: It is difficult to estimate the resource requirements for the transition phase because of their interactions with both tooling development and with other parts of the Observables Model implementation effort.
• Maintenance phase: It is expected that resource requirements for maintenance of observation result content will be lower after completion of the proposed redesign than they would otherwise have been, due to improved quality and consistency of the terminology.

Appendix