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. BioTopLite

is 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.