Observable entities and Clinical findings Some thoughts for group discussion… David Sperzel June 2017

Introduction Goals Some key questions: What is the difference between Provide a partial response to the concerns expressed here by Keith Campbell. Propose distinctions that provide greater clarity for modelers. Some key questions: What is the difference between An observable entity and a clinical finding? A clinical finding and a disorder or diagnosis? An observation result and a clinical finding? The distinction between clinical entities and information entities may help provide some clarity about these questions.

Information entities refer to clinical entities An important representational problem, which is inherent in the domain of medical care and documentation in electronic health records (EHRs), is the inter- dependence of two fundamentally different kinds of things, viz. the referring entities, in the following named “information entities”, and their referents we will call “clinical entities.” Clinical entities encompass organisms, their material and immaterial parts, the environment they interact with, the processes they are involved in, as well as the qualities, (mal)functions, and dispositions they exhibit and which are relevant to clinical observations, assessments or actions. Information entities encompass, among many other things, all elements of discourse that are about some particular clinical entity or a type thereof. Typical examples are statements recorded by health professionals to express facts, beliefs, hypotheses, orders, and plans, using unstructured (human) language or codes from appropriate terminology or coding systems. Schulz, S., Martínez-Costa, C., Karlsson, D., Cornet, R., Brochhausen, M., & Rector, A. L. (2014, September). An Ontological Analysis of Reference in Health Record Statements. In FOIS (pp. 289-302).

This view of clinical entities is entirely consistent with the ECE work on clinical life phases Copied from final Observables Model presentation prepared by Kent Spackman and dated December 26, 2014

Confronting some confusing or ambiguous names… Unfortunately, the word “finding” seems very similar to the word “result” (at least in English). Additionally, the names separated by slash (‘/’) characters in the list below arguably mean “more or less” the same thing – at least in the sense that considering alternative names may help clarify our thinking: Clinical finding / Clinical life phase / Clinical entity HAS INTERPRETATION / HAS VALUE / HAS RESULT IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT

Overview of suggestions Observation results as information entities Features in the context of clinical entities Overview of suggestions

Observation results as information entities Observable entity vs. observation result: An observable entity is a feature of another entity (the independent continuant in which a property inheres or the process that the property characterizes) An observation result is created assigning a value to an observable entity Assertion: It can sometimes be very useful for an observation result to refer to a different (clinical) entity that provides additional context for the feature observed. Numeric vs. non-numeric observation results: Numeric observation result values are typically represented in information models rather than SNOMED CT But non-numeric observation results are typically represented in SNOMED CT.

A possible revised observables diagram is about / refers to / has observation context observation result observation procedure output of specified by observes clinical entity/ clinical life phase / procedure / event material entity body structure observable entity feature is about

Why have a value for a feature of one entity with an optional reference to a different entity? There can be a many-to-many relationship between observable features and clinical entities: A single observable feature may apply to (be relevant to) many different clinical entities and a single clinical entity may have many different observable features. But sometimes, you want to interpret an observation result in reference to or in the context of a different clinical entity. This can be especially true for qualitative observation results. The PROPERTY TYPE may be fairly general, while the other entity referred to can be much more specific and may already be represented in SNOMED CT.

More details and analysis… Status as a property type Property type for presence observables SWEC concepts as observation results Identifying allowable observation result values More details and analysis…

Recall some background 6.1.1 Outline of design The concept model for Observable entities has two main parts and two main sets of attributes: the specification of the feature of reality that is observed, i.e. what is observed, and the observation procedure, i.e. how that feature is observed. The feature exists independently of being observed. The feature observed is specified by the PROPERTY TYPE attribute An observation result is an observable entity that has been given a value. The value may be qualitative or quantitative. The INTERPRETS attribute currently connects a clinical finding to an observable entity. From artf6283 Observables and investigation procedures redesign Inception-Elaboration v1.0rc-v2.docx

Can we require a PROPERTY TYPE for every observable entity? This would certainly “make life much easier!” We could then have a simple new rule: If you cannot assign a reasonable PROPERTY TYPE, then you cannot model a concept as an observable entity (or as an observation result). “Presence observables” are problematic because they do currently do not have an obvious property type. (See next two slides.)

Longstanding recommendation to disallow “presence” and “absence” as values of the PROPERTY TYPE attribute Copied from final Observables Model presentation prepared by Kent Spackman and dated December 26, 2014

Current thinking on presence observables From artf6283 Observables and investigation procedures redesign Inception-Elaboration v1.0rc-v2.docx 6.7.3 Presence observables In the Observables Project Group there has been a separate discussion about how to represent presence observables. The different cases discussed includes presence or absence of findings and procedures on the one hand and presence and absence of substances, abnormal structures, etc., i.e. material entities. While observables about findings and procedures could rely on the concepts models for findings and procedures respectively for representation, presence of material entities have no or limited such corresponding models and would thus have to use the observables model. While the details of the representation of presence and absence observables will be the topic of a separate document, the proposed solution is to use the 704647008 | Is about (attribute) | attribute with the range extended to include 404684003| Clinical findings | and 71388002 | Procedures | and being subsumed by a primitive “Presence observable” concept. Other presence/absence observables would have a property type of “Presence” and use any other existing quality observable attributes. This conflicts with the existential restriction use in SNOMED CT definitions, in that having a presence/absence observable should not imply the existence of an instance of the type of entity intended to be observed.

Consider Status (property) (qualifier value) as a PROPERTY TYPE value Searching for “status” in the January 2017 edition returns 822 concepts containing the word. There is no “plain” Status (qualifier value) concept, but there is a Status (attribute) concept that is a child of Unapproved attribute (attribute)

Using Status as a PROPERTY TYPE value Appears to be a reasonable way to represent: A state that INHERES IN an independent continuant A state that CHARACTERIZES a process Allows Status observable (observable entity) to be fully defined The property and the corresponding observable entity can be subtyped as necessary: Presence-absence status (property) (qualifier value) Presence-absence status observable (observable entity) Using the word “status” as suggested arguably removes (or greatly reduces) the aforementioned conflict between the existential restriction used in SNOMED CT definitions and the use of the word “Presence” as a PROPERTY TYPE value.

There is a longstanding recognition that SWEC concepts are actually information entities Concepts in the Situation with explicit context hierarchy should be regarded as information entities (which are generically dependent continuants) rather than situations or life phases (which are occurrents). Copied from final Observables Model presentation prepared by Kent Spackman and dated December 26, 2014

Identifying allowed observation result values within the Qualifier value hierarchy Currently, many concepts scattered around the Qualifier value hierarchy can be used as allowed values for qualitative (i.e., non-numeric) observation results. Greater clarity could be achieved by one or both of the following: Labeling each allowed value for a qualitative observation result with a semantic tag, such as (observation result value) (qualifier value) Creating a sub-hierarchy of allowed observation result values within the Qualifier value hierarchy could be grouped by a common ancestor.

Suggested modeling options A separate observation result hierarchy Findings as observation results Expanding the existing Clinical finding hierarchy Suggested modeling options

Option 1: Refactor existing attributes into a separate Observation result hierarchy From Clinical finding hierarchy To Observation result hierarchy INTERPRETS INTERPRETS HAS INTERPRETATION HAS INTERPRETATION / HAS VALUE / HAS RESULT From SWEC hierarchy ASSOCIATED FINDING ASSOCIATED PROCEDURE IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT FINDING CONTEXT PROCEDURE CONTEXT SUBJECT RELATIONSHIP CONTEXT SUBJECT RELATIONSHIP CONTEXT TEMPORAL CONTEXT TEMPORAL CONTEXT

Option 1 Example: Presence or absence of dot-blot hemorrhage Presence/absence of retinal lesion by ophthalmoscopy (observable entity) |Observable entity|: |property type| = |presence-absence status (property) (qualifier value)|, |inheres in| = 52988006 |Lesion (morphologic abnormality)|, |inherent location| = 5665001 |Retinal structure (body structure)|, |using device| = 309640002 |Ophthalmoscope (physical object)| Dot-blot hemorrhage present (observation result) |Observation result|: |is about / refers to / has observation context| = 247133006 |Retinal dot hemorrhage (finding)|, |interprets| = |Presence/absence of retinal lesion by ophthalmoscopy (observable entity)|, |has interpretation / has value / has result| = |Present (observation result value) (qualifier value)

Option 1: Pros and cons Pros Cons Clean ontological separation among clinical entities, features of clinical entities (observables), and information entities (observation results) Situation with explicit context concept could be consolidated into an observation result hierarchy Cons Requires introduction of a new top-level hierarchy Requires “splitting” the existing Clinical finding hierarchy Default contexts are problematic (see next slide)

The problem of default contexts Default contexts are arguably problematic because they are really implied observation results, which makes it difficult to maintain a clear distinction between information entities and the clinical entities to which they refer. A possible solution is to create a reference set that “reifies” default observation results by providing explicit values for the relevant attributes: INTERPRETS HAS INTERPRETATION / HAS VALUE / HAS RESULT SUBJECT RELATIONSHIP CONTEXT TEMPORAL CONTEXT

Option 2: Same as Option 1, but assert that the phrase Clinical finding is simply another name for the phrase Observation result. Existing Clinical finding hierarchy is renamed to Clinical life phase or Clinical entity New Observation result hierarchy is renamed to Clinical finding INTERPRETS INTERPRETS HAS INTERPRETATION HAS INTERPRETATION / HAS VALUE / HAS RESULT From SWEC hierarchy ASSOCIATED FINDING ASSOCIATED PROCEDURE IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT FINDING CONTEXT PROCEDURE CONTEXT SUBJECT RELATIONSHIP CONTEXT SUBJECT RELATIONSHIP CONTEXT TEMPORAL CONTEXT TEMPORAL CONTEXT

Option 2 Example: Presence or absence of dot-blot hemorrhage Presence/absence of retinal lesion by ophthalmoscopy (observable entity) Same definition as for Option 1 Dot-blot hemorrhage present (finding) Note reference to concept in a different hierarchy |Clinical finding|: |is about / refers to / has context| = |Retinal dot hemorrhage (clinical life phase / clinical entity)| |interprets| = |Presence/absence of retinal lesion by ophthalmoscopy (observable entity)| |has interpretation / has value / has result| = |Present (observation result value) (qualifier value)

Option 2: Pros and cons Same pros and cons as Option 1, because only the names have changed. Additional cons: Users may be confused by renaming the existing Clinical finding hierarchy to Clinical life phase or Clinical entity after moving concepts with INTERPRETS or HAS INTERPRETATION attributes into the new Clinical finding (a.k.a. Observation result) hierarchy Observation results about procedures would need to be represented as “clinical findings about procedures.”

Option 3: Put all observation results, including SWEC concepts, in the current Clinical finding hierarchy with different attribute sets Clinical life phase / Clinical entity attribute set Observation result attribute set After Associated morphology Associated with Causative agent Clinical course Due to Episodicity Finding informer Finding method Finding site Occurrence Pathological process Severity Interprets Has interpretation/ Has value / Has result Context attribute set Subject relationship context Temporal context

Option 3 Example: Presence or absence of dot-blot hemorrhage Presence/absence of retinal lesion by ophthalmoscopy (observable entity) Same definition as for Options 1 and 2 247133006 |Retinal dot hemorrhage (finding)| Most proximal primitive (in this case) |Clinical finding|: { |associated morphology| = 50960005 |Hemorrhage (morphologic abnormality)|, |finding site| = 5665001 |Retinal structure (body structure)| } |interprets| = |Presence/absence of retinal lesion by ophthalmoscopy (observable entity)|, |has interpretation / has value / has result| = |Present (observation result value) (qualifier value), |subject relationship context| = 410604004 |Subject of record (person)|, |temporal context| = 410512000 |Current or specified time (qualifier value)| The last four attributes show how the default context could potentially be made explicit for clinical findings

Option 3: Pros and cons Pros Cons No new or renamed hierarchies are required. No need for an IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT attribute because its values are implied. Default contexts (for clinical findings) could be made explicit, if desired, without introducing new concepts. Cons Reduced ontological clarity because information entities (observation results) and the clinical entities that they “are about” reside in the same hierarchy. Support for nesting (with OWL expressions representing “anonymous concepts”) may eventually be needed to clarify meanings precisely.

Open questions and summary of suggestions Acceptability of possible changes Property type for presence observables Clear identification of allowed observation result values Additional context for observation results Distinctions based on required property types Open questions and summary of suggestions

Questions and suggestions (1) Question: How important is it to distinguish between clinical entities and information entities in SNOMED CT? Questions: How receptive are current SNOMED CT users likely to be toward: Introducing a new top-level hierarchy for observation results and splitting the existing Clinical finding hierarchy? Deleting the current Situation with explicit context hierarchy and moving the concepts to a new observation results hierarchy?

Questions and suggestions (2) Suggestion: All presence observables should be assigned a PROPERTY TYPE value of Status (property) qualifier value or a subtype such as Presence-absence status (property) (qualifier value). This should make it possible to require a property type for all observable entity concepts and thereby make it easier to distinguish observable entities from clinical life phases / clinical entitles / clinical findings.

Questions and suggestions (3) Suggestion: All allowed (non-numeric) observation result values in the Qualifier value hierarchy should be identified by a semantic tag such as (observation result value) and/or by being grouped beneath a primitive Allowed observation result value (qualifier value) concept.

Questions and suggestions (4) Suggestion: In addition to providing a value for the feature represented by an observable entity, an observation result should have an optional attribute that allows it to refer to a different entity that provides additional context for the observation. This would presumably allow the values of the PROPERTY TYPE attribute to be fairly general because an IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT attribute could have a more specific value, as shown in the examples.

Questions and suggestions (5) Suggestion: Consider the following proposed distinctions, based on required attribute types: An observable entity represents a feature of an entity and must therefore always have a PROPERTY TYPE attribute. An observation result INTERPRETS an observable entity and has a value (as specified by a HAS INTERPRETATION / HAS VALUE / HAS RESULT attribute). Thus, both of these attributes must be present if a concept is to be considered an observation result. An observation result may have any of the following optional attributes: IS ABOUT / REFERS TO / HAS OBSERVATION CONTEXT SUBJECT RELATIONSHIP CONTEXT TEMPORAL CONTEXT

Questions and suggestions (6) The word “finding” is completely synonymous with the phrase “observation result.” Consequently, the rules for an observation result must also apply to anything called a “finding.” A disorder or diagnosis is a clinical entity that can be experienced during a phase of a patient’s life, independent of any observation that may be made. A “pure” disorder or diagnosis should not have an INTERPRETS or a HAS INTERPRETATION / HAS VALUE / HAS RESULT attribute. A disorder or diagnosis can be transformed into an observation result or finding by adding these attributes explicitly or implicitly (i.e. by default).

Questions and suggestions (7) Question: When does it make sense to give a name to the “observation procedure” part of a fully defined observable entity concept so that it can be reused (as opposed to repeatedly specifying the same set of attributes)?